From elmroth@math.chalmers.se Mon Jul 20 12:46:40 1992 Return-Path: From: Tony Elmroth Date: Sun, 19 Jul 92 18:22:18 +0200 To: tvangod@ecst.csuchico.edu, crossfire@ifi.uio.no In-Reply-To: Skud the Great's message of Sat, 18 Jul 92 17:39:49 PDT <9207190039.AA00368@math.chalmers.se> Subject: AAAAh, slow. Status: RO There is a bug in cd.patch.2 (and cd.patch.all). I did forget to put -name $(FONTNAME) argument to xbmtobdf. The font target in Imakefile should look like: font: xbmtobdf $(RM) $(FONTNAME).bdf $(FONTNAME).$(FONTTYPE) ( cd bitmaps; ../xbmtobdf -name $(FONTNAME) -f ../bmaps.$(FONTNAME) * > ../$(FONTNAME).bdf ) chmod 644 $(FONTNAME).bdf bdfto$(FONTTYPE) < $(FONTNAME).bdf > $(FONTNAME).$(FONTTYPE) Then the font name within crossfire and the font will be the same. Tony From elmroth@math.chalmers.se Sat Jul 18 19:36:10 1992 Return-Path: From: Tony Elmroth Date: Sat, 18 Jul 92 09:05:34 +0200 To: tvangod@ecst.csuchico.edu Cc: crossfire@ifi.uio.no In-Reply-To: Skud the Great's message of Fri, 17 Jul 92 19:23:04 PDT <199207180223.AAifi.uio.no02967@ifi.uio.no> Subject: AAAAh, slow. Status: RO Hi Skud, The patches from CD are tested on sun3 and sun4. And we din't find them slow. How are they slow? Have you looked at the tick time with the 'time command? What is your MAX_TIME (tick time) in the Imakefile? If you put this to 65300 you should have the same speed as without the patches. On a sun4 we get the following times (2 - 4 players): average time needed in a tick = 35 msec. max time = 600 msec min time = 3 msec ticks longer than max time (124 msec) = 3% If this doesn't help, please try to undef TWO_BYTES_FONT in global.h, then the changes we have made to the code shouldn't affect the speed. (We have X11R5 and XDrawImageString16 seems to have he same speed as XDrawImageString on our sun3-50, sun3-60, and IBM-RT.) Tony From tvangod@ecst.csuchico.edu Sat Jul 18 05:12:59 1992 Return-Path: From: Skud the Great Subject: AAAAh, slow. To: crossfire@ifi.uio.no Date: Fri, 17 Jul 92 19:23:04 PDT X-Mailer: ELM [version 2.3 PL11] Status: RO Hello, I just applied all the patches to crossfire, compiled it and wow, very cool, but very slow. The slow down in the game was very noticable. This is a big problem, made it basically unplayable. I am playing it on a hp RISC machine and it is still very slow, hmm, have I applied the patches wrong or something?? Also, the map editor, concerning stacking objects, is nice. but a little bit cumbersome. A small suggestion would be the following: button 1: puts an object on top of any other object. button 2: edits the top object. button 3: removes the top object. Any thoughts are welcome on this. Not to put down the work you have done, its great, keep it up. thanks Skud. From elmroth@cd.chalmers.se Fri Jul 17 18:55:55 1992 Return-Path: Date: Fri, 17 Jul 1992 18:41:27 +0200 From: Tony Elmroth To: crossfire@ifi.uio.no Subject: CD patch 2 X-Charset: LATIN1 X-Char-Esc: 29 Status: RO Hi Here are some more patches from CD that are placed in /pub/crossfire/incoming at ifi.uio.no. cd.patch.2 is the diff from crossfire with cd.patch.1 applied. cd.patch.all are the combinded patches in cd.patch.[1-2] to crossfire0.82 . The changes need for 2-byte-chars and XDrawImageString16 are many but we have tested them for week, and they seems to work. If you don't define TWO_BYTES_FONT in global.h you will have the 8-bit chars as before. You have to edit your Imakefile after applying the patches. In the shar archive cd.lib.patch.1.sh you will find a new monster, slime, and a new map cd.110.earth. I did put the entry to this map among the glue by the rats in old house. Are there any rules where we can add new levels? Tony Here is the ChangeLog file describing the patches --- Patch 2 -- Fri Jul 17 15:38:01 1992 Tony Elmroth (elmroth at castafiore) * Use font_graphics in xio.h as global font name. Added FONTNAME as a variable in the Imakefile. Moved bmaps to bmaps.crossfire and made bmaps.cross16. I think the defines in the Imakefile should be moved to a configure file say config.h, then the dependencies work if you change the names of lib, bin etc. Tue Jul 14 20:26:50 1992 Tony Elmroth (elmroth@monet) * Added a 'time command that reports statistics on tick times. Mon Jul 13 18:34:36 1992 Tony Elmroth (elmroth@monet) * Bug fix for starvation. Now you don't die with positive hit points. Sun Jul 12 19:15:30 1992 Tony Elmroth (elmroth@galois) * The delay for each tick fixed. About 0.12 seconds gives good speed to the game. We tested 0.22 and this was to slow, the game did get to easy the monster where to slow. Before the fix the tick time allways was 0.065. * Added the possibility to hide monster below EARTHWALLs (and other objects). Do not remove objects from map that can't move in move_ob. Do not move monster below EARTHWALLs in move_monster. * Test of 2 byte-char fonts and XDrawImageString16. This works fine but the number of changes are many. Changed the type for all 'face' variables to Fontindex. typedef unsigned short Fontindex; Change defines in grafics.h to numbers. Added function that translate Fontindex to XChar. typedef XChar2b XChar Translate face to a XChar2b buf before sending it to X with XDrawImageString16. The negative face values in archetypes translated to positive on reading with face>=0?face:256+face. Added a defines in global.h that toggles between 2 byte-char font and 8-bit font. Tested with a new monster slime with faces 257, 258, and 259. ---- End patch 2 --- ---- Patch 1 ---- Fri Jul 10 02:06:05 1992 Tony Elmroth (elmroth at bianca) * Changed the editor to handle stacks of objects. Button 1: remove all objects, add selected Button 2: edit the top object Button 3: add one object or if background selected remove one object * .TP missing in crossfire.man before peaceful. * Fixed the bug for paying in shops. First pay as much silver that is meaningful, then pay enough gold, and then receive change in silver. Thu Jul 9 15:49:55 1992 Tony Elmroth (elmroth at bianca) * On level 89 the lower left exit is not set to 87: 6,41 as it should be. Changed. * Limit food consumption for high level players, when they are completely healed to 1 food per 7 'ticks'. * Some signed char changed to char to get rid of warnings during compilation. --- End patch 1 --- From elmroth@math.chalmers.se Fri Jul 17 16:55:40 1992 Return-Path: From: Tony Elmroth Date: Fri, 17 Jul 92 16:03:01 +0200 To: jh@cadre.com Cc: crossfire@ifi.uio.no In-Reply-To: Joe Hartley's message of Wed, 15 Jul 92 09:34:13 EDT Subject: some patches from CD Status: RO I made the patches with diff -c crossfire.cd crossfire which makes diff on all files in these directories. This is the wrong order for the new and old directory. But patch -p -R < cd.patch.1 works if your current dir is crossfire/.. . Tony diff -c crossfire.cd/crossfire.man crossfire/crossfire.man *** crossfire.cd/crossfire.man Fri Jul 10 17:52:58 1992 --- crossfire/crossfire.man Sat Jul 4 01:48:55 1992 *************** *** 47,53 **** Specifies which name your character will start with in Crossfire. You have to choose a name, either this way or with the "name" command, if you want to enter the highscore list. - .TP .B peaceful You can turn this mode on or off with the strings "on"/"off". Default is off. If the mode is turned on, you will push other players instead of --- 47,52 ---- diff -c crossfire.cd/edit.c crossfire/edit.c *** crossfire.cd/edit.c Fri Jul 10 21:20:05 1992 --- crossfire/edit.c Sat Jul 4 01:49:00 1992 *************** *** 249,256 **** XSetBackground(pl->gdisp,pl->gc_game,pl->gbackground); if(mx>=0&&mxemx&&my>=0&&myemy) { object *op; - object *opa; - if(start_flag) { int dx=pl->edx,dy=pl->edy; pl->emap->startx=mx+pl->edx,pl->emap->starty=my+pl->edy; --- 249,254 ---- *************** *** 260,266 **** start_flag=0; return; } - if(button==2) { #if 0 fprintf(stderr,"Background: %d\n", --- 258,263 ---- *************** *** 268,312 **** #endif if(moved) return; if((pl->e_ob=get_map_ob(pl->emap,mx+pl->edx,my+pl->edy))!=NULL) { - #if 0 if(pl->e_ob->above) fprintf(stderr,"Error, more than one object present.\n"); - #endif dump_object(pl->e_ob); fprintf(stderr,"%s\n",errmsg); - while (pl->e_ob->above) { /* edit the top object */ - pl->e_ob = pl->e_ob->above; - dump_object(pl->e_ob); - fprintf(stderr,"%s\n",errmsg); - } } redraw_edit_item(pl); return; } - if(button==3||(button==1&&pl->eselect!=0)) { ! /* button 1 does replace of all objects ! button 3 adds one object above the others or removes one object ! if background selected if no object lefts add background ! */ ! char f = pl->eselect!=0 ? pl->eselect : G_BLANK; ! ! if((button==1 || pl->earchselect==NULL) && ! (op=get_map_ob(pl->emap,mx+pl->edx,my+pl->edy))!=NULL) { ! while (op) { ! opa = op->above; ! if (button == 1 || !opa) { ! remove_ob(op); ! free_object(op); ! } else { ! f = op->face; ! } ! op = opa; ! } } set_omap(pl->emap,mx+pl->edx,my+pl->edy,f); ! ! if(pl->earchselect!=NULL) { op=arch_to_object(pl->earchselect); f=op->face,op->x=mx+pl->edx,op->y=my+pl->edy; insert_ob_in_map(op,pl->emap); --- 265,286 ---- #endif if(moved) return; if((pl->e_ob=get_map_ob(pl->emap,mx+pl->edx,my+pl->edy))!=NULL) { if(pl->e_ob->above) fprintf(stderr,"Error, more than one object present.\n"); dump_object(pl->e_ob); fprintf(stderr,"%s\n",errmsg); } redraw_edit_item(pl); return; } if(button==3||(button==1&&pl->eselect!=0)) { ! char f=(button==1?pl->eselect:G_BLANK); ! if((op=get_map_ob(pl->emap,mx+pl->edx,my+pl->edy))!=NULL) { ! remove_ob(op); ! free_object(op); } set_omap(pl->emap,mx+pl->edx,my+pl->edy,f); ! if(pl->earchselect!=NULL&&button==1) { op=arch_to_object(pl->earchselect); f=op->face,op->x=mx+pl->edx,op->y=my+pl->edy; insert_ob_in_map(op,pl->emap); *************** *** 326,334 **** update_walls(pl,mx+pl->edx,my+pl->edy,4+mx*24,28+24*my); return; } - set_map(pl->emap,mx+pl->edx,my+pl->edy,f); - if (pl->iscolor){ biff = f; XSetForeground(pl->gdisp,pl->gc_game, --- 300,306 ---- diff -c crossfire.cd/edit.h crossfire/edit.h *** crossfire.cd/edit.h Fri Jul 10 20:05:15 1992 --- crossfire/edit.h Sat Jul 4 01:48:57 1992 *************** *** 31,41 **** /* The maximum width of the edit-window */ int edit_width=24,edit_height=20; ! #define BG_SIZE 19 static char bg_icons[BG_SIZE]={ ! 'a','b','c','d','e','f','g','h','i','j','k','l','m','n','o','p', ! '\037',G_BLANK,'\0' }; static char walls[16]= { --- 31,40 ---- /* The maximum width of the edit-window */ int edit_width=24,edit_height=20; ! #define BG_SIZE 18 static char bg_icons[BG_SIZE]={ ! 'a','b','c','d','e','f','g','h','i','j','k','l','m','n','o','p','\037','\0' }; static char walls[16]= { diff -c crossfire.cd/global.h crossfire/global.h *** crossfire.cd/global.h Wed Jul 8 18:37:46 1992 --- crossfire/global.h Sat Jul 4 01:48:57 1992 *************** *** 59,65 **** float speed_left; /* How much speed is left to spend this round */ unsigned short count; /* Which nr. of object created this is. */ unsigned short nrof; ! char face; signed char dirx,diry; /* Means the object is moving that way. */ unsigned char type; /* PLAYER, BULLET, etc */ unsigned char immune; /* Attacks the object is immune against */ --- 59,65 ---- float speed_left; /* How much speed is left to spend this round */ unsigned short count; /* Which nr. of object created this is. */ unsigned short nrof; ! signed char face; signed char dirx,diry; /* Means the object is moving that way. */ unsigned char type; /* PLAYER, BULLET, etc */ unsigned char immune; /* Attacks the object is immune against */ diff -c crossfire.cd/living.c crossfire/living.c *** crossfire.cd/living.c Wed Jul 8 18:51:37 1992 --- crossfire/living.c Sat Jul 4 01:49:01 1992 *************** *** 76,82 **** void remove_statbonus(object *op) { int i; ! char *p; for(i=0,p= (char *) &op->stats;i<6;i++,p++) *p-=classbonus[op->contr->face][i]; } --- 76,82 ---- void remove_statbonus(object *op) { int i; ! signed char *p; for(i=0,p= (char *) &op->stats;i<6;i++,p++) *p-=classbonus[op->contr->face][i]; } *************** *** 83,89 **** void add_statbonus(object *op) { int i; ! char *p; for(i=0,p= (char *) &op->stats;i<6;i++,p++) *p+=classbonus[op->contr->face][i]; } --- 83,89 ---- void add_statbonus(object *op) { int i; ! signed char *p; for(i=0,p= (char *) &op->stats;i<6;i++,p++) *p+=classbonus[op->contr->face][i]; } *************** *** 146,152 **** int allowed_class(object *op) { int i; ! char *p; for(i=0,p= (char *) &op->stats;i<6;i++,p++) if(*p<0) return 0; return 1; --- 146,152 ---- int allowed_class(object *op) { int i; ! signed char *p; for(i=0,p= (char *) &op->stats;i<6;i++,p++) if(*p<0) return 0; return 1; diff -c crossfire.cd/main.c crossfire/main.c *** crossfire.cd/main.c Thu Jul 9 21:43:23 1992 --- crossfire/main.c Sat Jul 4 01:49:03 1992 *************** *** 1408,1417 **** if(!op->state&&--op->last_heal<0) { if(op->stats.hpstats.maxhp) op->stats.hp++,op->stats.food--; ! op->last_heal=500/(op->stats.maxhp>66 && op->stats.hp >= op->stats.maxhp ? ! 70 : ! op->stats.maxhp+4); ! op->stats.food--; } if(!op->state&&op->contr->golem==NULL&&--op->last_sp<0) { if(op->stats.spstats.maxsp) --- 1408,1414 ---- if(!op->state&&--op->last_heal<0) { if(op->stats.hpstats.maxhp) op->stats.hp++,op->stats.food--; ! op->last_heal=500/op->stats.maxhp+4, op->stats.food--; } if(!op->state&&op->contr->golem==NULL&&--op->last_sp<0) { if(op->stats.spstats.maxsp) diff -c crossfire.cd/shop.c crossfire/shop.c *** crossfire.cd/shop.c Fri Jul 10 01:53:38 1992 --- crossfire/shop.c Sat Jul 4 01:49:04 1992 *************** *** 79,89 **** if(tmp!=NULL) free_object(tmp); return 1; ! } else if (silver_ob->nrof >= i%10) { ! paid= i%10 + ((silver_ob->nrof - i%10)/10)*10; ! tmp=get_split_ob(silver_ob, paid); ! if(tmp!=NULL) ! free_object(tmp); } } if(gold_ob==NULL) { --- 79,88 ---- if(tmp!=NULL) free_object(tmp); return 1; ! } else { ! paid=silver_ob->nrof; ! remove_ob(silver_ob); ! free_object(silver_ob); } } if(gold_ob==NULL) { *************** *** 90,96 **** fprintf(stderr,"Bug, should have gold coins.\n"); return 0; } ! tmp=get_split_ob(gold_ob,(i-paid+9)/10); if(tmp!=NULL) { paid+=tmp->nrof*10; free_object(tmp); --- 89,95 ---- fprintf(stderr,"Bug, should have gold coins.\n"); return 0; } ! tmp=get_split_ob(gold_ob,i/10); if(tmp!=NULL) { paid+=tmp->nrof*10; free_object(tmp); From bell@cs.unc.edu Fri Jul 17 00:42:04 1992 Return-Path: Date: Thu, 16 Jul 92 10:01:15 -0400 From: Andrew Bell To: crossfire@ifi.uio.no Subject: A few thoughts Status: RO >> There could also be a key that means attack a square, but don't move >> in (useful for holding a key position). >This would be useful (especially for opening doors :). On which keys >do suggest to put it? I'd suggest adding a "stand" toggle with the 's' key, which indicates that you won't move until you hit the 's' key again. >hhmmm, well firechests are my creation, are you sure they do not explode when >they hit a player? They sure seem to hit me... I always stand a (chessboard) knight's move away and wait for it to shoot the fireball, go in and hack for a bit, and then run away again. >My main "gripe" with crossfire is that it's trying to be parts of several >games at once and maybe it's grabbed the wrong parts. It might be nice to set up a crossfire library that could be used to create games more like gauntlet or Xelda or nethack, depending on the programmer's desire. Of course, if wishes were code, we'd have intelligent AIs doing everything for us... >Another may be to allow a pause >during a regular multi-player game, which would put your character in a >statsis field Heck, why not a stasis field spell? Makes you immune to everything until you try to move again... simple, not particularly abusable. -Andrew Bell bell@cs.unc.edu From dwagon@nella11.cc.monash.edu.au Fri Jul 17 00:39:27 1992 Return-Path: From: Dougal Scott Date: Thu, 16 Jul 1992 13:18:32 AEST Reply-To: dougal.scott@fcit.monash.edu.au X-Mailer: Mail User's Shell (7.2.3 5/22/91) To: crossfire@ifi.uio.no Subject: New spell (Iron Wall) Status: RO Here is a patch that implements a new spell - Iron Wall. This creates an Earth Wall next to the caster. This is useful if you want to rest for a while, or block of areas. Also in this patch a small addition that makes the terminal beep when a character starts to get hungry. A result of starving too many times when I didn't see that I was hungry. *** define.h Thu Jul 16 13:06:09 1992 --- ../define.h Thu Jul 16 13:11:43 1992 *************** *** 131,137 **** #define NROFPFACES 7 /* How many player icons/classes there are */ ! #define NROFSPELLS 8 #define SP_BULLET 0 #define SP_FIREBALL 1 --- 131,137 ---- #define NROFPFACES 7 /* How many player icons/classes there are */ ! #define NROFSPELLS 9 #define SP_BULLET 0 #define SP_FIREBALL 1 *** input.c Thu Jul 16 13:06:16 1992 --- ../input.c Thu Jul 16 13:11:48 1992 *************** *** 1158,1163 **** --- 1158,1166 ---- case 7: draw_info(op,"Switched to dimension door."); break; + case 8: + draw_info(op,"Switched to Iron Wall."); + break; } draw_stats(op); break; *** main.c Thu Jul 16 13:06:22 1992 --- ../main.c Thu Jul 16 13:11:55 1992 *************** *** 1038,1043 **** --- 1038,1056 ---- draw(op); } return; + case 8: /* Iron Wall */ + if(!IS_WIZ(op)&&op->stats.sp<6) { + draw_info(op,"You don't have enough spellpoints."); + op->contr->count_left=0; + return; + } + if(!blocked(op->map,op->x+dx,op->y+dy)) { + put_item_on_map(op->map,MAP_EARTH,op->x+dx,op->y+dy); + op->stats.sp-=6; + draw_stats(op); + } + draw(op); + return; case 10: /* Thrown items */ draw_info(op,"Throw is unimplemented as of now."); return; *** xio.c Thu Jul 16 13:06:36 1992 --- ../xio.c Thu Jul 16 13:12:03 1992 *************** *** 454,462 **** if(pl->contr->last_value==-1||pl->contr->last_speed!=pl->speed|| pl->stats.food!=pl->contr->last_stats.food) { flag[5]=1; ! if(pl->stats.food<100&&(pl->stats.food&4)) sprintf(buff[5],"Speed: %3.1f Food: *%d* HUNGRY!", pl->speed,pl->stats.food); else sprintf(buff[5],"Speed: %3.1f Food: %3d", pl->speed,pl->stats.food); --- 454,464 ---- if(pl->contr->last_value==-1||pl->contr->last_speed!=pl->speed|| pl->stats.food!=pl->contr->last_stats.food) { flag[5]=1; ! if(pl->stats.food<100&&(pl->stats.food&4)) { sprintf(buff[5],"Speed: %3.1f Food: *%d* HUNGRY!", pl->speed,pl->stats.food); + fprintf(stderr,""); + } else sprintf(buff[5],"Speed: %3.1f Food: %3d", pl->speed,pl->stats.food); *** xio.h Thu Jul 16 13:06:46 1992 --- ../xio.h Thu Jul 16 13:12:11 1992 *************** *** 28,34 **** static char font_inv_text[]="8x13"; char spellname[11][MAX_NAME]={ "bullets","fireball","lightning","magic missile","arrows","bombs", ! "golem","dimension door","unused", "unused","unused" }; char ann_last[MAX_BUF]; --- 28,34 ---- static char font_inv_text[]="8x13"; char spellname[11][MAX_NAME]={ "bullets","fireball","lightning","magic missile","arrows","bombs", ! "golem","dimension door","iron wall", "unused","unused" }; char ann_last[MAX_BUF]; Dougal Scott-Dougal.Scott@fcit.monash.edu.au Faculty of Computing & Info Tech I am eager for the pleasures of the flesh more Monash University, Caulfield than for salvation, my soul is dead, so I shall Victoria, AUSTRALIA look after the flesh. -Carmina Burana Who says hedgehogs are of no value to the economy? In New Zealand they make up approximately 1.7% of the roading. From elmroth@cd.chalmers.se Wed Jul 15 03:38:22 1992 Return-Path: Date: Tue, 14 Jul 1992 21:51:09 +0200 From: Tony Elmroth To: crossfire@ifi.uio.no Subject: some patches from CD X-Charset: LATIN1 X-Char-Esc: 29 Status: RO Crossfire is a hit here at CD (Chalmers Computer Society). Several players every evening. Here is my changlog to the patches placed at ftp.ifi.uio.no in /pub/crossfire/incoming as cd.patch.1. Tony (elmroth@cd.chalmers.se) Fri Jul 10 02:06:05 1992 Tony Elmroth (elmroth at bianca) * Changed the editor to handle stacks of objects. Button 1: remove all objects, add selected Button 2: edit the top object Button 3: add one object or if background selected remove one object * .TP missing in crossfire.man before peaceful. * Fixed the bug for paying in shops. First pay as much silver that is meaningful, then pay enough gold, and then receive change in silver. Thu Jul 9 15:49:55 1992 Tony Elmroth (elmroth at bianca) * On level 89 the lower left exit is not set to 87: 6,41 as it should be. Changed. * Limit food consumption for high level players, when they are completely healed to 1 food per 7 'ticks'. * Some signed char changed to char to get rid of warnings during compilation. From kjetilho Mon Jul 13 23:34:57 1992 Return-Path: From: Kjetil Torgrim Homme Date: Mon, 13 Jul 1992 23:32:30 +0200 To: crossfire@ifi.uio.no Subject: Mail-archive available Status: RO Someone asked me if this mailing list was archived anywhere, so I made one :) It's a 50kB large Unix mbox file (which means it is quite human readable), and it's available at ftp.ifi.uio.no in /pub/crossfire/crossfire.mail. I will try to add mail once a week or so. Also, some people have sent me patches, which is fine. I just thought I'd mention that you should feel to upload patches to /pub/crossfire/incoming, and telling the others on the list about it. That way, we will all benefit from your work. Kjetil T. From jh@cadre.com Mon Jul 13 23:23:57 1992 Return-Path: Date: Fri, 10 Jul 92 10:04:47 EDT From: jh@cadre.com (Joe Hartley) To: meh@ifi.uio.no Subject: Re: Timing (was Re: crossfire) Cc: crossfire@ifi.uio.no Status: RO > > [Much sacrificed to the bandwidth gods.] > > Jap, same here :-) > > > With no way to save or freeze the gasme, I had to let my character get his > > butt whomped by some insignificant monsters. > > How about ^Z? Of course you pause the game for everybody. > > Morten > That doesn't work for me, at least not when I run Crossfire from an OpenWindows menu :-) It does work if I start it from a shell, but I think a "polite" in-game pause feature would be a better solution. =============================================================================== Joe Hartley | jh@cadre.com - Whenever you find that you are on the Cadre Technologies | side of the majority, it is time to reform. - M. Twain 222 Richmond St. | -------------------------------------------------------- Providence, RI 02903 | Overman 1st Class - the Kilgore Trout Memorial Clench (401) 351-5950 x266 | of the Church of the SubGenius =============================================================================== From meh@ifi.uio.no Mon Jul 13 23:23:39 1992 Return-Path: Date: Fri, 10 Jul 1992 14:32:18 +0200 From: Morten Hanshaugen To: jh@cadre.com (Joe Hartley) Cc: crossfire@ifi.uio.no Subject: Re: Timing (was Re: crossfire) In-Reply-To: jh@cadre.com (Joe Hartley)'s message of Thu, 9 Jul 92 09:52:03 EDT References: Status: RO > [Much sacrificed to the bandwidth gods.] Jap, same here :-) > With no way to save or freeze the gasme, I had to let my character get his > butt whomped by some insignificant monsters. How about ^Z? Of course you pause the game for everybody. Morten From thoth@reef.cis.ufl.edu Mon Jul 13 23:23:19 1992 Return-Path: To: crossfire@ifi.uio.no Subject: Re: crossfire In-Reply-To: Your message of "Thu, 09 Jul 92 00:52:06 +0200." <199207082252.AAholmenkollen.ifi.uio.no01499@holmenkollen.ifi.uio.no> Date: Thu, 09 Jul 92 11:33:14 EDT From: Robert Forsman Status: RO In message <199207082252.AAholmenkollen.ifi.uio.no01499@holmenkollen.ifi.uio.no > you wrote: > This would be useful (especially for opening doors :). On which keys > do suggest to put it? > or ? > There are two reasons for not changing the size of the bitmaps: > - we would have to draw new bitmaps > - the larger the bitmap, the more difficult/the more effort it is to > make it look good. > See below. > Crossfire is currently using a font, and a font must be monochrome. > Monochrome support is definetely going to stay, so we would have to > draw and keep one monochrome image used for the font, and one pixmap. Not really. The XPM format supports color, monochrome and greyscale all in the same image. There are programs to merge a pixmap and a bitmap into the same pixmap so that the pixmap will appear when you have a color display and the bitmap will appear when you have a monochrome. If you ever do decide to go to pixmaps, make them a little bigger :) > Every pixmap would need to be in a separate file, too, leading to lots > of small files chewing up disc space. The way it is now, you can Not really. You can concatenate them into one big file, #include it and use the XpmReadPixmapFromData function. > Using a font is fast: You can draw a whole line at once in monochrome, > ie. minimum protocol overhead. When you draw one character, you send > one byte, when you send a monochrome pixmap, you send 72 bytes, when > you send a 16 colour pixmap, you send 288 bytes (plus overheads). Do > we want to make resource hogs? As the other person mentioned. This only happens at startup. Pixmaps are stored on the server. > It sounds like you think there is a problem with Crossfire's handling > of this. Not really. I'm just acknowledging that this problem is a real bitch and I'm still not thrilled with your solution. Don't get depressed. I have yet to see a solution that I'm thrilled with. My main "gripe" with crossfire is that it's trying to be parts of several games at once and maybe it's grabbed the wrong parts. But why should I complain? I didn't invest scads of time in it and I'm sure other people love it! :) Maybe I should just write Xelda (the generic Zelda clone with random monsters)... Another thing. Somebody needs to find a real ARTIST and have them draw the pictures! Too many coders and not enough artist From jh@cadre.com Mon Jul 13 23:23:37 1992 Return-Path: Date: Thu, 9 Jul 92 09:52:03 EDT From: jh@cadre.com (Joe Hartley) To: crossfire@ifi.uio.no Subject: Timing (was Re: crossfire) Status: RO > Subject: Re: crossfire > Content-Length: 8348 > > Robert Forsman raises some topics I think you > others on the crossfire list are interested in. [Much sacrificed to the bandwidth gods.] > > > Also, the timing is a hateful problem. I'm not sure there's a > > decent solution to the multi-player realtime problem. Games like > > nettrek work because combat is fairly slow and there aren't many > > opponents. Nethack works by not being realtime, so that the player > > can handle several opponents at once by thinking things out. Ditto > > with Moria. > > It sounds like you think there is a problem with Crossfire's handling > of this. Crossfire assumes that everyone is active when they are in. > You can never turn away for long for fear of dying of hunger. A pause > button could be added, but such a feature is easily misused. But then > again, so are savefiles in Moria and Nethack, or even DM mode in > Crossfire. > > > Kjetil T. > I would like to second the motion for *some* sort of pause feature. I was playing yesterday (after hours) when my boss came by to ask some questions. With no way to save or freeze the gasme, I had to let my character get his butt whomped by some insignificant monsters. Since I frequently play in a single user mode anyway, I think that specifying single-user mode and allowing a pause may be one way to go. Another may be to allow a pause during a regular multi-player game, which would put your character in a statsis field, allowing the game to continue, but your character to remain in stasis. Potentially annoying to other users, particularly ones you've allied yourself with, but it seems necessary to the playing of the game, at least to me. =============================================================================== Joe Hartley | jh@cadre.com - Whenever you find that you are on the Cadre Technologies | side of the majority, it is time to reform. - M. Twain 222 Richmond St. | -------------------------------------------------------- Providence, RI 02903 | Overman 1st Class - the Kilgore Trout Memorial Clench (401) 351-5950 x266 | of the Church of the SubGenius =============================================================================== From kjetilho Mon Jul 13 23:22:40 1992 Return-Path: From: Kjetil Torgrim Homme Date: Thu, 9 Jul 1992 10:43:32 +0200 To: crossfire@ifi.uio.no In-Reply-To: Skud the Great's message of Wed, 8 Jul 92 19:19:11 PDT <199207090218.AAifi.uio.no09593@ifi.uio.no> Subject: Re: editing objects Status: RO > nrof : I believe this determines if the object will disappear after being > applied. This will happen if nrof is set to 1. (Don't quote me on this.) > ??????? If nrof is 0, the objects will not merge ie., you will have "leather armour" and "leather armour" instead of "two leather armours". If nrof is one, two or higher, you will have "one/two scrolls". I hope this makes sense :) Kjetil T. From tvangod@ecst.csuchico.edu Mon Jul 13 23:22:22 1992 Return-Path: From: Skud the Great Subject: editing objects To: crossfire@ifi.uio.no Date: Wed, 8 Jul 92 19:19:11 PDT X-Mailer: ELM [version 2.3 PL11] Status: RO This is a breif description on how to edit and create new objects: All objects in the game are contained in the archetypes file found in the lib directory. This file is read in at the beginning of each game. Take a look at it. Desciption of each argument: name : What defualt name will appear when object is looked at. This name can be changed in the editor. type : The type is defined in define.c. face : What character in the font that the object will have. anim/mina : If the object is to be animated, the numbers in between represent the order and which characters in the font to use in the animation. alive : a flag, if set to 1, then the object is alive. immune: a set of flags to determine what an object is immune to. #define PHYSICAL 1 #define MAGIC 2 #define FIRE 4 #define ELECTRICITY 8 #define COLD 16 #define WATER 32 #define ACID 64 /* Rusts things */ #define DRAIN 128 /* Drain Life */ #define WEAPONMAGIC 256 #define GHOSTHIT 512 /* Attacker dissolves */ material: flag, to determine what type of material the object is made of. #define M_PAPER 1 #define M_IRON 2 #define M_GLASS 4 #define M_LEATHER 8 #define M_WOOD 16 #define M_ORGANIC 32 #define M_STONE 64 no_pick: if set to 1, player can not pick up the item. no_pass: if set to 1, player can move over that object. value: what an item is worth. weight : what an item weighs. walk_on : if set to 1, automatically applies the object, when walked on. speed: tells how fast a live object will move or do an action. nrof : I believe this determines if the object will disappear after being applied. This will happen if nrof is set to 1. (Don't quote me on this.) ??????? exp : hp : maxhp : ac : dam : wc : Thaco, I believe. level : All the above act the same as a player's stats. The exp, is how much exp the object is worth upon killing it. sp : this is a special ability for non-player objects. For generators it determines how what a generator will generate. The number being the type number of the object to generator, "type" defined above. if object is of type 4, a treasure, it will generate a treasure when applied. It choses what type of treasure from several treasure lists, located in treasure.c. sp tells what list to choose from. Any new object added to this file will automatically appear on the map editor. Well, this will give people a start. Anyway, I know Frank has an Object editor in the agenda after he gets back, but until then, you can change archtypes directly. any questions, give me a buzz. tyler skud. tvangod@ecst.csuchio.edu From tvangod@ecst.csuchico.edu Mon Jul 13 23:22:19 1992 Return-Path: From: Skud the Great Subject: more replies To: crossfire@ifi.uio.no Date: Wed, 8 Jul 92 17:10:01 PDT X-Mailer: ELM [version 2.3 PL11] Status: RO >From thoth@vixen.cis.ufl.edu Wed Jul 8 07:09 PDT 1992 Received: from vixen.cis.ufl.edu by cscihp.ecst.csuchico.edu with SMTP (16.6/16.2-1) id AA10332; Wed, 8 Jul 92 07:09:34 -0700 Return-Path: Received: by vixen.cis.ufl.edu with SMTP (15.11/15.6) id AA04804; Wed, 8 Jul 92 09:49:54 edt To: Skud the Great Subject: Re: SCROLLING In-Reply-To: Your message of "Wed, 08 Jul 92 03:57:05 PDT." <199207081056.AAifi.uio.no19600@ifi.uio.no> Date: Wed, 08 Jul 92 09:49:51 EDT From: Robert Forsman Status: RO In message <199207081056.AAifi.uio.no19600@ifi.uio.no> you wrote: > Hello, this is Skud(tyler). I have add a new fix to the xio.c. It scrolls the > message window, instead of just starting at the top and writing over the old > window. We have tested it on a fast machine with three players, there were no > noticable slow downs, I would like to see more tests run on the new code. > Try scrolling it swiftly with a window that obscures part of it. I bet you aren't handling the GraphicsExpose events properly (they're fairly difficult to handle). ok, I am fairly new to X windows, as is Frank, if you find a problem with the GraphicsExpose, please let Frank or myself know, so it can be corrected. thanks. tyler. From tvangod@ecst.csuchico.edu Mon Jul 13 23:22:10 1992 Return-Path: From: Skud the Great Subject: replies to letters To: crossfire@ifi.uio.no Date: Wed, 8 Jul 92 17:06:59 PDT X-Mailer: ELM [version 2.3 PL11] Status: RO Ok, time to add my two cents worth to the comments made. >From owner-crossfire@ifi.uio.no Wed Jul 8 15:56 PDT 1992 Received: from ifi.uio.no by cscihp.ecst.csuchico.edu with SMTP (16.6/16.2-1) id AA05215; Wed, 8 Jul 92 15:52:55 -0700 Received: by ifi.uio.no id ; Thu, 9 Jul 1992 00:52:09 +0200 Return-Path: Received: from holmenkollen.ifi.uio.no by ifi.uio.no with SMTP id ; Thu, 9 Jul 1992 00:52:07 +0200 From: Kjetil Torgrim Homme Received: by holmenkollen.ifi.uio.no ; Thu, 9 Jul 1992 00:52:06 +0200 Date: Thu, 9 Jul 1992 00:52:06 +0200 Message-Id: <199207082252.AAholmenkollen.ifi.uio.no01499@holmenkollen.ifi.uio.no> To: crossfire@ifi.uio.no In-Reply-To: Robert Forsman's message of Mon, 06 Jul 92 10:56:07 EDT <199207061456.AAifi.uio.no19935@ifi.uio.no> Subject: Re: crossfire Status: RO >> A specific instance of generators gone out of hand is the mice in >> the old house. I found at least two generators and can often manage >> to destroy one, but while I was, the rest of the place filled up with >> mice and I couldn't get out. **************An important note******************** The mice can generate without generators, yes, thats right, if you have one mouse and no generators and you wander for a while and come back, the whole room will be filled with them. This was orignally a bug, Frank mentioned it to me, apparently, he liked the idea of monsters reproducing themselves, as do I. The old house can be cleared easly, by using the scrolls one can find there. There are two, use them to kill a large group of mice, then kill the straglers before they reproduce. **************An important note******************** >The mice in the old house are quite possible to get rid of if you have >say 14 hp, a sword, ac 5 and speed 1.0. I'm not saying it's easy, you >need to be thorough and watch your hp :) >> In nethack, you don't usually get swamped in evil monsters that >> often. Generators were designed in to Gauntlet. They don't play well >> unless you have infinite stand-off capability Until this problem is >> fixed, the game is unplayable. With Gauntlet, you do not have spells though, such as Golems, these are great for sending into rooms with lots of deadly things to take out generators. Lightening and bombs are also useful. >In Crossfire you have infinite run-away capability instead, unless you >do a mistake :) >> Firechests are a real pain to destroy. We once worked on one for >> about 3 or 4 minutes. >Due to a bug, firechests aren't that hard - the fireballs thrown in >your direction will not explode, so just keep hacking away at it until >it is dead. Of course, this is one area where some tuning may have to >be done. hhmmm, well firechests are my creation, are you sure they do not explode when they hit a player? Seems to work fine here. Fireballs will not explode when they hit a breakaway wall though. Keep me informed on this, if you are sure it is not working I will go muck around with the fire_a_ball subroutine in main.c. >If they are too difficult, either raise the points awarded or >lower its hit points. Yes, good point, I will describe below how to edit monster artibutes in a seperate post. Until of course one can do that with the editor. >> There could also be a key that means attack a square, but don't move >> in (useful for holding a key position). >This would be useful (especially for opening doors :). On which keys >do suggest to put it? > Also, the window seemed a bit small. You may have a small display, > but I usually operate on 1280x1024 or 1152x900 displays. The bitmaps > could be a little larger. >>It's currently 988x482. I think that's rather large already! :) I >>think I once heard Frank say that it won't get wider than 1024 pixels. >>(Many of our terminals are 1024x768, so there 8) Height could be >>changed if you have a better reason than that it "seems a bit small". >There are two reasons for not changing the size of the bitmaps: > - we would have to draw new bitmaps > - the larger the bitmap, the more difficult/the more effort it is to > make it look good. >If you were talking about how much you can see of your surroundings, I >don't think that will increase, simply because you aren't supposed to >look so far. However, Frank has started talking about adding light, >but he hasn't found any good algorithms for the spreading of it. >Please feel free to help out with this! Anyway, with light sources, >perhaps the size of that window could be bigger, but that's my >opinion. Also a factor is the speed. the larger the window the slower the game will move, a good example is the map editor. Try moving one square at a time. >> And, why settle for bitmaps. Use pixmaps! There is a pixmap editor >> for R5 in the contrib directory. I've also written a paint program >> (xscribble), but it wouldn't be as well-tailored to icon generation as >> the pixmap editor. >Crossfire is currently using a font, and a font must be monochrome. >Monochrome support is definetely going to stay, so we would have to >draw and keep one monochrome image used for the font, and one pixmap. >Every pixmap would need to be in a separate file, too, leading to lots >of small files chewing up disc space. The way it is now, you can >delete all the bitmaps after you've assembled the font. This is good >for those not taking part in the development of the game. Well, one would not necessarily need to put each pixmaps in the a different file, why not make a large pixmap, will all graphics tiled on it. Then each imagine could be copied off the pixmap into the window, this is how Ulitma was done on the old Apple IIs. >Using a font is fast: You can draw a whole line at once in monochrome, >ie. minimum protocol overhead. When you draw one character, you send >one byte, when you send a monochrome pixmap, you send 72 bytes, when >you send a 16 colour pixmap, you send 288 bytes (plus overheads). Do >we want to make resource hogs? > Equipment is hard to come by (especially after you've been cleaning > out a few dungeons and die). The static object thing just isn't good > enough. > > There needs to be a way to have random monster encounters. I can > agree with certain things being static, but that should only be major > encounters or artifacts. Most mundane monsters should be appearing > fairly frequently and randomly. Imagine an orc camp that has a number > of orcs running around in it and these orcs have random objects (like > swords, clubs, food). Then there's an orc chieftan with his > bodyguards who are static and some static treasure. I do like the idea of random encounters, does anyone want to help out on this one, I am willing to look into it. >> Also, the timing is a hateful problem. I'm not sure there's a >> decent solution to the multi-player realtime problem. Games like >> nettrek work because combat is fairly slow and there aren't many >> opponents. Nethack works by not being realtime, so that the player >> can handle several opponents at once by thinking things out. Ditto >> with Moria. >It sounds like you think there is a problem with Crossfire's handling >of this. Crossfire assumes that everyone is active when they are in. >You can never turn away for long for fear of dying of hunger. A pause >button could be added, but such a feature is easily misused. But then >again, so are savefiles in Moria and Nethack, or even DM mode in >Crossfire. Ok, the timing thing may be resolved when crossfire moves to a client/server model. It would be haddled much the way lpmud is haddled. Players will login to servers with their character's name and password. This will be a ways down the road, as there are a lot of other things to do with Crossfire first. If you have any questions or problems fill free to get a hold on me. Thanks for your input. Skud Tyler (tvangod) From mycroft@gnu.ai.mit.edu Mon Jul 13 23:22:06 1992 Return-Path: From: mycroft@gnu.ai.mit.edu Subject: Re: crossfire To: kjetilho@ifi.uio.no (Kjetil Torgrim Homme) Date: Wed, 8 Jul 92 20:04:42 EDT Cc: crossfire@ifi.uio.no In-Reply-To: <199207082252.AAholmenkollen.ifi.uio.no01499@holmenkollen.ifi.uio.no>; from "Kjetil Torgrim Homme" at Jul 10, 92 00:52:06 am Status: RO > Every pixmap would need to be in a separate file, too, leading to lots > of small files chewing up disc space. The way it is now, you can > delete all the bitmaps after you've assembled the font. There's no particularly good reason that pixmaps can't be compiled into the executable. > Using a font is fast: You can draw a whole line at once in monochrome, > ie. minimum protocol overhead. When you draw one character, you send > one byte, when you send a monochrome pixmap, you send 72 bytes, when > you send a 16 colour pixmap, you send 288 bytes (plus overheads). Pixmaps can be (and usually are) cached in the X server. The main concern here is rendering speed. Fonts can be drawn *very* quickly (on the order of 100K characters per second on some boxen) on most newer hardware; pixmaps are almost always much slower. This is not really much of a concern, though, as it's not drawing very much. From kjetilho Mon Jul 13 23:21:59 1992 Return-Path: From: Kjetil Torgrim Homme Date: Thu, 9 Jul 1992 01:10:16 +0200 To: crossfire@ifi.uio.no In-Reply-To: K.B's message of Wed, 8 Jul 92 23:26:51 +0200 <9207082126.AA20134@clipper.ens.fr> Subject: Map editor Status: RO belabas@clipper.ens.fr also raises some interesting topics... > I'd like to subscribe... > > I have a suggestion regarding the map editor : it doesn't seem to be > possible to specify that a given item is to be magical (neither to fix > the magical bonus...), I skipped through the source code and I didn't > find anything either. > > Why not have all objects (and not only exits...) "editable", that is > when placing an item you could : > - specify the item's magical bonus > - give the item a name > - print a message when the item is examined > ... > idem with the monsters, you could > - edit their characteristics to have weaker or tougher monsters, > leaders, heroes... > - give them a name (for heroes or leaders) > - print a message when the monster is looked at (some personalized > insults...) > > and so on. This would tremendously increase the "adventure" feel of > the game. There are definetely plans for allowing modification of most of an objects attributes, but I'm sure Frank won't mind if someone does this in his absence :) It's supposed to work like the way you can edit exits, only with many more variables... It would also be nice to be able to put several object on top of eachother. Currently, it's impossible to put a generator on top of grass or mountains or whatever, so when they are killed, white spots appear. A third thing would be to allow objects larger than one cell. The large castle is special, since it's really four seperate exits looking like one. The same trick can't be used for the dragon. However, fixing this is couple to the internal representation of linked objects. Frank wants arbitrarily linked objects, i.e. star-shaped objects or whatever. Does anyone feel like doing some work on the map editor? Kjetil T. (trying to spur people to do some programming :) From kjetilho Mon Jul 13 23:21:49 1992 Return-Path: From: Kjetil Torgrim Homme Date: Thu, 9 Jul 1992 00:52:06 +0200 To: crossfire@ifi.uio.no In-Reply-To: Robert Forsman's message of Mon, 06 Jul 92 10:56:07 EDT <199207061456.AAifi.uio.no19935@ifi.uio.no> Subject: Re: crossfire Status: RO Robert Forsman raises some topics I think you others on the crossfire list are interested in. I quote his message in its entirety, I hope you don't mind :) (Robert Forsman is now on the list) Below, I mostly answer in my own capacity as a player of crossfire, but in some places I try and describe what I think Frank thinks about that subject in his absence. > I recently grabbed crossfire and tried it out. I mostly died. I > got help from another player and I still mostly died. Stick me on the > list. > > It's kinda hard to judge crossfire because I don't know what sort of > game it's trying to be. > > In my opinion, the generators (as implemented) are a bad idea. In > gauntlet, you could stand off firing missiles forever and the passages > were often tight enough that three people could cover the whole thing. > In crossfire, you do NOT have an infinite supply of bullets. You > therefore usually have to wade in suffering major damage (especially > as a new character) and destroy the generator, getting surrounded and > mangled in the process. The arrows are more comparable to Gauntlet's bullets, but you still haven't an infinite supply. It takes time to balance a game, it's very easy to make it too easy or too difficult. I think our main problem right now is that there are too few newbie levels, but that should be easily remedied by you lot :) > A specific instance of generators gone out of hand is the mice in > the old house. I found at least two generators and can often manage > to destroy one, but while I was, the rest of the place filled up with > mice and I couldn't get out. > > This is not dissimilar to a flea infestation in moria, but in moria, > you can abandon the level and never have to deal with them again. In > crossfire I could not enter the old house the rest of the game without > getting instantly destroyed. The mice in the old house are quite possible to get rid of if you have say 14 hp, a sword, ac 5 and speed 1.0. I'm not saying it's easy, you need to be thorough and watch your hp :) > Generators could have an "optimum" number of monsters they can > support and when the number exceeds this amount, some of them die > randomly (slowly). This way dungeons grown out of hand will > eventually die down to a reasonable level. It might necessitate a > parent pointer in most objects, or a child list in generators. We've discussed a very similar idea - a generator will not generate more than monsters. I don't think Frank is unwilling to put that in. > In nethack, you don't usually get swamped in evil monsters that > often. Generators were designed in to Gauntlet. They don't play well > unless you have infinite stand-off capability Until this problem is > fixed, the game is unplayable. In Crossfire you have infinite run-away capability instead, unless you do a mistake :) > Firechests are a real pain to destroy. We once worked on one for > about 3 or 4 minutes. Due to a bug, firechests aren't that hard - the fireballs thrown in your direction will not explode, so just keep hacking away at it until it is dead. Of course, this is one area where some tuning may have to be done. If they are too difficult, either raise the points awarded or lower its hit points. > There could also be a key that means attack a square, but don't move > in (useful for holding a key position). This would be useful (especially for opening doors :). On which keys do suggest to put it? > Also, the window seemed a bit small. You may have a small display, > but I usually operate on 1280x1024 or 1152x900 displays. The bitmaps > could be a little larger. It's currently 988x482. I think that's rather large already! :) I think I once heard Frank say that it won't get wider than 1024 pixels. (Many of our terminals are 1024x768, so there 8) Height could be changed if you have a better reason than that it "seems a bit small". There are two reasons for not changing the size of the bitmaps: - we would have to draw new bitmaps - the larger the bitmap, the more difficult/the more effort it is to make it look good. If you were talking about how much you can see of your surroundings, I don't think that will increase, simply because you aren't supposed to look so far. However, Frank has started talking about adding light, but he hasn't found any good algorithms for the spreading of it. Please feel free to help out with this! Anyway, with light sources, perhaps the size of that window could be bigger, but that's my opinion. > And, why settle for bitmaps. Use pixmaps! There is a pixmap editor > for R5 in the contrib directory. I've also written a paint program > (xscribble), but it wouldn't be as well-tailored to icon generation as > the pixmap editor. Crossfire is currently using a font, and a font must be monochrome. Monochrome support is definetely going to stay, so we would have to draw and keep one monochrome image used for the font, and one pixmap. Every pixmap would need to be in a separate file, too, leading to lots of small files chewing up disc space. The way it is now, you can delete all the bitmaps after you've assembled the font. This is good for those not taking part in the development of the game. Using a font is fast: You can draw a whole line at once in monochrome, ie. minimum protocol overhead. When you draw one character, you send one byte, when you send a monochrome pixmap, you send 72 bytes, when you send a 16 colour pixmap, you send 288 bytes (plus overheads). Do we want to make resource hogs? > Also, there are several easily accessible dungeons that would waste > a new character (for example, the old house). I don't know if you > guys have ever played the adventure games on the nintendo, but there's > usually a clear message about places you can and can not handle or > travel in. A player that wanders in to these regions gets ALMOST > dead, and quickly retreats. Relatively tough monsters appear > infrequently in the lower levels so that the player can realize when > he's ready to graduate to a different section. Tough dungeons are > nestled in tough areas. This is not inherent in Crossfire, it's the level designer's responsibility to playtest their levels carefully. I do however object to classify the old house as one of those levels: When you go in, you have all the time you need to get out again. I've seen levels where you are surrounded by ghosts when you enter - now that's not a good thing even in a tough area. > Equipment is hard to come by (especially after you've been cleaning > out a few dungeons and die). The static object thing just isn't good > enough. > > There needs to be a way to have random monster encounters. I can > agree with certain things being static, but that should only be major > encounters or artifacts. Most mundane monsters should be appearing > fairly frequently and randomly. Imagine an orc camp that has a number > of orcs running around in it and these orcs have random objects (like > swords, clubs, food). Then there's an orc chieftan with his > bodyguards who are static and some static treasure. A quick hack to fix this is indestructable generators. It is possible to put out single monsters with the editor (with the exception of the giant and the dragon, because they're kind of special :) > Note that the terms artifact and mundane are relative. A +1 sword > is an artifact at a low level, but mundane inside the Creepy Castle of > Gruesome Death. An Ogre is an artifact in an orc camp, but mundane in > the City of Dragons. We need a better level editor. See the next mail about this. > Also, the timing is a hateful problem. I'm not sure there's a > decent solution to the multi-player realtime problem. Games like > nettrek work because combat is fairly slow and there aren't many > opponents. Nethack works by not being realtime, so that the player > can handle several opponents at once by thinking things out. Ditto > with Moria. It sounds like you think there is a problem with Crossfire's handling of this. Crossfire assumes that everyone is active when they are in. You can never turn away for long for fear of dying of hunger. A pause button could be added, but such a feature is easily misused. But then again, so are savefiles in Moria and Nethack, or even DM mode in Crossfire. Kjetil T. From tvangod@ecst.csuchico.edu Mon Jul 13 23:21:31 1992 Return-Path: From: Skud the Great Subject: SCROLLING To: crossfire@ifi.uio.no Date: Wed, 8 Jul 92 3:57:05 PDT X-Mailer: ELM [version 2.3 PL11] Status: RO Hello, this is Skud(tyler). I have add a new fix to the xio.c. It scrolls the message window, instead of just starting at the top and writing over the old window. We have tested it on a fast machine with three players, there were no noticable slow downs, I would like to see more tests run on the new code. It consists of changing two lines in xio.c. In the routine draw_info() change this: if(++(pl->contr->infoline)>=INFOLINES){ pl->contr->infoline=0; to : if(++(pl->contr->infoline)>=INFOLINES){ XCopyArea(pl->contr->gdisp,pl->contr->win_info,pl->contr->win_info, pl->contr->gc_info,0,13,410,363,0,0); pl->contr->infoline--; } that is all there is to it, my concern here is time, how slow it runs on smaller platforms, so let me know. any questions, just send some mail. later. Tyler. skud. tvangod@ecst.csuchico.edu From tvangod@ecst.csuchico.edu Mon Jul 13 23:19:12 1992 Return-Path: From: Skud the Great Subject: Skud castle To: crossfire@ifi.uio.no Date: Sat, 4 Jul 92 18:46:58 PDT X-Mailer: ELM [version 2.3 PL11] Status: RO I have made many modifications to skud castle. Also included are two new items a liche and a magical sword. Check them out, they are on the ftp site in incoming. ok, later skud, also, check out the new version of crossfire, rings and potions have been improved. later. From wchuang@Athena.MIT.EDU Mon Jul 13 23:18:37 1992 Return-Path: From: wchuang@Athena.MIT.EDU Date: Fri, 3 Jul 92 19:40:23 -0400 To: pruyne@cs.wisc.edu Cc: crossfire@ifi.uio.no Subject: Decstation version Status: RO Concerning the problems you're having with the DECstation build... what OS are you using? I have gotten it running on a DECstation 3100, Ultrix V4.2A (Rev. 47). You'll have to use bdftopcf to compile the bdf file, though. From frankj Mon Jul 13 23:17:50 1992 Return-Path: From: Frank Tore Johansen Subject: Re: CrossFire To: pruyne@cs.wisc.edu (Jim Pruyne) Date: Fri, 3 Jul 1992 19:57:53 +0200 Cc: crossfire In-Reply-To: <9207031752.AA25790@hermit.cs.wisc.edu>; from "Jim Pruyne" at Jul 3, 92 12:52 pm X-Mailer: ELM [version 2.3 PL11] Status: RO > Greetings, > I just grabbed the source, and compiled Crossfire on my DecStation > last night, but I seem to have a couple problems. First, although all > seemed to go well during compilation (i.e. no error messages), most of the > bit-maps don't appear to be working right. Crossfire.snf did get built, > and I was able to dump it out with showsnf, but in the game the player and > most of the locations (like the "hut", the "house", etc.) just look like > random bitmaps. Any ideas? I did do the mkfontdir, and the directory with > crossfire.snf is in my font path via xset +fp. I must admit I have had problems making the game work on our local decstations. It even crashed our X-servers... Unfortunately I don't have enough knowledge about the ways of Dec to find out what's wrong. Hopefully I'll get in touch with someone who knows what goes wrong. But I do know that Decstations doesn't use .snf but .bdf or .pcf. If you have bdftopcf, try to use it. > Second, I am able to get to these locations (like the "hut", or goblin > camp), but I can't seem to do anything once I get there. Does this mean > that my maps aren't installed right? If you managed to enter the first levels, your maps are installed right. Maybe it's just the fonts that fools you. > Thanks for any help from my sketchy details. The game really looks like it > will be great! I really hope to get a working DecStation version working someday. Keep in touch. -Frank. From bingle@cs.purdue.edu Mon Jul 13 23:17:17 1992 Return-Path: To: meh@ifi.uio.no, tvangod@ecst.csuchico.edu Cc: crossfire@ifi.uio.no, bingle@cs.purdue.edu Subject: Re: Possible speedup in draw() (crossfire0.8) (fwd) In-Reply-To: Your message of "Thu, 02 Jul 92 17:56:26 +0200." Date: Thu, 02 Jul 92 11:56:37 EST From: bingle@cs.purdue.edu Status: RO >> At present there are 13 colors including black and white, what you are >> purposing is to create 169 GCs > >No, just 156 (n*n-n). > Actually, this isn't quite right either... You don't need EVERY combination of EVERY color used, just every different foreground/background combination that is used. Looking at color.h shows that there are only 16 DIFFERENT color combinations currently being used - Black - White Black - Gold Black - Khaki Black - DarkOrange2 White - Khaki Brown - White Brown - Khaki Gold - Khaki DodgerBlue4 - Khaki Red - Khaki Yellow1 - Khaki DarkOrchid3 - Khaki DarkOrange2 - Khaki ForestGreen - Khaki ForestGreen - DodgerBlue4 Grey35 - Khaki Sure, there could be more (once configuring colors on a per display basis via resources is available), but the people who want 100+ different color combinations will just have to suffer with the larger space requirements. Besides, some colors just don't go with each other and too many different (and odd) color combinations causes the game to have that "Las Vegas" look. (For those of you not familiar with Las Vegas, Nevada, that isn't a good thing.) However, you'll need more GCs than the 16 combos above, because each display (player) needs its own GCs. Rich From meh@ifi.uio.no Mon Jul 13 23:17:14 1992 Return-Path: Date: Thu, 2 Jul 1992 17:56:26 +0200 From: Morten Hanshaugen To: crossfire@ifi.uio.no Subject: Re: Possible speedup in draw() (crossfire0.8) (fwd) In-Reply-To: Skud the Great 's message of Wed, 1 Jul 92 14:58:06 PDT References: <199207012157.AAifi.uio.no19691@ifi.uio.no> Status: RO > At present there are 13 colors including black and white, what you are > purposing is to create 169 GCs No, just 156 (n*n-n). > I am relatively new to X windows, so I have one question: How much memory will > be required to define 169 GCs??, Also consider that colors may be added, which > would require yet more GCs to be defined. The GC is defined like this (look at XLib.h): typedef struct _XGC { XExtData *ext_data; /* hook for extension to hang data */ GContext gid; /* protocol ID for graphics context */ Bool rects; /* boolean: TRUE if clipmask is list of rectangles */ Bool dashes; /* boolean: TRUE if dash-list is really a list */ unsigned long dirty;/* cache dirty bits */ XGCValues values; /* shadow structure of values */ } *GC; The size of the GC struct looks like some 200 bytes, and 13 colours would give some 32 K extra. 64 colours would give ca. 800 K if I am not wrong? No problem with 13 colors, but 64, I don't know. Test it out. Morten From tvangod@ecst.csuchico.edu Mon Jul 13 23:16:59 1992 Return-Path: From: Skud the Great Subject: Re: Possible speedup in draw() (crossfire0.8) (fwd) To: crossfire@ifi.uio.no Date: Wed, 1 Jul 92 14:58:06 PDT X-Mailer: ELM [version 2.3 PL11] Status: RO Hello, this is Tyler, I am the one that has been developing the color system. Had a couple of comments: > > Instead of changing foreground and background colors within the GC before > > using XDrawImageString to print the item/player/whatever with the right > > colors, a faster and more in the spirit of what GCs are for, would be to have > > a separate GC for each foregound/background color combination and just use the > > correct GC. > > Yes, I agree, that is a much better solution. At present there are 13 colors including black and white, what you are purposing is to create 169 GCs, hmmm, interesting idea, This would definately, put more flexability in the color system. We would be able to define colors to specific objects with the same font characters quickly, this was one of my concerns when messing with the color. I will look into it and get back to you. Good Idea. I am relatively new to X windows, so I have one question: How much memory will be required to define 169 GCs??, Also consider that colors may be added, which would require yet more GCs to be defined. If there is not a large constraint on memory, this is definately the way to go with colors. > > > It would also be nice to let players override the color selection (via > > resources). (I find the yellow objects hard to see). Also, it would be nice Very easy to do, I will make this possible, get back to you on that one too. > > if each player was a different color (handy when several people choose the > > same class). It is actually very easy to at least make other player's > > characters a different color than your own character (since your character is Yes, it would be nice to be able to determine who is who in the game, the other day, we had a person's character killed, because another player thought he was an Ogre, instead of a barbarian. Another possible way of determining the different players apart would be to attack a number to the character's bitmap, much like is done in netrek. > If you all send fixes to me, they will probably be incorporated into the game. Ditto here: although I do not have access to the ftp site at Frank's site, I can post new updates to my ftp site as well. > > Unfortunately I'll be gone for 1 1/2 months soon, but maybe someone else, > possibly Tylor, can come up with something in the meanwhile. Yes, I will be here all summer, don't hesitate(sp?) to send me some mail. > > There are still 100 things to do in the game...one of them is to make > a TODO list... > Let me try a short summary: > - optimize the inventory and look windows so that they don't draw the > same item more than once. > - make it possible to have an archtype which consist of two or more > objects (like the dragon and the giant) > - make it possible to have an endless linked list of joined objects. > (currently there are a couple hooks in the game which makes it possible for > the dragon and giant to exist. The find_free_spot() function handles > only one object.) > - put some security and user-friendlyness in the map-editor. > - make it possible to have more than 256 different graphical bitmaps. > This can be done either by converting to XDrawImageString16 or by > using bitmaps instead of a font (Currently, though, the speed of > the color-version of draw() is as slow as it would be with bitmaps). > - decide what to use the lower-right window to and put that into it. > - use X-resources more extensively > - fix the bugs in the above mentioned improvements > > At this point I'll post v1.0.alpha to alt.sources and later v1.0 to > comp.sources.games. But the TODO list will never stop...: > > - make a string allocating system. This way all objects will have a > (char *) pointer instead of an array and all objects with similar > names will just point to the same string. > - make more items! Imagine all the items in nethack/moria/ularn/omega... > - make more graphics. > - make more spells. > - make spellbooks, maybe of different classes. > - put the wisdom stat to use. > - make more move/fight routines which the monsters can choose between. > the current move_monster() just aimlessly tries to move towards the > players, and then try to hit them. The move_friendly_monster(), > move_smart_monster() and move_pet_monster() routines are sorely needed. > - make more maps. > - make a client/server system > - make some login system, with passwords, like the muds have, and save > the player object between logins. > - make easier to make new object-types. > - maybe even make a simple interpreting programmin language to be used by > the objects. [object ob;ob=environment();set_speed(ob,3);sleep(30); > set_speed(ob,default_speed(ob));destruct(this_object());] > (sleep(30) is the easy part: speed_left=-1,speed=1/30.0) > - make DOCS! > - make even more items/graphics... > > > Obviously this is more than I can handle, so any help will be greatly > appreciated. > > -Frank. > To add to this list: A message editor, for each level. Right now, it is difficult to put a message in with each level. I have built some routines for rings, if anybody is interesting in getting them please write me. The rings add and subtract points from your abilities: Str, Int, Dam, Ac, etc. Please keep in touch, via the mailing list, don't want to have several different versions of crossfire floating around, that would make it harder to to merge ideas together and to prevent from people spending lots of time on the same areas. Also I think it is wise to maybe to make a standard for all new maps as far as names. I have already metioned this to Frank. Also needed is someone to keep track of allocating slots to put maps, Example : levels 30-39 levels 40-49 levels 50-59 This will make it easier to incorporate another site's maps into a "global version." Ok, thats about all for now, any comments welcome. Tyler. Skud. tvangod@ecst.csuchico.edu