From crossfire-devel at archives.real-time.com Mon Dec 1 02:47:53 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:44 2005 Subject: [CF-Devel] Bug: dragon claws attack Message-ID: > Character file? > > It's hard to fix this without knowing whether the problem is that the > character has actually lost those attacktypes, or if perceive self just isn't > showing them properly. Hum it's on crossfire.metalforge.net, so I can't access it directly (name is 'Kaori'). But as far as I remember, ever since I got fire claws (level 6 or 11, not sure) then electric, then poison, I never saw _any_ message like 'melting', 'chilling', and so on. I killed quite many monsters yesterday, not any single was poisoned - yet I'm supposed to have poisoned claws. Nicolas 'Ryo' Acc?dez au courrier ?lectronique de La Poste : www.laposte.net ; 3615 LAPOSTENET (0,34?/mn) ; t?l : 08 92 68 13 50 (0,34?/mn) _______________________________________________ crossfire-devel mailing 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 Dec 1 12:21:16 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:44 2005 Subject: [CF-Devel] A few glitches In-Reply-To: <3FCAC9B8.5000207@sonic.net> Message-ID: On 01-Dec-03 Mark Wedel wrote: > But looking at the code, it would seem the same thing would happen if you > hit > the doors with arrows, or any other range attack - the spring attack code > just > takes the trap and puts it where the plaeyr is, which is certainly a bug. The way it's doing it is probably a bug. But perhaps a high level fireball rune should "shoot back". --- Tim Rightnour NetBSD: Free multi-architecture OS http://www.netbsd.org/ NetBSD supported hardware database: http://mail-index.netbsd.org/cgi-bin/hw.cgi _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Mon Dec 1 23:06:00 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:44 2005 Subject: [CF-Devel] A few glitches In-Reply-To: References: Message-ID: <3FCC1DB8.3030000@sonic.net> Tim Rightnour wrote: > On 01-Dec-03 Mark Wedel wrote: > >> But looking at the code, it would seem the same thing would happen if you >>hit >>the doors with arrows, or any other range attack - the spring attack code >>just >>takes the trap and puts it where the plaeyr is, which is certainly a bug. > > > The way it's doing it is probably a bug. But perhaps a high level fireball > rune should "shoot back". I thought of that. However, most traps are only 1 use (eg, you get hit by the rune or whatever, but its then gone). So one would need a fair bit of logic to figure that all out. If players decide to use bows to open doors safely, so be it, but that probably isn't that big an issue (after all, in many maps, there are several doors connected - you could search, find the ones that don't have traps, and open those - as the other doors with traps do open, the trap disappears anyways). If one really cared about some of this when designing a map, you could always put the rune/trap on the floor of the space that has the door. Thus, even if the door was destroyed with arrows, you'd still set the trap off as you walked over the space. _______________________________________________ crossfire-devel mailing 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 Dec 2 13:00:42 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:44 2005 Subject: [CF-Devel] Code documentation, output example Message-ID: <3FCCE15A.5030301@laposte.net> Hello. Just committed a few updates on comments in the socket/ subdir. Before going on with other files, I just wonder what people think of the result :) So attached is a sample generated HTML page, and the stylesheet it uses. Also for curious masses the doxygen settings file I used to generate the doc. The style itself can probably be changed by doxygen settings, as well as the kind of info generated. Note: I did not update ChangeLog as I only changed comments. Nicolas 'Ryo' -------------- next part -------------- A non-text attachment was scrubbed... Name: example.tar.gz Type: application/x-gzip-compressed Size: 7909 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20031202/b47d3184/example.tar.bin -------------- next part -------------- _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Wed Dec 3 01:19:26 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:44 2005 Subject: [CF-Devel] Bug: dragon claws attack In-Reply-To: <3FCA2854.8050504@laposte.net> References: <3FCA2854.8050504@laposte.net> Message-ID: On Sun, 30 Nov 2003, Nicolas Weeger wrote: > Just noticed, dragon don't have anymore fire/electric/cold/poison > claws... I can confirm this bug: server/player.c line 3134: else if (item->type == SKILL) { if (item->subtype == SK_CLAWING && (skop=find_skill_by_name(who,item->skill))!=NULL) The server expects type == 42(skill) and subtype == 31(clawing). But the type for elemental claws in the arch is set to 74(skill tool) and no subtype. Thus it can be fixed by either changing the code or the arch. I changed the arches and tested it against a monster made immune to physical damage. Although I can kill it now (ergo: I did get the elem. dam.), I still do not get "melting","chilling" messages. This is because the function attack_message in server/attack.c does not consider attack-types if one uses clawing,punching or karate. This is IMO wrong. If e.g. punching while possessed with Sorig, I ought to get "electricity" messages. _______________________________________________ crossfire-devel mailing 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 Dec 3 02:18:37 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:45 2005 Subject: [CF-Devel] Bug: dragon claws attack In-Reply-To: Message-ID: On 03-Dec-03 Bernd Edler wrote: > This is because the function attack_message in server/attack.c does > not consider attack-types if one uses clawing,punching or karate. > This is IMO wrong. > If e.g. punching while possessed with Sorig, I ought to get "electricity" > messages When I designed the attack_message stuff, my primary goal was eye candy. To that end, I usually picked the attack type that would yeild the most interesting damage messages (ie, in the order I judged had the coolest messages). It also does a fallback, so if you were to attack with fire and cold, and the monster was immune to cold, you would get the fire message, even if "cold" was a "more interesting" message. Now, if the monsters are immune to physical, and you get karate messages rather than fire ones, thats probably not ideal. As for your sorig example.. it's mostly a matter of asthetics for that. The way I did the clawing and karate was a bit of a hack, because they are both physical damage. It could probably be fiddled with. --- Tim Rightnour NetBSD: Free multi-architecture OS http://www.netbsd.org/ NetBSD supported hardware database: http://mail-index.netbsd.org/cgi-bin/hw.cgi _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Thu Dec 4 12:26:30 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:45 2005 Subject: [CF-Devel] Item merging bug on crossfire.metalforge.net Message-ID: <3FCF7C56.5000806@laposte.net> Hello. On cf.mf.net, i have diamonds of exceptional value that won't merge. Dumping'em shows that some have a value of 10000 while the others have a value of 40000. Value is not affected by number of items, is it? I have respectively 12 & 4 of those diamonds. 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 Thu Dec 4 12:41:39 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:45 2005 Subject: [CF-Devel] Item merging bug on crossfire.metalforge.net In-Reply-To: <3FCF7C56.5000806@laposte.net> References: <3FCF7C56.5000806@laposte.net> Message-ID: <1070563299.18445.51.camel@d5110227.lss.emc.com> On Thu, 2003-12-04 at 13:26, Nicolas Weeger wrote: > On cf.mf.net, i have diamonds of exceptional value that won't merge. > Dumping'em shows that some have a value of 10000 while the others have a value > of 40000. > Value is not affected by number of items, is it? I have respectively 12 & 4 of > those diamonds. I've seen things like that before. My impression is that this is because you found some on a map that had a hard-coded value, which should probably be considered a map bug. Someone want to grep through the maps to find the offending diamonds? --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 Thu Dec 4 18:49:16 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:45 2005 Subject: [CF-Devel] Item merging bug on crossfire.metalforge.net References: <3FCF7C56.5000806@laposte.net> <1070563299.18445.51.camel@d5110227.lss.emc.com> Message-ID: <001101c3bac9$bf70a810$1a2406d5@KOLF2> > I've seen things like that before. My impression is that this is > because you found some on a map that had a hard-coded value, which > should probably be considered a map bug. Someone want to grep through > the maps to find the offending diamonds? The diamonds in raffle1 are hardcoded, and they don't stack with the default diamonds. D. K. _______________________________________________ crossfire-devel mailing 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 Dec 5 09:18:22 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:45 2005 Subject: [CF-Devel] Flying monster stealing patch In-Reply-To: <3FBB2229.1020006@sonic.net> References: <20031117133402.GA11974@crystal> <3FB9CCF7.8080903@sonic.net> <20031118182448.GC27656@crystal> <3FBB2229.1020006@sonic.net> Message-ID: <20031205151821.GA21986@crystal> On Tue, Nov 18, 2003 at 11:56:25PM -0800, Mark Wedel wrote: > H. S. Teoh wrote: > >On Mon, Nov 17, 2003 at 11:40:39PM -0800, Mark Wedel wrote: > > >>Check to see if tmp->env changes - if so, the object was stolen. > >>This means storing the old ->env field away. If that succeeds, then > >>send the esrv_del_item with the tag that was stored away. > > > > > >Given that I've changed pick_up() to return a true/false value indicating > >whether the pickup was successful, I probably don't need this anymore, > >right? > > Correct. > > > > >Also, do you think it makes more sense to send esrv_del_item *inside* > >pick_up() or pick_up_item() instead? It would seem that fixing it once in > >pick_up() will save us the headache of fixing the 50 other places where > >pick_up() is called, which might have to do the same thing. (I don't know > >if there's any other place which needs to do this right now, but it's > >conceivable to happen in the future.) > > Well, using pick_up in the stealing code is really a pretty bad hack. > > pick_up was obviously originally designed/coded to pick up items off the > floor and move it to a creatures inventory. Thus, things like checking for > fly, no_pick, etc. And for that case, it seems to work fine. > > The expectation for pick_up() that the object may be in another creatures > inventory is odd OK, so should pick_up() check to see if the object is in another creature's inventory, and do something different in that case? > I suppose it wouldn't hurt for pick_up to send the appropriate > client/server command. If it detects that the object happens to be in another creature's inventory, I suppose. [snip] > >Hmm, that's true. So then the question is, is it possible to have a flying > >monster that steals, and how would I do it? > > Well, as said above, pick_up was originally designed for picking things up > from the ground, where such a change made sense. > > The best solution would be to pass another flag into pick_up() which could > say to let flying creatures pick up the object. Or the simpler, but > slightly more dangerous way, would be to clear the flag_flying before > calling pick_up, and then re-setting it afterwards. But calling pick_up() > may call fix_player() or otherwise update stats, which makes that not quite > such a good method. [snip] Perhaps the most correct way would be for pick_up() to behave differently (eg. skip the is_flying check) if the object being picked up is in another creature's inventory? T -- Mediocrity has been pushed to extremes. _______________________________________________ crossfire-devel mailing 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 Dec 5 16:25:39 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:45 2005 Subject: [CF-Devel] Map bug: /scorn/oldcity/end Message-ID: <3FD105E3.2080902@laposte.net> Hello. (posted to cf-maps & cf-devel) A player just showed me, on crossfire.metalforge.net, a nice bug in the /scorn/oldcity/end map. At the end are 3 gates, after a bridge. Those gates are opened by a lever somewhere else in the map, and you supposedly need to grab a few items to access the lever (from what the player told me, i haven't done personally the quest). Except there's a nice issue: if you go just west of the door, use magic missile, you can _destroy_ walls around the door. Those walls are 'rock' as arch, 'stone' as material. A few have 'no_magic' flags... but missiles cross that, apparently. If you fire south a few missiles, you'll destroy not the first wall, but the second. So missiles _cross_ walls! Also, having destroyed the 2nd, you can push the first wall south, and enter the zone behind the door (walls have the 'can_roll' flag). So simply with magic missile you can cross the door, without bothering to activate the lever... Nicolas 'Ryo' _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Sat Dec 6 03:21:58 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:45 2005 Subject: [CF-Devel] Patch: some warning cleaning under Win32 Message-ID: <3FD19FB6.5020408@laposte.net> Hello. Here's a small patch for socket/image.c to clean some compilation warnings under W32. Changed a few variables from int to char/short, and explicitely casted a (short + 1) to short (as that gets promoted to int & sent to a function expecting a short) I think those changes are harmless, since incrimed variables were used as short in the first place. Changing'em just makes that official :) Nicolas 'Ryo' -------------- next part -------------- Index: socket/image.c =================================================================== RCS file: /cvsroot/crossfire/crossfire/socket/image.c,v retrieving revision 1.4 diff -u -r1.4 image.c --- socket/image.c 2 Dec 2003 18:51:44 -0000 1.4 +++ socket/image.c 6 Dec 2003 09:19:53 -0000 @@ -325,7 +325,7 @@ void esrv_send_face(NewSocket *ns,short face_num, int nocache) { SockList sl; - int fallback; + char fallback; if (face_num < 0 || face_num >= nrofpixmaps) { LOG(llevError,"esrv_send_face (%d) out of bounds??\n",face_num); @@ -414,7 +414,9 @@ */ void send_image_sums(NewSocket *ns, char *params) { - int start, stop, qq,i; + int start, stop; + short i; + char qq; char *cp, buf[MAX_BUF]; SockList sl; @@ -443,7 +445,7 @@ SockList_AddChar(&sl, qq); qq = strlen(new_faces[i].name); - SockList_AddChar(&sl, qq + 1); + SockList_AddChar(&sl, ( char )( qq + 1 )); strcpy(sl.buf + sl.len, new_faces[i].name); sl.len += qq; SockList_AddChar(&sl, 0); -------------- next part -------------- _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Sat Dec 6 12:57:26 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:45 2005 Subject: [CF-Devel] Patch: some warning cleaning under Win32 In-Reply-To: <3FD19FB6.5020408@laposte.net> References: <3FD19FB6.5020408@laposte.net> Message-ID: <3FD22696.5020908@laposte.net> Here's another patch to remove some compilation warnings (for Win32 at least). (note: this patch completes and replaces the previous one) Core of changes is type fixing. When a socket function was used to write data, I either explicitly casted the argument(s) to the matching type (ie SockList_AddChar( &sl, ( char )x ) where x is an int) or fixed the argument's type by changing its definition (ie changing int x to char x). Also fixed a few signed/unsigned mismatches. I also changed the sounds functions prototypes, 'cause x, y (relative coordinates) are sent as char anyway so no need to give int, same for soundnum (int sent as short) Finally, tweaked global.h, the Win32 specific part, and also changed freearr_x / freearr_y to be short[ ] instead of int[ ]. Consequently common/object.c is patched too for the actual implementation of those variables :) Nicolas 'Ryo' -------------- next part -------------- A non-text attachment was scrubbed... Name: warning1.patch.gz Type: application/x-gzip-compressed Size: 3814 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20031206/7cca54fc/warning1.patch.bin -------------- next part -------------- _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Sat Dec 6 19:17:25 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:45 2005 Subject: [CF-Devel] New fast map-rendering scripts Message-ID: <20031207011725.GA19599@crystal> Hi all, Based on previous feedback, I've created a new script that processes crossfire.0 (or crossfire.1, although that set is not complete enough and may result in large "holes") to create a color map for each face in the game. This color map can then be used with the fastmap.pl script (also updated to add support for this feature) so that it produces a bigworld map based on actual image colors. There are still a few issues surrounding transparency, etc. (rivers show up black because they are the first object on the square, and ImageMagick converts its transparent pixels into black). However, I thought I'd post the scripts now so people could play with it first. Quick-n-dirty usage outline: makecmap.pl crossfire/lib/crossfire.0 colormap.0 fastmap.pl --colormap=colormap.0 --outfile=world.png ... As usual, --help will give detailed option descriptions in both scripts. T -- "A man's wife has more power over him than the state has." -- Ralph Emerson -------------- next part -------------- A non-text attachment was scrubbed... Name: fastmap.pl Type: application/x-perl Size: 13800 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20031206/d7f32ef0/fastmap.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: makecmap.pl Type: application/x-perl Size: 3075 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20031206/d7f32ef0/makecmap.bin -------------- next part -------------- _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Sun Dec 7 07:27:14 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:45 2005 Subject: [CF-Devel] Compilation problems Message-ID: <87ekvgzrkd.fsf@phiwumbda.org> Hey ho. Sorry if this is the wrong list. I posted this question to the crossfire-list, but I received no answers at all. In fact, I've seen no activity on that list for a little while. Let me know to bugger off if this is the wrong place. I want to install crossfire on my Slackware 9.1 machine. When I compile, I see two errors, the second of which is fatal. root@phiwumbda:/usr/src/games/crossfire-client-1.0.0# make depend g -O2 -DALSA_SOUND -DNEW_SOUND -DBINDIR='"/usr/local/bin/"' -Wall -I. -- client.c commands.c init.c item.c metaserver.c misc.c newsocket.c player.c sound.c x11.c cfsndserv.c misc.c make: g: Command not found make: [depend] Error 127 (ignored) This error evidently occurs because of the line "DEPEND=" (DEPEND is set to the null string). I have ignored this error and tried to make anyway. Here's the result. root@phiwumbda:/usr/src/games/crossfire-client-1.0.0# make gcc -o gcfclient client.o commands.o init.o item.o metaserver.o misc.o newsocket.o player.o sound.o gx11.o -lm -lXpm -L/usr/lib -L/usr/X11R6/lib -lgtk -lgdk -rdynamic -lgmodule -lglib -ldl -lXext -lX11 -lm client.o(.text+0x118): In function `DoClient': /usr/src/games/crossfire-client-1.0.0/client.c:95: undefined reference to `errno' gx11.o(.text+0x1f7): In function `do_network': /usr/src/games/crossfire-client-1.0.0/gx11.c:513: undefined reference to `errno' collect2: ld returned 1 exit status make: *** [gcfclient] Error 1 Note that I have no PNG support, despite the fact that this is a new distribution with a recent libpng installed (leastways, I think it's recent). Installing the RPMs just give me segmentation faults, so I think building from source is the way to go. But, now what? Thanks. -- "We want a single platform. We're trying to get there using the carrot, or blackmail, or rewards, or whatever you call it." -- Madison, WI, superintendent Rainwater grasps subtlety in the operating system wars. _______________________________________________ crossfire-devel mailing 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 Dec 7 08:56:18 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:46 2005 Subject: [CF-Devel] Compilation problems In-Reply-To: <87ekvgzrkd.fsf@phiwumbda.org> References: <87ekvgzrkd.fsf@phiwumbda.org> Message-ID: <200312071556.41793.tchize@myrealbox.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Could you tell us which version of crossfire client your tried to compile? According to your logs, you are trying to compile and install crossfire client version 1.0.0 which is more than 2 year old, you should try downloading and installing crossfire client version 1.6.0 (source) or 1.5.0 (rpm) available there http://sourceforge.net/project/showfiles.php?group_id=13833&release_id=190031 If you were already compiling a recent vrsion, could you dump us , the output of configure and the complete output of make (an error at linking time mean a warning during the compilation of a file , probably a header not found) thank you. Le Dimanche 7 D?cembre 2003 14:27, Jesse F. Hughes a ?crit : > Hey ho. > > Sorry if this is the wrong list. I posted this question to the > crossfire-list, but I received no answers at all. In fact, I've seen > no activity on that list for a little while. Let me know to bugger > off if this is the wrong place. > > I want to install crossfire on my Slackware 9.1 machine. When I > compile, I see two errors, the second of which is fatal. > > root@phiwumbda:/usr/src/games/crossfire-client-1.0.0# make depend > g -O2 -DALSA_SOUND -DNEW_SOUND -DBINDIR='"/usr/local/bin/"' -Wall -I. > -- client.c commands.c init.c item.c metaserver.c misc.c newsocket.c > player.c sound.c x11.c cfsndserv.c misc.c make: g: Command not found > make: [depend] Error 127 (ignored) > > This error evidently occurs because of the line "DEPEND=" (DEPEND is > set to the null string). > > I have ignored this error and tried to make anyway. Here's the > result. > > root@phiwumbda:/usr/src/games/crossfire-client-1.0.0# make > gcc -o gcfclient client.o commands.o init.o item.o metaserver.o misc.o > newsocket.o player.o sound.o gx11.o -lm -lXpm -L/usr/lib > -L/usr/X11R6/lib -lgtk -lgdk -rdynamic -lgmodule -lglib -ldl -lXext -lX11 > -lm client.o(.text+0x118): In function `DoClient': > /usr/src/games/crossfire-client-1.0.0/client.c:95: undefined reference to > `errno' gx11.o(.text+0x1f7): In function `do_network': > /usr/src/games/crossfire-client-1.0.0/gx11.c:513: undefined reference to > `errno' collect2: ld returned 1 exit status > make: *** [gcfclient] Error 1 > > Note that I have no PNG support, despite the fact that this is a new > distribution with a recent libpng installed (leastways, I think it's > recent). > > Installing the RPMs just give me segmentation faults, so I think > building from source is the way to go. But, now what? > > Thanks. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/0z+YHHGOa1Q2wXwRAtzDAJ0cHLGLSVKG2NvUU5OsYfSTEQ9G7ACfbDRd HeehTQcEjsTC2kB3uYNtAW4= =IKoc -----END PGP SIGNATURE----- _______________________________________________ crossfire-devel mailing 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 Dec 7 09:58:16 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:46 2005 Subject: [CF-Devel] Compilation problems [Never mind] In-Reply-To: <87ekvgzrkd.fsf@phiwumbda.org> (Jesse F. Hughes's message of "Sun, 07 Dec 2003 14:27:14 +0100") References: <87ekvgzrkd.fsf@phiwumbda.org> Message-ID: <87smjwy607.fsf@phiwumbda.org> jesse@phiwumbda.org (Jesse F. Hughes) writes: > Hey ho. > > Sorry if this is the wrong list. I posted this question to the > crossfire-list, but I received no answers at all. In fact, I've seen > no activity on that list for a little while. Let me know to bugger > off if this is the wrong place. I seem to have downloaded a rather old client. The new client compiled with few problems (an odd error regard the sound system, easily fixed). -- Jesse Hughes "[I]t's the damndest thing. There's something wrong with every last one of you, and I *never* thought that was a possibility. But now I feel it's the only reasonable conclusion." --JSH sees some sorta light _______________________________________________ crossfire-devel mailing 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 Dec 7 10:07:23 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:46 2005 Subject: [CF-Devel] Compilation problems In-Reply-To: <200312071556.41793.tchize@myrealbox.com> (tchize@myrealbox.com's message of "Sun, 7 Dec 2003 15:56:18 +0100") References: <87ekvgzrkd.fsf@phiwumbda.org> <200312071556.41793.tchize@myrealbox.com> Message-ID: <87ptf0y5l0.fsf@phiwumbda.org> tchize writes: > Could you tell us which version of crossfire client your tried to compile? > > According to your logs, you are trying to compile and install > crossfire client version 1.0.0 which is more than 2 year old, you > should try downloading and installing crossfire client version 1.6.0 > (source) or 1.5.0 (rpm) available there You're absolutely right. Somehow, I got hold of an old version. I must've clicked on the wrong link a couple of days ago. I'm up-and-running now. Thanks. -- Jesse F. Hughes "Mathematicians don't fit in with a consistent view, unless you accept that to a strangely large extent they are acting under the influence of something very powerful, dark, and negative." -- James S. Harris _______________________________________________ crossfire-devel mailing 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 Dec 7 22:18:53 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:46 2005 Subject: [CF-Devel] /share/settings addition, destroy_items variable Message-ID: <200312072218.AA216138138@mail.smempire.org> Here's the patch--this should help alleviate the problem of key items burning up if the server admin allows it. Coded at the request of 66.6% of my server's 3 players. Running on my Win32 server atm. /server/attack.c 141c141,143 < { --- > { > if (settings.destroy_items == FALSE) > return; /include/config.h 135c135,136 < #define SET_FRIENDLY_FIRE 5 --- > #define SET_FRIENDLY_FIRE 5 > #define DESTROY_ITEMS TRUE /server/init.c 585a586,594 > } else if (!strcasecmp(buf,"destroy_items")) { > if (!strcasecmp(cp,"on") || !strcasecmp(cp,"true")) { > settings.destroy_items=TRUE; > } else if (!strcasecmp(cp,"off") || !strcasecmp(cp,"false")) { > settings.destroy_items=FALSE; > } else { > LOG(llevError,"load_settings: Unkown value for destroy_items: %s\n", > cp); > } /include/global.h 317c317,318 < uint16 set_friendly_fire; /* Percent of damage done by peaceful player vs player damage */ --- > uint16 set_friendly_fire; /* Percent of damage done by peaceful player vs player damage */ > uint8 destroy_items; /* do items burn up/turn into ice cubes? key items at stake */ -- _____ Stwong -- Tutorial Writer, Programmer Sovereign Modding Empire http://www.smempire.org/ -- _______________________________________________ crossfire-devel mailing 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 Dec 8 01:37:22 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:46 2005 Subject: [CF-Devel] /share/settings addition, destroy_items variable In-Reply-To: <200312072218.AA216138138@mail.smempire.org> References: <200312072218.AA216138138@mail.smempire.org> Message-ID: <3FD42A32.4030502@sonic.net> Stwong wrote: > Here's the patch--this should help alleviate the problem of key items burning up if the server admin allows it. Coded at the request of 66.6% of my server's 3 players. Running on my Win32 server atm. > I don't mind the patch all that much - it is minor, and is a configurable option. However, this now makes it so that no items are ever destroyed - this will likely result in shifting even more money/power to the player. Ideally, any item that is needed for a quest should be modified so that they are indestructible. _______________________________________________ crossfire-devel mailing 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 Dec 8 11:08:26 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:46 2005 Subject: =?iso-8859-1?Q?Re:_Re:_[CF-Devel]_/share/settings_addition, _destroy_items_variable?= Message-ID: > > Here's the patch--this should help alleviate the problem of key items burning up if the server admin allows it. Coded at the request of 66.6% of my server's 3 players. Running on my Win32 server atm. > > > > I don't mind the patch all that much - it is minor, and is a configurable option. > > However, this now makes it so that no items are ever destroyed - this will > likely result in shifting even more money/power to the player. > > Ideally, any item that is needed for a quest should be modified so that they > are indestructible. That's what I thought the behaviour should be. I don't like this patch as it confuses the issue and takes away one of the principles of treasure generation. Many maps are set up so that if you use a lot of fireballs or whatever you get less treasure. This allows mapmakers to create more flexable rewards. If an item is supposed to be indestructable it should be set that way on a per item basis (is what materials are for), not with a global server setting. _______________________________________________ crossfire-devel mailing 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 Dec 9 23:44:30 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:46 2005 Subject: [CF-Devel] Patch: some warning cleaning under Win32 In-Reply-To: <3FD22696.5020908@laposte.net> References: <3FD19FB6.5020408@laposte.net> <3FD22696.5020908@laposte.net> Message-ID: <3FD6B2BE.50203@sonic.net> Nicolas Weeger wrote: > Here's another patch to remove some compilation warnings (for Win32 at > least). > (note: this patch completes and replaces the previous one) please don't compress/gzip/whatever small attachments - it makes it harder to just quickly browse the change. > > Core of changes is type fixing. When a socket function was used to write > data, I either explicitly casted the argument(s) to the matching type > (ie SockList_AddChar( &sl, ( char )x ) where x is an int) or fixed the > argument's type by changing its definition (ie changing int x to char x). > Also fixed a few signed/unsigned mismatches. > > I also changed the sounds functions prototypes, 'cause x, y (relative > coordinates) are sent as char anyway so no need to give int, same for > soundnum (int sent as short) Changing any data type to 'char' is sure to cause problems. This is because I don't believe the data type of 'char' is defined as either signed or unsigned. That is to say on some systems, this may be a signed value, while on other systems, it would be an unsigned value. Thus, in the case where you mention in sound play, that may break things on systems where chars are unsigned (passing in -1 will not result in the value you want). So basic moral is never use 'char' for anything but strings. Use the uint8/sint8 types instead. This applies to other code where you've changed some other type to a char. I'm considered about the stat code, as another example. Many of the stat numbers are now above 127 - assigning those a value greater than 127 may not have the desired 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 Tue Dec 9 23:56:50 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:46 2005 Subject: [CF-Devel] Flying monster stealing patch In-Reply-To: <20031205151821.GA21986@crystal> References: <20031117133402.GA11974@crystal> <3FB9CCF7.8080903@sonic.net> <20031118182448.GC27656@crystal> <3FBB2229.1020006@sonic.net> <20031205151821.GA21986@crystal> Message-ID: <3FD6B5A2.9010206@sonic.net> H. S. Teoh wrote: > On Tue, Nov 18, 2003 at 11:56:25PM -0800, Mark Wedel wrote: > > > OK, so should pick_up() check to see if the object is in another > creature's inventory, and do something different in that case? Well, pick_up() should really be split apart. Currently, there is a can_pick() function which says if an object can be picked up. What you really want is the code from pick_up() that does the container handling - make a new function like move_item_into_players_inv() (shorter name may be nice). Change pick_up() to use that for that piece of code also. IMO, pick_up shouldn't be designed to handle every case thrown at it - it's design is to handle players picking up objects on the ground. So handling special cases for stealing, or other objects that put something into the players inventory shouldn't be using pick_up(). And as said before, at one point, this wasn't a case, because the steal code did just use remove_ob and insert_ob functions. However, more I look at pick_up, the more it probably needs to be rewritten (anythign with a goto is questionable - in this case in particular, as it would seem almost everywhere the goto is called doesn't need the processing afterward) So all that said, there should probably be these functions for the code: can_pick (already exists) - is this an object the player can pick up (basic sanity checking based on object flags) can_carry (new function) - can the player carry this object find_sack_for_ob(new function) - finds the environment to insert the object into. with those, pick_up() would become a very basic fucntion, but other functions that want to to inventory handling can now do it properly also. > Perhaps the most correct way would be for pick_up() to behave differently > (eg. skip the is_flying check) if the object being picked up is in another > creature's inventory? As said, pick_up was (IMO) only designed to handle cases where the object is on the ground. It really shouldn't be designed for all those special cases. _______________________________________________ crossfire-devel mailing 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 Dec 10 02:14:11 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:46 2005 Subject: [CF-Devel] Patch: some warning cleaning under Win32 In-Reply-To: <3FD6B2BE.50203@sonic.net> References: <3FD19FB6.5020408@laposte.net> <3FD22696.5020908@laposte.net> <3FD6B2BE.50203@sonic.net> Message-ID: <3FD6D5D3.1090400@laposte.net> > please don't compress/gzip/whatever small attachments - it makes it > harder to just quickly browse the change. Hum I think the patch is around 10k, do you consider that small? (no pun intended, just wondering) > Changing any data type to 'char' is sure to cause problems. > > This is because I don't believe the data type of 'char' is defined as > either signed or unsigned. That is to say on some systems, this may be > a signed value, while on other systems, it would be an unsigned value. > > Thus, in the case where you mention in sound play, that may break > things on systems where chars are unsigned (passing in -1 will not > result in the value you want). So basic moral is never use 'char' for > anything but strings. Use the uint8/sint8 types instead. > > This applies to other code where you've changed some other type to a > char. I'm considered about the stat code, as another example. Many of > the stat numbers are now above 127 - assigning those a value greater > than 127 may not have the desired effects. Ok, I will change to uint8 or sint8 (depending on the use). Apart that mistake on s/uint8, any objection to the patch? 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 Dec 10 13:00:28 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:46 2005 Subject: [CF-Devel] patch: gcc 3.3 infinite loop fixed Message-ID: After a session with ddd, CFLAGS="-g -O1 -Wall -W -pedantic" and even valgrind, i found a lot of minor stuff, and finally the real problem. :) Summary by file: common/item.c The vital fix. Wrong buffer size was used. common/object.c reading uninitialized value (valgrind) include/define.h typo in function safe_strncpy, trailing comma in enum (pedantic) include/global.h c++ style comments include/player.h trailing comma in enum (pedantic) socket/init.c reading uninitialized value (valgrind) Bernd Edler -------------- next part -------------- Index: common/item.c =================================================================== RCS file: /cvsroot/crossfire/crossfire/common/item.c,v retrieving revision 1.38 diff -c -r1.38 item.c *** common/item.c 13 Sep 2003 05:01:27 -0000 1.38 --- common/item.c 10 Dec 2003 18:06:00 -0000 *************** *** 603,617 **** case ROD: if (QUERY_FLAG(op,FLAG_IDENTIFIED)||QUERY_FLAG(op,FLAG_BEEN_APPLIED)) { if(!op->title) { ! safe_strcat(buf," of ", &len, HUGE_BUF); if (op->inv) ! safe_strcat(buf,op->inv->name, &len, HUGE_BUF); else LOG(llevError,"Spellbook %s lacks inventory\n", op->name); } if(op->type != SPELLBOOK) { sprintf(buf2, " (lvl %d)", op->level); ! safe_strcat(buf, buf2, &len, HUGE_BUF); } } break; --- 603,617 ---- case ROD: if (QUERY_FLAG(op,FLAG_IDENTIFIED)||QUERY_FLAG(op,FLAG_BEEN_APPLIED)) { if(!op->title) { ! safe_strcat(buf," of ", &len, MAX_BUF); if (op->inv) ! safe_strcat(buf,op->inv->name, &len, MAX_BUF); else LOG(llevError,"Spellbook %s lacks inventory\n", op->name); } if(op->type != SPELLBOOK) { sprintf(buf2, " (lvl %d)", op->level); ! safe_strcat(buf, buf2, &len, MAX_BUF); } } break; Index: common/object.c =================================================================== RCS file: /cvsroot/crossfire/crossfire/common/object.c,v retrieving revision 1.75 diff -c -r1.75 object.c *** common/object.c 27 Oct 2003 07:24:14 -0000 1.75 --- common/object.c 10 Dec 2003 18:06:04 -0000 *************** *** 510,516 **** if (op->msg!=NULL) FREE_AND_CLEAR_STR(op->msg); if (op->lore!=NULL) FREE_AND_CLEAR_STR(op->lore); if (op->materialname!= NULL) FREE_AND_CLEAR_STR(op->materialname); ! /* Using this memset is a lot easier (and probably faster) * than explicitly clearing the fields. --- 510,517 ---- if (op->msg!=NULL) FREE_AND_CLEAR_STR(op->msg); if (op->lore!=NULL) FREE_AND_CLEAR_STR(op->lore); if (op->materialname!= NULL) FREE_AND_CLEAR_STR(op->materialname); ! op->active_next = NULL; ! op->active_prev = NULL; /* Using this memset is a lot easier (and probably faster) * than explicitly clearing the fields. Index: include/define.h =================================================================== RCS file: /cvsroot/crossfire/crossfire/include/define.h,v retrieving revision 1.69 diff -c -r1.69 define.h *** include/define.h 27 Oct 2003 03:44:33 -0000 1.69 --- include/define.h 10 Dec 2003 18:06:07 -0000 *************** *** 721,727 **** strncpy(dest+*curlen, orig, maxlen-*curlen-1); dest[maxlen-1]=0; *curlen += strlen(orig); ! if (*curlen>(maxlen-1)) *curlen=maxlen=1; } --- 721,727 ---- strncpy(dest+*curlen, orig, maxlen-*curlen-1); dest[maxlen-1]=0; *curlen += strlen(orig); ! if (*curlen>(maxlen-1)) *curlen=maxlen-1; } *************** *** 807,813 **** /* Optional flags, for bitwise or with a basic flag */ AP_NO_MERGE = 16, AP_IGNORE_CURSE = 32, ! AP_PRINT = 64, /* Print what to do, don't actually do it */ /* Note this is supported in all the functions */ }; --- 807,813 ---- /* Optional flags, for bitwise or with a basic flag */ AP_NO_MERGE = 16, AP_IGNORE_CURSE = 32, ! AP_PRINT = 64 /* Print what to do, don't actually do it */ /* Note this is supported in all the functions */ }; Index: include/global.h =================================================================== RCS file: /cvsroot/crossfire/crossfire/include/global.h,v retrieving revision 1.44 diff -c -r1.44 global.h *** include/global.h 13 Sep 2003 05:01:33 -0000 1.44 --- include/global.h 10 Dec 2003 18:06:07 -0000 *************** *** 60,73 **** typedef unsigned short Fontindex; #ifdef WIN32 ! // Python plugin stuff defines SIZEOF_LONG_LONG as 8, and besides __int64 is a 64b type on MSVC... ! // So let's force the typedef typedef unsigned __int64 uint64; typedef signed __int64 sint64; ! // Needed for experience #define atoll _atoi64 ! #else // WIN32 #if SIZEOF_LONG == 8 typedef unsigned long uint64; --- 60,75 ---- typedef unsigned short Fontindex; #ifdef WIN32 ! /* Python plugin stuff defines SIZEOF_LONG_LONG as 8, and besides __int64 is a 64b type on MSVC... ! * So let's force the typedef ! */ typedef unsigned __int64 uint64; typedef signed __int64 sint64; ! /* Needed for experience */ #define atoll _atoi64 ! #else ! /* WIN32 */ #if SIZEOF_LONG == 8 typedef unsigned long uint64; Index: include/player.h =================================================================== RCS file: /cvsroot/crossfire/crossfire/include/player.h,v retrieving revision 1.33 diff -c -r1.33 player.h *** include/player.h 13 Sep 2003 05:01:34 -0000 1.33 --- include/player.h 10 Dec 2003 18:06:08 -0000 *************** *** 72,78 **** typedef enum usekeytype { key_inventory=0, keyrings=1, ! containers=2, } usekeytype; /* This is used to control what to do when we need to unapply --- 72,78 ---- typedef enum usekeytype { key_inventory=0, keyrings=1, ! containers=2 } usekeytype; /* This is used to control what to do when we need to unapply *************** *** 81,87 **** typedef enum unapplymode { unapply_nochoice=0, /* Will unapply objects when there no choice to unapply */ unapply_never=1, /* will not unapply objects automatically */ ! unapply_always=2, /* Will unapply whatever is necessary - this goes beyond */ /* no choice - if there are multiple ojbect of the same type */ /* that need to be unapplied, there is no way for the player */ /* to control which of these will be unapplied. */ --- 81,87 ---- typedef enum unapplymode { unapply_nochoice=0, /* Will unapply objects when there no choice to unapply */ unapply_never=1, /* will not unapply objects automatically */ ! unapply_always=2 /* Will unapply whatever is necessary - this goes beyond */ /* no choice - if there are multiple ojbect of the same type */ /* that need to be unapplied, there is no way for the player */ /* to control which of these will be unapplied. */ Index: socket/init.c =================================================================== RCS file: /cvsroot/crossfire/crossfire/socket/init.c,v retrieving revision 1.30 diff -c -r1.30 init.c *** socket/init.c 13 Sep 2003 05:02:14 -0000 1.30 --- socket/init.c 10 Dec 2003 18:06:17 -0000 *************** *** 67,72 **** --- 67,73 ---- int bufsize=65535; /*Supposed absolute upper limit */ int oldbufsize; int buflen=sizeof(int); + int i; #ifdef WIN32 /* ***WIN32 SOCKET: init win32 non blocking socket */ int temp = 1; *************** *** 113,118 **** --- 114,121 ---- ns->itemcmd = 1; /* Default is version item1 command*/ ns->ext_mapinfos=0; /*extendedmapinfo datas*/ ns->EMI_smooth=0; + ns->look_position=0; + ns->update_look=0; /* we should really do some checking here - if total clients overflows * we need to do something more intelligent, because client id's will start *************** *** 125,131 **** * HandleClient for oldsocketmode without checking the * length of data. */ ! ns->inbuf.buf[0] = 0; memset(&ns->lastmap,0,sizeof(struct Map)); memset(&ns->faces_sent,0,sizeof(ns->faces_sent)); memset(&ns->anims_sent,0,sizeof(ns->anims_sent)); --- 128,135 ---- * HandleClient for oldsocketmode without checking the * length of data. */ ! for (i = 0; iinbuf.buf[i] = 0; memset(&ns->lastmap,0,sizeof(struct Map)); memset(&ns->faces_sent,0,sizeof(ns->faces_sent)); memset(&ns->anims_sent,0,sizeof(ns->anims_sent)); -------------- 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 Dec 10 16:52:36 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:46 2005 Subject: [CF-Devel] patch: gcc 3.3 infinite loop fixed In-Reply-To: References: Message-ID: <3FD7A3B4.4040107@laposte.net> Bernd Edler wrote: > After a session with ddd, CFLAGS="-g -O1 -Wall -W -pedantic" > and even valgrind, i found a lot of minor stuff, and > finally the real problem. :) Haven't actually patched / compiled & tried, but looks ok at reading. The C++-like comments in global.h are not supposed to be seen by Linux, as they are enclosed in #ifdef WIN32 :) But fixing is not bad (i fixed'em in some other patch i submitted) 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 Dec 10 18:05:39 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:46 2005 Subject: [CF-Devel] /share/settings addition, _destroy_items_variable?= Message-ID: <200312101805.AA110887206@mail.smempire.org> ---------- Original Message ---------------------------------- From: Todd Mitchell Reply-To: crossfire-devel@lists.real-time.com Date: Mon, 08 Dec 2003 12:08:26 -0500 > > >> > Here's the patch--this should help alleviate the problem of key items burning up if the server admin allows it. Coded at the request of 66.6% of my server's 3 players. Running on my Win32 server atm. >> > >> >> I don't mind the patch all that much - it is minor, and is a configurable option. >> >> However, this now makes it so that no items are ever destroyed - this will >> likely result in shifting even more money/power to the player. >> >> Ideally, any item that is needed for a quest should be modified so that they >> are indestructible. > >That's what I thought the behaviour should be. I don't like this patch as it confuses the issue and takes away one of the principles of treasure generation. Many maps are set up so that if you use a lot of fireballs or whatever you get less treasure. This allows mapmakers to create more flexable rewards. If an item is supposed to be indestructable it should be set that way on a per item basis (is what materials are for), not with a global server setting. > >_______________________________________________ >crossfire-devel mailing list >crossfire-devel@lists.real-time.com >https://mailman.real-time.com/mailman/listinfo/crossfire-devel > Ideally is the keyword here... in most of the scorn royalty quests, I've had to redo many of them because I burnt the final item. In the farmhouse outside scorn, I've burnt the troll's head... I've destroyed the Special Chalice in oldcity--I don't remember a quest I *haven't* had to do twice due to carelessness... The problem is that, ideally, all important items that shouldn't be able to be sold but are needed for a quest will be invulnerable. However, in practice, many of the mapmakers don't even know how to make an item invincible (set hp to -1 and maxhp to -1) and if they do, either forget to set it for key items, or are too lazy to... Just my opinion, but this idealism doesn't really work. I don't even see it listed as one of the suggestions for mapmaking on real-time... -- _____ Stwong -- Tutorial Writer, Programmer Sovereign Modding Empire http://www.smempire.org/ -- _______________________________________________ crossfire-devel mailing 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 Dec 10 20:59:34 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:46 2005 Subject: [CF-Devel] /share/settings addition, _destroy_items_variable?= In-Reply-To: <200312101805.AA110887206@mail.smempire.org> References: <200312101805.AA110887206@mail.smempire.org> Message-ID: <1071111573.539.63.camel@oberon.Kameria> Previously.... > >> > Here's the patch--this should help alleviate the problem of key items burning up if the server admin allows it. Coded at the request of 66.6% of my server's 3 players. Running on my Win32 server atm. > >> > > >> > >> I don't mind the patch all that much - it is minor, and is a configurable option. > >> > >> However, this now makes it so that no items are ever destroyed - this will > >> likely result in shifting even more money/power to the player. > >> > >> Ideally, any item that is needed for a quest should be modified so that they > >> are indestructible. > > > >That's what I thought the behaviour should be. I don't like this patch as it confuses the issue and takes away one of the principles of treasure generation. Many maps are set up so that if you use a lot of fireballs or whatever you get less treasure. This allows mapmakers to create more flexable rewards. If an item is supposed to be indestructable it should be set that way on a per item basis (is what materials are for), not with a global server setting. On Wed, 2003-12-10 at 19:05, Stwong wrote: > Ideally is the keyword here... in most of the scorn royalty quests, I've had to redo many of them because I burnt the final item. In the farmhouse outside scorn, I've burnt the troll's head... I've destroyed the Special Chalice in oldcity--I don't remember a quest I *haven't* had to do twice due to carelessness... The problem is that, ideally, all important items that shouldn't be able to be sold but are needed for a quest will be invulnerable. However, in practice, many of the mapmakers don't even know how to make an item invincible (set hp to -1 and maxhp to -1) and if they do, either forget to set it for key items, or are too lazy to... > > Just my opinion, but this idealism doesn't really work. I don't even see it listed as one of the suggestions for mapmaking on real-time... I think you are overstating the problem, first even if there are some items that should be indestructable but are not, it is a _very_ small subset of the items which should be destructable. If there are objects vital to a quest that are not purposefully destructable then that can be reported and fixed as a map bug/enhancement by setting hte material type properly (many archetype items like keys are set to do this by default as well for easy map making) But making ALL items invunerable is really an huge overkill. It goes against the material system and overrides all objects that are supposed to be destructable. If this patch does what I think it does and prevents all items from being destroyed by exiting from the save throw check, it will break a lot of maps that depend on items getting destroyed to function correctly. (item gets burnt up releasing a button for example). It also takes away one of largest intentionally negative issues with destructive spells so that the spells become much more usable without the bad side effects of burning up books and other treasure. I can't think of any good reason to ever do this when you can simply set an objects material type to 256 (or leave it out) on those items that need it. If you are burning too much treasure then stop lobbing fireballs all the time, don't prevent items from burning up (well you can do what you like on your own 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 Wed Dec 10 21:53:38 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:46 2005 Subject: [CF-Devel] /share/settings addition, _destroy_items_variable?= In-Reply-To: <200312101805.AA110887206@mail.smempire.org> References: <200312101805.AA110887206@mail.smempire.org> Message-ID: Good point and added.. http://crossfire.real-time.com/guides/map/technical_suggestions.html#7 - Rick Tanner On Wed, 10 Dec 2003, Stwong wrote: > ---------- Original Message ---------------------------------- > From: Todd Mitchell > >> > >> Ideally, any item that is needed for a quest should be modified so that they > >> are indestructible. > > Just my opinion, but this idealism doesn't really work. I don't even > see it listed as one of the suggestions for mapmaking on real-time... _______________________________________________ crossfire-devel mailing 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 Dec 10 22:26:09 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:47 2005 Subject: [CF-Devel] A few glitches In-Reply-To: <200311301641.52102.won_fang@yahoo.com.au> References: <3FBE7377.6030604@laposte.net> <3FC9865D.1000106@sonic.net> <200311301641.52102.won_fang@yahoo.com.au> Message-ID: For the time being, here's a list of spells with "restricted" availability. http://crossfire.real-time.com/guides/map/things_to_avoid.html#11 - Rick Tanner On Sun, 30 Nov 2003, David Seikel wrote: > On Sun, 30 Nov 2003 03:55 pm, Mark Wedel wrote: > > The only way to really try and do that now days would be to traverse the > > treasurelists for the scroll and see if the spell in question shows up > > anyplace - if not, must be a special spell. > > > > OR alternatively, a flag could be used, like 'not_inscribable', and add > > that to the archs. > > > > But the question I guess really, is do people see this as being much an > > issue? I personally thought it may add some more player interaction > > (players trading scrolls back and forth for spells they normally could not > > get). > > Remembering the flak I got when using special spells in my maps, I vote for > having some real way of telling them apart. _______________________________________________ crossfire-devel mailing 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 Dec 10 23:00:58 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:47 2005 Subject: [CF-Devel] patch: gcc 3.3 infinite loop fixed In-Reply-To: References: Message-ID: <3FD7FA0A.8060604@sonic.net> Bernd Edler wrote: > After a session with ddd, CFLAGS="-g -O1 -Wall -W -pedantic" > and even valgrind, i found a lot of minor stuff, and > finally the real problem. :) > > Summary by file: > > common/item.c > The vital fix. Wrong buffer size was used. > > common/object.c > reading uninitialized value (valgrind) > > include/define.h > typo in function safe_strncpy, > trailing comma in enum (pedantic) > > include/global.h > c++ style comments > > include/player.h > trailing comma in enum (pedantic) > > socket/init.c > reading uninitialized value (valgrind) > > Bernd Edler Looks fine. My only change would be to use memset or the like to clear out ns->inbuf.buf[] and not a for loop. > > _______________________________________________ crossfire-devel mailing 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 Dec 10 23:07:05 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:47 2005 Subject: [CF-Devel] A few glitches In-Reply-To: References: <3FBE7377.6030604@laposte.net> <3FC9865D.1000106@sonic.net> <200311301641.52102.won_fang@yahoo.com.au> Message-ID: <3FD7FB79.2080409@sonic.net> Rick Tanner wrote: > For the time being, here's a list of spells with "restricted" > availability. > > http://crossfire.real-time.com/guides/map/things_to_avoid.html#11 destruction can be found randomly in spell books. One thing I would add to that section: With the new spell code, it is very easy to just create 'new' spells within a map itself. And IMO, that is the preferred way that quest spells should be done now days. _______________________________________________ crossfire-devel mailing 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 Dec 10 23:14:19 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:47 2005 Subject: [CF-Devel] /share/settings addition, _destroy_items_variable?= In-Reply-To: <1071111573.539.63.camel@oberon.Kameria> References: <200312101805.AA110887206@mail.smempire.org> <1071111573.539.63.camel@oberon.Kameria> Message-ID: <3FD7FD2B.3050309@sonic.net> Todd Mitchell wrote: > Previously.... > I think you are overstating the problem, first even if there are some > items that should be indestructable but are not, it is a _very_ small > subset of the items which should be destructable. If there are objects > vital to a quest that are not purposefully destructable then that can be > reported and fixed as a map bug/enhancement by setting hte material type > properly (many archetype items like keys are set to do this by default > as well for easy map making) But making ALL items invunerable is really > an huge overkill. It goes against the material system and overrides all > objects that are supposed to be destructable. I agree. One could also argue from some point that even some quest items should never be indestructible. EG, if the quest is to recover a book, is there any reason that book should be indestructible? Not really. I'd almost state that having important items get destroyed might be a better way to curtail spell use than covering a map with no magic areas. That said, if a creature (and not player) is likely to destroy an item, then perhaps it should be made invulnerable. Also, there is nothing preventing players from selling important items (without a flag or the like, there is no way to prevent that. I suppose you could make them zero value, but unless you also prevent players from dropping them, they could still sell it just by dropping all the loot the got quickly). Likewise, they aren't immune to alchemy. Or for that matter, just not picking them up and leaving them behind. I personally do see reason to fix maps where it may not be the player that destroys the item. But I don't see a whole bunch of reason to insulate the player from potentially doing something harmful (where does it stop?) > If this patch does what I think it does and prevents all items from > being destroyed by exiting from the save throw check, it will break a > lot of maps that depend on items getting destroyed to function > correctly. (item gets burnt up releasing a button for example). I hadn't even thought of that. That reason right there is good enough reason to reject this patch. OTherwise, I'm sure we'll be seeing other bug reports 'map XYZ is broken - I can't open the gate and I followed all the steps'. > It also > takes away one of largest intentionally negative issues with destructive > spells so that the spells become much more usable without the bad side > effects of burning up books and other treasure. True also. The value of some spells is that they don't destroy items. > I can't think of any good reason to ever do this when you can simply set > an objects material type to 256 (or leave it out) on those items that > need it. That is the correct approach if some items should be indestructible. I agree that these are map bugs, and adding such code will actually create new bugs as mentioned 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 Wed Dec 10 23:18:13 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:47 2005 Subject: [CF-Devel] Patch: some warning cleaning under Win32 In-Reply-To: <3FD6D5D3.1090400@laposte.net> References: <3FD19FB6.5020408@laposte.net> <3FD22696.5020908@laposte.net> <3FD6B2BE.50203@sonic.net> <3FD6D5D3.1090400@laposte.net> Message-ID: <3FD7FE15.40702@sonic.net> Nicolas Weeger wrote: >> please don't compress/gzip/whatever small attachments - it makes it >> harder to just quickly browse the change. > > > Hum I think the patch is around 10k, do you consider that small? > (no pun intended, just wondering) I'd probably consider anything less than about 50k small. > > Ok, I will change to uint8 or sint8 (depending on the use). > Apart that mistake on s/uint8, any objection to the patch? Everything else looked OK. _______________________________________________ crossfire-devel mailing 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 Dec 10 23:51:57 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:47 2005 Subject: [CF-Devel] /share/settings addition, _destroy_items_vari In-Reply-To: <1071111573.539.63.camel@oberon.Kameria> Message-ID: On 11-Dec-03 Todd Mitchell wrote: > If you are burning too much treasure then stop lobbing fireballs all the > time, don't prevent items from burning up (well you can do what you like > on your own server...). Then I fail to understand why you are arguing against the patch. It's a setting, which unless I read the original email wrong, would be off by default. The originator of the patch is attempting to do what you suggest, "what he likes on his server". Why NOT add the optional behavior? --- Tim Rightnour NetBSD: Free multi-architecture OS http://www.netbsd.org/ NetBSD supported hardware database: http://mail-index.netbsd.org/cgi-bin/hw.cgi _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Thu Dec 11 11:53:36 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:47 2005 Subject: [CF-Devel] Patch: some warning cleaning under Win32 In-Reply-To: <3FD7FE15.40702@sonic.net> References: <3FD19FB6.5020408@laposte.net> <3FD22696.5020908@laposte.net> <3FD6B2BE.50203@sonic.net> <3FD6D5D3.1090400@laposte.net> <3FD7FE15.40702@sonic.net> Message-ID: <3FD8AF20.7040809@laposte.net> Hum, i have troubles determining the correct type to use for 'char' in play_sound_player_only's definition. x & y are chars, ok, and are sent using SockList_AddChar, which takes a 'char'! This char is added to the socket's buffer, which is... unsigned char. Except x & y, since they are relative positions of sound from player, can be negative! So at some point, the signed char will be converted to unsigned (arguably there is no information loss, though, so it isn't too bad). Is it better to fix (x, y) as uint8, and SockList_AddChar too (since 'char' is signed or unsigned depending on platforms, potentially)? Or do i leave x, y as sint8, SockList_AddChar as it is, and let explicit conversions take care of the rest? 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 Thu Dec 11 12:20:03 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:47 2005 Subject: [CF-Devel] Artifact & subtype question (to know how to fix broken build patch...) Message-ID: <3FD8B553.5070909@laposte.net> Yesterday i showed my building patch to some players, and it worked fine... except i had to fix subtypes of items manually (i use'em to discriminate between some items: type 161 = building material, subtype 1 = floor, and so on). Investigating the reason, it's because subtype is not part of what an artifact can give to an item (see common/treasure.c:add_abilities) My 'building tiles', in shops, generate items, with the correct artifacts, but since subtype isn't copied, it is wrong. So the question would be: is there a compelling reason why an artifact could not alter the archetype's subtype? The type obviously is archetype-depend, but what about the subtype? (btw, is subtype actually used somewhere?) Now i could use another way to find what the player is building: use the builded item's 'type' field. Which is not set for most floors & walls. So I'd have to change archetypes for those, to add the 'type' field. I can live with that, though :) (the 'is_floor' is not enough, i fear, to correctly discriminate, especially when there are walls without floors. And the 'no_pass' is not enough for walls, since for instance doors have it too...) Any thoughts about 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 Fri Dec 12 22:02:41 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:47 2005 Subject: [CF-Devel] /share/settings addition, _destroy_items_vari In-Reply-To: References: Message-ID: <3FDA8F61.1060208@sonic.net> Tim Rightnour wrote: > On 11-Dec-03 Todd Mitchell wrote: > >>If you are burning too much treasure then stop lobbing fireballs all the >>time, don't prevent items from burning up (well you can do what you like >>on your own server...). > > > Then I fail to understand why you are arguing against the patch. It's a > setting, which unless I read the original email wrong, would be off by default. > The originator of the patch is attempting to do what you suggest, "what he > likes on his server". > > Why NOT add the optional behavior? Because any optional behaviour that is in CVS has the expectation of users that it would work. I can envision cases right now where with that option enable, some new server admin might set up there server with that, and some maps now don't work. They then post a message and state 'hey, map XYZ is broken'. Of which the only suggested fix that can be sent back is 'don't use that option'? It is true a server admin can do whatever they want. And if they create bugs, it is their own problem to fix. As said, I didn't have much problem with the patch until it was pointed out that it will almost certainly break some maps. So if such an option was added, the comment would basically have to be 'do not enable this, because if you do, some things won't 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 Fri Dec 12 22:07:21 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:47 2005 Subject: [CF-Devel] Artifact & subtype question (to know how to fix broken build patch...) In-Reply-To: <3FD8B553.5070909@laposte.net> References: <3FD8B553.5070909@laposte.net> Message-ID: <3FDA9079.2010104@sonic.net> Nicolas Weeger wrote: > Yesterday i showed my building patch to some players, and it worked > fine... except i had to fix subtypes of items manually (i use'em to > discriminate between some items: type 161 = building material, subtype 1 > = floor, and so on). > > Investigating the reason, it's because subtype is not part of what an > artifact can give to an item (see common/treasure.c:add_abilities) > > My 'building tiles', in shops, generate items, with the correct > artifacts, but since subtype isn't copied, it is wrong. > > So the question would be: is there a compelling reason why an artifact > could not alter the archetype's subtype? > The type obviously is archetype-depend, but what about the subtype? > (btw, is subtype actually used somewhere?) Yes - there is compelling reason - subtype might very well be used in the future as additional matching code. Also, changing subtypes may have bad effects down the road. subtypes are extensively used in the new spell code. And I personally see adding more objects to use type/subtype (really, all the stuff a player may equipment should be of something like 'type equipment, subtype shield/weapon/armor/helm/....'. Arguably, the artifact stuff could be done better (have some area which lists what to match against, and another area which lists what to set). However, at some level, I'd just rather the artifact file disappear or otherwise get completely redone. _______________________________________________ crossfire-devel mailing 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 Dec 13 03:03:11 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:47 2005 Subject: [CF-Devel] Artifact & subtype question (to know how to fix broken build patch...) In-Reply-To: <3FDA9079.2010104@sonic.net> References: <3FD8B553.5070909@laposte.net> <3FDA9079.2010104@sonic.net> Message-ID: <3FDAD5CF.6020809@laposte.net> > Yes - there is compelling reason - subtype might very well be used in > the future as additional matching code. > > Also, changing subtypes may have bad effects down the road. > > subtypes are extensively used in the new spell code. And I personally > see adding more objects to use type/subtype (really, all the stuff a > player may equipment should be of something like 'type equipment, > subtype shield/weapon/armor/helm/....'. Hum, that's exactly how i use subtype in my building code: general material has type 161, and subtype is used to discriminate between what you are building (floor, wall, other items). Also, from your comment I think I wasn't clear enough: the question is, rather, would it be bad if an artifact could override the archetype's subtype (using the 'subtype' in artifact, as weight/title/stats can be overriden)? You just need to NOT use this field for most items, and it'll make it easier for my building patch :) Actually, problem occurs (in my building case) because I implemented different 'instances' of material using artifacts, not archetypes. I thought 'they all share some fields, like type & stuff, so i'll make a global ''virtual'' archetype and different artifacts'. Now of course I can reimplement using different archetypes for different materials, instead of one archetype and different artifacts (would remove the need for my treasure.c hack) > Arguably, the artifact stuff could be done better (have some area which > lists what to match against, and another area which lists what to set). > > However, at some level, I'd just rather the artifact file disappear or > otherwise get completely redone. Couldn't we use something like what is used for archetypes? Add .art files that get collected by a script to make artifact 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 Sat Dec 13 15:02:16 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:47 2005 Subject: [CF-Devel] GTK+ 1.6.0 CVS - memory leak Message-ID: <200312131502.16532.eracclists@bellsouth.net> Greetings Coders, So, my first message to the list is about the memory leak I am having with the 1.6.0 GTK+ client from CVS. It has been suggested to me off-list that the problem is probably library related. It was also suggested that this *might* have been discussed on the list recently. Unfortunately I can't find that discussion in the archives for crossfire-devel going back three months, unless it is this one: http://archives.real-time.com/pipermail/crossfire-devel/2003-September/005110.html - which doesn't help me very much. If I overlooked the discussion in the archives my apologies and please e-mail the URL for that if any of you know it. If there is a search engine for the archives, other than Google, please let me know that as well (although Google seems to pull up what I was seeking on the archives.real-time.com site minus the information I need). Otherwise if some kind soul(s) would please offer assistance I would be eternally grateful. :-) Perhaps a suggestion of which libraries and versions of same I *should* be using would help. Someone with a successful, non-memory-leaking, GTK+ 1.6.0 CVS client build on Linux should be using the libraries about which I need to know. My OS is Mandrake 9.1 Linux which is fully patched with the latest "urpmi" updates. BTW, thank you Leaf for helping me get subscribed to the list. Sorry the automated sign-up didn't like my e-mail address. :-) TIA, Gene -- Linux era4.eracc.UUCP 2.4.21-0.25mdk i686 15:00:32 up 42 days, 3:33, 10 users, load average: 0.12, 0.05, 0.01 ERA Computer Consulting - http://www.eracc.com/ eCS, OS/2, Mandrake GNU/Linux, OpenServer & UnixWare resellers _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Sat Dec 13 19:05:01 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:47 2005 Subject: [CF-Devel] Artifact & subtype question (to know how to fix broken build patch...) In-Reply-To: <3FDAD5CF.6020809@laposte.net> References: <3FD8B553.5070909@laposte.net> <3FDA9079.2010104@sonic.net> <3FDAD5CF.6020809@laposte.net> Message-ID: <3FDBB73D.8010403@sonic.net> Nicolas Weeger wrote: you are building (floor, wall, other items). > > Also, from your comment I think I wasn't clear enough: the question is, > rather, would it be bad if an artifact could override the archetype's > subtype (using the 'subtype' in artifact, as weight/title/stats can be > overriden)? You just need to NOT use this field for most items, and > it'll make it easier for my building patch :) Yes, that would be bad. Perhaps I wasn't clear. My main concern is this: currently the 'type' value in the artifacts file is a matching criteria. Thus, this object: Allowed all chance 1 Object Blindness type 34 is_blind 1 magic 1 cursed 1 end Basically says only objects of 'type 34' can possible match on this artifact. Suppose down the road, I wand to do something like: type 34 subtype 3 To say 'if object type is 34, and subtype is 3, make this an artifact'. If 'subtype' is used as an attribute of the artifact taht it imbues on the object, this is impossible (having it be a matching as well as assigning value makes no sense). And I certainly see the potential need for subtype to act as a match operator in the future. > > Actually, problem occurs (in my building case) because I implemented > different 'instances' of material using artifacts, not archetypes. I > thought 'they all share some fields, like type & stuff, so i'll make a > global ''virtual'' archetype and different artifacts'. > Now of course I can reimplement using different archetypes for different > materials, instead of one archetype and different artifacts (would > remove the need for my treasure.c hack) IMO, that is preferable. I personally don't like the artifacts file that much, so anything that can easily be done as an archetype instead of an object is preferable in my mind. > >> Arguably, the artifact stuff could be done better (have some area >> which lists what to match against, and another area which lists what >> to set). >> >> However, at some level, I'd just rather the artifact file disappear >> or otherwise get completely redone. > > > Couldn't we use something like what is used for archetypes? > Add .art files that get collected by a script to make artifact file? I'll send my thoughts about artifacts (and how to properly redo) in a different message/thread. _______________________________________________ crossfire-devel mailing 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 Dec 13 19:26:39 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:47 2005 Subject: [CF-Devel] new artifact & treasures idea Message-ID: <3FDBBC4F.4080703@sonic.net> As per a different thread, I mentioned that I don't really like how the current lib/artifacts works. As I was thinking about this, I came up with what I thought was a clever solution. Use template objects (same idea of template monsters in AD&Dv3). That is to say, you make up objects of type 'template'. The values and what not would work similar to how the artifacts file. However, instead of hard coded chances of artifacts in the treasures.c, instead use these templates in treasurelists. Thus, you could have a treasurelist like: treasureone template_helms arch template_xebinon chance .. more arch template_blindness chance .. more ... Then the helms themselves would have a 'randomitems template_helms' The advantages of this: 1) Basically all fields in the template (artifact) could now be set in the object, were as right now some of the fields in the artifact file are used for matching. 2) Better control of how often artifacts show up (now in treasurelist instead of hard coded into treasure.c). Could also easily disable double artifact items (eg, strange ring of wizardry) (not that those are really a problem, but just the ability to disable that could be nice) 3) Ability to apply more than one template to an object. Eg, you could have templates for the special abilities, like now, and different template for materials. Then, you could have something like: randomitems helm list helm_special_abilities chance 5 # 5% of helms are special more list armor_material_change chance 25 # 25% of helms are not made of the normal material more arch cursed chance 3 # 3% of hels are cursed end end 4) Given that the templates would be archetypes, I could certainly see the java editor better able to handle this (eg, you select the template, and then an object, and hit the 'apply template to object' button or the like) The biggest advantage of this is a bunch of new treasurelists would be needed. I have thought that the treasure list code could be extended also. However, my thought on that are a bit more modest: 1) Add min_nrof and min_magic fields (eg, if nrof is 20 right now, 1-20 objects are created. IT would be better to do something like min_nrof 10 max_nrof 20 To say to generate 10-20 of those objects. Likewise, min_magic could be used to say 'make this object at least min_magic'. Thus, treasurelists could be used to make the magic bonus of the weapons and whatnot. 2) Add a min and max difficulty for each entry. Thus, instead of using list transitions to make sure too god objects aren't created, this could be done in just one list. For an object to be created, in must be between min and max difficulty, based on the difficulty of the map (max difficulty is there so you could make it so junk items don't appear on high level maps. Might be some other nice things to add. Those are just off the top of my head. The treasurelist stuff would actually be relatively easy to do - at least point #1 would not cause nay problems with existing treasure lists (just new fields really). Point 2 would require a little more work, as currently 'magic' is used for list transitions. _______________________________________________ crossfire-devel mailing 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 Dec 14 02:45:52 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:47 2005 Subject: [CF-Devel] Artifact & subtype question (to know how to fix broken build patch...) In-Reply-To: <3FDBB73D.8010403@sonic.net> References: <3FD8B553.5070909@laposte.net> <3FDA9079.2010104@sonic.net> <3FDAD5CF.6020809@laposte.net> <3FDBB73D.8010403@sonic.net> Message-ID: <3FDC2340.20506@laposte.net> > Yes, that would be bad. > > Perhaps I wasn't clear. > Suppose down the road, I wand to do something like: > type 34 > subtype 3 > To say 'if object type is 34, and subtype is 3, make this an artifact'. > And I certainly see the potential need for subtype to act as a match > operator in the future. Ok, didn't think of subtype matching. Fair enough, i'll reimplement differently :) > IMO, that is preferable. I personally don't like the artifacts file > that much, so anything that can easily be done as an archetype instead > of an object is preferable in my mind. Ok, i'll remake my stuff using artifacts. 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 Dec 14 03:11:48 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:47 2005 Subject: [CF-Devel] new artifact & treasures idea In-Reply-To: <3FDBBC4F.4080703@sonic.net> References: <3FDBBC4F.4080703@sonic.net> Message-ID: <3FDC2954.7000201@laposte.net> Sounds like a good idea. Here are some more random suggestions/thoughts: * some way to tweak sublist's chance based on 'difficulty' (map or whatnot). For instance to increase the chance of damned item as it goes more powerful. Like: randomitem helm ... arch damned min_diff 30 chance 5 diff_factor 2 for a difficulty of 37 damned chance becomes 5 + 2 * 7 = 19% (formulea is just the first to pop outta my mind, can be changed :)) * one drawback i see with the implementation is that it'll be real hard to forbid special combinations. If we want to forbid strange ring of ruling, we'll need to make 2 lists, one with strange and not ruling, the other with ruling and not strange, and duplicate all stuff we put (else probabilities make that at some point one will appear). I'd suggest a way to say 'this arch can be used only if this arch was not used', but it may be slightly overkill to implement... (this assumes ring is implemented something like arch random_ring arch strange_ring chance 5 end arch Ruling chance 1 end * the treasures file will grow fat, but maybe that's not too bad. Someone wanting to find some info without downloading whole arch module will need sometime to find it, though :) Nicolas 'Ryo' _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Tue Dec 16 16:04:56 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:48 2005 Subject: [CF-Devel] GTK+ 1.6.0 CVS - memory leak In-Reply-To: <200312131502.16532.eracclists@bellsouth.net> References: <200312131502.16532.eracclists@bellsouth.net> Message-ID: On Sat, 13 Dec 2003, ERACC wrote: > If I overlooked the discussion in the archives my apologies and > please e-mail the URL for that if any of you know it. If there is a > search engine for the archives, other than Google, please let me know > that as well (although Google seems to pull up what I was seeking on > the archives.real-time.com site minus the information I need). Try using [cf-devel] (or [cf-list], [cf-announce], etc.) as one of your search terms. Example: site:archives.real-time.com [cf-devel] leak - Rick Tanner _______________________________________________ crossfire-devel mailing 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 Dec 16 23:55:51 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:48 2005 Subject: [CF-Devel] new artifact & treasures idea In-Reply-To: <3FDC2954.7000201@laposte.net> References: <3FDBBC4F.4080703@sonic.net> <3FDC2954.7000201@laposte.net> Message-ID: <3FDFEFE7.1000406@sonic.net> Nicolas Weeger wrote: > Sounds like a good idea. > > Here are some more random suggestions/thoughts: > * some way to tweak sublist's chance based on 'difficulty' (map or > whatnot). For instance to increase the chance of damned item as it goes > more powerful. > Like: > randomitem helm > ... > arch damned > min_diff 30 > chance 5 > diff_factor 2 > > for a difficulty of 37 damned chance becomes 5 + 2 * 7 = 19% > (formulea is just the first to pop outta my mind, can be changed :)) That's a good idea - it would do one of the things I did mention in my previous mail, which is to make it easier to make better objects show up more often in high level maps - one could even do something like negative diff_factors (eg, item becomes less likely to show up as the map increases in difficulty). The one problem with this is increased cpu time. Currently, the total chance of a treasure list is set when the treasure lists are first loaded (chancedifficulty). In this way, if the treasureone list total chance is 85, we can generate that number between 1->85, and then as we walk the treasure list, substracting the chance for the object - when we get to <=0, that is the item to do. If adjustments to chance are allowed on the treasureone lists, now the list would have to be walked two times - once to find out the total chance based on difficulty, and then again to actually choose the item. But that probably isn't that big a deal. > > * one drawback i see with the implementation is that it'll be real hard > to forbid special combinations. If we want to forbid strange ring of > ruling, we'll need to make 2 lists, one with strange and not ruling, the > other with ruling and not strange, and duplicate all stuff we put (else > probabilities make that at some point one will appear). I'd suggest a > way to say 'this arch can be used only if this arch was not used', but > it may be slightly overkill to implement... > > (this assumes ring is implemented something like > arch random_ring > arch strange_ring > chance 5 > end > arch Ruling > chance 1 > end That may be less an issue. I'd presume that it'd be more generic than 'don't allow strange ring of ruling', but more likely of 'if this is a strange ring, then it can't get additional artifact abilities'. And in that case, its much simpler - it may just mean we set the randomitems for the strange ring to be empty (presuming that since it is an artifact, things like material and other abilities shouldn't be added). > > * the treasures file will grow fat, but maybe that's not too bad. > Someone wanting to find some info without downloading whole arch module > will need sometime to find it, though :) Well, I'd imagine one coudl probably write a nice tool to display the treasurelist in a friendly to display format (hyperlink or something to show how the lists are related to each other). The counter to this is that the archetypes file disappear, and everything is more public (you don't need to look at treasure.c to figure out how attributes to some items are added). Perhaps part of this, allow treasurelists to be set in objects themselves - that in itself would be relative simple of something like: starttreasurelist .... endtreasurelist such a list could make references to other lists in treasures, but those lists could not make references to that per object list of course. _______________________________________________ crossfire-devel mailing 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 Dec 18 02:12:35 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:48 2005 Subject: [CF-Devel] new artifact & treasures idea In-Reply-To: <3FDFEFE7.1000406@sonic.net> References: <3FDBBC4F.4080703@sonic.net> <3FDC2954.7000201@laposte.net> <3FDFEFE7.1000406@sonic.net> Message-ID: <3FE16173.6070905@laposte.net> > The one problem with this is increased cpu time. Currently, the total > chance of a treasure list is set when the treasure lists are first > loaded (chancedifficulty). In this way, if the treasureone list total > chance is 85, we can generate that number between 1->85, and then as we > walk the treasure list, substracting the chance for the object - when we > get to <=0, that is the item to do. > > If adjustments to chance are allowed on the treasureone lists, now the > list would have to be walked two times - once to find out the total > chance based on difficulty, and then again to actually choose the item. > But that probably isn't that big a deal. I was thinking of chance adjustement on a 'sublist' level. IE 5% chance of damned item, independantly from other 'sublists', and +2% per level over 30 for instance. It would not affect total chance, just the item generation. > That may be less an issue. I'd presume that it'd be more generic than > 'don't allow strange ring of ruling', but more likely of 'if this is a > strange ring, then it can't get additional artifact abilities'. And in > that case, its much simpler - it may just mean we set the randomitems > for the strange ring to be empty (presuming that since it is an > artifact, things like material and other abilities shouldn't be added). Indeed depends on the granularity we want for forbidding combinations. If it's not too hard to implement i'd go for the finest granularity (ie forbid strange ring of ruling but let go strange ring of thieves) > Well, I'd imagine one coudl probably write a nice tool to display the > treasurelist in a friendly to display format (hyperlink or something to > show how the lists are related to each other). Kinda like the java editor displays treasure list. > The counter to this is that the archetypes file disappear, and > everything is more public (you don't need to look at treasure.c to > figure out how attributes to some items are added). Didn't you mean 'artifacts file'? And since all files are public in the first place, I don't really think that's an issue to make things more public. Quite the contrary, maybe it'll give non-tech-savy people a chance to come up with nice items :) Also will give more options for server customisation, since you'll be able to change a text file instead of hacking the code. 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 Thu Dec 18 12:53:26 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:48 2005 Subject: [CF-Devel] Function weirdness Message-ID: <3FE1F7A6.2030204@laposte.net> I think there's something weird with this function (from server/apply.c): static void eat_item(object *op,char *item, int nrof) { object *prev; prev = op; op=op->below; while(op!=NULL) { if (strcmp(op->arch->name,item)==0) { if (op->nrof >= nrof) { decrease_ob_nr(op,nrof); return; } else { decrease_ob_nr(op,op->nrof); <<<<<<<< nrof -= op->nrof; <<<<<<<< } op=prev; } prev = op; op=op->below; } } Since decrease_ob_nr will remove the item and more important set op->nrof to 0 (check decrease_ob_nr, object.c:1655), it seems that nrof will not get decreased in this case... I suggest inverting the 2 lines :) 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 Thu Dec 18 16:01:09 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:48 2005 Subject: [CF-Devel] WG: [Crossfire-cvs] CVS commit: crossfire Message-ID: Hit wrong list. > > On Daimonin this part will break the server and on > crossfire i think too. > > The reason is that the server use clear_object() in > this context: > clear_object() > update_speed() > > update_speed() will notice now the speed 0 and remove this > object from active list. > > This is a bit hidden in the source because the function are > called over some edges. > > You can proof it by login in a new started server... go in a map > with monster and logout (server still runing). Login back and all > monster should stay around without acting. If not this is still not > a proof - this effect will happens because the player as active object > should be before loaded map content (= mobiles). > > MT > > > *************** > > *** 534,540 **** > > op->head=NULL; > > op->map=NULL; > > op->refcount=0; > > ! /* What is not cleared is next, prev, active_next, > > active_prev, and count */ > > > > op->expmul=1.0; > > op->face = blank_face; > > --- 534,542 ---- > > op->head=NULL; > > op->map=NULL; > > op->refcount=0; > > ! op->active_next = NULL; > > ! op->active_prev = NULL; > > ! /* What is not cleared is next, prev, and count */ > > > > op->expmul=1.0; > > op->face = blank_face; > > > > ------------------------------------------------------- > This SF.net email is sponsored by: IBM Linux Tutorials. > Become an expert in LINUX or just sharpen your skills. Sign up for IBM's > Free Linux Tutorials. Learn everything from the bash shell to sys admin. > Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click > _______________________________________________ > Crossfire-cvs mailing list > Crossfire-cvs@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/crossfire-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 Thu Dec 18 23:30:10 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:48 2005 Subject: [CF-Devel] Re: AW: [Crossfire-cvs] CVS commit: crossfire] Message-ID: <3FE28CE2.50303@sonic.net> Must of followed up to the wrong alias. Forwarded to the correct one. -------------- next part -------------- An embedded message was scrubbed... From: crossfire-cvs-admin@lists.sourceforge.net Subject: Re: AW: [Crossfire-cvs] CVS commit: crossfire Date: Thu, 18 Dec 2003 21:26:42 -0800 Size: 7182 Url: http://shadowknight.real-time.com/pipermail/crossfire/attachments/20031218/9db6c785/crossfire.mht -------------- 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 Thu Dec 18 23:54:56 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:48 2005 Subject: [CF-Devel] new artifact & treasures idea In-Reply-To: References: Message-ID: <3FE292B0.3060103@sonic.net> Todd Mitchell wrote: > This is good as well, especially when dealing with monster abilities. I > think it would be great to be able to assign more than one treasure list to a > object - especially for say monsters or NPCs who could be assigned a body > parts list, a treasure list and a 'jail' or citizen list which contains local > specific random items or special 'guards' to summon when they are killed. > (you slay the orc at the door to the summoner's lair but now 5 gnolls appear- > he must have sounded an alarm! You should have tried to sneak past him.) Well, if you can assign treasurelists to objects, you could easily do this. you could do something like: starttlist list body_parts more list city_item more list normal_treasure endtlist And thus you basically have three treasure lists. > > Making the list more modular would be good too as now the treasure list calls > the bodypart list so new lists must be created for any new combinations. You > can of course insert items directly in the inventory but this would be a > better way to insert entire lists and random items. Not completely sure if I follow what you mean. Are you asking for something like an 'allowed' keyword in the treasurelist? Thus, you could have one list of bodyparts, but something like: treasure body_parts arch orc_chop allowed orc chance 5 more arch dragon_scale allowed dragon chance 30 more ... And so on? Given the list format can contain redundant entries, with different match criteria, probably easier to list each monster you want the item to show up for (one entry for dragon, one for wyvern, one for chinese dragon, etC). OTOH, I really wonder how much it comes up - the dragon is already going to have a different treasure list than the orc anyways. Such customizations would be most useful for common lists (more low level lists). I had thought of changing the format - it seems that more than once there have been errors of missing 'more' keywords or the like. But I'm not sure of a form that would necessarily be a lot clearer. And the current list does allow the fact that even within a single list, you can basically form a tree structure (eg, the no/yes combos) Nicolas Weeger wrote: >> If adjustments to chance are allowed on the treasureone lists, now >> the list would have to be walked two times - once to find out the >> total chance based on difficulty, and then again to actually choose >> the item. But that probably isn't that big a deal. > > > I was thinking of chance adjustement on a 'sublist' level. IE 5% chance > of damned item, independantly from other 'sublists', and +2% per level > over 30 for instance. > It would not affect total chance, just the item generation. But if it is a treasureone list, you need to change the total chance. Eg, take the following list: treasureone physical_traps arch trap_diseased_needle chance 70 more arch trap_blades chance 33 more arch trap_needle chance 33 more arch trap_spikes2 chance 33 end If you add something like diff_adjustment 3 to the 'trap_diseased_needle list', then if this list is called on a high level map, the effective chance fo a disease needle show up might be 100. Without a change to the code, that would need that the last entry could basically never happen (code makes a number between 1->169, based on the total chance that is stored away. Lets say it rolls 150. Process the first item, with adjusted chance of 100. Doesn't choose that, but remaining chance is no 50. Looks at next item - chance 33. Doesn't take that, but remaining chance is now 17. IT does take the next item (trap_needle) because that chance is now greater than the remaining value. So for those higher difficulty treasureone lists, you need to adjust what the total roll chance is before making the roll, otherwise items at the end of the list are less likely to show up. > >> That may be less an issue. I'd presume that it'd be more generic >> than 'don't allow strange ring of ruling', but more likely of 'if this >> is a strange ring, then it can't get additional artifact abilities'. >> And in that case, its much simpler - it may just mean we set the >> randomitems for the strange ring to be empty (presuming that since it >> is an artifact, things like material and other abilities shouldn't be >> added). > > > Indeed depends on the granularity we want for forbidding combinations. > If it's not too hard to implement i'd go for the finest granularity (ie > forbid strange ring of ruling but let go strange ring of thieves) While fine granularity is often nice, there is the code complication (and in this case, also treasurelist and so on). However, if that was really the desired result, one coudl still do that - just take the normal treasurelists for ring, rename them, and remove the ruling template but leave the rest. In the long run, such granularity could make the lists unmanagable. OTOH, I'm not sure I see the need of such granularity. And it really doesn't exist right now (the artifact code just matches all rings right now, so you could get a strange ring of whatever, but of course some combos would be quite rare). My personal thought is that in most cases, the 'true' artifacts should probably be disabled from having templates applied to them. This is mostly for balance - true artifacts are often already quite powerful. If some template like '20% more damage' was applied on top, that could really take an artifact from 'very powerful but OK' to 'too powerful - shouldn't be allowed'. > And since all files are public in the first place, I don't really think > that's an issue to make things more public. Quite the contrary, maybe > it'll give non-tech-savy people a chance to come up with nice items :) > Also will give more options for server customisation, since you'll be > able to change a text file instead of hacking the code. My point is that it is reasonable to expect map makers to be able to understand treasure lists and archetype files. IT's a bit unreasonable to tell them 'look at the code in treasure.c to try and figure out the likelihood of specific plus items showing up on your map'. _______________________________________________ crossfire-devel mailing 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 Dec 19 17:57:58 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:48 2005 Subject: [CF-Devel] new artifact & treasures idea In-Reply-To: <3FE292B0.3060103@sonic.net> References: <3FE292B0.3060103@sonic.net> Message-ID: <1071878278.559.4.camel@oberon.Kameria> On Fri, 2003-12-19 at 00:54, Mark Wedel wrote: > Todd Mitchell wrote: > > > This is good as well, especially when dealing with monster abilities. I > > think it would be great to be able to assign more than one treasure list to a > > object - especially for say monsters or NPCs who could be assigned a body > > parts list, a treasure list and a 'jail' or citizen list which contains local > > specific random items or special 'guards' to summon when they are killed. > > (you slay the orc at the door to the summoner's lair but now 5 gnolls appear- > > he must have sounded an alarm! You should have tried to sneak past him.) > > Well, if you can assign treasurelists to objects, you could easily do this. > you could do something like: > > starttlist > list body_parts > more > list city_item > more > list normal_treasure > endtlist > > And thus you basically have three treasure lists. > Yes, exactly - excellent. This is what I mean by modular as well - body parts do not have to be wrapped up in a parent treasure list any longer. This makes it easier to have a dragon cleric without making a dragon_cleric treasurelist - just add dragon_bodyparts and cleric_treasure... > > > > Making the list more modular would be good too as now the treasure list calls > > the bodypart list so new lists must be created for any new combinations. You > > can of course insert items directly in the inventory but this would be a > > better way to insert entire lists and random items. > > Not completely sure if I follow what you mean. I just meant you can have distinct purpose treasure lists as I mention 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 Fri Dec 19 23:39:07 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:48 2005 Subject: [CF-Devel] new artifact & treasures idea In-Reply-To: <1071878278.559.4.camel@oberon.Kameria> References: <3FE292B0.3060103@sonic.net> <1071878278.559.4.camel@oberon.Kameria> Message-ID: <3FE3E07B.5050701@sonic.net> Todd Mitchell wrote: > On Fri, 2003-12-19 at 00:54, Mark Wedel wrote: > Yes, exactly - excellent. This is what I mean by modular as well - body > parts do not have to be wrapped up in a parent treasure list any > longer. This makes it easier to have a dragon cleric without making a > dragon_cleric treasurelist - just add dragon_bodyparts and > cleric_treasure... Note that in a large sense, that could be done right now - it would just require more treasurelists. At some level, the archetype treasurelists should probably still get collected into the treasures.bld. The ability to customize treasurelists on an object level is most useful for map design. OTOH, it wasn't until recently that collections of .trs files was added - really, there shouldn't be any treasures file at all - it should be 100% generated - that would also make it easier to deal with the treasures (most likely), in that the dragon treasure would be right with the dragon creature - you wouldn't have to go searching through the treasures file to find the dragon treasurelist. That in its own regard may make the treasurelists better - having a 50 line treasure file for a creature probably isn't that unreasonable, and you may better customize the treasures. Where as with a common treasures file, there may be more perceived need to recycle treasures. _______________________________________________ crossfire-devel mailing 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 Dec 19 23:45:51 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:48 2005 Subject: [CF-Devel] GTK+ 1.6.0 CVS - memory leak In-Reply-To: <200312131502.16532.eracclists@bellsouth.net> References: <200312131502.16532.eracclists@bellsouth.net> Message-ID: <3FE3E20F.5010309@sonic.net> ERACC wrote: > > Otherwise if some kind soul(s) would please offer assistance I would > be eternally grateful. :-) Perhaps a suggestion of which libraries > and versions of same I *should* be using would help. Someone with a > successful, non-memory-leaking, GTK+ 1.6.0 CVS client build on Linux > should be using the libraries about which I need to know. I've not noticed any horrendous memory leaks on my system. But I'm using gtk 1.2.10, gcc 3.2.3. However, there are also lots of options that one can use with the client, and certainly possible that one causes more memory leakage than another. For example, I typically use image caching adn sdl display mode. non caching or non sdl may make a difference. But even there, the entire image set can't possible take more than 60 MB or so of memory (yes, that is a lot, but I'm assuming worse case scenario - 4 bits per pixel, and different image sizes for the icons vs map, as well as the pre rendered fog of war spaces (eg, one image may have 3-4 different renderings). OTOH, if you really want to track this down, you can get a leak detector. I see that rational purify has free demo version for linux now (go to www.rational.com as a starting point). Purify tends to be very good about finding lost references and whatnot, and will also find leaks in libraries, and its quite easy to use. I'm a little frightened at how many leaks it may find :) _______________________________________________ crossfire-devel mailing 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 Dec 20 06:51:47 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:48 2005 Subject: [CF-Devel] patch: gcc 3.3 infinite loop fixed In-Reply-To: <3FD7FA0A.8060604@sonic.net> References: <3FD7FA0A.8060604@sonic.net> Message-ID: <200312202251.48231.won_fang@yahoo.com.au> Has this been committed yet? _______________________________________________ crossfire-devel mailing 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 Dec 20 06:58:14 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:49 2005 Subject: [CF-Devel] Got some time on my hands, time to stomp bugs. Message-ID: <200312202258.14967.won_fang@yahoo.com.au> The government has been interfering with my life recently, and I haven't had much time to do other stuff, but I now have a two or three week holiday. Time to stomp some bugs. On the other hand, I managed to loose my personal TODO list for Crossfire. So, could someone prioritise the current set of bugs and list them here, along with information about anybody that is already working on said bug, and I will get stuck into hunting them down. Or is the source forge bug list a good representation of the current bug state? After the holiday, it's back to video editing and FX for the governments buddies for the next three or four months. (On the gripping hand, there are some bugs in my own open source project that really need stomping - http://matrix-dfs.flox.net/ ) _______________________________________________ crossfire-devel mailing 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 Dec 20 07:05:12 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:49 2005 Subject: [CF-Devel] patch: gcc 3.3 infinite loop fixed In-Reply-To: <200312202251.48231.won_fang@yahoo.com.au> References: <3FD7FA0A.8060604@sonic.net> <200312202251.48231.won_fang@yahoo.com.au> Message-ID: <3FE44908.7020500@laposte.net> David Seikel a ?crit : > Has this been committed yet? Committed'em a few days ago. Seems there may be an issue with the 'active_next/active_prev' set to null, though, haven't checked yet. Nicolas 'Ryo' _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Sat Dec 20 08:52:21 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:49 2005 Subject: [CF-Devel] Got some time on my hands, time to stomp bugs. In-Reply-To: <200312202258.14967.won_fang@yahoo.com.au> References: <200312202258.14967.won_fang@yahoo.com.au> Message-ID: <3FE46225.9070103@laposte.net> Help me fix compilation warnings under Windows? I'm also trying to put comments in code, doxygen-like format, but not always taking the time for that... Seriously, though, i think most important bugs are either on SF, on the message board, or here in the archives... Nicolas 'Ryo' _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Sat Dec 20 10:05:06 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:49 2005 Subject: [CF-Devel] Re: AW: [Crossfire-cvs] CVS commit: crossfire] In-Reply-To: <3FE28CE2.50303@sonic.net> References: <3FE28CE2.50303@sonic.net> Message-ID: <3FE47332.3080108@laposte.net> Actually, the fix does break a few things.... My mistake for not making sure that was ok. Basically, when you login, player won't even move... (probably due to the call from check_login). Here's the fix i propose (attached patch): set speed to 0 in clear_object, call update_ob_speed (if speed isn't 0 already, of course). This way, a call to clear_object certifies object is correctly removed from active list. Doing that there was a trouble in treasure.c, during artifact initialization: init_artifacts would directly malloc( ) an object and call reset_object on it (thus some breakage in update_ob_speed due to uninitialized active_next/prev). So i changed to call get_object( ) (which is there to provide objects, isn't it? :)) And, to be on the safe side, i added a speed = 0 in common/arch.c : get_archetype_struct( ) (note that update_ob_speed wouldn't do anything, because arch_init is set at that point) With those fixes i couldn't find any bug in newbie tower, even after resetting map. Nicolas 'Ryo' -------------- next part -------------- Index: common/treasure.c =================================================================== RCS file: /cvsroot/crossfire/crossfire/common/treasure.c,v retrieving revision 1.42 diff -u -r1.42 treasure.c --- common/treasure.c 2 Nov 2003 05:18:02 -0000 1.42 +++ common/treasure.c 20 Dec 2003 15:53:18 -0000 @@ -1200,8 +1200,7 @@ else if (sscanf(cp, "difficulty %d", &value)) art->difficulty = (uint8) value; else if (!strncmp(cp, "Object",6)) { - art->item = (object *) malloc(sizeof(object)); - reset_object(art->item); + art->item = get_object( ); if (!load_object(fp, art->item,LO_LINEMODE,0)) LOG(llevError,"Init_Artifacts: Could not load object.\n"); art->item->name = add_string((strchr(cp, ' ')+1)); Index: common/object.c =================================================================== RCS file: /cvsroot/crossfire/crossfire/common/object.c,v retrieving revision 1.77 diff -u -r1.77 object.c --- common/object.c 18 Dec 2003 20:39:44 -0000 1.77 +++ common/object.c 20 Dec 2003 15:53:36 -0000 @@ -511,6 +511,11 @@ if (op->lore!=NULL) FREE_AND_CLEAR_STR(op->lore); if (op->materialname!= NULL) FREE_AND_CLEAR_STR(op->materialname); + if ( op->speed != 0 ) + { + op->speed = 0; + update_ob_speed( op ); + } /* Using this memset is a lot easier (and probably faster) * than explicitly clearing the fields. @@ -534,8 +539,6 @@ op->head=NULL; op->map=NULL; op->refcount=0; - op->active_next = NULL; - op->active_prev = NULL; /* What is not cleared is next, prev, and count */ op->expmul=1.0; @@ -705,6 +708,7 @@ if(objects!=NULL) objects->prev=op; objects=op; + op->speed = 0; clear_object(op); SET_FLAG(op,FLAG_REMOVED); nroffreeobjects--; Index: common/arch.c =================================================================== RCS file: /cvsroot/crossfire/crossfire/common/arch.c,v retrieving revision 1.29 diff -u -r1.29 arch.c --- common/arch.c 27 Oct 2003 07:24:13 -0000 1.29 +++ common/arch.c 20 Dec 2003 15:53:41 -0000 @@ -366,6 +366,7 @@ new->clone.race=NULL; new->clone.slaying=NULL; new->clone.msg=NULL; + new->clone.speed = 0; clear_object(&new->clone); /* to initial state other also */ CLEAR_FLAG((&new->clone),FLAG_FREED); /* This shouldn't matter, since copy_object() */ SET_FLAG((&new->clone), FLAG_REMOVED); /* doesn't copy these flags... */ -------------- 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 Dec 20 19:26:34 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:49 2005 Subject: [CF-Devel] Re: AW: [Crossfire-cvs] CVS commit: crossfire] In-Reply-To: <3FE47332.3080108@laposte.net> References: <3FE28CE2.50303@sonic.net> <3FE47332.3080108@laposte.net> Message-ID: <3FE4F6CA.2070606@sonic.net> Nicolas Weeger wrote: > Actually, the fix does break a few things.... > My mistake for not making sure that was ok. > > Basically, when you login, player won't even move... (probably due to > the call from check_login). > > Here's the fix i propose (attached patch): set speed to 0 in > clear_object, call update_ob_speed (if speed isn't 0 already, of > course). This way, a call to clear_object certifies object is correctly > removed from active list. IMO, that is a broken fix. It should be expected that if you make a call to reset_object() that none of the fields have any meaningful value. Thus, passing in data that has been malloc'd should be perfectly valid (I think there may be other areas of the code that do something similar, but not 100% sure). reset_object() does call clear_object(). I suppose you could init the speed to zero in reset_object() - thus clear object won't do anything with it. But that won't fix the bug. I already mentioned how to fix the bug - add a op->speed=0, update_ob_speed(op) into the code in login.c. It shouldn't be up to clear_object() to remove the object from any lists. And in fact, it currently doesn't do this with respect to maps, inventories, or whatever else - it just sets those pointers to null. Thus, if you make a call to clear_object() without calling remove_ob() first, there will be bugs there. > > Doing that there was a trouble in treasure.c, during artifact > initialization: init_artifacts would directly malloc( ) an object and > call reset_object on it (thus some breakage in update_ob_speed due to > uninitialized active_next/prev). So i changed to call get_object( ) > (which is there to provide objects, isn't it? :)) Depends. get_object() provides objects on teh global linked list. This is not always desirable - objects on the global list may get processed in various ways, which you don't want to have happen to things like the artifact objects. This is why I believe that it did in fact malloc the data instead of using get_object() _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Sat Dec 20 19:32:43 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:49 2005 Subject: [CF-Devel] Got some time on my hands, time to stomp bugs. In-Reply-To: <200312202258.14967.won_fang@yahoo.com.au> References: <200312202258.14967.won_fang@yahoo.com.au> Message-ID: <3FE4F83B.8000706@sonic.net> David Seikel wrote: > The government has been interfering with my life recently, and I haven't had > much time to do other stuff, but I now have a two or three week holiday. > Time to stomp some bugs. > > On the other hand, I managed to loose my personal TODO list for Crossfire. > > So, could someone prioritise the current set of bugs and list them here, along > with information about anybody that is already working on said bug, and I > will get stuck into hunting them down. > > Or is the source forge bug list a good representation of the current bug > state? Probably not, but it should be (eg, a lot of people mention bugs elsewhere). Ideally, all bugs should be posted there. If people post bugs on private message boards, irc, or wherever else, obviously some number of people will never see them. I don't know of anyone in particular working on bugs. I'm not aware of any horrendous bugs right now, so prioritizing the more minor ones is harder to do (more a personal opinion of what people think is or is not important). Probably the best thing is to look at the bugs and see what you think you can tackle. any bug that is eliminated is a good thing, even a minor one. _______________________________________________ crossfire-devel mailing 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 Dec 20 19:42:51 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:49 2005 Subject: [CF-Devel] Patch: some warning cleaning under Win32 In-Reply-To: <3FD8AF20.7040809@laposte.net> References: <3FD19FB6.5020408@laposte.net> <3FD22696.5020908@laposte.net> <3FD6B2BE.50203@sonic.net> <3FD6D5D3.1090400@laposte.net> <3FD7FE15.40702@sonic.net> <3FD8AF20.7040809@laposte.net> Message-ID: <3FE4FA9B.3000807@sonic.net> Nicolas Weeger wrote: > Hum, i have troubles determining the correct type to use for 'char' in > play_sound_player_only's definition. > > x & y are chars, ok, and are sent using SockList_AddChar, which takes a > 'char'! > This char is added to the socket's buffer, which is... unsigned char. > Except x & y, since they are relative positions of sound from player, > can be negative! > > So at some point, the signed char will be converted to unsigned > (arguably there is no information loss, though, so it isn't too bad). > Is it better to fix (x, y) as uint8, and SockList_AddChar too (since > 'char' is signed or unsigned depending on platforms, potentially)? > Or do i leave x, y as sint8, SockList_AddChar as it is, and let explicit > conversions take care of the rest? The biggest problem here is any mathematic operations done to the values either before or after they are passed. In terms of passed value, at some level, it shouldn't make a difference, because 8 bits are 8 bits. However, it would seem to be safer for SockList_AddChar() to take a uint8, as it just assigns the value to that buffer of that same type. If the values that are passed in may be negative, you obviously need to use sint8 types. Because try to set negative values for object types that are assigned to be positive only is more likely to break than any potential casting of the type. _______________________________________________ crossfire-devel mailing 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 Dec 20 20:13:00 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:49 2005 Subject: [CF-Devel] Re: AW: [Crossfire-cvs] CVS commit: crossfire] In-Reply-To: <3FE4F6CA.2070606@sonic.net> References: <3FE28CE2.50303@sonic.net> <3FE47332.3080108@laposte.net> <3FE4F6CA.2070606@sonic.net> Message-ID: <3FE501AC.2080107@sonic.net> Mark Wedel wrote: > > I already mentioned how to fix the bug - add a op->speed=0, > update_ob_speed(op) into the code in login.c. Just a note - this fix is now committed 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 Sat Dec 20 20:15:20 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:49 2005 Subject: [CF-Devel] Map bug: /scorn/oldcity/end In-Reply-To: <3FD105E3.2080902@laposte.net> References: <3FD105E3.2080902@laposte.net> Message-ID: <3FE50238.2060605@sonic.net> Nicolas Weeger wrote: > Hello. > (posted to cf-maps & cf-devel) > > A player just showed me, on crossfire.metalforge.net, a nice bug in the > /scorn/oldcity/end map. > At the end are 3 gates, after a bridge. Those gates are opened by a > lever somewhere else in the map, and you supposedly need to grab a few > items to access the lever (from what the player told me, i haven't done > personally the quest). > > Except there's a nice issue: if you go just west of the door, use magic > missile, you can _destroy_ walls around the door. Those walls are 'rock' > as arch, 'stone' as material. A few have 'no_magic' flags... but > missiles cross that, apparently. > If you fire south a few missiles, you'll destroy not the first wall, but > the second. So missiles _cross_ walls! > Also, having destroyed the 2nd, you can push the first wall south, and > enter the zone behind the door (walls have the 'can_roll' flag). > So simply with magic missile you can cross the door, without bothering > to activate the lever... This is now fixed. It wasn't a bug specific to the map - in fact, every boulder/rock on any map could be destroyed. I'm not sure the root cause. IT may have be related to material code, but I haven't bothered to look through the past to figure out the real cause - it isn't that important. The real issue, and what I fixed here, is that some objects just shouldn't be destroyable, no matter what material they are set (walls come to mind here also). So I jsut changed the code so that objects with no_pass set, which is mostly walls and those rocks, can't be destroyed by damage. _______________________________________________ crossfire-devel mailing 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 Dec 21 03:45:23 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:49 2005 Subject: [CF-Devel] Re: AW: [Crossfire-cvs] CVS commit: crossfire] In-Reply-To: <3FE4F6CA.2070606@sonic.net> References: <3FE28CE2.50303@sonic.net> <3FE47332.3080108@laposte.net> <3FE4F6CA.2070606@sonic.net> Message-ID: <3FE56BB3.3020505@laposte.net> > IMO, that is a broken fix. > > It should be expected that if you make a call to reset_object() that > none of the fields have any meaningful value. Thus, passing in data > that has been malloc'd should be perfectly valid (I think there may be > other areas of the code that do something similar, but not 100% sure). Seems you fixed in CVS already, many thanks. > Depends. get_object() provides objects on teh global linked list. > This is not always desirable - objects on the global list may get > processed in various ways, which you don't want to have happen to things > like the artifact objects. This is why I believe that it did in fact > malloc the data instead of using get_object() Hum ok. This just means the objects won't be reused, but since they are actual archetypes, shouldn't be an issue :) Note that the difference between reset_object & clear_object is another reason i feel like adding comments... (first will accept any uninitialized item, second needs valid/null pointers) 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 Dec 21 04:40:08 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:49 2005 Subject: [CF-Devel] Dragon claws & attack types Message-ID: <3FE57888.5030704@laposte.net> I checked on cf.mf.net why my dragon didn't have any special cold/fire/poison attack with clawing. Apparently, something is broken in attack type & such. I have 'clawing' skill, type 43 subtype 31. Then i have archetypes 'fire_clawing', 'poison_clawing', and so on. In player.c, dragon_ability_gain() checks treasure list's items for type '43' (skill). Except archetypes fire_clawing/... have the type 74 (skilltool). So my player has (global) attack type 1 (physical) only, and all archetypes for fire/electric/... attacks.... Now I don't know if the archetypes are not updated, or it the code checks the wrong thing. Also, should the attacktype be set for the player itself, or on a skill base? (ie set in the 'clawing' skill item, or on the player's attacktype?). Side note: i have in inventory multiple 'one handed weapons' (even though i'm a dragon) 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 Dec 21 17:32:21 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:49 2005 Subject: [CF-Devel] Dragon claws & attack types In-Reply-To: <3FE57888.5030704@laposte.net> References: <3FE57888.5030704@laposte.net> Message-ID: <1072049541.614.5.camel@oberon.Kameria> On Sun, 2003-12-21 at 05:40, Nicolas Weeger wrote: > I checked on cf.mf.net why my dragon didn't have any special cold/fire/poison > attack with clawing. > > Apparently, something is broken in attack type & such. > I have 'clawing' skill, type 43 subtype 31. > Then i have archetypes 'fire_clawing', 'poison_clawing', and so on. > > In player.c, dragon_ability_gain() checks treasure list's items for type '43' > (skill). Except archetypes fire_clawing/... have the type 74 (skilltool). > So my player has (global) attack type 1 (physical) only, and all archetypes for > fire/electric/... attacks.... > If anyone is in there fixing dragons I would like to remind them that there are some lovely colour dragon sprites so that the different dragon 'paths' can have a different colour faces. There are fully functional and animated black dragon, blue dragon, red dragon and green dragon faces - you only need to modify the dragon skill code... _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Tue Dec 23 22:44:08 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:49 2005 Subject: [CF-Devel] Dragon claws & attack types In-Reply-To: <3FE57888.5030704@laposte.net> References: <3FE57888.5030704@laposte.net> Message-ID: <3FE91998.3010900@sonic.net> Nicolas Weeger wrote: > I checked on cf.mf.net why my dragon didn't have any special > cold/fire/poison attack with clawing. > > Apparently, something is broken in attack type & such. > I have 'clawing' skill, type 43 subtype 31. > Then i have archetypes 'fire_clawing', 'poison_clawing', and so on. > > In player.c, dragon_ability_gain() checks treasure list's items for type > '43' (skill). Except archetypes fire_clawing/... have the type 74 > (skilltool). > So my player has (global) attack type 1 (physical) only, and all > archetypes for fire/electric/... attacks.... Looking at the code, it appears the code should be changed. That is because other code looks for objects of type skill, with skill name 'clawing' when we need to insert that skill object into the players inventory to hold experience. That is to say, if you change the archetype, then first time someone goes to use clawing, it may add the 'fire_clawing' archetype as the holder of skill exp. I'm not 100% satisfied that the method I coded, but this gets messy with the clawing code - I think right now that is the only skill where there are different skill type objects that give the exp into one skill. For example, there is only one 'two_handed_weapon' skill, and it basically gives the exp to itself. In any case, I'll update the code to check for the appropriate type. > > Now I don't know if the archetypes are not updated, or it the code > checks the wrong thing. > Also, should the attacktype be set for the player itself, or on a skill > base? (ie set in the 'clawing' skill item, or on the player's attacktype?). the clawing skill. If it gets set in the player attacktype, that gets reset the next time fix_player() is called (that goes and examines everything the player has equipped, and sets attacktype appropriate). In the case of using skills, when you go and use a combat skill (like clawing), it is marked as applied, so the fix_player sees that, and then sets the player attacktype appropriate. (interestingly enough, you could do something like have 'fire kung fu', which attacks with fire, simply by making the attacktype in that skill new skill fire). Now the one thing I do see that seems odd is that the attacktype of the new clawing ability is or'd with the existing attacktype. That would seem to mean that a dragon character could attack with fire, ice, poisoning, and electricity all with the claw attack. That seems wrong to me, so I'll fix that up. > > Side note: i have in inventory multiple 'one handed weapons' (even > though i'm a dragon) It's odd you have more than one. I could see that you would have exactly 1 (there isn't anything preventing you from learning the skill, even though you'd never be able to use it). But in that case, you should only have one. _______________________________________________ crossfire-devel mailing 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 Dec 23 22:54:38 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:49 2005 Subject: [CF-Devel] Dragon claws & attack types In-Reply-To: <1072049541.614.5.camel@oberon.Kameria> References: <3FE57888.5030704@laposte.net> <1072049541.614.5.camel@oberon.Kameria> Message-ID: <3FE91C0E.30401@sonic.net> Todd Mitchell wrote: > If anyone is in there fixing dragons I would like to remind them that > there are some lovely colour dragon sprites so that the different dragon > 'paths' can have a different colour faces. There are fully functional > and animated black dragon, blue dragon, red dragon and green dragon > faces - you only need to modify the dragon skill code... This isn't hard to do - I'll code it up quickly enough. For now, I've put this face changing at the same time you pick up the attacktype. That seems better than doing it at first ability (attunement) or last ability (special attack spell). I'll have to quickly test the code, make sure it works, then commit 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 Dec 23 23:32:36 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:49 2005 Subject: [CF-Devel] Got some time on my hands, time to stomp bugs. In-Reply-To: <3FE46225.9070103@laposte.net> References: <200312202258.14967.won_fang@yahoo.com.au> <3FE46225.9070103@laposte.net> Message-ID: <200312241532.36258.won_fang@yahoo.com.au> On Sun, 21 Dec 2003 12:52 am, Nicolas Weeger wrote: > Help me fix compilation warnings under Windows? Sorry, I don't do Windows B-). _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Wed Dec 24 02:59:30 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:50 2005 Subject: [CF-Devel] Dragon claws & attack types In-Reply-To: <3FE91998.3010900@sonic.net> References: <3FE57888.5030704@laposte.net> <3FE91998.3010900@sonic.net> Message-ID: <3FE95572.7000908@laposte.net> > the clawing skill. If it gets set in the player attacktype, that gets > reset the next time fix_player() is called (that goes and examines > everything the player has equipped, and sets attacktype appropriate). > > In the case of using skills, when you go and use a combat skill (like > clawing), it is marked as applied, so the fix_player sees that, and then > sets the player attacktype appropriate. > > (interestingly enough, you could do something like have 'fire kung fu', > which attacks with fire, simply by making the attacktype in that skill > new skill fire). I tweaked my attack type for 'clawing' skill to put poison + fire + ice + electricity, and right enough i do get the 'you poison xxx' messages (and monsters die), i don't have other attack messages though (like 'you set fire to xxx'). Don't know if i should have different attacktypes or not, i'll check the code. But i think monsters die more rapidly, so probably everything is all right. And i do get those attack types with perceive self. > Now the one thing I do see that seems odd is that the attacktype of the > new clawing ability is or'd with the existing attacktype. > > That would seem to mean that a dragon character could attack with fire, > ice, poisoning, and electricity all with the claw attack. That seems > wrong to me, so I'll fix that up. Actually, that was the behaviour with the old skill system, too. A dragon could have all attacktypes, which was pretty useful sometimes... (this is even mentioned in the dragon player guide, iirc) And if you look at the code, there is no place a dragon actually loses an attack type, or an ability spell, or xray. Same goes for attenuation, btw, a dragon can be attuned to the 4 paths. I think, also, the or is here to ensure the 'physical' attack type is still here - after all clawing is still physical damage :) > It's odd you have more than one. I could see that you would have > exactly 1 (there isn't anything preventing you from learning the skill, > even though you'd never be able to use it). But in that case, you > should only have one. I think another player has more'an one, too. I also think i had it by default (when i started), but i'm not 100% sure. Side note: i do have multiple in 'hidden' inventory, but i don't remember right on top of my head if i have multiple 'one hand weapons' using the 'skills' command - i'll check when i have time to. Also, it seems if you try to learn a skill scroll, and fail, you still get the exp holding object, thus the skill appears in 'skills' output. Not that a big issue, but may be confusion... 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 Dec 24 11:04:52 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:50 2005 Subject: [CF-Devel] Dragon claws & attack types In-Reply-To: <3FE91998.3010900@sonic.net> References: <3FE57888.5030704@laposte.net> <3FE91998.3010900@sonic.net> Message-ID: <200312241104.52872.eracclists@bellsouth.net> On Tuesday 23 December 2003 10:44 pm Mark Wedel wrote: [...] > That would seem to mean that a dragon character could attack with > fire, ice, poisoning, and electricity all with the claw attack. > That seems wrong to me, so I'll fix that up. [...] From a player, non-developer, perspective that is not wrong. It is as designed based on the information seen in the dragon player guide. A multitype claw attack is one of the *reasons* to play dragon characters. My $2 Gene -- Linux era4.eracc.UUCP 2.4.21-0.26mdk i686 10:58:27 up 1 day, 20:03, 8 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 Thu Dec 25 07:53:00 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:50 2005 Subject: [CF-Devel] Dragon claws & attack types References: <3FE91998.3010900@sonic.net> Message-ID: <14174.1072360380@www55.gmx.net> Hi, As I've written some of the original dragon code, a few words I wanna add - even though most of it has already been said. I think the dragon code "bugs" mentioned were caused by the changes of the new skill system. While that may be obvious, it should explain why some behaviour of the dragon code now looks strange or even wrong. The code was never of extraordinary quality, I apologize for that, but it seemed the best way to do it at the time. The reason for multiple archtypes working together for the functionality of the dragon code lies in the donation-mechanism which is based on treasurelists, and the race attributes based on skill forces. The challenge behind this was that the dragon code is specialized code, as a fact. Opposed to that, the CF server is supposed to be generic. It would be possible to simplify the dragon code more by rooting it more concretely into the code (which has already happened to a certain degree anyways), and reducing some of the archetype-logic. OTOH, from design perspective we strive for the latter and not the first. > Now the one thing I do see that seems odd is that the attacktype of > the new clawing ability is or'd with the existing attacktype. > > That would seem to mean that a dragon character could attack with > fire, ice, poisoning, and electricity all with the claw attack. > That seems wrong to me, so I'll fix that up. As others have said, or'd attacktypes are intended behaviour, and I plead not to remove this. Dragons cannot wield weapons, that's how it was supposed to be. Warriors are able to collect artifact weapons, and thus attack with multiple attacktypes. A number of three or four attacktypes per weapon is about normal here. Therefore, it seems only fair to me that dragons be able to accumulate attacktypes on their claws. Remember that dragon players have to gain levels in order to accomplish this. To get all attacktypes, quite a high level is needed (There is no reward for regaining lost experience, you really have to climb the ladder). If that is not enough, the treasurelists could be adjusted to grant attacktypes at even higher levels. I'm not sure if that is required though. AndreasV -- +++ GMX - die erste Adresse f?r Mail, Message, More +++ Neu: Preissenkung f?r MMS und FreeMMS! http://www.gmx.net _______________________________________________ crossfire-devel mailing 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 Dec 25 15:16:19 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:50 2005 Subject: [CF-Devel] Dragon claws & attack types In-Reply-To: <14174.1072360380@www55.gmx.net> References: <3FE91998.3010900@sonic.net> <14174.1072360380@www55.gmx.net> Message-ID: <3FEB53A3.7030807@sonic.net> Andreas Vogl wrote: > > The challenge behind this was that the dragon code is specialized > code, as a fact. Opposed to that, the CF server is supposed to be > generic. It would be possible to simplify the dragon code more by > rooting it more concretely into the code (which has already happened > to a certain degree anyways), and reducing some of the archetype-logic. > OTOH, from design perspective we strive for the latter and not the first. Specialized code is always necessary at some level - there is no real problem with it - it does sometimes create bugs, OTOH, it can sometimes avoid bugs. The one thing, looking at the code, that is too hardcoded for my liking is the determination of when to grant abilities (basically, every 5 levels, you get one of the abilities on the treasurelist, in the order they are given). This means for example that you can't easily say 'well, at level 3, he should get this special ability, level 12 this one, etc'. It is basically level 5, 10, 15 (relative to focus) It'd probably make more sense to use some of the other fields in the treasurelist to denote when to get the ability. Eg, use the 'magic' field (using existing abilities - ignoring the other thread about improved treasurelists) on when to get an ability. Thus, the existing treasurelists can be maintained by just putting 'magic 5/10/15' in the list. But one could add new ability at lower levels. if one wanted, without upsetting anything else. The other thing that could be done is add a new skill, like 'dragon ability' or something, and that is where exp from clawing things to death goes. But you culd then also use that skill for the special spells they get, and exp from those spells also goes to that skill. > As others have said, or'd attacktypes are intended behaviour, > and I plead not to remove this. I'll put that back. It just seems odd that something could attack with fire and cold at the some moment, but we'll ignore that detail. Going with the above thoughts about a 'dragon ability' type skill, one could see having the different attacktype skills broken apart. Eg, if you want to fire claw something to death, you ready the fire clawing skill. OTOH, that probably just makes it too much busy work on the part of the player to ready the different skill. _______________________________________________ crossfire-devel mailing 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 Dec 25 15:53:16 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:50 2005 Subject: [CF-Devel] Dragon claws & attack types In-Reply-To: <3FEB53A3.7030807@sonic.net> References: <3FE91998.3010900@sonic.net> <14174.1072360380@www55.gmx.net> <3FEB53A3.7030807@sonic.net> Message-ID: <3FEB5C4C.7030206@laposte.net> > I'll put that back. It just seems odd that something could attack with > fire and cold at the some moment, but we'll ignore that detail. > > Going with the above thoughts about a 'dragon ability' type skill, one > could see having the different attacktype skills broken apart. Eg, if > you want to fire claw something to death, you ready the fire clawing > skill. OTOH, that probably just makes it too much busy work on the part > of the player to ready the different skill. If we break down dragon ability, then i suggest some auto-selection for the attack type, much like the arrow one is down - ie select automatically based on monster's resistances. OTOH, clawing is clawing, whether you add fire or cold to your claws..... What could be done would be let a dragon use only one attacktype (poison/fire/cold/electricity) at the same time, but select it automatically - like, first attacks are poison to poison the opponent, then fire or cold or electric based on the resistances. This way you don't have all attacktypes at the same time as now, but you don't force the player to switch between all modes. 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 Dec 26 07:22:25 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:50 2005 Subject: [CF-Devel] Dragon claws & attack types References: <3FEB5C4C.7030206@laposte.net> Message-ID: <5639.1072444945@www65.gmx.net> In reply to Mark Wedel and Nicolas Weeger: > > The one thing, looking at the code, that is too hardcoded for > > my liking is the determination of when to grant abilities > > (basically, every 5 levels [...] > > > > It'd probably make more sense to use some of the other > > fields in the treasurelist to denote when to get the ability. > > Eg, use the 'magic' field (using existing abilities - ignoring > > the other thread about improved treasurelists) on when to > > get an ability. I agree, that would be an improvement. > > The other thing that could be done is add a new skill, like > > 'dragon ability' or something, and that is where exp from > > clawing things to death goes. But you culd then also use that > > skill for the special spells they get, and exp from > > those spells also goes to that skill. Yeah, that's a good point. In the old skill system that wouldn't have made much difference as the exp would probably have gone into the physical cathegory anyways - but now things are different. A dragon ability skill could make sense now. > What could be done would be let a dragon use only one attacktype > (poison/fire/cold/electricity) at the same time, but select it > automatically - like, first attacks are poison to poison the > opponent, then fire or cold or electric based on the resistances. > This way you don't have all attacktypes at the same time as now, > but you don't force the player to switch between all modes. When I recall correctly this would make no big difference. Having multiple attacktypes at once effectively means the best one strikes. The only exception AFAIK are the "special" effect attacktypes of which only poison is available to dragons. Apart from that, I believe that such things should better be done in the attack logic directly, instead of making the players' hands magically do something. Arrows are somewhat of an exceptional case, because selecting arrows is something everyone would expect is done by hand. Finally, looking at artifact weapons, many of them got multiple attacktypes (plus one extra for god blessing). Admittedly fire and cold is an especially weird combination, but I think there should be no harm in it. Ruggilli blessings on a frostbrand are possible too. AndreasV -- +++ GMX - die erste Adresse f?r Mail, Message, More +++ Neu: Preissenkung f?r MMS und FreeMMS! http://www.gmx.net _______________________________________________ crossfire-devel mailing 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 Dec 26 09:49:52 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:50 2005 Subject: [CF-Devel] Dragon claws & attack types In-Reply-To: <5639.1072444945@www65.gmx.net> References: <3FEB5C4C.7030206@laposte.net> <5639.1072444945@www65.gmx.net> Message-ID: <20031226154952.GF973@laranja.org> On Fri, Dec 26, 2003 at 02:22:25PM +0100, Andreas Vogl wrote: > > Finally, looking at artifact weapons, many of them got multiple > attacktypes (plus one extra for god blessing). Admittedly fire > and cold is an especially weird combination, but I think there > should be no harm in it. Ruggilli blessings on a frostbrand are > possible too. ...and to the rescue comes the Knight of Weird In-Game Logic. : Your claws are enveloped in a hot blazing fire! and : Your claws are covered with shards of ice! there's nothing mutually exclusive here, one thing can be covered with shards of ice and then enveloped in fire. Of course if this situation lasts long enough the ice will melt, but I suppose since it's magic, it's constantly regenerated (it would probably melt anyway once it hits something warm). In particular, that would be an incredibly nasty attack, due to thermal shock. Even better if it was possible for the ice to hit first, but you can't have everything ;-) []s, |alo +---- -- Those who trade freedom for security lose both and deserve neither. -- http://www.laranja.org/ mailto:lalo@laranja.org pgp key: http://www.laranja.org/pessoal/pgp GNU: never give up freedom http://www.gnu.org/ _______________________________________________ crossfire-devel mailing 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 Dec 26 18:42:37 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:50 2005 Subject: [CF-Devel] Dragon claws & attack types In-Reply-To: <20031226154952.GF973@laranja.org> References: <3FEB5C4C.7030206@laposte.net> <5639.1072444945@www65.gmx.net> <20031226154952.GF973@laranja.org> Message-ID: <3FECD57D.3010006@sonic.net> Perhaps that is what I found oddest about the multiple attacktypes - that you can get fire and cold at the same time. AV is right about attacktypes - when using multiple attacktypes, the one that does the most damage is the one that is used. Thus, if a weapon had 4 attack types, dam 10, and was used against a creature with new protection/immunities, it still just does 10 points of damage, and not 40. Effect attacktypes (confusion, slow, paralyze, etc) do go in addition to the damage - thus, you could have something with 4 effect attacktypes, and all of them effect the target (it may not mean a lot, eg, confusion, slow, and fear don't mean diddly if the target was also hit with paralyze). There has been a past discussion (and currently mentioned in the todo list) is to split out attacktypes, each with their own damage value. Thus, you could have something like: dam_fire 8 dam_physical 4 dam_cold 1 dam_poison 12 for a dragon. If that was done, then presumably the dragon code would need to get changed, such as levels are gained, the damage in the attacktype you are currently focused to increases. I suppose if we really cared about contradictory attacktypes, we should have a table or something about those that don't go together (fire/cold, no real other ones right now). Then variosu bits of code could do sanity checking (eg, blessing weapons don't give contradictory attacktype, 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 Dec 27 02:58:20 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:50 2005 Subject: [CF-Devel] Summoning bug: can't level up Message-ID: <3FED49AC.1020608@laposte.net> Hello. Yesterday i saw a player who couldn't cast 'summon lesser golem'. Checking some, the reason is pretty obvious: This player just learned summoning, thus his skill is 1. Lesser golem is level 1. The player worships Mostrai, so summoning repelled. So player lever becomes (see spell_util.c:caster_level) 1 - 2 (repelled) -> -1 Min level to cast (min_casting_level) is 1 - 2 -> -1 checked against <1 -> 1 So he simply can't cast the spell, and can't level up alone, need to party. I think the best way to fix is to check caster_level and return at least 1. Nicolas 'Ryo' _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Tue Dec 30 13:16:16 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:50 2005 Subject: [CF-Devel] Path: some more warning cleaning Message-ID: <3FF1CF00.4090406@laposte.net> Before the year ends, time to clean some more warnings :) Quick overview of (proposed) changes: * include/player.h: last_save_tick changed to long, for coherence with common/time.c * include/define.h: explicit cast to sint64 for slow penality (uses exp field) * common/loader.l: some explicit double-to-float casts, casting_time is integer, not float * server/disease.c: explicit float-to-int casts * server/egoitem.c: explicit cast to int * server/gods.c: strlen & strncmp use size_t, some explicit float-to-int casts * server/hiscore.c: strlen uses size_t * server/init.c: explicit double-to-float cast * server/monster.c: radius is unsigned int * server/move.c: explicit casts to sint16 * server/pets.c: added f at end of float constants Have a nice end of year! Nicolas 'Ryo' -------------- next part -------------- Index: include/player.h =================================================================== RCS file: /cvsroot/crossfire/crossfire/include/player.h,v retrieving revision 1.33 diff -u -r1.33 player.h --- include/player.h 13 Sep 2003 05:01:34 -0000 1.33 +++ include/player.h 30 Dec 2003 19:04:50 -0000 @@ -170,7 +170,7 @@ time_t last_save_time; #endif /* SAVE_INTERVAL */ #ifdef AUTOSAVE - uint32 last_save_tick; + long last_save_tick; #endif sint16 party_number; /* Party number this player is part of */ sint16 party_number_to_join; /* used when player wants to join a party */ Index: include/define.h =================================================================== RCS file: /cvsroot/crossfire/crossfire/include/define.h,v retrieving revision 1.70 diff -u -r1.70 define.h --- include/define.h 18 Dec 2003 20:39:45 -0000 1.70 +++ include/define.h 30 Dec 2003 19:04:53 -0000 @@ -559,7 +559,7 @@ #define NROFNEWOBJS(xyz) ((xyz)->stats.food) #define SLOW_PENALTY(xyz) ((xyz)->stats.exp)/1000.0 -#define SET_SLOW_PENALTY(xyz,fl) (xyz)->stats.exp=(fl)*1000 +#define SET_SLOW_PENALTY(xyz,fl) (xyz)->stats.exp=( sint64 )( (fl)*1000 ) #define SET_GENERATE_TYPE(xyz,va) (xyz)->stats.sp=(va) #define GENERATE_TYPE(xyz) ((xyz)->stats.sp) #define GENERATE_SPEED(xyz) ((xyz)->stats.maxsp) /* if(!RANDOM()%) */ Index: common/loader.l =================================================================== RCS file: /cvsroot/crossfire/crossfire/common/loader.l,v retrieving revision 1.55 diff -u -r1.55 loader.l --- common/loader.l 11 Nov 2003 07:58:30 -0000 1.55 +++ common/loader.l 30 Dec 2003 19:05:44 -0000 @@ -603,13 +603,13 @@ ^last_sp{S} op->last_sp = IVAL; ^last_grace{S} op->last_grace = IVAL; ^last_eat{S} op->last_eat = IVAL; -^speed{S} { op->speed = FVAL; +^speed{S} { op->speed = ( float )FVAL; if (!(map_flags & MAP_STYLE)) { - if (op->speed<0) op->speed_left = op->speed_left-RANDOM()%100/100.0; + if (op->speed<0) op->speed_left = op->speed_left-RANDOM()%100/100.0f; update_ob_speed(op); } } -^speed_left{S} op->speed_left = FVAL; +^speed_left{S} op->speed_left = ( float )FVAL; ^slow_move{S} { SET_SLOW_PENALTY(op,FVAL); SET_FLAG(op, FLAG_SLOW_MOVE); } @@ -851,7 +851,7 @@ ^can_dam_armour{S} { } ^weapontype{S} op->weapontype = IVAL; ^tooltype{S} op->tooltype = IVAL; -^casting_time{S} op->casting_time = FVAL; +^casting_time{S} op->casting_time = IVAL; ^elevation{S} op->elevation = IVAL; ^smoothlevel{S} op->smoothlevel = IVAL; ^client_type{S} op->client_type = IVAL; Index: server/disease.c =================================================================== RCS file: /cvsroot/crossfire/crossfire/server/disease.c,v retrieving revision 1.27 diff -u -r1.27 disease.c --- server/disease.c 13 Sep 2003 05:02:09 -0000 1.27 +++ server/disease.c 30 Dec 2003 19:06:35 -0000 @@ -458,7 +458,7 @@ float scale; symptom->value += disease->stats.ac; - scale = 1.0 + symptom->value/100.0; + scale = 1.0f + symptom->value/100.0f; /* now rescale all the debilities */ symptom->stats.Str = (int) (scale*disease->stats.Str); symptom->stats.Dex = (int) (scale*disease->stats.Dex); @@ -521,10 +521,10 @@ } if(symptom->stats.dam > 0) hit_player(victim,symptom->stats.dam,symptom,symptom->attacktype); - else hit_player(victim,MAX(1,-victim->stats.maxhp * symptom->stats.dam / 100.0),symptom,symptom->attacktype); + else hit_player(victim,( int )MAX(1,-victim->stats.maxhp * symptom->stats.dam / 100.0),symptom,symptom->attacktype); if(symptom->stats.maxsp>0) sp_reduce = symptom->stats.maxsp; - else sp_reduce = MAX(1,victim->stats.maxsp * symptom->stats.maxsp/100.0); + else sp_reduce = ( int )MAX(1,( victim->stats.maxsp * symptom->stats.maxsp/100.0 )); victim->stats.sp = MAX(0,victim->stats.sp - sp_reduce); /* create the symptom "other arch" object and drop it here Index: server/egoitem.c =================================================================== RCS file: /cvsroot/crossfire/crossfire/server/egoitem.c,v retrieving revision 1.4 diff -u -r1.4 egoitem.c --- server/egoitem.c 14 Oct 2001 07:57:14 -0000 1.4 +++ server/egoitem.c 30 Dec 2003 19:06:35 -0000 @@ -54,7 +54,7 @@ power_space = crystal->stats.maxsp - crystal->stats.sp; power_grab = 0; if(available_power>=0 && power_space> 0 ) - power_grab = MIN ( power_space, 0.5 * op->stats.sp ); + power_grab = ( int )MIN ( power_space, 0.5 * op->stats.sp ); if(available_power < 0 && crystal->stats.sp >0 ) power_grab = - MIN( -available_power, crystal->stats.sp); Index: server/gods.c =================================================================== RCS file: /cvsroot/crossfire/crossfire/server/gods.c,v retrieving revision 1.38 diff -u -r1.38 gods.c --- server/gods.c 10 Nov 2003 05:39:50 -0000 1.38 +++ server/gods.c 30 Dec 2003 19:06:39 -0000 @@ -43,7 +43,8 @@ #endif int lookup_god_by_name(char *name) { - int godnr=-1,nmlen = strlen(name); + int godnr=-1; + size_t nmlen = strlen(name); if(name && strcmp(name,"none")) { godlink *gl; @@ -782,9 +783,9 @@ if (item->type == BOOK && item->invisible && strcmp (item->name, "restore spellpoints") == 0) { - int max = op->stats.maxsp * (item->stats.maxsp / 100.0); + int max = ( int )( op->stats.maxsp * (item->stats.maxsp / 100.0) ); /* Restore to 50 .. 100%, if sp < 50% */ - int new_sp = random_roll(1000, 1999, op, PREFER_HIGH) / 2000.0 * max; + int new_sp = ( int )( random_roll(1000, 1999, op, PREFER_HIGH) / 2000.0 * max ); if (op->stats.sp >= max / 2) continue; new_draw_info (NDI_UNIQUE, 0, op, "A blue lightning strikes " @@ -930,7 +931,7 @@ if (skop->type == SKILL && skop->subtype == SK_PRAYING) break; if (skop) - loss = 0.05 * (float) skop->stats.exp; + loss = ( int )( 0.05 * (float) skop->stats.exp ); change_exp(op, -random_roll(0, loss*angry-1, op, PREFER_LOW), skop?skop->skill:"none", SK_SUBTRACT_SKILL_EXP); if(random_roll(0, angry, op, PREFER_LOW)) { Index: server/hiscore.c =================================================================== RCS file: /cvsroot/crossfire/crossfire/server/hiscore.c,v retrieving revision 1.9 diff -u -r1.9 hiscore.c --- server/hiscore.c 8 Mar 2003 05:35:32 -0000 1.9 +++ server/hiscore.c 30 Dec 2003 19:06:40 -0000 @@ -314,7 +314,8 @@ void display_high_score(object *op,int max, char *match) { FILE *fp; char buf[MAX_BUF],*scorebuf, *bp, *cp; - int i=0,j=0,maxchar=80,comp; + int i=0,j=0,comp; + size_t maxchar=80; score *sc; sprintf(buf,"%s/%s",settings.localdir,HIGHSCORE); Index: server/init.c =================================================================== RCS file: /cvsroot/crossfire/crossfire/server/init.c,v retrieving revision 1.53 diff -u -r1.53 init.c --- server/init.c 27 Oct 2003 03:44:33 -0000 1.53 +++ server/init.c 30 Dec 2003 19:06:42 -0000 @@ -584,7 +584,7 @@ cp); } } else if (!strcasecmp(buf, "item_power_factor")) { - float tmp = atof(cp); + float tmp = ( float )atof(cp); if (tmp < 0) LOG(llevError, "load_settings: item_power_factor must be a postive number (%f < 0)\n", tmp); Index: server/monster.c =================================================================== RCS file: /cvsroot/crossfire/crossfire/server/monster.c,v retrieving revision 1.67 diff -u -r1.67 monster.c --- server/monster.c 26 Oct 2003 06:56:57 -0000 1.67 +++ server/monster.c 30 Dec 2003 19:06:46 -0000 @@ -241,7 +241,7 @@ */ int check_wakeup(object *op, object *enemy, rv_vector *rv) { - int radius = op->stats.Wis>MIN_MON_RADIUS?op->stats.Wis:MIN_MON_RADIUS; + unsigned int radius = op->stats.Wis>MIN_MON_RADIUS?op->stats.Wis:MIN_MON_RADIUS; /* Trim work - if no enemy, no need to do anything below */ if (!enemy) return 0; Index: server/move.c =================================================================== RCS file: /cvsroot/crossfire/crossfire/server/move.c,v retrieving revision 1.29 diff -u -r1.29 move.c --- server/move.c 4 Sep 2003 06:25:32 -0000 1.29 +++ server/move.c 30 Dec 2003 19:06:47 -0000 @@ -232,8 +232,8 @@ if (tele_type == SHOP_MAT && user->type == PLAYER) { for (k=1; k<9; k++) { if (!(get_map_flags(other_teleporter->map, NULL, - other_teleporter->x + freearr_x[k], - other_teleporter->y + freearr_y[k], NULL,NULL) & + ( sint16 )( other_teleporter->x + freearr_x[k] ), + ( sint16 )( other_teleporter->y + freearr_y[k] ), NULL,NULL) & (P_NO_PASS | P_OUT_OF_MAP))) break; } if (k==9) { Index: server/pets.c =================================================================== RCS file: /cvsroot/crossfire/crossfire/server/pets.c,v retrieving revision 1.18 diff -u -r1.18 pets.c --- server/pets.c 13 Sep 2003 05:02:11 -0000 1.18 +++ server/pets.c 30 Dec 2003 19:06:49 -0000 @@ -640,8 +640,8 @@ else tmp->stats.dam= spob->stats.dam + SP_level_dam_adjust(caster,spob); - tmp->speed += .02 * SP_level_range_adjust(caster,spob); - tmp->speed = MIN(tmp->speed, 1.0); + tmp->speed += .02f * SP_level_range_adjust(caster,spob); + tmp->speed = MIN(tmp->speed, 1.0f); if (spob->attacktype) tmp->attacktype = spob->attacktype; } tmp->stats.wc -= SP_level_range_adjust(caster,spob); -------------- next part -------------- _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Tue Dec 30 17:08:30 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:50 2005 Subject: [CF-Devel] Summoning bug: can't level up In-Reply-To: <3FED49AC.1020608@laposte.net> References: <3FED49AC.1020608@laposte.net> Message-ID: <20031230200830.21f4c008.kstenger@adinet.com.uy> > So player lever becomes (see spell_util.c:caster_level) 1 - 2 (repelled) -> -1 > Min level to cast (min_casting_level) is 1 - 2 -> -1 checked against <1 -> 1 > > So he simply can't cast the spell, and can't level up alone, need to party. > > I think the best way to fix is to check caster_level and return at least 1. Maybe a way to solve this relatively easy and intuitive could be instead of doing "current_level -2" to calculate the repelled level calculate it like "(int)(current_level * percentage)" percentage beeing some number between 0.8 and 0.99 perhaps? Maybe even lower, i'm just saying a number. I thought about this way cause after helping that guy to grow up in his summoning skill (wich had to be up to level 5 and not 3 as anyone would supose) he would have such a hard work to level up from 5 to 6 using just the summon lesser golem spell, but if it was by percentage that would also be solved. Not in my best day, do i explain myself? -- +-----------------------------+ | 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 Dec 30 20:12:32 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:50 2005 Subject: [CF-Devel] Summoning bug: can't level up In-Reply-To: <20031230200830.21f4c008.kstenger@adinet.com.uy> References: <3FED49AC.1020608@laposte.net> <20031230200830.21f4c008.kstenger@adinet.com.uy> Message-ID: <20031231021232.GJ6188@laranja.org> On Tue, Dec 30, 2003 at 08:08:30PM -0300, Karla Stenger wrote: > Maybe a way to solve this relatively easy and intuitive could be instead of > doing "current_level -2" to calculate the repelled level calculate it like > "(int)(current_level * percentage)" percentage beeing some number between 0.8 > and 0.99 perhaps? Maybe even lower, i'm just saying a number. Hey neighbor! You have my vote, not only this solves the proposed problem, but it also makes repelled paths *more* cumbersome at higher levels, which I think is desirable. (Once you're past level 50, 2 levels aren't a lot) []s, |alo +---- -- Those who trade freedom for security lose both and deserve neither. -- http://www.laranja.org/ mailto:lalo@laranja.org pgp key: http://www.laranja.org/pessoal/pgp GNU: never give up freedom http://www.gnu.org/ _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel