From owner-crossfire Sat Oct 5 01:44:01 1996 Return-Path: Received: (from mdomo@localhost) by ifi.uio.no (8.6.11/ifi2.4) id for crossfire-ut ; Sat, 5 Oct 1996 01:44:01 +0200 Received: from acrux.is.s.u-tokyo.ac.jp (acrux.is.s.u-tokyo.ac.jp [133.11.14.5]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Sat, 5 Oct 1996 01:43:56 +0200 Received: from rigel.sl.um.u-tokyo.ac.jp by acrux.is.s.u-tokyo.ac.jp (8.7.6/TISN-1.3/R3) id IAA10027; Sat, 5 Oct 1996 08:43:52 +0900 (JST) From: MANNEN Akihiro Received: by rigel.sl.um.u-tokyo.ac.jp (8.7.5/TISN-1.0N/1.8) id IAA04462; Sat, 5 Oct 1996 08:43:52 +0900 (JST) Date: Sat, 5 Oct 1996 08:43:52 +0900 (JST) Message-Id: <199610042343.IAA04462@rigel.sl.um.u-tokyo.ac.jp> Mime-Version: 1.0 To: crossfire@ifi.uio.no Subject: CF: patch for Improvement scroll Sender: owner-crossfire Precedence: bulk Status: RO This is a report from Japanese crossfire maling-list. If character use improvement scroll without mark to item (use mark command), the game is crash. Because NON-mark code doesn't exist in program. We refer to torch code to make this patch. patch for server/apply.c *** apply.c Mon Sep 30 14:53:55 1996 --- apply.c.new Thu Oct 3 09:24:39 1996 *************** *** 769,785 **** } } #endif ! if (otmp->type!=WEAPON) { ! new_draw_info(NDI_UNIQUE, 0,op,"Marked item is not a weapon"); ! return 0; ! } ! new_draw_info(NDI_UNIQUE, 0,op,"Applied weapon builder."); ! improve_weapon(op,tmp,otmp); ! if (op->contr->eric_server > 0) ! esrv_send_item(op, tmp); ! else ! draw_inventory(op); ! return 1; } /* archetypes don't contain any MONEY_CHANGER object, --- 769,788 ---- } } #endif ! if (otmp) { ! if (otmp->type!=WEAPON) { ! new_draw_info(NDI_UNIQUE, 0,op,"Marked item is not a weapon"); ! return 0; ! } ! new_draw_info(NDI_UNIQUE, 0,op,"Applied weapon builder."); ! improve_weapon(op,tmp,otmp); ! if (op->contr->eric_server > 0) ! esrv_send_item(op, tmp); ! else ! draw_inventory(op); ! return 1; ! } else ! new_draw_info(NDI_UNIQUE, 0,op,"You need to mark a weapon."); } /* archetypes don't contain any MONEY_CHANGER object, *************** *** 1944,1966 **** ||op->inv->type==BRACERS || op->inv->type==SHIELD ||op->inv->type==HELMET) #endif ! if (armor->type==ARMOUR ! || armor->type==CLOAK ! || armor->type==BOOTS || armor->type==GLOVES ! ||armor->type==BRACERS || armor->type==SHIELD ! ||armor->type==HELMET) ! { new_draw_info(NDI_UNIQUE, 0,op,"Applying armour enchantment."); improve_armour(op,tmp,armor); ! if (op->contr->eric_server > 0) ! esrv_send_item(op, tmp); else ! draw_inventory(op); return 1; ! } new_draw_info(NDI_UNIQUE, 0,op,"Your marked item is not armour!\n"); return 0; } --- 1947,1973 ---- ||op->inv->type==BRACERS || op->inv->type==SHIELD ||op->inv->type==HELMET) #endif ! if (armor) { ! if (armor->type==ARMOUR ! || armor->type==CLOAK ! || armor->type==BOOTS || armor->type==GLOVES ! ||armor->type==BRACERS || armor->type==SHIELD ! ||armor->type==HELMET) ! { new_draw_info(NDI_UNIQUE, 0,op,"Applying armour enchantment."); improve_armour(op,tmp,armor); ! if (op->contr->eric_server > 0) ! esrv_send_item(op, tmp); else ! draw_inventory(op); return 1; ! } new_draw_info(NDI_UNIQUE, 0,op,"Your marked item is not armour!\n"); + } else + new_draw_info(NDI_UNIQUE, 0,op,"You need to mark a armour."); + return 0; } *************** *** 2496,2501 **** save_throw_object(item,AT_FIRE); } else /* nothing to light */ ! new_draw_info(NDI_UNIQUE, 0,who,"You need to mark a lightable object"); } --- 2503,2508 ---- save_throw_object(item,AT_FIRE); } else /* nothing to light */ ! new_draw_info(NDI_UNIQUE, 0,who,"You need to mark a lightable object."); } Sorry, my English is poor. -- Mannen Akihiro mannen@is.s.u-tokyo.ac.jp Department of Information Science, Faculty of Science University of Tokyo From owner-crossfire Sat Oct 5 01:39:47 1996 Return-Path: Received: (from mdomo@localhost) by ifi.uio.no (8.6.11/ifi2.4) id for crossfire-ut ; Sat, 5 Oct 1996 01:39:47 +0200 Received: from dragoncat.net (jtraub@herne.dragoncat.net [204.137.132.225]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Sat, 5 Oct 1996 01:39:41 +0200 Received: (from jtraub@localhost) by dragoncat.net (8.7.6/8.7.3) id QAA30995; Fri, 4 Oct 1996 16:39:50 -0700 Date: Fri, 4 Oct 1996 16:39:50 -0700 From: JT Traub Message-Id: <199610042339.QAA30995@dragoncat.net> Mime-Version: 1.0 To: murray@indigo2.scri.fsu.edu Subject: Re: CF: bugs in 0.92.7 Cc: crossfire@ifi.uio.no Sender: owner-crossfire Precedence: bulk Status: RO I sent Mark a patch for the Armor and Weapon improvement scrolls crashing the game yesterday.. They will only crash the game if you haven't marked an object for them to be applied to. The fix is to check the return value of find_marked_object() to make sure it's not NULL in two places in apply.c I've included the patch below for anyone else who needs it. *** apply.c.orig Thu Oct 3 15:02:08 1996 --- apply.c Thu Oct 3 15:05:45 1996 *************** *** 767,776 **** --- 767,780 ---- new_draw_info(NDI_UNIQUE,0,op,"You have no weapon to enchant.\n"); return 0; } } #endif + if(!otmp) { + new_draw_info(NDI_UNIQUE, 0, op, "You need to mark a weapon object."); + return 0; + } if (otmp->type!=WEAPON) { new_draw_info(NDI_UNIQUE, 0,op,"Marked item is not a weapon"); return 0; } new_draw_info(NDI_UNIQUE, 0,op,"Applied weapon builder."); *************** *** 1942,1951 **** --- 1946,1959 ---- || op->inv->type==CLOAK || op->inv->type==BOOTS || op->inv->type==GLOVES ||op->inv->type==BRACERS || op->inv->type==SHIELD ||op->inv->type==HELMET) #endif + if(!armor) { + new_draw_info(NDI_UNIQUE, 0, op, "You need to mark an armor object."); + return 0; + } if (armor->type==ARMOUR || armor->type==CLOAK || armor->type==BOOTS || armor->type==GLOVES ||armor->type==BRACERS || armor->type==SHIELD ||armor->type==HELMET) From owner-crossfire Sat Oct 5 01:06:59 1996 Return-Path: Received: (from mdomo@localhost) by ifi.uio.no (8.6.11/ifi2.4) id for crossfire-ut ; Sat, 5 Oct 1996 01:06:59 +0200 Received: from acrux.is.s.u-tokyo.ac.jp (acrux.is.s.u-tokyo.ac.jp [133.11.14.5]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Sat, 5 Oct 1996 01:06:53 +0200 Received: from rigel.sl.um.u-tokyo.ac.jp by acrux.is.s.u-tokyo.ac.jp (8.7.6/TISN-1.3/R3) id IAA09970; Sat, 5 Oct 1996 08:06:51 +0900 (JST) From: MANNEN Akihiro Received: by rigel.sl.um.u-tokyo.ac.jp (8.7.5/TISN-1.0N/1.8) id IAA04374; Sat, 5 Oct 1996 08:06:51 +0900 (JST) Date: Sat, 5 Oct 1996 08:06:51 +0900 (JST) Message-Id: <199610042306.IAA04374@rigel.sl.um.u-tokyo.ac.jp> Mime-Version: 1.0 To: crossfire@ifi.uio.no Subject: CF: patches for savethrow & regeneration Sender: owner-crossfire Precedence: bulk Status: RO This is a report from Japanese crossfire mailing-list. 1) Character max level is 110 now. But elements of savethrow array are 101 yet. We adopt "1" for 101-110 level savethrow value on this patch, however, I don't know it is a right. 2) There are no regeneration codes in living.c. So regereration variables doesn't change on 0.92.7. Regeneration variables in character save-file (gen_hp,gen_sp, gen_grace,digestion) may be different from right value. So you must check save-files after use this patch. patch for common/living.c *** living.c.orig Fri Oct 4 14:51:11 1996 --- living.c.new Fri Oct 4 15:29:37 1996 *************** *** 196,208 **** /* Max level is 100. By making it 101, it means values 0->100 are valid. * Thus, we can use op->level directly, and it also works for level 0 people. */ ! int savethrow[101]={ 18, 18,17,16,15,14,14,13,13,12,12,12,11,11,11,11,10,10,10,10, 9, 9, 9, 9, 9, 8, 8, 8, 8, 8, 8, 7, 7, 7, 7, 7, 7, 7, 6, 6, 6, 6, 6, 6, 6, 6, 5, 5, 5, 5, 5, 5, 5, 5, 5, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 2, 2, 2, 2, 2, ! 2, 2, 2, 2, 2, 2, 2, 2, 2, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1 }; int object_saves[NROFATTACKS][NROFMATERIALS] = { --- 196,209 ---- /* Max level is 100. By making it 101, it means values 0->100 are valid. * Thus, we can use op->level directly, and it also works for level 0 people. */ ! int savethrow[111]={ 18, 18,17,16,15,14,14,13,13,12,12,12,11,11,11,11,10,10,10,10, 9, 9, 9, 9, 9, 8, 8, 8, 8, 8, 8, 7, 7, 7, 7, 7, 7, 7, 6, 6, 6, 6, 6, 6, 6, 6, 5, 5, 5, 5, 5, 5, 5, 5, 5, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 2, 2, 2, 2, 2, ! 2, 2, 2, 2, 2, 2, 2, 2, 2, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, ! 1, 1, 1, 1, 1, 1, 1, 1, 1, 1 }; int object_saves[NROFATTACKS][NROFMATERIALS] = { *************** *** 572,577 **** --- 573,579 ---- (*draw_info_func)(NDI_UNIQUE, 0, op,"You feel less lucky."); } if(tmp->stats.hp && op->type==PLAYER) { + op->contr->gen_hp+=tmp->stats.hp*flag; if(flag*tmp->stats.hp>0) (*draw_info_func)(NDI_UNIQUE, 0, op,"You feel much more healthy!"); else *************** *** 578,583 **** --- 580,586 ---- (*draw_info_func)(NDI_UNIQUE, 0, op,"You feel much less healthy!"); } if(tmp->stats.sp && op->type==PLAYER && tmp->type!=SKILL) { + op->contr->gen_sp+=tmp->stats.sp*flag; if(flag*tmp->stats.sp>0) (*draw_info_func)(NDI_UNIQUE, 0, op,"You feel one with the powers of magic!"); else *************** *** 585,596 **** } /* for the future when artifacts set this -b.t. */ if(tmp->stats.grace && op->type==PLAYER) { ! if(flag*tmp->stats.grace>0) (*draw_info_func)(NDI_UNIQUE, 0, op,"You feel closer to your god!"); else (*draw_info_func)(NDI_UNIQUE, 0, op,"You suddenly feel less holy."); } if(tmp->stats.food && op->type==PLAYER) { if(tmp->stats.food*flag>0) (*draw_info_func)(NDI_UNIQUE, 0, op,"You feel your digestion slowing down."); else --- 588,601 ---- } /* for the future when artifacts set this -b.t. */ if(tmp->stats.grace && op->type==PLAYER) { ! op->contr->gen_grace+=tmp->stats.grace*flag; ! if(flag*tmp->stats.grace>0) (*draw_info_func)(NDI_UNIQUE, 0, op,"You feel closer to your god!"); else (*draw_info_func)(NDI_UNIQUE, 0, op,"You suddenly feel less holy."); } if(tmp->stats.food && op->type==PLAYER) { + op->contr->digestion+=tmp->stats.food*flag; if(tmp->stats.food*flag>0) (*draw_info_func)(NDI_UNIQUE, 0, op,"You feel your digestion slowing down."); else patch for include/living.h *** living.h.orig Fri Oct 4 15:02:07 1996 --- living.h.new Fri Oct 4 15:03:09 1996 *************** *** 43,49 **** extern int turn_bonus[MAX_STAT + 1]; extern int max_carry[MAX_STAT + 1]; extern int dam_bonus[MAX_STAT + 1]; ! extern int savethrow[101]; extern int turn_bonus[MAX_STAT + 1]; extern int object_saves[NROFATTACKS][NROFMATERIALS]; extern int learn_spell[]; --- 43,49 ---- extern int turn_bonus[MAX_STAT + 1]; extern int max_carry[MAX_STAT + 1]; extern int dam_bonus[MAX_STAT + 1]; ! extern int savethrow[111]; extern int turn_bonus[MAX_STAT + 1]; extern int object_saves[NROFATTACKS][NROFMATERIALS]; extern int learn_spell[]; Sorry, May English is poor. -- Mannen Akihiro mannen@is.s.u-tokyo.ac.jp Department of Information Science, Faculty of Science University of Tokyo From owner-crossfire Sat Oct 5 00:25:37 1996 Return-Path: Received: (from mdomo@localhost) by ifi.uio.no (8.6.11/ifi2.4) id for crossfire-ut ; Sat, 5 Oct 1996 00:25:37 +0200 Received: from acrux.is.s.u-tokyo.ac.jp (acrux.is.s.u-tokyo.ac.jp [133.11.14.5]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Sat, 5 Oct 1996 00:25:31 +0200 Received: from rigel.sl.um.u-tokyo.ac.jp by acrux.is.s.u-tokyo.ac.jp (8.7.6/TISN-1.3/R3) id HAA09879; Sat, 5 Oct 1996 07:25:28 +0900 (JST) From: MANNEN Akihiro Received: by rigel.sl.um.u-tokyo.ac.jp (8.7.5/TISN-1.0N/1.8) id HAA04270; Sat, 5 Oct 1996 07:25:28 +0900 (JST) Date: Sat, 5 Oct 1996 07:25:28 +0900 (JST) Message-Id: <199610042225.HAA04270@rigel.sl.um.u-tokyo.ac.jp> Mime-Version: 1.0 To: crossfire@ifi.uio.no Subject: CF: praying on altar BUG (patch) Sender: owner-crossfire Precedence: bulk Status: RO Hello all, This is a report from Japanese crossfire mailing-list. When a character pray on a altar, he can learn a cleric spell sometimes. But in this version, character can lern NON-cleric spell too!! (e.g. haste,hellfire...) patch for server/gods.c *** gods.c.orig Sat Oct 5 06:19:01 1996 --- gods.c Sat Oct 5 06:19:20 1996 *************** *** 276,282 **** /*generate a random rare clerical spell*/ spell=RANDOM()%NROFREALSPELLS; ! while(spells[spell].books && !spells[spell].cleric) { spell++; if (spell >= NROFREALSPELLS) spell = 0; --- 276,282 ---- /*generate a random rare clerical spell*/ spell=RANDOM()%NROFREALSPELLS; ! while(spells[spell].books || !spells[spell].cleric) { spell++; if (spell >= NROFREALSPELLS) spell = 0; Sorry, My English is poor. -- Mannen Akihiro mannen@is.s.u-tokyo.ac.jp Department of Information Science, Faculty of Science University of Tokyo From owner-crossfire Fri Oct 4 23:50:26 1996 Return-Path: Received: (from mdomo@localhost) by ifi.uio.no (8.6.11/ifi2.4) id for crossfire-ut ; Fri, 4 Oct 1996 23:50:26 +0200 Received: from mailer.scri.fsu.edu (mailer.scri.fsu.edu [144.174.112.142]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Fri, 4 Oct 1996 23:50:20 +0200 Received: from indigo2.scri.fsu.edu (indigo2.scri.fsu.edu [144.174.128.47]) by mailer.scri.fsu.edu (8.7.5/8.7.5) with SMTP id RAA22560 for <@mailer.scri.fsu.edu:crossfire@ifi.uio.no>; Fri, 4 Oct 1996 17:50:14 -0400 (EDT) Received: by indigo2.scri.fsu.edu (940816.SGI.8.6.9/931108.SGI.AUTO.ANONFTP) id RAA08578; Fri, 4 Oct 1996 17:50:42 -0400 Date: Fri, 4 Oct 1996 17:50:42 -0400 From: murray@indigo2.scri.fsu.edu (John R. Murray) Message-Id: <199610042150.RAA08578@indigo2.scri.fsu.edu> Mime-Version: 1.0 To: crossfire@ifi.uio.no Subject: CF: bugs in 0.92.7 Cc: murray@indigo2.scri.fsu.edu Sender: owner-crossfire Precedence: bulk Status: RO I've found the following reproducible (well, on my machine, at least) bugs in cf0.92.7 1) (fairly trivial) I found that typing "'use_skill" does the appropriate thing, but "'use_skill " (note extra space) crashes the game. I don't have a stack trace for this one yet, but I'll get one if no one else is seeing this. 2) (more damaging) Weapon and armour improvement scrolls crash the game. I've tried this with old characters, newly created characters, old scrolls, newly bought scrolls, already enchanted weapons and plain old weapons, and the result is the same each time upon attempting to apply one: immediate crash. Here's a stack trace from the last crash (an attempt to apply Enchant Armour): (dbx) where 0 _kill(0x205b, 0x6, 0x7fffa710, 0x0) ["kill.s":15, 0xfae25d4] 1 raise(0x6, 0x6, 0x7fffa710, 0x0) ["raise.c":22, 0xfae3928] 2 abort(0x205b, 0x6, 0x7fffa710, 0x0) ["abort.c":37, 0xfb17354] 3 fatal_signal(0x1, 0x1, 0x7fffa710, 0x0) ["init.c":516, 0x433d0c] 4 rec_sigsegv(0xb, 0x6, 0x7fffa710, 0x0) ["init.c":460, 0x433a50] 5 _sigtramp(0x205b, 0x6, 0x7fffa7d0, 0x0) ["sigtramp.s":59, 0xfad5958] > 6 apply(0x101cb9f0, 0x1032d870, 0x1c, 0x10177fac) ["apply.c":1947, 0x41a480] 7 handle_buttonpress(0x101cb9f0, 0x15, 0x1c, 0x10177fac) ["player.c":1654, 0x450484] 8 handle_player(0x101cb9f0, 0x15, 0x1c, 0x10177fac) ["player.c":2049, 0x451e28] 9 process_players1(0x0, 0x15, 0x1c, 0x10177fac) ["main.c":544, 0x440858] 10 process_events(0x0, 0x15, 0x1c, 0x10177fac) ["main.c":619, 0x440c08] 11 main(0x2, 0x7fffaf4c, 0x7fffaf58, 0x10177fac) ["main.c":858, 0x441894] 12 __start() ["crt1text.s":133, 0x411a4c] (dbx) list > 1940 return 0; 1941 if (op->inv->type==ARMOUR 1942 || op->inv->type==CLOAK 1943 || op->inv->type==BOOTS || op->inv->type==GLOVES 1944 ||op->inv->type==BRACERS || op->inv->type==SHIELD 1945 ||op->inv->type==HELMET) 1946 #endif *1947 if (armor->type==ARMOUR 1948 || armor->type==CLOAK 1949 || armor->type==BOOTS || armor->type==GLOVES This is on SGI IRIX 5.3 -- John R. Murray murray@indigo2.scri.fsu.edu http://www.scri.fsu.edu/~murray/ FSU Aikido Club/North Florida Aikikai home of Miko's Aikido MPEGs and the Tallahassee, FL WWW Aikido online calendar of events From owner-crossfire Fri Oct 4 16:02:05 1996 Return-Path: Received: from capp.cap.se (capp.cap.se [192.176.199.25]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Fri, 4 Oct 1996 16:02:05 +0200 From: ian.vitek@capgemini.se Received: from smtp ([192.176.198.70]) by capp.cap.se (8.7.5/8.7.3) with SMTP id PAA03370; Fri, 4 Oct 1996 15:05:39 +0100 (MET) Message-Id: <199610041405.PAA03370@capp.cap.se> Date: Fri, 4 Oct 1996 16:02:19 +0100 To: master@rahul.net, crossfire-bugs@ifi.uio.no Subject: making crossfire... :( MIME-version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: quoted-printable X-Mailer: TFS Gateway /220000000/220020140/220000469/220120025/ Status: RO Ahrrg! :) Hello! Sorry for disturbing the peace! =20 I realy wanna play... =20 I wanna play crossfire-0.92.7 on my solaris 2.5 in openwindows. It seems to compile in gcc. =20 The history so far... =20 Prolog: edit 'crosssite.def' . =20 Chapter1: Where is 'Imake.tmpl' ? 'xmkmf /usr/openwin/lib' did it! =20 Chapter2: Where is './../crosssite.def' ? edit line 58 'crossfire.cf' =20 Pause: 'make Makefiles' =20 Chapter3: Where is 'INCROOT' ? edit all 'Makefile''s 'INCROOT' to '/usr/openwin/share/include' 'make's output: =20 making all in ./common... making all in ./doc... making all in ./doc/playbook... making all in ./doc/spoiler... making all in ./doc/spell-docs... making all in ./doc/spoiler-html... making all in ./doc/playbook-html... making all in ./server... rm -f crossfire gcc -ansi -Wall -o crossfire alchemy.o apply.o attack.o ban.o=20 c_bind.o c_chat.o c_misc.o c_move.o c_new.o c_object.o c_party.o=20 c_wiz.o commands.o daemon.o egoitem.o encounter.o ericserver.o=20 hiscore.o gods.o init.o input.o login.o main.o monster.o move.o=20 newitem.o obwin.o pets.o player.o resurrection.o rune.o shop.o=20 skills.o skill_util.o socket.o sounds.o spell_effect.o spell_util.o=20 swamp.o swap.o time.o xio.o -DSYSV -DSVR4 -xF -Wa,-cg92=20 -R:/usr/openwin/lib -L/lib -L../common -lcross -lXext -lX11 =20 -lsocket -lnsl =20 ld: fatal: library -lXext: not found ld: fatal: library -lX11: not found ld: fatal: File processing errors. No output written to crossfire *** Error code 1 make: Fatal error: Command failed for target `crossfire' Current working directory=20 /home/ivi2146/crossfire/crossfire-0.92.7/server *** Error code 1 make: Fatal error: Command failed for target `all' =20 What is lacking? (My knowledge?) These EXTRA_LIBRARIES... I have tried to remove '-lXext' and it just want X11. I have changed '-lX11' to '-l/usr/openwin/lib/X11' and '-l/usr/openwin/share/include/X11' but just get the same error message (well it sez something like "ld: fatal: library -l/usr/openw..."=20 instead). =20 I have read, I have tried... What to change? What to do? Which directory does it look for? How do I specify that? Are there any workarounds? What file does it need and how do I include them? (I have tried to exlude Xext and X11 but it is missing lots of things=20 then [funktions?]) =20 :) Just the answer that works is enough! =20 I hope this information can help you. =20 Thanks/ /Ian Vitek ian.vitek@capgemini.se +46 8 7045139 PS: Any help is help...DS From owner-crossfire Fri Oct 4 16:23:52 1996 Return-Path: Received: from mne.ifi.uio.no (1232@mne.ifi.uio.no [129.240.70.5]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id ; Fri, 4 Oct 1996 16:23:52 +0200 From: Kjetil Torgrim Homme Received: (from kjetilho@localhost) by mne.ifi.uio.no ; Fri, 4 Oct 1996 16:23:49 +0200 Date: Fri, 4 Oct 1996 16:23:49 +0200 Message-Id: <199610041423.6984.mne.ifi.uio.no@ifi.uio.no> To: ian.vitek@capgemini.se CC: crossfire-bugs@ifi.uio.no In-reply-to: <199610041405.PAA03370@capp.cap.se> (ian.vitek@capgemini.se) Subject: Re: making crossfire... :( Status: RO [Ian Vitek] | I wanna play crossfire-0.92.7 on my solaris 2.5 in openwindows. It | seems to compile in gcc. | | The history so far... | | Prolog: | edit 'crosssite.def' . | | Chapter1: Where is 'Imake.tmpl' ? | 'xmkmf /usr/openwin/lib' did it! You really should set up Imake right, it spares you a lot of hassle when compiling software for X. 1. Set the environment variable OPENWINHOME to /usr/openwin. 2. Locate the MKDIRHIER command in /usr/openwin/lib/config/Project.tmpl and remove the "$(BINDIR)". 3. Edit /usr/openwin/lib/config/site.def to reflect your system. You can now define BinDir to be a directory other than /usr/openwin/bin. The first step alone will solve most of your problems, including the linking command. The other steps need root privelege. Kjetil T. From owner-crossfire Fri Oct 4 12:26:45 1996 Return-Path: Received: (from mdomo@localhost) by ifi.uio.no (8.6.11/ifi2.4) id for crossfire-ut ; Fri, 4 Oct 1996 12:26:45 +0200 Received: from nexus.astro.psu.edu (nexus.astro.psu.edu [128.118.147.20]) by ifi.uio.no with SMTP (8.6.11/ifi2.4) id for ; Fri, 4 Oct 1996 12:26:39 +0200 Received: from zaphod.astro.psu.edu by nexus.astro.psu.edu (4.1/Nexus-1.3) id AA29491; Fri, 4 Oct 96 06:27:27 EDT Received: by zaphod.astro.psu.edu (4.1/Client-1.3) id AA15304; Fri, 4 Oct 96 06:26:23 EDT Date: Fri, 4 Oct 96 06:26:23 EDT From: "Brian Thomas" Message-Id: <9610041026.AA15304@zaphod.astro.psu.edu> Mime-Version: 1.0 To: crossfire@ifi.uio.no Subject: CF: throwing patch Cc: mon.diff@zaphod.astro.psu.edu Sender: owner-crossfire Precedence: bulk Status: RO In CF0.92.7 monsters decide what to throw based on their INT, unfortunately, only the "head" portion of the monster seems to contain the INT information. Therefore, in some cases (now that monsters take a shot from more than just the head), the monster reverts to the "no INT" case (ie it will throw ANYTHING). This patch also prevents ANY monster from throwing the SPECIAL_KEY type (which are often used to construct the quest logic of a map). -b.t. *** ../../tarfiles/crossfire-0.92.7/server/monster.c Mon Sep 30 01:53:56 1996 --- ./monster.c Fri Oct 4 06:22:39 1996 *************** *** 1243,1253 **** /* find_mon_throw_ob() - modeled on find_throw_ob */ object *find_mon_throw_ob( object *op ) { object *tmp = NULL, *heaviest = NULL; ! int stupid = op->stats.Int<6?1:0,dumb=op->stats.Int<10?1:0; if(!op) { /* safety */ LOG(llevError,"find_mon_throw_ob(): confused! have a NULL thrower!\n"); return (object *) NULL; } --- 1243,1257 ---- /* find_mon_throw_ob() - modeled on find_throw_ob */ object *find_mon_throw_ob( object *op ) { object *tmp = NULL, *heaviest = NULL; ! int stupid,dumb; ! ! if(op->head) tmp=op->head; else tmp=op; ! stupid = tmp->stats.Int<6?1:0; ! dumb=tmp->stats.Int<10?1:0; if(!op) { /* safety */ LOG(llevError,"find_mon_throw_ob(): confused! have a NULL thrower!\n"); return (object *) NULL; } *************** *** 1256,1267 **** * thrown weapons first, followed by heaviest objects. */ for(tmp=op->inv;tmp;tmp=tmp->below) { if(!tmp) break; /* no throwing your arms,hands, head, etc. or invisible ! * items like skills */ ! if(tmp->invisible||tmp->type==FLESH) continue; /* this should prevent us from throwing away * cursed items, worn armour, etc. */ if(QUERY_FLAG(tmp,FLAG_APPLIED)&& (QUERY_FLAG(tmp,FLAG_CURSED)||QUERY_FLAG(tmp,FLAG_DAMNED))) continue; --- 1260,1271 ---- * thrown weapons first, followed by heaviest objects. */ for(tmp=op->inv;tmp;tmp=tmp->below) { if(!tmp) break; /* no throwing your arms,hands, head, etc. or invisible ! * items like skills. No throwing special keys either! */ ! if(tmp->invisible||tmp->type==FLESH||tmp->type==SPECIAL_KEY) continue; /* this should prevent us from throwing away * cursed items, worn armour, etc. */ if(QUERY_FLAG(tmp,FLAG_APPLIED)&& (QUERY_FLAG(tmp,FLAG_CURSED)||QUERY_FLAG(tmp,FLAG_DAMNED))) continue; *************** *** 1278,1288 **** &&!spells[tmp->stats.sp].onself) break; if(QUERY_FLAG(tmp,FLAG_APPLIED)) continue; else if(tmp->type==BOW||tmp->type==ARROW||tmp->type==SCROLL ||tmp->type==BOOK||tmp->type==SPELLBOOK||tmp->type==AMULET ||tmp->type==MONEY||tmp->type==GEM||tmp->type==SKILL ! ||(tmp->type==CONTAINER&&tmp->inv) ||tmp->magic>0||tmp->value>(10*SK_level(op))) continue; /* 'throw' away 'trash'--spent wands and cursed items*/ if((tmp->type==WAND&&tmp->stats.food==0)||QUERY_FLAG(tmp,FLAG_CURSED) ||QUERY_FLAG(tmp,FLAG_DAMNED)) --- 1282,1293 ---- &&!spells[tmp->stats.sp].onself) break; if(QUERY_FLAG(tmp,FLAG_APPLIED)) continue; else if(tmp->type==BOW||tmp->type==ARROW||tmp->type==SCROLL ||tmp->type==BOOK||tmp->type==SPELLBOOK||tmp->type==AMULET ||tmp->type==MONEY||tmp->type==GEM||tmp->type==SKILL ! ||tmp->type==KEY||(tmp->type==CONTAINER&&tmp->inv) ! ||(tmp->glow_radius>0&&!QUERY_FLAG(op->head?op->head:op,FLAG_SEE_IN_DARK)) ||tmp->magic>0||tmp->value>(10*SK_level(op))) continue; /* 'throw' away 'trash'--spent wands and cursed items*/ if((tmp->type==WAND&&tmp->stats.food==0)||QUERY_FLAG(tmp,FLAG_CURSED) ||QUERY_FLAG(tmp,FLAG_DAMNED)) From owner-crossfire Fri Oct 4 08:06:02 1996 Return-Path: Received: (from mdomo@localhost) by ifi.uio.no (8.6.11/ifi2.4) id for crossfire-ut ; Fri, 4 Oct 1996 08:06:02 +0200 Received: from xplorer.gsfc.nasa.gov (xplorer.gsfc.nasa.gov [128.183.126.216]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Fri, 4 Oct 1996 08:05:59 +0200 Received: (from thomas@localhost) by xplorer.gsfc.nasa.gov (LHEA9504/950407.s1) id CAA14401 for crossfire@ifi.uio.no; Fri, 4 Oct 1996 02:05:57 -0400 Date: Fri, 4 Oct 1996 02:05:57 -0400 From: Brian Thomas Message-Id: <199610040605.CAA14401@xplorer.gsfc.nasa.gov> Mime-Version: 1.0 To: crossfire@ifi.uio.no Subject: CF: Fwd: misc crossfire stuff (bugs) Sender: owner-crossfire Precedence: bulk Status: RO Im forwarding this message to the list from Steve Yegge. He brings up several important bugs in the current distribution. I have addressed the throwing problem (in terms of what gets thrown) already. THese others await your kindly attention good sirs... :) -b.t. > From: Steve Yegge writes: > > incredible, but since I like the game so much I wanted to bring > a few things to your attention. > > - my wiz character keeps finding boulders in his > inventory. I suspect it's because giants are > throwing them at me, and when they hit, they stay. > This is not something I can rationalize - they're > not made of velcro and I certainly wouldn't keep > one if thrown it were thrown at me. It slows my > wiz down to about half speed frequently, until > I can detect the problem and drop the boulder(s). > > - monsters don't seem to discriminate between things > they should throw and things that in "real life" > they might want to hold on to. I see monsters > throwing their armor & treasure around like rocks, > when in reality even a dumb monster would want to > hold on to its shiny possessions, and it would want > to keep its only armor when it sees its companions > being butchered. > > of stability, but we've found perhaps a dozen bugs in it that I'm > sure everyone else is encountering and haven't really heard much > about whether people are tracking them. (Yes, I know - I should > do it myself. Well, we'll see.) For example (off the top of my > head), > > - you can't take something out of one of your bags if you're > levitating. > > - the game doesn't deduct the weight of a food from your > inventory if you eat it. > > - the graphical inventory list often gets out of synch with > the game's idea of the list, so that (even when you're > in show-all mode) when it says "the arrow is now on top", > if you try to drop it using the keyboard, you wind up > selling your Power Dragon Mail. > > - the notorious "run-bug", where the game thinks you've got > the control-key (run-key) down even though you don't. It > seems to be a race condition, but on our Sparcs running > SunOS 4.x it happens frequently, often causing us to get > killed. > > Steve Yegge > stevey@geoworks.com > > p.s. one feature request - more characters in a "tell" message. Sigh. > > From owner-crossfire Thu Oct 3 09:43:25 1996 Return-Path: Received: (from mdomo@localhost) by ifi.uio.no (8.6.11/ifi2.4) id for crossfire-ut ; Thu, 3 Oct 1996 09:43:25 +0200 Received: from nexus.astro.psu.edu (nexus.astro.psu.edu [128.118.147.20]) by ifi.uio.no with SMTP (8.6.11/ifi2.4) id for ; Thu, 3 Oct 1996 09:43:15 +0200 Received: from zaphod.astro.psu.edu by nexus.astro.psu.edu (4.1/Nexus-1.3) id AA22693; Thu, 3 Oct 96 03:44:09 EDT Received: by zaphod.astro.psu.edu (4.1/Client-1.3) id AA09589; Thu, 3 Oct 96 03:43:03 EDT Date: Thu, 3 Oct 96 03:43:03 EDT From: "Brian Thomas" Message-Id: <9610030743.AA09589@zaphod.astro.psu.edu> Mime-Version: 1.0 To: crossfire@ifi.uio.no Subject: CF: player race question Sender: owner-crossfire Precedence: bulk Status: RO I see that the player archetypes all have the race field set to the archetype name (ie arch wizard has "race wizard"). For all I can tell, this is not used at all (except the resurrection code makes some avoidable assumptions based on this). Does anyone know what else this is used for? I would like to reset the player races to a more "meaningfull" value in the races file, eg half-orc players are "goblin", barbarian players are "human", etc. thanks! -b.t. From owner-crossfire Wed Oct 2 13:59:55 1996 Return-Path: Received: (from mdomo@localhost) by ifi.uio.no (8.6.11/ifi2.4) id for crossfire-ut ; Wed, 2 Oct 1996 13:59:55 +0200 Received: from scol.sco.com (scol.london.sco.COM [150.126.1.48]) by ifi.uio.no with SMTP (8.6.11/ifi2.4) id for ; Wed, 2 Oct 1996 13:59:23 +0200 Received: from middx.x.co.uk by scol.sco.COM id aa25633; 2 Oct 96 12:31 BST Received: from avon.x.co.uk by middx.sco.COM id aa00694; 2 Oct 96 12:30 BST Received: by avon.x.co.uk (8.6.8.2/1.2-eef) id LAA13072; Wed, 2 Oct 1996 11:27:37 GMT From: Tim Moss Message-Id: <199610021127.LAA13072@avon.x.co.uk> Subject: CF: patches for spell_effects and login.c Mime-Version: 1.0 To: crossfire@ifi.uio.no Date: Wed, 2 Oct 1996 11:27:36 +0000 (GMT) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2084 Sender: owner-crossfire Precedence: bulk Status: RO Here are two patches: One fixes login.c which will not compile if ENABLE_CHECKSUMS is defined The second fixes spiell_effects.c which does not compile if SPELL_FAILURE_EFFECTS is defined *** login.c.orig Tue Oct 1 16:39:21 1996 --- login.c Tue Oct 1 16:40:06 1996 *************** *** 753,759 **** LOG(llevDebug,"Checksums: %x %x\n", checksum,calculate_checksum(filename,1)); #ifdef ENABLE_CHECKSUM ! if(calculate_checksum(filename) != checksum) { new_draw_info(NDI_UNIQUE, 0,op,"Since your savefile has been tampered with,"); new_draw_info(NDI_UNIQUE, 0,op,"you will not be able to save again."); set_cheat(op); --- 753,759 ---- LOG(llevDebug,"Checksums: %x %x\n", checksum,calculate_checksum(filename,1)); #ifdef ENABLE_CHECKSUM ! if(calculate_checksum(filename,1) != checksum) { new_draw_info(NDI_UNIQUE, 0,op,"Since your savefile has been tampered with,"); new_draw_info(NDI_UNIQUE, 0,op,"you will not be able to save again."); set_cheat(op); *** spell_effect.c.orig Tue Oct 1 16:53:10 1996 --- spell_effect.c Tue Oct 1 16:55:14 1996 *************** *** 49,55 **** if(failure<= -20&&failure > -40) /* wonder */ { new_draw_info(NDI_UNIQUE, 0,op,"Your spell causes an unexpected effect."); ! cast_cone(op,0,10,SP_WOW,spellarch[SP_WOW],0); } else if (failure <= -40&&failure > -60) /* confusion */ --- 49,55 ---- if(failure<= -20&&failure > -40) /* wonder */ { new_draw_info(NDI_UNIQUE, 0,op,"Your spell causes an unexpected effect."); ! cast_cone(op,op,0,10,SP_WOW,spellarch[SP_WOW],0); } else if (failure <= -40&&failure > -60) /* confusion */ Tim ____________________________________________________________________________ Tim Moss SCO Client Integration Division Phone: +44 (0)1223 518034 Software Engineer Vision Park Cambridge England Phax : +44 (0)1223 518001 WWW: http://www.vision.sco.com Email: timm@sco.com From owner-crossfire Tue Oct 1 15:05:12 1996 Return-Path: Received: (from mdomo@localhost) by ifi.uio.no (8.6.11/ifi2.4) id for crossfire-ut ; Tue, 1 Oct 1996 15:05:12 +0200 Received: from xplorer.gsfc.nasa.gov (xplorer.gsfc.nasa.gov [128.183.126.216]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Tue, 1 Oct 1996 15:04:37 +0200 Received: (from thomas@localhost) by xplorer.gsfc.nasa.gov (LHEA9504/950407.s1) id JAA12013; Tue, 1 Oct 1996 09:04:20 -0400 Date: Tue, 1 Oct 1996 09:04:20 -0400 From: Brian Thomas Message-Id: <199610011304.JAA12013@xplorer.gsfc.nasa.gov> Mime-Version: 1.0 To: crossfire@ifi.uio.no, frits@chemde4.leidenuniv.nl Subject: Re: CF: Re: 0.92.7 is out Sender: owner-crossfire Precedence: bulk Status: RO > Frits writes: > > I seem to be lacking a file bookarch in the lib directory. > Can you upload it, Thomas? (I think it was thomas who did this feature) > or mail it to the list if it's not too big? > Oh, you arent supposed to have one :) The bookarch(ive) is generated each time you run the game. All server administrators should always *carry over* the old copy of the bookarch file from the prior version. This way, book text content and book titles will remain fairly constant (thats what the book archiving feature does..) If you want *my* book archive, I guess I can mail it out. Let me know. b.t. From owner-crossfire Tue Oct 1 14:28:23 1996 Return-Path: Received: (from mdomo@localhost) by ifi.uio.no (8.6.11/ifi2.4) id for crossfire-ut ; Tue, 1 Oct 1996 14:28:23 +0200 Received: from rulway.leidenuniv.nl (rulway.LeidenUniv.nl [132.229.8.6]) by ifi.uio.no with SMTP (8.6.11/ifi2.4) id for ; Tue, 1 Oct 1996 14:28:10 +0200 Received: from chemde4.LeidenUniv.nl by rulway.leidenuniv.nl with SMTP id AA24206 (5.67b/IDA-1.5 for <@RULWAY.LEIDENUNIV.NL:crossfire@ifi.uio.no>); Tue, 1 Oct 1996 13:28:08 +0100 Received: by chemde4.leidenuniv.nl (920330.SGI/920502.SGI) for @RULWAY.LEIDENUNIV.NL:crossfire@ifi.uio.no id AA02405; Tue, 1 Oct 96 14:30:12 +0200 Date: Tue, 1 Oct 96 14:30:12 +0200 From: frits@chemde4.leidenuniv.nl (Frits Daalmans) Message-Id: <9610011230.AA02405@chemde4.leidenuniv.nl> Mime-Version: 1.0 To: crossfire@ifi.uio.no Subject: CF: Re: 0.92.7 is out Sender: owner-crossfire Precedence: bulk Status: RO grmbl.. and I transferred 0.92.6 over my 9600 baud modem just yesterday... this game is costing me telephone bills! :-) Keep up the good work!! :-) I seem to be lacking a file bookarch in the lib directory. Can you upload it, Thomas? (I think it was thomas who did this feature) or mail it to the list if it's not too big? Greetings, Frits Frits Daalmans OIO Conformational Analysis Gorlaeus Laboratoria Leiden, The Netherlands E-mail: frits@chemde4.leidenuniv.nl Tel: [+31] (0)71-5274505 From owner-crossfire Sun Oct 13 01:39:05 1996 Return-Path: Received: (from mdomo@localhost) by ifi.uio.no (8.6.11/ifi2.4) id for crossfire-ut ; Sun, 13 Oct 1996 01:39:05 +0200 Received: from gossip.pyramid.com (gossip.pyramid.com [129.214.1.101]) by ifi.uio.no with SMTP (8.6.11/ifi2.4) id for ; Sun, 13 Oct 1996 01:39:01 +0200 Received: from stealth-news.pyramid.com by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway) id AA26084; Sat, 12 Oct 96 16:38:30 -0700 Received: by stealth.eng.pyramid.com (8.6.12/Pyramid_Internal_Configuration) id QAA25635; Sat, 12 Oct 1996 16:38:21 -0700 From: "Mark Wedel" Message-Id: <9610121638.ZM25633@stealth.eng.pyramid.com> Date: Sat, 12 Oct 1996 16:38:18 -0700 In-Reply-To: Michael Martin "Re: CF: Windows 95, NT" (Oct 12, 4:33pm) References: X-Mailer: Z-Mail (3.2.0 06sep94) Mime-Version: 1.0 To: Michael Martin , crossfire@ifi.uio.no Subject: Re: CF: Windows 95, NT Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-crossfire Precedence: bulk Status: RO On Oct 12, 4:33pm, Michael Martin wrote: > Subject: Re: CF: Windows 95, NT > > I've been working on learning Java for the past couple months or so > (following a self-taught crash course in C++), and it seems to me to be an > ideal language for the client. But, having taken a peek at the Crossfire > code, I don't know how easy this would be (my first glance says, "highly > non-trivial"). The client.c file in the client/ directory apparently > doesn't do much (just parses command-line options, a little preliminary X > work, and network socket handling). But the "real code" (e.g. the stuff > that draws the window) isn't there. It looks to me like that code is > spread across both the common/* files and server/* files. Is this > correct? Can someone tell me where the split between client and server > source is? What types of internal data structures does the client need? get the crossfire-0.92.4.client.tar.gz file - this contains a partial implementation of true client/server. > > As I understand it, the pixmap data has to be sent to the client every > game session (during gameplay, in fact?). IMHO, it would be best to have > all the graphics (pixmap) data handled at the client end. The server > should only have to send over the current map and player data (referring > to objects by name or number, I guess), and the client then figures out > which pixmaps are needed and displays them. This is a compromise. The client above gets images as needed. This has the advantage of a quick startup time (don't need to send 2500 images or negotiate what images to send.) The disadvantage is that you are potentially wasting a bit of bandwidth by sending these each time. I think local caching is a good idea, because depending on the system, you may have a better image format than XPM. > I guess animation of > "in-place" objects (like the "glowing" effect of a wand, for example) > could be handled at either end. (If by the client, then it would have to > know somehow whether the wand had any changes left, since "used up" wands > don't do the animation. If by the server, the server could simply > instruct the client to display frame #x in the pixmap sequence for the > given object. The latter method's probably a lot easier to implement). This has been discussed a bit before. I think on the client side animation, the server just tells it how fast to animate, and what images (for example, the power crystal has variable animation speed depending on how much power is stored in it.) I know someone else was working on another game similar to crossfire on the bebox, last I heard they were being held up a little waiting for software for the bebox. -- --Mark From owner-crossfire Sat Oct 12 23:13:37 1996 Return-Path: Received: (from mdomo@localhost) by ifi.uio.no (8.6.11/ifi2.4) id for crossfire-ut ; Sat, 12 Oct 1996 23:13:37 +0200 Received: from gossip.pyramid.com (gossip.pyramid.com [129.214.1.101]) by ifi.uio.no with SMTP (8.6.11/ifi2.4) id for ; Sat, 12 Oct 1996 23:13:34 +0200 Received: from stealth-news.pyramid.com by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway) id AA25885; Sat, 12 Oct 96 14:13:02 -0700 Received: by stealth.eng.pyramid.com (8.6.12/Pyramid_Internal_Configuration) id OAA17842; Sat, 12 Oct 1996 14:12:57 -0700 From: "Mark Wedel" Message-Id: <9610121412.ZM17840@stealth.eng.pyramid.com> Date: Sat, 12 Oct 1996 14:12:56 -0700 In-Reply-To: murray@indigo2.scri.fsu.edu (John R. Murray) "Re: CF: RUN+FIRE lock bug" (Oct 12, 3:25pm) References: <199610121925.PAA22190@indigo2.scri.fsu.edu> X-Mailer: Z-Mail (3.2.0 06sep94) Mime-Version: 1.0 To: murray@indigo2.scri.fsu.edu (John R. Murray), Mr T Woodhouse Subject: Re: CF: RUN+FIRE lock bug Cc: Crossfire@ifi.uio.no Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-crossfire Precedence: bulk Status: RO On Oct 12, 3:25pm, John R. Murray wrote: > Subject: Re: CF: RUN+FIRE lock bug > >I've come across the following bug quite often - sometimes when you > >move focus off the crossfire window then back on again your character > >suddenly has RUN+FIRE on-something which i've found difficult to switch > >off (sometimes switching between skills seems to fix it). This is extremely > >annoying, and if you've got something like a lightning rod activated, > >extremely deadly. Anyone got any ideas on how to fix that? Not move the mouse out of the window while playing? The problem basically comes because for certain keys (run and fire), it keeps track of the keypress (start firing/running) and key release (stop running/ firing.) If the mouse moves out of the window, and you release the appropriate key, crossfire doesn't see the release event. At least one solution is just pressing the run or fire key and releasing it while in the crossfire window. (crossfire will see the press and release events, but the release event is important.) I don't know if there is any good fix for this. I don't think there is a way to find out all keys being pressed on the keyboard. I also don't think there is any good way to find out if the release event happend outside the window without grabbing keys meant for other programs. As a playing issue, changing your window manager to click to focus might help reduce such problems. Actually, just looking, I suppose we can look at the window focus - if crossfire looses focus, reset the fire and run flags to 0. On the otherhand, I sometimes use the run 'feature' - if I am travelling a long way and not moving very quickly, I will press run + direction and move my mouse out of the window before releasing, so my character keeps going that way until I reenter the window. -- --Mark From owner-crossfire Sat Oct 12 22:34:03 1996 Return-Path: Received: (from mdomo@localhost) by ifi.uio.no (8.6.11/ifi2.4) id for crossfire-ut ; Sat, 12 Oct 1996 22:34:03 +0200 Received: from millner.bevc.blacksburg.va.us (millner.bevc.blacksburg.va.us [198.82.200.50]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Sat, 12 Oct 1996 22:33:59 +0200 Received: (from martinm@localhost) by millner.bevc.blacksburg.va.us (8.7.5/8.7.3) id QAA02088; Sat, 12 Oct 1996 16:33:50 -0400 Date: Sat, 12 Oct 1996 16:33:49 -0400 (EDT) From: Michael Martin Mime-Version: 1.0 To: crossfire@ifi.uio.no Subject: Re: CF: Windows 95, NT In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-crossfire Precedence: bulk Status: RO On Fri, 11 Oct 1996, John W Klar wrote: > Java... > > The XPM library does not compile under Java, so an implementation is called for > there. I'm not convinced Java can handle the load that CF puts on the client > but I've been surprised before. I looked at the source for libXpm 4.7 and it looks like quite a bit of work to rewrite it (or at least the key parts) in Java. How about using a different format? I would suggest either GIF (reading GIF files is already in the Java AWT) or PNG (if someone does a Java port of libpng). But if you *have* to deal with pixmaps, Java supports the calling of "native" (i.e. non-Java) functions, so it might be possible to have Java call functions in libXpm. Considering that Java can smoothly double-buffer full-window animation in a window larger than the standard Crossfire window on my humble Intel-Linux/X P90 box, I think Java can handle the load. I've been working on learning Java for the past couple months or so (following a self-taught crash course in C++), and it seems to me to be an ideal language for the client. But, having taken a peek at the Crossfire code, I don't know how easy this would be (my first glance says, "highly non-trivial"). The client.c file in the client/ directory apparently doesn't do much (just parses command-line options, a little preliminary X work, and network socket handling). But the "real code" (e.g. the stuff that draws the window) isn't there. It looks to me like that code is spread across both the common/* files and server/* files. Is this correct? Can someone tell me where the split between client and server source is? What types of internal data structures does the client need? Obviously it has to keep track of the player's inventory, the current map view, the list of objects on the ground (beneath the player), some player stats, and text messages. What else? Does it keep track of the player's entire data structure? And how exactly does the eutl library fit in? I get the impression that Crossfire doesn't really implement a "true" client/server architecture (except where it uses the X client/server stuff). Am I wrong? As I understand it, the pixmap data has to be sent to the client every game session (during gameplay, in fact?). IMHO, it would be best to have all the graphics (pixmap) data handled at the client end. The server should only have to send over the current map and player data (referring to objects by name or number, I guess), and the client then figures out which pixmaps are needed and displays them. I guess animation of "in-place" objects (like the "glowing" effect of a wand, for example) could be handled at either end. (If by the client, then it would have to know somehow whether the wand had any changes left, since "used up" wands don't do the animation. If by the server, the server could simply instruct the client to display frame #x in the pixmap sequence for the given object. The latter method's probably a lot easier to implement). Of course, you need to make sure the client and server are synchronised, so the server would also have a copy of the game objects and their pixmaps. When the client connects, the client (or server) initiates a dialog wherein they determine whether the client has all the pixmaps it needs, and if not the new ones are then transmitted before the player enters the game. This way only new objects created on the server would actually have to be transmitted after the client is installed (with a default set of pixmaps included in the client distribution, of course). If the server administrator adds an item which uses new pixmaps, the new ones (only) are copied to the client (which stores them so the data only has to be copied once), and then the gameplay starts. This scheme would make sure that the client has the pixmap data as soon as it's needed, conserve a great deal of network bandwidth during gameplay, and put less strain on the server. Any comments on this strategy? Now, I'm not suggesting that the Crossfire developers should do a rewrite to implement something like this (that'd most likely be a *lot* of work which could be spent on feature coding). These were just some thoughts I had. This might be stupid on my part, but I think I'll throw this out here before I quit: Is there anyone familiar with (or willing to learn) Java programming who would be interested in working on a somewhat Crossfire-like game? What I had in mind includes a full client/server interface (with a good graphical client), multi-player support (of course!), and a lot of Crossfire-like gameplay attributes (too many to list here). Another option would be to do the server in C++ (if you know C++ instead, or just prefer it to Java). Why "re-invent the wheel", instead of just hacking on the Crossfire source? Well, this type of game is very well-suited for OOP (resulting in cleaner design and less bugs, I think) and the Crossfire source is a maze (at least to me). I have a number of ideas for the design of such a game (at least a few of which I think are good ones :), but not nearly enough time to write a working implementation. If others were interested, I would be willing to give it a try. A simpler (?) short-term project would be to put a Java client on crossfire, but I don't think the current code would allow this in an easy fashion. (If someone can show me otherwise, I might be willing to give it a try.) -Michael From owner-crossfire Sat Oct 12 21:25:16 1996 Return-Path: Received: (from mdomo@localhost) by ifi.uio.no (8.6.11/ifi2.4) id for crossfire-ut ; Sat, 12 Oct 1996 21:25:16 +0200 Received: from mailer.scri.fsu.edu (mailer.scri.fsu.edu [144.174.112.142]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Sat, 12 Oct 1996 21:25:12 +0200 Received: from indigo2.scri.fsu.edu (indigo2.scri.fsu.edu [144.174.128.47]) by mailer.scri.fsu.edu (8.7.5/8.7.5) with SMTP id PAA12628; Sat, 12 Oct 1996 15:25:05 -0400 (EDT) Received: by indigo2.scri.fsu.edu (940816.SGI.8.6.9/931108.SGI.AUTO.ANONFTP) id PAA22190; Sat, 12 Oct 1996 15:25:26 -0400 Date: Sat, 12 Oct 1996 15:25:26 -0400 From: murray@indigo2.scri.fsu.edu (John R. Murray) Message-Id: <199610121925.PAA22190@indigo2.scri.fsu.edu> Mime-Version: 1.0 To: Mr T Woodhouse Subject: Re: CF: RUN+FIRE lock bug Cc: murray@indigo2.scri.fsu.edu, Crossfire@ifi.uio.no Sender: owner-crossfire Precedence: bulk Status: RO >I've come across the following bug quite often - sometimes when you >move focus off the crossfire window then back on again your character >suddenly has RUN+FIRE on-something which i've found difficult to switch >off (sometimes switching between skills seems to fix it). This is extremely >annoying, and if you've got something like a lightning rod activated, >extremely deadly. Anyone got any ideas on how to fix that? I haven't seen this exactly, but under this latest version of CF I have on occasion found myself with the RUN (ctrl) key locked, so pressing any direction key suddenly becomes run-until-you-hit-something-solid. In my case, deliberately activating and releasing RUN+AnyDirectionKey clears it up. Dunno if it's the mouse focus that's doing it; I'll try to pay more attention next time it happens. (CF 0.92.7, no patches, running on SGI IRIX 5.3) -- John R. Murray murray@indigo2.scri.fsu.edu http://www.scri.fsu.edu/~murray/ FSU Aikido Club/North Florida Aikikai home of Miko's Aikido MPEGs and the Tallahassee, FL WWW Aikido online calendar of events From owner-crossfire Sat Oct 12 19:48:27 1996 Return-Path: Received: (from mdomo@localhost) by ifi.uio.no (8.6.11/ifi2.4) id for crossfire-ut ; Sat, 12 Oct 1996 19:48:27 +0200 Received: from crocus.csv.warwick.ac.uk (lauka@crocus.csv.warwick.ac.uk [137.205.192.13]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Sat, 12 Oct 1996 19:48:24 +0200 From: Mr T Woodhouse Message-Id: <6351.199610121748@crocus.csv.warwick.ac.uk> Received: by crocus.csv.warwick.ac.uk id SAA06351; Sat, 12 Oct 1996 18:48:21 +0100 (BST) Subject: CF: RUN+FIRE lock bug Mime-Version: 1.0 To: Crossfire@ifi.uio.no Date: Sat, 12 Oct 1996 18:48:19 +0100 (BST) X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-crossfire Precedence: bulk Status: RO I've come across the following bug quite often - sometimes when you move focus off the crossfire window then back on again your character suddenly has RUN+FIRE on-something which i've found difficult to switch off (sometimes switching between skills seems to fix it). This is extremely annoying, and if you've got something like a lightning rod activated, extremely deadly. Anyone got any ideas on how to fix that? Zharradan From owner-crossfire Sat Oct 12 01:07:01 1996 Return-Path: Received: (from mdomo@localhost) by ifi.uio.no (8.6.11/ifi2.4) id for crossfire-ut ; Sat, 12 Oct 1996 01:07:01 +0200 Received: from gossip.pyramid.com (gossip.pyramid.com [129.214.1.101]) by ifi.uio.no with SMTP (8.6.11/ifi2.4) id for ; Sat, 12 Oct 1996 01:06:57 +0200 Received: from stealth-news.pyramid.com by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway) id AA21741; Fri, 11 Oct 96 16:06:25 -0700 Received: by stealth.eng.pyramid.com (8.6.12/Pyramid_Internal_Configuration) id QAA24044; Fri, 11 Oct 1996 16:06:22 -0700 From: "Mark Wedel" Message-Id: <9610111606.ZM24042@stealth.eng.pyramid.com> Date: Fri, 11 Oct 1996 16:06:21 -0700 In-Reply-To: frits@chemde4.leidenuniv.nl (Frits Daalmans) "CF: debugging crossfire malloc()'s" (Oct 11, 5:13pm) References: <9610111513.AA28781@chemde4.leidenuniv.nl> X-Mailer: Z-Mail (3.2.0 06sep94) Mime-Version: 1.0 To: crossfire@ifi.uio.no Subject: Re: CF: debugging crossfire malloc()'s Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-crossfire Precedence: bulk Status: RO On Oct 11, 5:13pm, Frits Daalmans wrote: > Subject: CF: debugging crossfire malloc()'s > Hello, > > I have an idea to help in debugging crossfire, but I am sure people have > thought about it or even implemented it yet, so I submit it here. > Please send flames to my E-mail address, not to the list :-) > > Crossfire obviously allocates a lot of different types of data, map info, > objects, players etc. etc, and if something goes wrong you can see it > if it gives a core dump (doesn't always happen immediately), or if you > run the server under a debugger (probably not recommended). > > A trick I saw in the Linux kernel was, to do each allocation of a certain > interesting "type" of struct with an extra byte/word padding up front, > or as first element of the struct itself, > and this word then contains a fixed "magic number" for what the data represents. > > This way, if you allocate everything you really want to debug with its own > alloc/free routine, you can check: > - whether, if the pointer is not NULL, what magic number if any it contains > - if you want to free() something, whether it still has the good magic number > A few quick notes: If you use something like the dmalloc library, you already have bounds checking mechanisms in place (to check for structure overruns.) dmalloc is a free/shareware product, so can be installed on any system. The use of putting a starting tag on all the alloc'd objects would require a lot of updates to make sure they are set correctly (if you miss a few areas, then that code becomes a bit less useful...) But I have seen very few cases where problems are caused my bad memory accesses or other malloc corruption. Most is caused be looking at invalid pointers and so forth. -- --Mark From owner-crossfire Fri Oct 11 17:38:56 1996 Return-Path: Received: (from mdomo@localhost) by ifi.uio.no (8.6.11/ifi2.4) id for crossfire-ut ; Fri, 11 Oct 1996 17:38:56 +0200 Received: from xplorer.gsfc.nasa.gov (xplorer.gsfc.nasa.gov [128.183.126.216]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Fri, 11 Oct 1996 17:38:51 +0200 Received: (from thomas@localhost) by xplorer.gsfc.nasa.gov (LHEA9504/950407.s1) id LAA19266; Fri, 11 Oct 1996 11:38:20 -0400 Date: Fri, 11 Oct 1996 11:38:20 -0400 From: Brian Thomas Message-Id: <199610111538.LAA19266@xplorer.gsfc.nasa.gov> Mime-Version: 1.0 To: raulir@voimax.voima.jkl.fi Subject: Re: CF: Jumping bug Cc: crossfire@ifi.uio.no Sender: owner-crossfire Precedence: bulk Status: RO > Rauli Ruohonen writes: > > There is a bug in jumping code (or is the bug in monster code, if > monsters shouldn't jump?), which crashes crossfire with SIGSEGV. > > There is a line in attempt_jump(object *pl), which uses pl->contr->something, > and with monsters pl->contr==NULL.. Sometimes it crashes in draw(), which > is called by stop_jump(). I think that monsters shouldn't jump at all > (what use is it to them?), so I made the following patch: > [snip] The contr is a player specific addon that monsters never have. As you point out, for monsters its always a NULL pointer. Monsters would find jumping usefull as a means to escape players or to damage them. Sadly, under the current monster AI, no monster is smart enough to use this skill well. I think for the time being your patch is the correct way to go. -b.t. From owner-crossfire Fri Oct 11 17:11:11 1996 Return-Path: Received: (from mdomo@localhost) by ifi.uio.no (8.6.11/ifi2.4) id for crossfire-ut ; Fri, 11 Oct 1996 17:11:11 +0200 Received: from rulway.leidenuniv.nl (rulway.LeidenUniv.nl [132.229.8.6]) by ifi.uio.no with SMTP (8.6.11/ifi2.4) id for ; Fri, 11 Oct 1996 17:11:06 +0200 Received: from chemde4.LeidenUniv.nl by rulway.leidenuniv.nl with SMTP id AA08426 (5.67b/IDA-1.5 for <@RULWAY.LEIDENUNIV.NL:crossfire@ifi.uio.no>); Fri, 11 Oct 1996 16:11:05 +0100 Received: by chemde4.leidenuniv.nl (920330.SGI/920502.SGI) for @RULWAY.LEIDENUNIV.NL:crossfire@ifi.uio.no id AA28781; Fri, 11 Oct 96 17:13:13 +0200 Date: Fri, 11 Oct 96 17:13:13 +0200 From: frits@chemde4.leidenuniv.nl (Frits Daalmans) Message-Id: <9610111513.AA28781@chemde4.leidenuniv.nl> Mime-Version: 1.0 To: crossfire@ifi.uio.no Subject: CF: debugging crossfire malloc()'s Sender: owner-crossfire Precedence: bulk Status: RO Hello, I have an idea to help in debugging crossfire, but I am sure people have thought about it or even implemented it yet, so I submit it here. Please send flames to my E-mail address, not to the list :-) Crossfire obviously allocates a lot of different types of data, map info, objects, players etc. etc, and if something goes wrong you can see it if it gives a core dump (doesn't always happen immediately), or if you run the server under a debugger (probably not recommended). A trick I saw in the Linux kernel was, to do each allocation of a certain interesting "type" of struct with an extra byte/word padding up front, or as first element of the struct itself, and this word then contains a fixed "magic number" for what the data represents. This way, if you allocate everything you really want to debug with its own alloc/free routine, you can check: - whether, if the pointer is not NULL, what magic number if any it contains - if you want to free() something, whether it still has the good magic number Simple example: suppose we have a struct object{int magicnumber=0x0b1ec1, bla bla..}; it can be allocated with malloc free() with routine free_object(struct object *o): if (o->magicnumber == 0x0b1ec1) { free(o) (well.. a bit more sophisticated than this, I'm sure :-))) return; } /* else */ print error message (try to free object but is not object) check magicnumber against 0xb1a7e6, 0x3ab, etc. abort() optionally (difficult to squeeze ASCII into hex... i,l -> 1 is OK, p -> b is OK??, but y -> 7 and r -> 6 and m -> 3 ??? I thought it would be readable to have magic numbers looking somewhat like the words "object", "player" and "map", if you haven't guessed) oh well you get the idea. If this is already implemented, please tell me where? If not, is it a good idea? Greetings, Frits Frits Daalmans OIO Conformational Analysis Gorlaeus Laboratoria Leiden, The Netherlands E-mail: frits@chemde4.leidenuniv.nl Tel: [+31] (0)71-5274505 From owner-crossfire Fri Oct 11 14:44:58 1996 Return-Path: Received: (from mdomo@localhost) by ifi.uio.no (8.6.11/ifi2.4) id for crossfire-ut ; Fri, 11 Oct 1996 14:44:58 +0200 Received: from cbgw3.lucent.com (cbgw3.lucent.com [192.20.239.137]) by ifi.uio.no with SMTP (8.6.11/ifi2.4) id for ; Fri, 11 Oct 1996 14:44:52 +0200 Cc: crossfire@ifi.uio.no Received: from nesuns2.oms.lucent.com. by cbig3.firewall.lucent.com (SMI-8.6/EMS-L sol2) id IAA16783; Fri, 11 Oct 1996 08:36:57 -0400 Received: from kinderlinux (jwk@neppp01.oms.lucent.com [135.114.250.241]) by nesuns2.oms.lucent.com. (8.7.5/OMS960320) with SMTP id IAA14201; Fri, 11 Oct 1996 08:12:33 -0400 (EDT) Date: Fri, 11 Oct 1996 08:42:36 -0400 (EDT) From: John W Klar Reply-To: John W Klar Subject: Re: CF: Windows 95, NT Mime-Version: 1.0 To: Bob Tanner Original-cc: crossfire@ifi.uio.no In-Reply-To: <199610102210.RAA09460@wizard.real-time.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-crossfire Precedence: bulk Status: RO Bob Tanner wrote: > Any chance of an NT or 95 client for crossfire? > Maybe a java client, so platform would not matter. Well... I wrote some code which comes close but not close enough I'm afraid. Actually it was the third or fourth iteration (Perl/Tk, Tcl/Tk (7.5/4.1 available for Windoze), C/Tcl/Tk, and then pure C). I discuss the caveats: The XPM libraries, which DO compile on NT/95, are extremely inefficient or something :) If I remember the CF Client/Server protocol correctly, an XPM is transmitted the first time it's used. Unfortunately, two things can happen: you start dropping packets (and lose animation) or the game comes to an absolute crawl. You may say "We don't need no stinkin animation", but I'd think you would like to know just how far that fireball will expand, eh? The xpm library takes an inordinate amount of time to convert the XPM data into some sort of pseudo pixmap for NT. Another 'feature' of the Windows XPM implementation is that on 8bit displays, the colors are really off. By the way, there's another bug in the XPM libary which affects the mask (no I haven't submitted it). Therefore, IMO, a lightweight XPM parser needs to be written. A problem with my code is that I'm no Windows coder and things work a little strange. X doesn't care what color depth you hand it, _something_ comes out, but Windows throws a massive fit. Oh I suppose I could share my code with interested parties, but the machine where it resides is in pieces. I had to cannibalize it for parts to get my new machine working until I can have words with my vendor . I'm not terribly fond of the current X client (sorry) so mine looks different. Java... The XPM library does not compile under Java, so an implementation is called for there. I'm not convinced Java can handle the load that CF puts on the client but I've been surprised before. Protocol... There are some buglets here. The one that comes to mind is the combined name and class of the character. Since the whole field can be changed (wasn't this deprecated?) I'd like to see the class part broken out into its own stats field. Enough pre-coffee rambling. John jklar@lucent.com jklar@cybernex.net From owner-crossfire Fri Oct 11 09:41:37 1996 Return-Path: Received: from capp.cap.se (capp.cap.se [192.176.199.25]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Fri, 11 Oct 1996 09:41:34 +0200 From: ian.vitek@capgemini.se Received: from smtp ([192.176.198.70]) by capp.cap.se (8.7.5/8.7.3) with SMTP id IAA25995 for ; Fri, 11 Oct 1996 08:45:29 +0100 (MET) Message-Id: <199610110745.IAA25995@capp.cap.se> Date: Fri, 11 Oct 1996 9:39:56 +0100 To: crossfire-bugs@ifi.uio.no Subject: Reading some scrolls makes a core dump... :( MIME-version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: quoted-printable X-Mailer: TFS Gateway /220000000/220020140/220000469/220120025/ Status: RO I LOVE this game. (but) When I read scroll of enchant armor the came core dumps...(!). (It have also happend when I read a armor-lightening scroll and some=20 other scrolls) Have you heard about this or do you need more information? I had a problem in my log file that was it couldn't find the bookarch=20 file in my lib directory (siud-bit [+s] was set for user&group for=20 crossclient, crossfire and crossloop). When I 'touch bookarch' in the=20 lib directory the error message is gone (in the log file), but the=20 core dumps is still there. I am running the "CrossFire, v0.92.7" on a Solaris 2.5 . =20 //Ian Vitek ian.vitek@capgemini.se PS: I hope that it is a bug and that I have not done any.... :) From owner-crossfire Fri Oct 11 10:12:35 1996 Return-Path: Received: (from mdomo@localhost) by ifi.uio.no (8.6.11/ifi2.4) id for crossfire-ut ; Fri, 11 Oct 1996 10:12:35 +0200 Received: from voimax.voima.jkl.fi (raulir@voimax.voima.jkl.fi [193.185.117.34]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Fri, 11 Oct 1996 10:12:24 +0200 Received: (from raulir@localhost) by voimax.voima.jkl.fi (8.7.6/8.7.3) id LAA00199 for crossfire@ifi.uio.no; Fri, 11 Oct 1996 11:12:27 +0300 From: Rauli Ruohonen Message-Id: <199610110812.LAA00199@voimax.voima.jkl.fi> Subject: CF: Jumping bug Mime-Version: 1.0 To: crossfire@ifi.uio.no Date: Fri, 11 Oct 1996 11:12:27 +0300 (EET DST) Content-Type: text Sender: owner-crossfire Precedence: bulk Status: RO There is a bug in jumping code (or is the bug in monster code, if monsters shouldn't jump?), which crashes crossfire with SIGSEGV. There is a line in attempt_jump(object *pl), which uses pl->contr->something, and with monsters pl->contr==NULL.. Sometimes it crashes in draw(), which is called by stop_jump(). I think that monsters shouldn't jump at all (what use is it to them?), so I made the following patch: --- skills.c.old Fri Oct 11 11:08:05 1996 +++ skills.c Thu Oct 10 17:25:11 1996 @@ -361,6 +361,7 @@ * while jumping over them. */ + if(pl->type!=PLAYER) return(0); remove_ob(pl); SET_FLAG(pl,FLAG_FLYING); for(i=0;i<=spaces;i++) { From owner-crossfire Fri Oct 11 00:15:10 1996 Return-Path: Received: (from mdomo@localhost) by ifi.uio.no (8.6.11/ifi2.4) id for crossfire-ut ; Fri, 11 Oct 1996 00:15:10 +0200 Received: from warrior.real-time.com (root@warrior.real-time.com [206.10.252.1]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Fri, 11 Oct 1996 00:15:04 +0200 Received: from wizard.real-time.com (tanner@wizard.real-time.com [206.10.252.7]) by warrior.real-time.com (8.7.6/8.7.3) with ESMTP id RAA22988 for ; Thu, 10 Oct 1996 17:14:59 -0500 (CDT) From: Bob Tanner Received: by wizard.real-time.com (8.7.6) id RAA09460; Thu, 10 Oct 1996 17:10:05 -0500 (CDT) Message-Id: <199610102210.RAA09460@wizard.real-time.com> Subject: CF: Windows 95, NT Mime-Version: 1.0 To: crossfire@ifi.uio.no Date: Thu, 10 Oct 1996 17:10:05 -0500 (CDT) X-Mailer: ELM [version 2.4 PL24 PGP3 *ALPHA*] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-crossfire Precedence: bulk Status: RO Any chance of an NT or 95 client for crossfire? Maybe a java client, so platform would not matter. -- email : tanner@real-time.com | www : http://www.real-time.com/~tanner phone : (612)943-8700 | fax : (612)943-8300 motto : I program, therefore I am | From owner-crossfire Wed Oct 9 20:52:09 1996 Return-Path: Received: (from mdomo@localhost) by ifi.uio.no (8.6.11/ifi2.4) id for crossfire-ut ; Wed, 9 Oct 1996 20:52:09 +0200 Received: from ue801di.lrz-muenchen.de (fb@dial181.ppp.lrz-muenchen.de [129.187.24.181]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Wed, 9 Oct 1996 20:52:01 +0200 Received: (from fb@localhost) by ue801di.lrz-muenchen.de (8.6.12/8.6.9) id UAA03190 for crossfire@ifi.uio.no; Wed, 9 Oct 1996 20:57:55 -0700 From: Florian Beck Message-Id: <199610100357.UAA03190@ue801di.lrz-muenchen.de> Subject: Re: CF: BUG in spell_effect.c? Mime-Version: 1.0 To: crossfire@ifi.uio.no Date: Wed, 9 Oct 1996 20:57:53 -0700 (MST) Reply-To: h729ihqu@sun1.cip.fak14.uni-muenchen.de In-Reply-To: <199610091509.15354.mne.ifi.uio.no@ifi.uio.no> from "Michael Martin" at Oct 9, 96 10:52:11 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 5983 Sender: owner-crossfire Precedence: bulk Status: RO Michael Martin wrote: > IMHO, making monsters more powerful is not necessary. The real problem is > that players can become way too powerful. For example, I once had a Agreed - at least it's too easy. > Most of this seems to me to result from the experience/level table (in > common/living.c). For the earlier levels a new level is gained by > (approximately) doubling the experience of the last level. But after > about level 12 or so, it flattens out. For example, it takes 900000 exp > to get to level 12, but only another 500000 (roughly 50%) to get to level > 13. I would suggest changing this so that levels require something much > closer to a doubling of experience. This would dramatically cut down on > the number of ultra-powerful characters, and in turn the nasty monsters > would still be nasty. Another thing is that characters become more powerful than their level would suggest (using artifact weapons). And you get MUCH more experience from higher level monsters. And a 50 lev fighter + "demonbane +10" has little difficulty with the lev 100 angels in Lake Country. And he gets tons of experience points. (And you get even *more* exp if the artifact gives a stat bonus.) Powerful equipment is very/too easily obtained, so powerful monsters are very/too easily slain, so experience is gained very quickly. What I did in my version (or plan to do) was removing most artifacts from the treasure file. I think they should almost NEVER be handed out randomly. Better make them quest items so charaters have to start with simple equipment and EARN the artifacts. This includes enchanted weapon/armour, spellbooks, stat rising potions, alchemy recipies and rings. [I once got a(!) One Ring from killing a red dragon; should never happen! The Rings of Life/Acid a too easy to get (that is too soon!). Grimreapers and the acid type monsters are Nice And Nasty things (who says you have to kill every monster;-). But as you'll find the protective rings very/too soon (even in shops) they are only a problem in the very beginning.] I'm planning to put some mid-level artifacts at the end of the maps I'm working at. (e.g. large fireball spell, ring of life/magic, stat potions, amulet ac+2, etc) Of course that's quite pointless as long as these things are sold out in the shops. > > > I agree here, mana blast SHOULD perhaps do more a percentage of damage > > than a fixed amount. > > It makes sense to me to have the failure effect "proportional" to the > difference in levels between the spell and the spellcaster. If a > 12th-level mage botches a 1st-level spell, no big deal (maybe lots of > flowers appear ;). But if he botches a 12th-level spell, look out! He should more likely FAIL with a high level spell. But the damage should better be depend on his hp or his spellcasting level. (There are not so many spells > level 10, but there are other reasons for spell failure) > > I've hit some nasty scroll failure effects on occasion, and didn't notice > > where it came from for a week. Turned out that a failure effect > > disenchanted my sword from a +7, and it wouldn't let me re-prepare it so I > > could charge it back up again. Definately not fun when you have a 5th > >level Wizard with no weapon worth talking about. ;) Thats probably a bit overdoing it when reading a scroll. But a magically untrained fighter casting a high level spell while carrying a bonecrusher - well, he has to know the chances he's taking... > > It might make sense to have a list of 'failure effects' that happen instead of > > randomly choosing a spell. Certainly, if you mess up a spell, and a detection > > spell is cost instead, that is no big deal. (as a side note, if you flub a > > spell, and it turns into something that kills the monsters, I don't think you > > should get exp for that - not sure if you do right now, however.) > > This sounds pretty good. Something like a detection spell is almost > certainly going to be beneficial (as opposed to detrimental), so I > wouldn't think it'd make a good failure effect. It seems to me that if > the magic "gets out of hand", a good light-moderate failure effect might > be a ball lightning. It could seriously damage the spellcaster, or maybe > not (it could instead damage nearby enemies, but the point is that you > don't know exactly what'll happen). I think I'd have to agree that the > spellcaster should not get experience for any kills resulting from a > botched spell (not because he wasn't responsible for the death, but > because it was accidental). > > Does anyone else agree with this? Sure. Though there is no need for hurting spells. Mana storm does this already. Note: spell_failure_effect does NOT the same as a failed scroll. The magic of the scroll is warped randomly, I think. Spell_failure_effect does only wonder/confusion/mana storm and does not take into account the level of the spell (afaik). The scroll failure system might be an improvement (perhaps + the mana storm which is a cool idea). Spells that do damage to the player are either to weak (-10% hp? just retreat for a while!) or too strong (no need to kill the player for a failed spell). I'd suggest e.g. confusion (BAD in a room full of monsters), sleep, desruction, curse (an item), summon hostile monsters, magic draining. All bad things but not fatal. > > -Michael > > (BTW, Brian, I like the lighting code. Too bad more maps don't make use > of it.) > -- Florian ------------------------------------------------ | h729ihqu@sun1.cip.fak14.uni-muenchen.de | | http://www.fak14.uni-muenchen.de/~h729ihqu/ | ------------------------------------------------ P.S. After thinking about it, doubling the experience for every level gain seems not such a good idea. I like my characters "specialize" in certain exp categories. If the next level needs so much more exprerience than the last level, other categories can "catch up". Result: an "average" character, not my taste. From owner-crossfire Wed Oct 9 22:00:16 1996 Return-Path: Received: (from mdomo@localhost) by ifi.uio.no (8.6.11/ifi2.4) id for crossfire-ut ; Wed, 9 Oct 1996 22:00:16 +0200 Received: from soda.CSUA.Berkeley.EDU (soda.CSUA.Berkeley.EDU [128.32.43.52]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Wed, 9 Oct 1996 22:00:11 +0200 Received: from soda.CSUA.Berkeley.EDU (peterm@localhost) by soda.CSUA.Berkeley.EDU (8.6.12/8.6.12) with ESMTP id MAA23943; Wed, 9 Oct 1996 12:58:13 -0700 Message-Id: <199610091958.MAA23943@soda.CSUA.Berkeley.EDU> Mime-Version: 1.0 To: h729ihqu@sun1.cip.fak14.uni-muenchen.de cc: crossfire@ifi.uio.no Subject: CF: Re: Spell failures, the programmer weighs in In-reply-to: Your message of "Wed, 09 Oct 1996 20:57:53 PDT." <199610100357.UAA03190@ue801di.lrz-muenchen.de> Date: Wed, 09 Oct 1996 12:57:56 -0700 From: Peter Mardahl Sender: owner-crossfire Precedence: bulk Status: RO > Michael Martin wrote: > > IMHO, making monsters more powerful is not necessary. The real problem is > > that players can become way too powerful. For example, I once had a > > Agreed - at least it's too easy. Possibly this is a map problem. I don't think any of the ORDINARY artifacts which are handed out are much of a problem. The ones you make are the real trouble. > > closer to a doubling of experience. This would dramatically cut down on > > the number of ultra-powerful characters, and in turn the nasty monsters > > would still be nasty. It's already worse than just gaining x experience to gain a level. You get less experience/monster as you go up in level, so it gets harder already. > Another thing is that characters become more powerful than their level > would suggest (using artifact weapons). And you get MUCH more experience > from higher level monsters. And a 50 lev fighter + "demonbane +10" has A *big* problem is that you can spray cone spells over a MULTI-SQUARE monster and kill him easily. I figure a big dragon, at 6 squares and 3000hp, is *easier* to kill than a "baby" dragon, at 1 square and 1250hp. A big dragon is 2.5 times *easier* to kill with icestorm!!!!! And I won't even mention how easy it is to kill a demon lord with Holy Word. At one point I hacked something to balance this a bit: I made it so that cone spells couldn't go through monsters. In this way, you could only hit the front of a monster with a cone spell, and cone spells in general are weaker. It's one of the #defines in config.h, NOT a default. > little difficulty with the lev 100 angels in Lake Country. And he gets > tons of experience points. (And you get even *more* exp if the > artifact gives a stat bonus.) Lots of monsters in lake country need adjustment. End of story. > What I did in my version (or plan to do) was removing most artifacts > from the treasure file. I think they should almost NEVER be handed out > randomly. Better make them quest items so charaters have to start with > simple equipment and EARN the artifacts. Why don't you design some better maps? > [I once got a(!) One Ring from killing a red dragon; should never happen! Well, the One Ring is really rare. One solution is to have a lot of artifacts in the artifacts file, so that the least probable item shows up more rarely. I've never seen the One Ring come randomly in a dungeon, only in a shop. Having things show up in shops *is* a problem. > I'm planning to put some mid-level artifacts at the end of the maps > I'm working at. (e.g. large fireball spell, ring of life/magic, stat potions, > amulet ac+2, etc) Of course that's quite pointless as long as these things > are sold out in the shops. > > > I agree here, mana blast SHOULD perhaps do more a percentage of damage > > > than a fixed amount. > > > > It makes sense to me to have the failure effect "proportional" to the > > difference in levels between the spell and the spellcaster. If a > > 12th-level mage botches a 1st-level spell, no big deal (maybe lots of > > flowers appear ;). But if he botches a 12th-level spell, look out! When I hacked the spell failure effects, I did make it proportional, though also random. You're *more* likely to get a big disaster like madness or a mana storm from a difficult spell than an easy one, and it also depends on how much encumbrance the player had. > He should more likely FAIL with a high level spell. But the damage > should better be depend on his hp or his spellcasting level. Modulating the damage by the players properties i have NOT done. > Note: spell_failure_effect does NOT the same as a failed scroll. The > magic of the scroll is warped randomly, I think. Spell_failure_effect > does only wonder/confusion/mana storm and does not take into account > the level of the spell (afaik). You are correct, unless someone changed this. This is how I programmed it. Random spells are distasteful, I prefer to screw the player in certain predictable ways, not inadvertently help him. > (no need to kill the player for a failed spell). I'd suggest e.g. > confusion (BAD in a room full of monsters), sleep, desruction, curse > (an item), summon hostile monsters, magic draining. All bad things but > not fatal. Perhaps the mana storm is too severe? It's not difficult to change, though it does require a little hacking. PM From owner-crossfire Wed Oct 9 21:43:41 1996 Return-Path: Received: (from mdomo@localhost) by ifi.uio.no (8.6.11/ifi2.4) id for crossfire-ut ; Wed, 9 Oct 1996 21:43:41 +0200 Received: from xplorer.gsfc.nasa.gov (xplorer.gsfc.nasa.gov [128.183.126.216]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Wed, 9 Oct 1996 21:43:36 +0200 Received: (from thomas@localhost) by xplorer.gsfc.nasa.gov (LHEA9504/950407.s1) id PAA17835 for crossfire@ifi.uio.no; Wed, 9 Oct 1996 15:43:15 -0400 Date: Wed, 9 Oct 1996 15:43:15 -0400 From: Brian Thomas Message-Id: <199610091943.PAA17835@xplorer.gsfc.nasa.gov> Mime-Version: 1.0 To: crossfire@ifi.uio.no Subject: CF: Re: experience gain in CF (too easy) Sender: owner-crossfire Precedence: bulk Status: RO > From: Florian Beck writes: > > Michael Martin wrote: > > IMHO, making monsters more powerful is not necessary. The real problem is > > that players can become way too powerful. For example, I once had a > > Agreed - at least it's too easy. > Some time before this tread started I sent in a patch for the experience gain. Back in the pre-skills CF (0.91.7?, yeesh!) you would *not* get the full experience from a monster if that monster would give you more experience than you currently had (!). In the skills implementation, there are *no* brakes (so to speak). The patch addresses that. But rather than just adopt the old system again (I believe you were awarded 1/2 of the monster's exp if its orignal exp value exceed your current expience) I thought it would make more playbalance/sense to limit the experience gain to *no greater than* 1/2 the experience difference between your present level and the next one. For example, you are 1st level (exp 512) and you kill (for arguments sake) a Jessy. You dont get awarded 2 million exp!, instead, you get 500 exp [ie (1000 - 0)/2 ]. In a philosophical sense, you can only learn so fast, AND, if you do manage to kill something way more powerfull than you, its either because of a flaw in a map (shame!) and/or luck! Just killing a Jessy *once* cant possibly teach a fighter/mage/whatever their trade all the way up to 15th level in an instant! -b.t. From owner-crossfire Wed Oct 9 19:50:40 1996 Return-Path: Received: (from mdomo@localhost) by ifi.uio.no (8.6.11/ifi2.4) id for crossfire-ut ; Wed, 9 Oct 1996 19:50:40 +0200 Received: from veal.csv.warwick.ac.uk (veal.csv.warwick.ac.uk [137.205.148.10]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Wed, 9 Oct 1996 19:50:36 +0200 From: Mr T Woodhouse Message-Id: <4838.199610091750@veal.csv.warwick.ac.uk> Received: by veal.csv.warwick.ac.uk id SAA04838; Wed, 9 Oct 1996 18:50:01 +0100 (BST) Subject: CF: Attacking Speed+Bonecrusher Mime-Version: 1.0 To: crossfire@ifi.uio.no Date: Wed, 9 Oct 1996 18:49:55 +0100 (BST) X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-crossfire Precedence: bulk Status: RO Hmmm this has probably been suggested before, but why not make it so there's a time delay between starting attacking a monster and a weapon landing for the first blow (depending on your attack speed)...this would remove the problem of say the Bonecrusher, which can kill a lot of monsters with the first hit, so it doesnt matter if you've got a speed of 0.01 when you wield it. Just a thought, Zharradan From owner-crossfire Wed Oct 9 17:09:59 1996 Return-Path: Received: (from mdomo@localhost) by ifi.uio.no (8.6.11/ifi2.4) id for crossfire-ut ; Wed, 9 Oct 1996 17:09:59 +0200 Received: from mne.ifi.uio.no (1232@mne.ifi.uio.no [129.240.70.5]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Wed, 9 Oct 1996 17:09:56 +0200 Received: (from kjetilho@localhost) by mne.ifi.uio.no ; Wed, 9 Oct 1996 17:09:53 +0200 Message-Id: <199610091509.15354.mne.ifi.uio.no@ifi.uio.no> Date: Wed, 9 Oct 1996 10:52:11 -0400 (EDT) From: Michael Martin Mime-Version: 1.0 To: crossfire@ifi.uio.no Subject: Re: CF: BUG in spell_effect.c? Sender: owner-crossfire Precedence: bulk Status: RO (Oops, sorry, lost the credit for the included text bits from the previous message. I think it was Dave.) > Agreed. Perhaps some code to beef up the monsters a bit as level > increases(to some preset maximum), would work. I know that it's fairly > easy for a low level char to get up in levels fairly quickly if you know > the right places to go. Would be nice to see even orcs stay a challenge > to a level 3 character when you are wandering around looking for more > things to kill without too high a risk. IMHO, making monsters more powerful is not necessary. The real problem is that players can become way too powerful. For example, I once had a barbarian which I got up to level 77 before I gave up on him due to boredom. He had an enchanted Bonecrusher +25 (with 150 dam and 14 combined stat bonuses), over 450 hp, over 500 sp, and over 400 grace (with the ring of Elrond--or was it two of them?). Needeless to say, his stats were quite high (more than one 30 with the Bonecrusher wielded) and the rest of his inventory was just as powerful. He could practically wade through dragons (well, any kind except electric) and the only thing really challenging was Jessy. While it might be fun to try playing such a powerful character for a little while, the game really should not make it so easy (if allowed at all). Most of this seems to me to result from the experience/level table (in common/living.c). For the earlier levels a new level is gained by (approximately) doubling the experience of the last level. But after about level 12 or so, it flattens out. For example, it takes 900000 exp to get to level 12, but only another 500000 (roughly 50%) to get to level 13. I would suggest changing this so that levels require something much closer to a doubling of experience. This would dramatically cut down on the number of ultra-powerful characters, and in turn the nasty monsters would still be nasty. > I agree here, mana blast SHOULD perhaps do more a percentage of damage > than a fixed amount. It makes sense to me to have the failure effect "proportional" to the difference in levels between the spell and the spellcaster. If a 12th-level mage botches a 1st-level spell, no big deal (maybe lots of flowers appear ;). But if he botches a 12th-level spell, look out! Likewise, if a 1st-level caster screws up a 1st-level spell, the consequences could also be severe. Also, you could allow (I don't think the game does this right now) a spellcaster to try to cast a spell with a level higher than his (e.g. the 12th-level mages tries to cast destruction, which I think is 18th-level). There would a very substantial chance of failure (depending on their relative levels), and if he fails that effects should be (potentially) disasterous. (Anyone remember the head "explosions" from trying use "transferrence" to overcharge on mana?) How about loss of an Int or Pow point or some sp as a possible *bad* spell failure effect? > I've hit some nasty scroll failure effects on occasion, and didn't notice > where it came from for a week. Turned out that a failure effect > disenchanted my sword from a +7, and it wouldn't let me re-prepare it so I > could charge it back up again. Definately not fun when you have a 5th >level Wizard with no weapon worth talking about. ;) Well, in principle a wizard should be able to get by with mostly just spells. In practice, he will need a good weapon. It seems to me that having weapon magic draining as a failure effect is a bit strong (it should only happen if something nasty goes wrong). > It might make sense to have a list of 'failure effects' that happen instead of > randomly choosing a spell. Certainly, if you mess up a spell, and a detection > spell is cost instead, that is no big deal. (as a side note, if you flub a > spell, and it turns into something that kills the monsters, I don't think you > should get exp for that - not sure if you do right now, however.) This sounds pretty good. Something like a detection spell is almost certainly going to be beneficial (as opposed to detrimental), so I wouldn't think it'd make a good failure effect. It seems to me that if the magic "gets out of hand", a good light-moderate failure effect might be a ball lightning. It could seriously damage the spellcaster, or maybe not (it could instead damage nearby enemies, but the point is that you don't know exactly what'll happen). I think I'd have to agree that the spellcaster should not get experience for any kills resulting from a botched spell (not because he wasn't responsible for the death, but because it was accidental). Does anyone else agree with this? -Michael (BTW, Brian, I like the lighting code. Too bad more maps don't make use of it.) From owner-crossfire Wed Oct 9 17:04:50 1996 Return-Path: Received: (from mdomo@localhost) by ifi.uio.no (8.6.11/ifi2.4) id for crossfire-ut ; Wed, 9 Oct 1996 17:04:50 +0200 Received: from mne.ifi.uio.no (1232@mne.ifi.uio.no [129.240.70.5]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Wed, 9 Oct 1996 17:04:46 +0200 Received: (from kjetilho@localhost) by mne.ifi.uio.no ; Wed, 9 Oct 1996 17:04:45 +0200 Message-Id: <199610091504.15172.mne.ifi.uio.no@ifi.uio.no> Subject: CF: Balance Mime-Version: 1.0 To: crossfire@ifi.uio.no Date: Wed, 9 Oct 1996 15:21:55 +0100 (BST) From: Mr T Woodhouse Sender: owner-crossfire Precedence: bulk Status: RO The following monsters seem to give way too much exp (either that or the level/exp structure needs to be changed..) 1) Twis in the Lake Country castle (the one trapped in an anti-magic moat). 2) The Demon in Lake Country caves (the quest for the dragon slayer). Pretty easy to kill with melee...damn easy to kill with holy word spell (even at low cleric levels). 3) The Angel in the same caves (managed to get to level 100+ pretty easily with the help of this and the demon). Now ok the Angel can be hard (espcially if it casts the seemingly overpowerfull meteor swarm spell, one touch of which can kill a barbarian with 500 hps...) but jumping up 20 levels at a time by killing him seems a little over generous. Btw.. has anyone got a list of Crossfire servers on the net? I'm the only one at my site who seems to like it :( Zharradan. PS. Forgot one other unbalanced monster: The DemiLich...pretty easy to kill and gives quite a lot of exp.. From owner-crossfire Wed Oct 9 14:44:32 1996 Return-Path: Received: from capp.cap.se (capp.cap.se [192.176.199.25]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Wed, 9 Oct 1996 14:44:32 +0200 From: ian.vitek@capgemini.se Received: from smtp ([192.176.198.70]) by capp.cap.se (8.7.5/8.7.3) with SMTP id NAA05473; Wed, 9 Oct 1996 13:48:06 +0100 (MET) Message-Id: <199610091248.NAA05473@capp.cap.se> Date: Wed, 9 Oct 1996 14:44:29 +0100 To: master@rahul.net, crossfire-bugs@ifi.uio.no Subject: Running my crossfire gives me coredumps MIME-version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: quoted-printable X-Mailer: TFS Gateway /220000000/220020140/220000469/220120025/ Status: RO When starting up my crossfire I get these messages=20 (/tmp/crosservlog/*): Starting Crossfire Tue Oct 8 18:44:39 MET DST 1996 for the 8 time... Welcome to CrossFire, v0.92.7 Copyright (C) 1994 Mark Wedel. Copyright (C) 1992 Frank Tore Johansen. Opening add user socket on 13326 Waiting for connections... Adding socket 5 from 192.176.197.66. socket[anon5]: version socket[anon5]: listen 0 socket[anon5]: name ivi2146 socket[ivi2146]: set pixmaps socket[ivi2146]: add 145.247.51.86:0 Reading artifacts... Resetting race to undead from skeleton for archetype generate_skeleton Resetting race to undead from skull for archetype generate_skull Resetting race to undead from skeleton for archetype skeleton =20 *snip* =20 Resetting race to giant from chaos for archetype cyclops Resetting race to dwarf from sylvan for archetype gnome Resetting race to insect from xan for archetype xan Initializing reading data... Can't open /home/ivi2146/crossfire/lib/bookarch init_mon_info() got 142 monsters Reading alchemical formulae...Trying to load=20 map/home/ivi2146/crossfire/lib/maps/city/city. load_original_map: /city/city =20 Then I get a core dump when I try to read any expensive scroll[!]. And if you look at the log file it sez:=20 Can't open /home/ivi2146/crossfire/lib/bookarch I can't find that file anywhere! Can you please mail me one if I should have one (for the v0.92.7), or=20 do you want more info (like the core dump)? =20 Regards Ian Vitek ian.vitek@capgemini.se PS: THANKS for your help last time :D From owner-crossfire Tue Oct 8 23:11:28 1996 Return-Path: Received: (from mdomo@localhost) by ifi.uio.no (8.6.11/ifi2.4) id for crossfire-ut ; Tue, 8 Oct 1996 23:11:28 +0200 Received: from ue801di.lrz-muenchen.de (root@dial001.ppp.lrz-muenchen.de [129.187.24.1]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Tue, 8 Oct 1996 23:11:23 +0200 Received: (from fb@localhost) by ue801di.lrz-muenchen.de (8.6.12/8.6.9) id XAA05691 for crossfire@ifi.uio.no; Tue, 8 Oct 1996 23:13:25 -0700 From: Florian Beck Message-Id: <199610090613.XAA05691@ue801di.lrz-muenchen.de> Subject: CF: BUG in spell_effect.c? Mime-Version: 1.0 To: crossfire@ifi.uio.no Date: Tue, 8 Oct 1996 23:13:24 -0700 (MST) Reply-To: h729ihqu@sun1.cip.fak14.uni-muenchen.de X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 1478 Sender: owner-crossfire Precedence: bulk Status: RO I've just compiled CF with SPELL_FAILURE_EFFECTS defined. Didn't work: I had to change "server/spell_effect.c" line 52: cast_cone(op,0,10,SP_WOW,spellarch[SP_WOW],0); to cast_cone(op,op,0,10,SP_WOW,spellarch[SP_WOW],0); A bug? Or is SPELL_FAILURE_EFFECTS not supportet anymore? BTW, while SPELL_FAILURE_EFFECTS is annoying for heavily encumbered low-level characters, it has MUCH less impact on gameplay than I had expected. Considering the only fault of CF (it's too easy), SPELL_FAILURE_EFFECTS seem a good idea to make the game a bit harder. E.g: Failure effects when a low level/badly injured/confued character casts a (high level) spell. AND: The failure effects are quite wimpy. Not in the beginning; but a mana blast is not much of a problem for a mid/high level character. I tried to cast a spell whle carryinf a very heavy weapon: >Oh, a wyvern! Icebolt! >Hm, strange effect, didn't work, damn. >Again! Same... >Again! Same... >Hm (reading the messages) ... oh mana storm, bad... >or no, just unwield the weapon. That happens often. Perhaps have a greater variety of negative effects (summon mighty enemies, destory part of the invetory, etc) and try to hurt even a HIGHER level character who casts something he can't handle. -- Florian ------------------------------------------------ | h729ihqu@sun1.cip.fak14.uni-muenchen.de | | http://www.fak14.uni-muenchen.de/~h729ihqu/ | ------------------------------------------------ From owner-crossfire Wed Oct 9 12:54:49 1996 Return-Path: Received: (from mdomo@localhost) by ifi.uio.no (8.6.11/ifi2.4) id for crossfire-ut ; Wed, 9 Oct 1996 12:54:49 +0200 Received: from mne.ifi.uio.no (1232@mne.ifi.uio.no [129.240.70.5]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Wed, 9 Oct 1996 12:54:46 +0200 Received: (from kjetilho@localhost) by mne.ifi.uio.no ; Wed, 9 Oct 1996 12:54:44 +0200 Message-Id: <199610091054.13805.mne.ifi.uio.no@ifi.uio.no> Date: Tue, 8 Oct 1996 16:29:06 -0700 (PDT) From: Dave Bristel Mime-Version: 1.0 To: crossfire@ifi.uio.no Subject: Re: CF: BUG in spell_effect.c? In-Reply-To: <9610081433.ZM829@stealth.eng.pyramid.com> Sender: owner-crossfire Precedence: bulk Status: RO On Tue, 8 Oct 1996, Mark Wedel wrote: > On Oct 8, 11:13pm, Florian Beck wrote: > > Subject: CF: BUG in spell_effect.c? > > > > > > I've just compiled CF with SPELL_FAILURE_EFFECTS defined. > > > > Didn't work: I had to change "server/spell_effect.c" line 52: > > cast_cone(op,0,10,SP_WOW,spellarch[SP_WOW],0); > > to > > cast_cone(op,op,0,10,SP_WOW,spellarch[SP_WOW],0); > > > > A bug? Or is SPELL_FAILURE_EFFECTS not supportet anymore? > > Its a bug. It is not really easy for me to compile the game with all possible > options, so some things slip by. So is the fix valid, or might there be an unexpected side effect? > > > > > > > BTW, while SPELL_FAILURE_EFFECTS is annoying for heavily encumbered > > low-level characters, it has MUCH less impact on gameplay than I had > > expected. Considering the only fault of CF (it's too easy), > > SPELL_FAILURE_EFFECTS seem a good idea to make the game a bit harder. > > E.g: Failure effects when a low level/badly injured/confued character > > casts a (high level) spell. Agreed. Perhaps some code to beef up the monsters a bit as level increases(to some preset maximum), would work. I know that it's fairly easy for a low level char to get up in levels fairly quickly if you know the right places to go. Would be nice to see even orcs stay a challenge to a level 3 character when you are wandering around looking for more things to kill without too high a risk. > > AND: The failure effects are quite wimpy. Not in the beginning; > > but a mana blast is not much of a problem for a mid/high level > > character. I tried to cast a spell whle carryinf a very heavy weapon: I agree here, mana blast SHOULD perhaps do more a percentage of damage than a fixed amount. > > >Oh, a wyvern! Icebolt! > > I don't know if the failure uses the same type of code when you mess a scroll > (would make some sense if it does), but I have seldom seen a scroll failur > actually have a harmful effect to the player (any cone spell goes outward, so > he is not hit, etc.) I've hit some nasty scroll failure effects on occasion, and didn't notice where it came from for a week. Turned out that a failure effect disenchanted my sword from a +7, and it wouldn't let me re-prepare it so I could charge it back up again. Definately not fun when you have a 5th level Wizard with no weapon worth talking about. ;) > It might make sense to have a list of 'failure effects' that happen instead of > randomly choosing a spell. Certainly, if you mess up a spell, and a detection > spell is cost instead, that is no big deal. (as a side note, if you flub a > spell, and it turns into something that kills the monsters, I don't think you > should get exp for that - not sure if you do right now, however.) > > But a short list of bad spells could be any of the ball spells, detonated on > the player, maybe ball lightning (might hit the player instead of others), etc. > > > -- > --Mark > Dave From owner-crossfire Tue Oct 8 23:34:24 1996 Return-Path: Received: (from mdomo@localhost) by ifi.uio.no (8.6.11/ifi2.4) id for crossfire-ut ; Tue, 8 Oct 1996 23:34:24 +0200 Received: from gossip.pyramid.com (gossip.pyramid.com [129.214.1.101]) by ifi.uio.no with SMTP (8.6.11/ifi2.4) id for ; Tue, 8 Oct 1996 23:34:20 +0200 Received: from stealth-news.pyramid.com by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway) id AA16185; Tue, 8 Oct 96 14:33:43 -0700 Received: by stealth.eng.pyramid.com (8.6.12/Pyramid_Internal_Configuration) id OAA00831; Tue, 8 Oct 1996 14:33:20 -0700 From: "Mark Wedel" Message-Id: <9610081433.ZM829@stealth.eng.pyramid.com> Date: Tue, 8 Oct 1996 14:33:19 -0700 In-Reply-To: Florian Beck "CF: BUG in spell_effect.c?" (Oct 8, 11:13pm) References: <199610090613.XAA05691@ue801di.lrz-muenchen.de> X-Mailer: Z-Mail (3.2.0 06sep94) Mime-Version: 1.0 To: h729ihqu@sun1.cip.fak14.uni-muenchen.de, crossfire@ifi.uio.no Subject: Re: CF: BUG in spell_effect.c? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-crossfire Precedence: bulk Status: RO On Oct 8, 11:13pm, Florian Beck wrote: > Subject: CF: BUG in spell_effect.c? > > > I've just compiled CF with SPELL_FAILURE_EFFECTS defined. > > Didn't work: I had to change "server/spell_effect.c" line 52: > cast_cone(op,0,10,SP_WOW,spellarch[SP_WOW],0); > to > cast_cone(op,op,0,10,SP_WOW,spellarch[SP_WOW],0); > > A bug? Or is SPELL_FAILURE_EFFECTS not supportet anymore? Its a bug. It is not really easy for me to compile the game with all possible options, so some things slip by. > > > BTW, while SPELL_FAILURE_EFFECTS is annoying for heavily encumbered > low-level characters, it has MUCH less impact on gameplay than I had > expected. Considering the only fault of CF (it's too easy), > SPELL_FAILURE_EFFECTS seem a good idea to make the game a bit harder. > E.g: Failure effects when a low level/badly injured/confued character > casts a (high level) spell. > > AND: The failure effects are quite wimpy. Not in the beginning; > but a mana blast is not much of a problem for a mid/high level > character. I tried to cast a spell whle carryinf a very heavy weapon: > > >Oh, a wyvern! Icebolt! I don't know if the failure uses the same type of code when you mess a scroll (would make some sense if it does), but I have seldom seen a scroll failur actually have a harmful effect to the player (any cone spell goes outward, so he is not hit, etc.) It might make sense to have a list of 'failure effects' that happen instead of randomly choosing a spell. Certainly, if you mess up a spell, and a detection spell is cost instead, that is no big deal. (as a side note, if you flub a spell, and it turns into something that kills the monsters, I don't think you should get exp for that - not sure if you do right now, however.) But a short list of bad spells could be any of the ball spells, detonated on the player, maybe ball lightning (might hit the player instead of others), etc. -- --Mark From owner-crossfire Mon Oct 7 04:12:21 1996 Return-Path: Received: (from mdomo@localhost) by ifi.uio.no (8.6.11/ifi2.4) id for crossfire-ut ; Mon, 7 Oct 1996 04:12:21 +0200 Received: from mne.ifi.uio.no (1232@mne.ifi.uio.no [129.240.70.5]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Mon, 7 Oct 1996 04:12:18 +0200 Received: (from kjetilho@localhost) by mne.ifi.uio.no ; Mon, 7 Oct 1996 04:12:16 +0200 Message-Id: <199610070212.9730.mne.ifi.uio.no@ifi.uio.no> Date: Sat, 5 Oct 96 07:10:18 MDT From: scott@alpe.Tymnet.COM (Scott Wedel) Mime-Version: 1.0 To: crossfire@ifi.uio.no Subject: CF: regeneration, sp recovery, hungry patch Sender: owner-crossfire Precedence: bulk Status: RO Mannen Akihiro sent out a patch that corrects a problem with the code not changing regeneration, magic (mana recovery), sustenance, or grace recovery when equiping or removing an item. His patch is correct, but his patch uses these attributes from the saved player file which may not be accurate any more. The following patch searches the applied items for these attributes and sets them accordingly. Thus, these fields will be correct even if they are not correctly saved in the player file. Since the applied items (fix_player function) are now checked as part equipping or removing items that can change abilities (change_abil function), either Mr Mannen Akihiro's patch or the following patch should be used. If both are used then temporarily (until fix_player is called) the affected attribute will be wrong. *** oldcommon/living.c Wed Oct 2 04:12:53 1996 --- common/living.c Sat Oct 5 06:46:36 1996 *************** *** 867,872 **** --- 867,876 ---- op->chosen_skill->level=op->chosen_skill->exp_obj->level; #endif op->attacktype=0; + op->contr->digestion = 0; + op->contr->gen_hp = 0; + op->contr->gen_sp = 0; + op->contr->gen_grace = 0; } if(op->slaying!=NULL) { free_string(op->slaying); *************** *** 909,917 **** * inappropriate to allow these applied objects to change stats */ && tmp->type!=EXPERIENCE #endif ! ) for(i=0;i<7;i++) change_attr_value(&(op->stats),i,get_attr_value(&(tmp->stats),i)); op->protected|=tmp->protected; op->vulnerable|=tmp->vulnerable; op->attacktype|=tmp->attacktype; --- 913,936 ---- * inappropriate to allow these applied objects to change stats */ && tmp->type!=EXPERIENCE #endif ! ) { for(i=0;i<7;i++) change_attr_value(&(op->stats),i,get_attr_value(&(tmp->stats),i)); + /* these are the items that currently can change digestion, regeneration, + * spell point recovery and mana point recovery. Seems sort of an arbitary + * list, but other items store other info into stats array. */ + if ( (tmp->type == EXPERIENCE) || (tmp->type == WEAPON) + || (tmp->type == ARMOUR) || (tmp->type == HELMET) + || (tmp->type == SHIELD) || (tmp->type == RING) + || (tmp->type == BOOTS) || (tmp->type == GLOVES) + || (tmp->type == AMULET ) || (tmp->type == GIRDLE) + || (tmp->type == BRACERS ) || (tmp->type == CLOAK)){ + op->contr->digestion += tmp->stats.food; + op->contr->gen_hp += tmp->stats.hp; + op->contr->gen_sp += tmp->stats.sp; + op->contr->gen_grace += tmp->stats.grace; + } + } op->protected|=tmp->protected; op->vulnerable|=tmp->vulnerable; op->attacktype|=tmp->attacktype; From owner-crossfire Wed Oct 23 15:49:45 1996 Return-Path: Received: from zikzak.zikzak.net (zikzak.zikzak.net [203.2.198.1]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Wed, 23 Oct 1996 15:48:02 +0200 Received: from otis.netspace.net.au (otis.netspace.net.au [203.10.110.171]) by zikzak.zikzak.net (8.6.10/8.6.10) with ESMTP id NAA06998 for <@zikzak.zikzak.net:crossfire-bugs@ifi.uio.no>; Wed, 23 Oct 1996 13:52:18 GMT Received: from phaedrus.zikzak.net (phaedrus.zikzak.net [203.2.198.131]) by otis.netspace.net.au (8.7.5/8.6.11) with SMTP id XAA02975 for <@zikzak.zikzak.net:crossfire-bugs@ifi.uio.no>; Wed, 23 Oct 1996 23:47:09 +1000 (EST) Received: (from karlg@localhost) by phaedrus.zikzak.net (950413.SGI.8.6.12/950213.SGI.AUTOCF) id XAA14755 for crossfire-bugs@ifi.uio.no; Wed, 23 Oct 1996 23:50:34 -0800 From: karlg@phaedrus.zikzak.net (Karl Geppert) Message-Id: <199610240750.XAA14755@phaedrus.zikzak.net> Subject: the moving player problem To: crossfire-bugs@ifi.uio.no Date: Wed, 23 Oct 1996 23:50:34 -0800 (EST) X-Mailer: ELM [version 2.4 PL24 PGP3 *ALPHA*] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO We have spoken on the problem before, that when running crossfire, any movement is interpreted as a push on the player. I have some more questions, based on a tonights debugging session with 0.92.7 statutary info follows o What version of crossfire did you use? 0.92.7 o What type of computer did you use? SGI indy, R5000 o What release of the operating system did it have? 6.2 o What windowing system are you using (Ie, openwindows, X11R6, etc) Irix flavoured X11R6 o What compiler (and its version) did you use (ie, gcc, acc, etc)? cc o Which flags did you give it? No extra flags. o If you managed to compile Crossfire, include the output of "crossfire -o". server/crossfire -o Welcome to CrossFire, v0.92.7 Copyright (C) 1994 Mark Wedel. Copyright (C) 1992 Frank Tore Johansen. Maintained locally by: karlg@phaedrus.zikzak.net Questions and bugs should be mailed to above address. Non-standard include files: Logging: Libdir: /usr/people/karlg/cross/lib Perm file: /forbid Shutdown file: /shutdown Save player: Save mode: 0660 Playerdir: /players Save homedir: Lock player: Unique items: Itemsdir: /unique-items Lock items: Use checksum: Tmpdir: /tmp Fontdir: /usr/people/karlg/cross/fonts Compress: /usr/bin/compress Uncompress: /usr/bin/uncompress Map max timeout: 1000 Map reset: Max objects: 6000 Use_calloc: CHRFONT: Use_swap_stats: Sound_effects: DM mail: karlg@phaedrus.zikzak.net Server: Port: 13326 Explore mode: Shop listings: Random encounter: New improve weapon: Max_time: 120000 IRIX phaedrus 6.2 03131015 IP22 ///// Now for the pertinent question bit I presume that move_player's lines 1463-1465 in server/player.c (to whit if(op->contr->fire_on) fire(op,dir); else move_player_attack(op,dir); ) is meant to call move_player_attack at every step. If there is nothing for a player to attack, then it will do nothing, allowing map updates to happen when you get the update_object(op); on line 1474. On this version, the test if ((tmp->enemy != op) && (tmp->type==PLAYER || QUERY_FLAG(tmp,FLAG_UNAGGRESSIVE) || QUERY_FLAG(tmp, FLAG_FRIENDLY)) && op->contr->peaceful && (!op->contr->braced)) { on lines 1372-1375 of move_player_attack in player.c always goes to true. However if you comment out the call to move_player_attack, and just let it fall to update_obj the player turns in the correct direction, but does not move at all. What should be the correct values to update_object be, to get a move? Cheers, Karl From owner-crossfire Thu Oct 17 15:01:46 1996 Return-Path: Received: from ceylon.informatik.uni-rostock.de (ceylon.informatik.uni-rostock.de [139.30.5.237]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Thu, 17 Oct 1996 15:01:43 +0200 Received: by ceylon.informatik.uni-rostock.de id OAA03322; Thu, 17 Oct 1996 14:59:46 +0200 Received: by zirkon.informatik.uni-rostock.de id OAA07126; Thu, 17 Oct 1996 14:59:31 +0200 (MET DST) From: Jan Echternach Message-Id: <199610171259.OAA07126@zirkon.informatik.uni-rostock.de> Subject: Some bugs in 0.92.6/0.92.7 To: crossfire-bugs@ifi.uio.no Date: Thu, 17 Oct 1996 14:59:27 +0200 (MET DST) Cc: mwedel@pyramid.com Reply-To: jan.echternach@informatik.uni-rostock.de (Jan Echternach) X-Mailer: ELM [version 2.4 PL24 ME7] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO Hi, I have found a few bugs in crossfire-0.92.7. First some system information: PC Compatible with Linux 2.0.21 X11R6.1 (XFree86 3.1.2G) gcc-2.7.2.1 libc-4.7.6 1. tempnam() is declared in libc-4.7.6 I had to remove the declaration from include/includes.h to compile crossfire successfully. Maybe it's a problem with my installation of gcc+libc. ------------------------------------------------------------------------------ making all in ./common... make[1]: Entering directory `/mnt/src/crossfire-0.92.7/common' gcc -g -DDEBUG -O -I../include -I/usr/local/include -I/usr/X11R6/include -Dlinux -D__i386__ -D_POSIX_SOURCE -D_BSD_SOURCE -D_SVID_SOURCE -DX_LOCALE -DLONGJUMP -DXpm_Pix -DSOUND_EFFECTS -DERIC_SERVER=0 -DFUNCPROTO=15 -DNARROWPROTO -DFONTDIR=\"/usr/local/games/crossfire/fonts\" -DFONTNAME=\"crossfire\" -DLIBDIR=\"/usr/local/games/crossfire/lib\" -c arch.c -o arch.o In file included from ../include/global.h:35, from arch.c:28: ../include/includes.h:70: conflicting types for `tempnam' /usr/include/stdio.h:152: previous declaration of `tempnam' make[1]: *** [arch.o] Error 1 make[1]: Leaving directory `/mnt/src/crossfire-0.92.7/common' making all in ./doc... [Compilation continues. Why that? Gives only more errors like this one.] ------------------------------------------------------------------------------ 2. The buffer in server/input.c/examine() is too small. -------patch-for-0.92.7------------------------------------------------------- *** input.c Wed Oct 16 19:13:45 1996 --- input.c-new Wed Oct 16 19:10:49 1996 *************** *** 338,348 **** return buf; } void examine(object *op, object *tmp) { ! char buf[MAX_BUF]; if (tmp == NULL || tmp->type == CLOSE_CON) return; /* Eneq(csd.uu.se): If NO_PRETEXT is defined we should only print the name. */ if (QUERY_FLAG(tmp, FLAG_NO_PRETEXT)) --- 338,348 ---- return buf; } void examine(object *op, object *tmp) { ! char buf[VERY_BIG_BUF]; if (tmp == NULL || tmp->type == CLOSE_CON) return; /* Eneq(csd.uu.se): If NO_PRETEXT is defined we should only print the name. */ if (QUERY_FLAG(tmp, FLAG_NO_PRETEXT)) ------------------------------------------------------------------------------ Example item to demonstrate this bug: ------------------------------------------------------------------------------ arch CSword title of God slaying undead,demon face CSword.112 speed_left -0.488908 attacktype 278784 state 12 magic 20 identified 1 been_applied 1 no_skill_ident 1 end ------------------------------------------------------------------------------ 3. Check for PATH_NULL (god intervention, learn spells) does not work. --------patch-for-0.92.6------------------------------------------------------ *** gods.c Tue Sep 3 09:50:36 1996 --- gods.c-1 Tue Sep 24 12:25:21 1996 *************** *** 290,300 **** * has PATH_NULL. */ if(!(Gods[godnr].path_denied&spells[spell].path) &&!(Gods[godnr].path_repelled&spells[spell].path) ! &&!(spells[spell].path&PATH_NULL) &&spells[spell].level<=level &&!check_spell_known(op,spell)) { #ifdef SOUND_EFFECTS play_sound_player_only(op->contr, SOUND_LEARN_SPELL); --- 290,300 ---- * has PATH_NULL. */ if(!(Gods[godnr].path_denied&spells[spell].path) &&!(Gods[godnr].path_repelled&spells[spell].path) ! &&!(spells[spell].path==PATH_NULL) &&spells[spell].level<=level &&!check_spell_known(op,spell)) { #ifdef SOUND_EFFECTS play_sound_player_only(op->contr, SOUND_LEARN_SPELL); ------------------------------------------------------------------------------ 4. other problems with learning spells through god intervention Maybe these problems disappear when only priest spells can be learned through god intervention. It was possible to learn all spells including "invulnerability", "regenerate spellpoints" and "shockwave". 5. When using Xpm, directors below the floor are invisible, but if some object is on the floor, they become visible. -------sample-map------------------------------------------------------------- arch map name director msg Creator: Jan Echternach Email: jan.echternach@informatik.uni-rostock.de Date: Thu Oct 3 11:25:38 1996 endmsg x 6 y 6 end arch oakdoor slaying /city/city hp 13 sp 13 x 1 y 1 end arch director_1 x 3 y 2 end arch cobblestones2 x 3 y 2 end arch helmet x 3 y 2 end arch director_1 x 3 y 3 end arch cobblestones2 x 3 y 3 end ------------------------------------------------------------------------------- 6. spell "regeneration": overflow possible (i.e. regeneration -116) 7. When attacking a castle guard (and probably other monsters as well), a weapon that slays something (i.e. stake +1) does more damage than a normal weapon (i.e. sword +4). -- jan.echternach@informatik.uni-rostock.de From owner-crossfire Wed Oct 16 20:25:15 1996 Return-Path: Received: (from mdomo@localhost) by ifi.uio.no (8.6.11/ifi2.4) id for crossfire-ut ; Wed, 16 Oct 1996 20:25:15 +0200 Received: from vortex.sdf.luth.se (root@vortex.sdf.luth.se [130.239.144.1]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Wed, 16 Oct 1996 20:25:10 +0200 Received: from what.sdf.luth.se (root@what [10.0.0.15]) by vortex.sdf.luth.se (8.8.0/8.8.0) with ESMTP id UAA27995 for ; Wed, 16 Oct 1996 20:30:41 +0200 (MET DST) Received: from wonko.sdf.luth.se (hombe@wonko.sdf.luth.se [10.0.0.27]) by what.sdf.luth.se (8.8.0/8.8.0) with ESMTP id UAA18407 for ; Wed, 16 Oct 1996 20:24:41 +0200 (MET DST) From: Markus Holmbom Received: (from hombe@localhost) by wonko.sdf.luth.se (8.8.0/8.8.0) id UAA07360 for crossfire@ifi.uio.no.; Wed, 16 Oct 1996 20:20:55 +0200 (MET DST) Message-Id: <199610161820.UAA07360@wonko.sdf.luth.se> Subject: CF: sorry mailing two letters Mime-Version: 1.0 To: crossfire@ifi.uio.no Date: Wed, 16 Oct 1996 20:20:54 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24 ME7] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-crossfire Precedence: bulk Status: RO Just sorry mailing two letters about jessy zoo I was wondering if it had reach the list /hombe hombe@sdf.luth.se From owner-crossfire Wed Oct 16 20:23:10 1996 Return-Path: Received: (from mdomo@localhost) by ifi.uio.no (8.6.11/ifi2.4) id for crossfire-ut ; Wed, 16 Oct 1996 20:23:10 +0200 Received: from vortex.sdf.luth.se (root@vortex.sdf.luth.se [130.239.144.1]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Wed, 16 Oct 1996 20:23:07 +0200 Received: from what.sdf.luth.se (root@what [10.0.0.15]) by vortex.sdf.luth.se (8.8.0/8.8.0) with ESMTP id UAA27986 for ; Wed, 16 Oct 1996 20:28:40 +0200 (MET DST) Received: from wonko.sdf.luth.se (hombe@wonko.sdf.luth.se [10.0.0.27]) by what.sdf.luth.se (8.8.0/8.8.0) with ESMTP id UAA18398 for ; Wed, 16 Oct 1996 20:22:40 +0200 (MET DST) From: Markus Holmbom Received: (from hombe@localhost) by wonko.sdf.luth.se (8.8.0/8.8.0) id UAA07349 for crossfire@ifi.uio.no.; Wed, 16 Oct 1996 20:18:54 +0200 (MET DST) Message-Id: <199610161818.UAA07349@wonko.sdf.luth.se> Subject: CF: Jessy zoo !!!!!! Mime-Version: 1.0 To: crossfire@ifi.uio.no Date: Wed, 16 Oct 1996 20:18:52 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24 ME7] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-crossfire Precedence: bulk Status: RO If you want to come in to jessy zoo you must first take : the Castle southeast of Brest Moria Jessy Castle """Jessy zoo """" In jessy zoo you suppose to get a lot of treausers but you only get a no boost luggage I think this sucks ,becuase this is the hardest part of the game . In next version I hope that it will be a change in this case don't you . ................. When you finish taking Wiz tower (it's very easy I think) you will get atleast 10 super artifacts : amulet of Magi Dragon shield (pro cold) Dragon Mail of Powress Belzebub's sword Belzebub's shield Midnight robe Wizard hat and a lot more ....... just notice /hombe hombe@sdf.luth.se From owner-crossfire Wed Oct 16 19:48:45 1996 Return-Path: Received: (from mdomo@localhost) by ifi.uio.no (8.6.11/ifi2.4) id for crossfire-ut ; Wed, 16 Oct 1996 19:48:45 +0200 Received: from vortex.sdf.luth.se (root@vortex.sdf.luth.se [130.239.144.1]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Wed, 16 Oct 1996 19:48:40 +0200 Received: from what.sdf.luth.se (root@what [10.0.0.15]) by vortex.sdf.luth.se (8.8.0/8.8.0) with ESMTP id TAA27818 for ; Wed, 16 Oct 1996 19:54:12 +0200 (MET DST) Received: from wonko.sdf.luth.se (hombe@wonko.sdf.luth.se [10.0.0.27]) by what.sdf.luth.se (8.8.0/8.8.0) with ESMTP id TAA18004 for ; Wed, 16 Oct 1996 19:48:11 +0200 (MET DST) From: Markus Holmbom Received: (from hombe@localhost) by wonko.sdf.luth.se (8.8.0/8.8.0) id TAA07149 for crossfire@ifi.uio.no.; Wed, 16 Oct 1996 19:44:27 +0200 (MET DST) Message-Id: <199610161744.TAA07149@wonko.sdf.luth.se> Subject: CF: Ebony thief guild !!!!! Mime-Version: 1.0 To: crossfire@ifi.uio.no Date: Wed, 16 Oct 1996 19:44:26 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24 ME7] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-crossfire Precedence: bulk Status: RO Well I have found all things in this quest except the figure of xan if anybody know where you find it I would love to know For exchanges I could tell you where to find annother of these things that you must have .............. /hombe hombe@sdf.luth.se From owner-crossfire Wed Oct 16 19:44:16 1996 Return-Path: Received: (from mdomo@localhost) by ifi.uio.no (8.6.11/ifi2.4) id for crossfire-ut ; Wed, 16 Oct 1996 19:44:16 +0200 Received: from vortex.sdf.luth.se (root@vortex.sdf.luth.se [130.239.144.1]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Wed, 16 Oct 1996 19:44:13 +0200 Received: from what.sdf.luth.se (root@what [10.0.0.15]) by vortex.sdf.luth.se (8.8.0/8.8.0) with ESMTP id TAA27787 for ; Wed, 16 Oct 1996 19:49:41 +0200 (MET DST) Received: from wonko.sdf.luth.se (hombe@wonko.sdf.luth.se [10.0.0.27]) by what.sdf.luth.se (8.8.0/8.8.0) with ESMTP id TAA17925 for ; Wed, 16 Oct 1996 19:43:38 +0200 (MET DST) From: Markus Holmbom Received: (from hombe@localhost) by wonko.sdf.luth.se (8.8.0/8.8.0) id TAA07140 for crossfire@ifi.uio.no.; Wed, 16 Oct 1996 19:39:54 +0200 (MET DST) Message-Id: <199610161739.TAA07140@wonko.sdf.luth.se> Subject: CF: What's the meaning with jessy zoo ??? It suppose to be a lot of good treasures there but only a "luggage" Mime-Version: 1.0 To: crossfire@ifi.uio.no Date: Wed, 16 Oct 1996 19:39:52 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24 ME7] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-crossfire Precedence: bulk Status: RO After taking the cstle below brest ,taking Moria, jessy castle and jessy zoo you think that you will get a lot of treasures but no only bracer Dex 2 "speed +1" (in jessy castle) and a luggage in (jessy zoo) I think this must be a big misstake by the maker of the map and I hope to put some more treasures there in the future If you ask me this is the hardest part of the game but you will nothing get . In Lake Coutry Wiz tower you will easy get super artifacts If anybody think like I do send me a letter .......... /hombe hombe@sdf.luth.se From owner-crossfire Tue Oct 15 18:44:43 1996 Return-Path: Received: from chalmers.se (chalmers.se [129.16.1.1]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Tue, 15 Oct 1996 18:44:42 +0200 Received: from quarl0.etek.chalmers.se (quarl0.etek.chalmers.se [129.16.32.20]) by chalmers.se (8.7.5/8.7.3) with SMTP id SAA19651 for ; Tue, 15 Oct 1996 18:44:42 +0200 (MET DST) Message-Id: <9610151644.AA10171@quarl0.etek.chalmers.se> Received: from quarl107 by quarl0.etek.chalmers.se (6.14 (VSB)/3.14+gl) id AA10171; Tue, 15 Oct 96 17:44:41 +0100 Received: by quarl107.etek.chalmers.se (8.6.9/3.14+gl) id SAA19033; Tue, 15 Oct 1996 18:44:40 +0200 Subject: slay bug.. To: crossfire-bugs@ifi.uio.no Date: Tue, 15 Oct 1996 18:44:40 +0200 (MET DST) From: "Mr Gamas" X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Status: RO Hi.. I'm reporting a bug in attack.c that causes all weapons with slaying slay everything.. I fixed the bug locally in .6 and thought you'd have it fixed to .7, but it's still here so here is a bug report.. The bug is easily fixed by replacing Starting line 492: if (hitter->slaying) { if (((op->race !=NULL && strstr(op->race, hitter->slaying)) || #ifndef MULTIPLE_GODS (strstr(hitter->slaying, undead_name) && QUERY_FLAG(op,FLAG_UNDEAD)) || #endif (op->arch && op->arch->name!=NULL && strstr(op->arch->name, hitter->slaying)))) does_slay=1; dam*=3; with if (hitter->slaying) { if (((op->race !=NULL && strstr(op->race, hitter->slaying)) || #ifndef MULTIPLE_GODS (strstr(hitter->slaying, undead_name) && QUERY_FLAG(op,FLAG_UNDEAD)) || #endif (op->arch && op->arch->name!=NULL && strstr(op->arch->name, hitter->slaying)))) { does_slay=1; dam*=3; } notice the extra pair of {}.. /Alexander Wolgast (e5alex@etek.chalmers.se) Keeper of games (gam@etek.chalmers.se)..