From dnh at hawthorn.csse.monash.edu.au Sun Apr 1 05:10:47 2001 From: dnh at hawthorn.csse.monash.edu.au (dnh) Date: Thu Jan 13 18:00:21 2005 Subject: [CF-Devel] Okay I know.. Message-ID: I know the GTK client isn't being worked on.. but there is a large problem. When you look at an item under you or in your inv, the animation goes flat out. If you see it on square near by it goes at the normal rate. I don't know what caused this or when it happened, but whoever has been touching that stuff, could you please look into this? thanks, dnh From crow at bear.cs.dartmouth.edu Sun Apr 1 15:39:31 2001 From: crow at bear.cs.dartmouth.edu (Preston Crow) Date: Thu Jan 13 18:00:21 2005 Subject: [CF-Devel] bracers Message-ID: <200104012039.f31KdVA07160@bear.cs.dartmouth.edu> I've noticed that my bracers do nothing to my AC. I looked at the code in fix_player() in common/living.c, and I found that bracers are not treated like other types of armour. I don't recall seeing this documented anywhere. How exactly are bracers supposed to affect your AC? As it is now, even my acid corroded -5 bracers don't change my AC on bit. --PC From hsteoh at quickfur.yi.org Sun Apr 1 16:54:54 2001 From: hsteoh at quickfur.yi.org (H. S. Teoh) Date: Thu Jan 13 18:00:21 2005 Subject: [CF-Devel] bracers In-Reply-To: <200104012039.f31KdVA07160@bear.cs.dartmouth.edu>; from crow@bear.cs.dartmouth.edu on Sun, Apr 01, 2001 at 04:39:31PM -0400 References: <200104012039.f31KdVA07160@bear.cs.dartmouth.edu> Message-ID: <20010401175454.A11042@crystal> On Sun, Apr 01, 2001 at 04:39:31PM -0400, Preston Crow wrote: > I've noticed that my bracers do nothing to my AC. I looked at the > code in fix_player() in common/living.c, and I found that bracers are > not treated like other types of armour. I don't recall seeing this > documented anywhere. How exactly are bracers supposed to affect your > AC? As it is now, even my acid corroded -5 bracers don't change my AC > on bit. [snip] I think somebody mentioned a long time ago that bracers don't affect AC if you're also wearing something else (shield perhaps? I forget). This is a feature of AD&D rules (or so I heard). So yeah, -5 bracers aren't that bad, esp if they carry other bonuses. I used to have bracers with magic+1, and it didn't affect me at all when they got corroded to -3. T -- All men are mortal. Socrates is mortal. Therefore all men are Socrates. From peterm at alfven.EECS.Berkeley.EDU Sun Apr 1 16:55:08 2001 From: peterm at alfven.EECS.Berkeley.EDU (Peter Mardahl) Date: Thu Jan 13 18:00:21 2005 Subject: [CF-Devel] bracers In-Reply-To: Your message of "Sun, 01 Apr 2001 16:39:31 EDT." <200104012039.f31KdVA07160@bear.cs.dartmouth.edu> Message-ID: <200104012155.f31Lt8U19120@alfven.EECS.Berkeley.EDU> In D&D--and in crossfire-- bracers are treated specially. They set a "worst-case" AC instead of adding to AC like everything else. So if you have bracers +3, your "worst" AC with them on would be 6 (with no dex bonus). If you are naked except for bracers, you'll have an ac of 6. If you put a robe on (ac +1), you'd normally have an ac of 9. However, with the bracers, you get 6. Now, if you put on +3 dragonmail (total AC increase of 9) you'll have an ac of 1: the bracers will have ceased to matter. The meaning of -5 bracers is that your "worst" AC would be 15. Perhaps this is senseless, but that is how it is done. PeterM > I've noticed that my bracers do nothing to my AC. I looked at the > code in fix_player() in common/living.c, and I found that bracers are > not treated like other types of armour. I don't recall seeing this > documented anywhere. How exactly are bracers supposed to affect your > AC? As it is now, even my acid corroded -5 bracers don't change my AC > on bit. > > --PC > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel From mwedel at scruz.net Mon Apr 2 00:48:46 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:00:21 2005 Subject: [CF-Devel] Okay I know.. References: Message-ID: <3AC812BE.C8517648@scruz.net> dnh wrote: > > I know the GTK client isn't being worked on.. but there is a large > problem. When you look at an item under you or in your inv, the animation > goes flat out. If you see it on square near by it goes at the normal > rate. I don't know what caused this or when it happened, but whoever has > been touching that stuff, could you please look into this? I just ran the gtk client, and saw no problems. Note I did make some changes, but only for animations of the look (ground) area. Animation in the inventory should be unchanged. Has anyone else seen the behaviour DB has described? DB - can your provide more details (Server and version of the server you are runninng on for example?) From mwedel at scruz.net Mon Apr 2 00:56:47 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:00:21 2005 Subject: [CF-Devel] invisible objects show up under "examine"? References: <200103292053.f2TKrL318049@alfven.EECS.Berkeley.EDU> Message-ID: <3AC8149F.52DF2F89@scruz.net> Peter Mardahl wrote: > > Hello, > > A player has reported that 'examine' will report things > about an invisible object in a square. This happens in > 97.0. The particular weirdness is that a disease object > lying on the ground may be examined. Fixed in cvs: server/c_object: Modify examine command to only be able to examine valid objects, and not whatever is on top of the space, which may be insivisible. MSW 2001-04-01 From dnh at hawthorn.csse.monash.edu.au Mon Apr 2 04:17:44 2001 From: dnh at hawthorn.csse.monash.edu.au (dnh) Date: Thu Jan 13 18:00:21 2005 Subject: [CF-Devel] Okay I know.. In-Reply-To: <3AC812BE.C8517648@scruz.net> Message-ID: yes i can, it was running my own server, with alternate image, and looking at the new midnight robes. I fiddled with the animation speed, first I set it to .025, it was really slow, then when I picked it up it suddenly went really fast. I did this in the middle of scorn with an added midnight robes (not the one from wizard tower although I believe it happens for that also). dnh On Sun, 1 Apr 2001, Mark Wedel wrote: > dnh wrote: > > > > I know the GTK client isn't being worked on.. but there is a large > > problem. When you look at an item under you or in your inv, the animation > > goes flat out. If you see it on square near by it goes at the normal > > rate. I don't know what caused this or when it happened, but whoever has > > been touching that stuff, could you please look into this? > > I just ran the gtk client, and saw no problems. > > Note I did make some changes, but only for animations of the look (ground) > area. Animation in the inventory should be unchanged. > > Has anyone else seen the behaviour DB has described? DB - can your provide > more details (Server and version of the server you are runninng on for example?) > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > From dnh at hawthorn.csse.monash.edu.au Mon Apr 2 04:18:57 2001 From: dnh at hawthorn.csse.monash.edu.au (dnh) Date: Thu Jan 13 18:00:21 2005 Subject: [CF-Devel] Okay I know.. HMM In-Reply-To: <3AC812BE.C8517648@scruz.net> Message-ID: Okay I just got todays CVS (I was running yesterdays) and now it seems fixed =). What ever you did with those fixes seemed to do the trick. dnh On Sun, 1 Apr 2001, Mark Wedel wrote: > dnh wrote: > > > > I know the GTK client isn't being worked on.. but there is a large > > problem. When you look at an item under you or in your inv, the animation > > goes flat out. If you see it on square near by it goes at the normal > > rate. I don't know what caused this or when it happened, but whoever has > > been touching that stuff, could you please look into this? > > I just ran the gtk client, and saw no problems. > > Note I did make some changes, but only for animations of the look (ground) > area. Animation in the inventory should be unchanged. > > Has anyone else seen the behaviour DB has described? DB - can your provide > more details (Server and version of the server you are runninng on for example?) > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > From dnh at hawthorn.csse.monash.edu.au Mon Apr 2 07:30:03 2001 From: dnh at hawthorn.csse.monash.edu.au (dnh) Date: Thu Jan 13 18:00:21 2005 Subject: [CF-Devel] Graphics libs. Message-ID: Does anyone have all or can supply me with all the current sources of png graphics for the standard set? Mostly I would like to see the weapons sets and armour etc.. Mich? dnh From dnh at hawthorn.csse.monash.edu.au Tue Apr 3 05:14:54 2001 From: dnh at hawthorn.csse.monash.edu.au (dnh) Date: Thu Jan 13 18:00:21 2005 Subject: [CF-Devel] GTK client still has big problems Message-ID: Using latest CVS client. Any pile over about 20 flashes so much you can neither scroll down, nor pick up anything. To do anything with my item piles.. I have to pick everything up.. drop what I want.. move to a different spot then drop all. Nor entirely user friendly. This is a server problem I am certain, and I am fairly certain MichToen has already said what the problem is. If anyone can look into this I would be most grateful, thanks. dnh ps if you want more info, mail me. From dnh at hawthorn.csse.monash.edu.au Tue Apr 3 07:57:19 2001 From: dnh at hawthorn.csse.monash.edu.au (dnh) Date: Thu Jan 13 18:00:21 2005 Subject: [CF-Devel] Just some idle thoughts Message-ID: I feel the current biggest problem concerning general game play, is that we tend to focus to greatly on one or two things (probably those things in which we are currently playing, or most favour) and forget the rest. For example, It is clear, just by looking at the current lists of monsters, that demons and giants are favoured why is that? Simply because when those map makers were adding them they were probably mostrai and valriel followers. I know for a fact this is true of the demons, smiles at Pete. Recently a new player came into #crossfire (puff) and said he favoured rogues when playing. What strikes me, is how useless most of the theifs skills are, stealing? hardly ever works.. and exp is practically worthless. Not only that, but if you fail the monster attacks you (ouch, watch out level 1 players). Hiding is also pretty much useless I can see its uses but the way crossfire is played it simply isn't worth the time. This of course extends beyond monsters, for example artifacts. There are heaps of warrior items, some what less, but still large numbers of wizard items, and then there are items for generic use. What about all those other classes? the Monk, the Priest (I suppose could be considered mage), the Theif. Now of course this is all generalisations, I know for a fact that peterm has spent some time organising new angels simply for balance, and new items are always being added, but I feel we should start thinking about these issues. They are alot more tricky than they may at first seems; a) Skills tend to be deep rooted, if we change something the effects may cause some unforseen unbalance thus causing more and more problems b) Most of the problem areas tend to be in code which hasn't been touched for quite along time. c) Most of the weapons etc are buried throughout maps, and new maps take along time to make, and even longer to make fun and balanced. d) Sometimes something may look broken, but on closer inspection may turn out to be the only possible way to do it without redoing crossfire! For mapmakers, all I can do is plea to who ever is busy working on maps to consider ALL the characters not just your current one =). For server developers I wonder if we can start a thread discussing problems areas and possible solutions. While I am currently busy fixing images, I think the discussion can occur, I hope to have all the problem images done withing a month or two, then I can start working on these problems. As a possible example, should we consider changing items in current mapsets? I recently changed a few but they were minor changes, and just things like an extra +10 to resistance caused quite abit of checking with everyone to make sure it is fair and balanced. If we start changing this sword to a new glove, it may upset players who have come to enjoy the prize for the challenge, it may also upset the author and it may upset other maps that require a weapon of that type. Therefore should we just leave items as they are? And what about skills? what about that stupid singing? and stealing? should we improve them? think of better ways to implement them? Where do we stand people? What are our problems? What are our choices? This is where my thoughts have led me, and I hope to hear some better ideas that what I have had, dnh From Philipp.Currlin at t-online.de Tue Apr 3 10:41:03 2001 From: Philipp.Currlin at t-online.de (Philipp Currlin) Date: Thu Jan 13 18:00:22 2005 Subject: [CF-Devel] Re: [CF-maps] Just some idle thoughts References: Message-ID: <3AC9EF0F.1020101@epost.de> Hello I'm currently working on a new mapset. Yeah, yet another one, but I've got some ideas in mind and don't know where else to put them. These maps will also include one or maybe even more places for thieves. This means you will need all skills a thief could use and at the end you will also get an artifact which will be usefull as a thief. I will try to make them in such a way that you have to use your head and won't get very far with brute force. If anybody has ideas for that or wants to help, feel free to contact me. Phil From hsteoh at quickfur.yi.org Tue Apr 3 11:51:14 2001 From: hsteoh at quickfur.yi.org (H. S. Teoh) Date: Thu Jan 13 18:00:22 2005 Subject: [CF-Devel] Re: [CF-maps] Just some idle thoughts In-Reply-To: <3AC9EF0F.1020101@epost.de>; from Philipp.Currlin@t-online.de on Tue, Apr 03, 2001 at 05:41:03PM +0200 References: <3AC9EF0F.1020101@epost.de> Message-ID: <20010403125114.A16300@crystal> On Tue, Apr 03, 2001 at 05:41:03PM +0200, Philipp Currlin wrote: > Hello > > > I'm currently working on a new mapset. Yeah, yet another one, but I've > got some ideas in mind and don't know where else to put them. > These maps will also include one or maybe even more places for thieves. > This means you will need all skills a thief could use and at the end you > will also get an artifact which will be usefull as a thief. > I will try to make them in such a way that you have to use your head and > won't get very far with brute force. [snip] This reminds me -- somebody on metalforge (a semi-newbie) suggested that we should have quests that reward exp for solving a puzzle or completing the quest. For example, a quest might be to retrieve some stolen item, and when the player gets the item (or safely reaches the map exit with the item), he should get some exp for it. Currently, the only recompense one may get for completing such quests is either the exp gained in killing monsters (which may not be very appropriate -- what if the player is weak but thinks of an ingenious way to get the item without facing the nasty monsters?), or in treasure found at the end of (or perhaps throughout) the quest. But we all know how "valuable" treasure is -- not very much. One way I thought of was to make a special object at the end of the quest that rewards the player with, eg., mental exp or some suitable category, for solving the quest. I don't think this would be too hard, would it? Just my $0.02. T -- WINDOWS = Will Install Needless Data On Whole System -- CompuMan From peterm at alfven.EECS.Berkeley.EDU Tue Apr 3 13:49:25 2001 From: peterm at alfven.EECS.Berkeley.EDU (Peter Mardahl) Date: Thu Jan 13 18:00:22 2005 Subject: [CF-Devel] Re: [CF-maps] Just some idle thoughts In-Reply-To: Your message of "Tue, 03 Apr 2001 12:51:14 EDT." <20010403125114.A16300@crystal> Message-ID: <200104031849.f33InPF27003@alfven.EECS.Berkeley.EDU> > On Tue, Apr 03, 2001 at 05:41:03PM +0200, Philipp Currlin wrote: > > This reminds me -- somebody on metalforge (a semi-newbie) suggested that > we should have quests that reward exp for solving a puzzle or completing > the quest. For example, a quest might be to retrieve some stolen item, and > when the player gets the item (or safely reaches the map exit with the > item), he should get some exp for it. You're right, and this has been suggested before. If anyone wants to code this, I suggest an addition to the player changer, which is what adds a class to a player in the Hall of Selection. It should not be hard. PeterM From Philipp.Currlin at t-online.de Tue Apr 3 15:58:36 2001 From: Philipp.Currlin at t-online.de (Philipp Currlin) Date: Thu Jan 13 18:00:22 2005 Subject: [CF-Devel] playerkills Message-ID: <3ACA397C.3060006@epost.de> Just a few notes that came into my mind about playerkills. 1. When somebody turns peacefull off and gets killed by somebody else then, the "killer" should not loose luck. I even think these playerkills should be turned off completely. 2. If you kill another player with spells, the player who died should loose only half the experience he would loose if he got killed by a monster. The caster of the spell should loose the other half. I think this would make teamplaying a lot easier because now everybody in the team should be more careful. Especially the caster of a spell should make sure that he doesn't hit any others. And I guess everybody knows how annoying it is if you get killed at a high level because some idiot behind you didn't pay attention to your vulnerabilites... Phil From crow at bear.cs.dartmouth.edu Tue Apr 3 16:34:28 2001 From: crow at bear.cs.dartmouth.edu (Preston Crow) Date: Thu Jan 13 18:00:22 2005 Subject: [CF-Devel] object movers Message-ID: <200104032134.f33LYSM16052@bear.cs.dartmouth.edu> Based on feedback here and some more thoughts of my own, I've updated my generic mover. I actually have it coded, though I haven't tested it. The major changes since I last discussed it are that I added the ability to move based on the type of an object, and I made it so that you can use it like a teleporter, moving to a non-adjacent square. Personally, I would like to have it be able to move to another map (loading and adjusting the timeout value of that map as appropriate), but I haven't looked into that. Since there currently is no way to move anything between maps besides players, I suspect that there would be some complications. As to my code, I have several questions: What do I need to do to make sure it doesn't move things like other movers, the floor, directors, and such? Should I have a list of object types that are by default excluded? In using these, how much do I have to worry about CPU time? If no object arrives on the same square as the mover, will the mover still have to scan through the objects on the square? Anyway, here is my code as it stands now. There are a few minor changes elsewhere (like adding the new GENERIC_MOVER type), but nothing too exciting. --PC /* move_generic_mover: this function takes a "generic mover" as an * argument, and performs the function of a mover, which is: * * a player mover finds any players that are sitting on it. It * moves them in the op->stats.ac direction. speed is how often it'll move. * If attacktype is nonzero it will paralyze the player. If lifesave is set, * it'll dissapear after grace+1 moves. If maxsp is set and attacktype is set, * it'll paralyze the victim for maxsp*his speed/op->speed * * ac: direction in which to move (0 for random or location) * hp,sp: x,y location to move to (or 0/0 if random) * speed: how often to move * lifesave: disappear after hp+1 moves if set * grace: number of moves (plus one) before disappearing, if lifesave is set. * attacktype: paralyze when moving if non-zero * maxsp: how long to paralyze (relative to victim->speed/speed) [default to 2 if zero] * level: bitmap to determine which objects move; add the values together * Selection options: (consider any matching object) * 1 -- move monsters * 2 -- move players * 4 -- move non-living objects * exp: bitmap to determine which objects to exclude; add the values together * Exclusion options: (ignore excluded objects) * 1 -- exclude flying objects * 2 -- exclude non-flying objects * 4 -- exclude identified objects * 8 -- exclude non-identified objects * 16 -- exclude unpaid objects * 32 -- exclude non-unpaid objects * slaying: only move objects that match the text string (match vs. query_name()) * maxhp: control how slaying matches are performed: * 0 -- ignore slaying field * 1 -- exact match * 2 -- fuzzy match (strncasecmp) * (negative values indicate only move non-matching objects) * value: only move if object type matches (negative to only move non-matching) * * For clarification: There are a number of ways here of controling which * objects are moved. In order for an object to be moved, it must pass the * tests for each of the selection methods. For example, if the level is * zero, nothing will be moved, even if it matches the slaying field. * */ void move_generic_mover(object *op) { object *victim, *nextmover; int direction; int newx,newy; /* * Consider every object on this square */ for(victim=get_map_ob(op->map,op->x,op->y); victim !=NULL; victim=victim->above) { /* * Is this an object that this mover acts on? */ if( /* Check type of object */ ( ( !QUERY_FLAG(victim, FLAG_ALIVE)&&(op->level&1) ) || ( QUERY_FLAG(victim, FLAG_ALIVE)&&(victim->type!=PLAYER)&&(op->level&2) ) || ( QUERY_FLAG(victim, FLAG_ALIVE)&&(victim->type==PLAYER)&&(op->level&4) ) ) && /* Check flying status */ !( (QUERY_FLAG(victim,FLAG_FLYING))&&(op->stats.exp&1) ) && !( !(QUERY_FLAG(victim,FLAG_FLYING))&&(op->stats.exp&2) ) && !( (QUERY_FLAG(victim,FLAG_IDENTIFIED))&&(op->stats.exp&4) ) && !( !(QUERY_FLAG(victim,FLAG_IDENTIFIED))&&(op->stats.exp&8) ) && !( (QUERY_FLAG(victim,FLAG_UNPAID))&&(op->stats.exp&16) ) && !( !(QUERY_FLAG(victim,FLAG_UNPAID))&&(op->stats.exp&32) ) ) { /* * Is this a type-checking mover? */ if (op->value && ( ( op->value>0 && victim->type!=op->value ) || ( op->value<0 && victim->type==-op->value ))) { continue; } /* * Is this a matching mover? */ if ( !op->slaying ) op->stats.maxhp=0; if (op->stats.maxhp) { char *vname; vname=query_name(victim); switch (op->stats.maxhp) { case 1: /* Exact match or next object */ if (strcmp(op->slaying,vname)) continue; break; case 2: /* Rough match or next object */ if (strncasecmp(op->slaying,vname,strlen(op->slaying))) continue; break; case -1: if (!strcmp(op->slaying,vname)) continue; break; case -2: if (!strncasecmp(op->slaying,vname,strlen(op->slaying))) continue; break; default: /* This is an error in the mover object definition */ /* Most likely it means the server needs to be upgraded */ break; } } /* * Have we exceeded our maximum number of moves? */ if(QUERY_FLAG(op,FLAG_LIFESAVE)&&op->stats.grace--<0) { remove_ob(op); free_object(op); return; } /* * Are we moving on top of another mover? */ if (op->stats.ac) { newx=op->x+freearr_x[op->stats.ac]; newy=op->y+freearr_y[op->stats.ac]; } else if (op->stats.hp || op->stats.sp) { newx=op->stats.hp; newy=op->stats.sp; } else { direction = op->stats.ac?op->stats.ac:(RANDOM()%8)+1; newx=op->x+freearr_x[direction]; newy=op->y+freearr_y[direction]; } if (out_of_map(op->map, newx, newy)) { LOG(llevError, "Removed illegal generic mover.\n"); remove_ob(op); free_object(op); return; } for(nextmover=get_map_ob(op->map,newx,newy); nextmover !=NULL; nextmover=nextmover->above) { if(nextmover->type == GENERICMOVER) { nextmover->speed_left=-.99;} if(QUERY_FLAG(nextmover,FLAG_ALIVE)) { op->speed_left=-1.1; /* wait until the next thing gets out of the way */ } } /* * Do the move */ if(victim->type==PLAYER) { /* Following is a bit of hack. We need to make sure it * is cleared, otherwise the player will get stuck in * place. This can happen if the player used a spell to * get to this space. */ victim->contr->fire_on=0; victim->speed_left=-FABS(victim->speed); } remove_ob(op); for(tmp=op;tmp!=NULL;tmp=tmp->more) { /* Is this for multi-square objects? */ tmp->x=newx+(tmp->arch==NULL?0:tmp->arch->clone.x); tmp->y=newy+(tmp->arch==NULL?0:tmp->arch->clone.y); } insert_ob_in_map(op,op->map,originator); /* * Paralyze */ if(!op->stats.maxsp&&op->attacktype) op->stats.maxsp=2.0; if(op->attacktype) /* flag to paralyze the player */ victim->speed_left= -FABS(op->stats.maxsp*victim->speed/op->speed); } } } From hsteoh at quickfur.yi.org Tue Apr 3 17:03:11 2001 From: hsteoh at quickfur.yi.org (H. S. Teoh) Date: Thu Jan 13 18:00:22 2005 Subject: [CF-Devel] Re: [CF-maps] Just some idle thoughts In-Reply-To: <200104031849.f33InPF27003@alfven.EECS.Berkeley.EDU>; from peterm@alfven.EECS.Berkeley.EDU on Tue, Apr 03, 2001 at 11:49:25AM -0700 References: <20010403125114.A16300@crystal> <200104031849.f33InPF27003@alfven.EECS.Berkeley.EDU> Message-ID: <20010403180311.A17030@crystal> On Tue, Apr 03, 2001 at 11:49:25AM -0700, Peter Mardahl wrote: > > On Tue, Apr 03, 2001 at 05:41:03PM +0200, Philipp Currlin wrote: > > > > This reminds me -- somebody on metalforge (a semi-newbie) suggested that > > we should have quests that reward exp for solving a puzzle or completing > > the quest. For example, a quest might be to retrieve some stolen item, and > > when the player gets the item (or safely reaches the map exit with the > > item), he should get some exp for it. > > You're right, and this has been suggested before. > > If anyone wants to code this, I suggest an addition to the > player changer, which is what adds a class to a player in the > Hall of Selection. [snip] OK, I'll take a look at the code and see if I can figure something out. T -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot From crow at bear.cs.dartmouth.edu Tue Apr 3 23:31:01 2001 From: crow at bear.cs.dartmouth.edu (Preston Crow) Date: Thu Jan 13 18:00:22 2005 Subject: [CF-Devel] non-merging items Message-ID: <200104040431.f344V1k16880@bear.cs.dartmouth.edu> This buffer is for notes you don't want to save, and for Lisp evaluation. If you want to create a file, visit that file with C-x C-f, then enter the text in that file's own buffer. I've been noticing items that appear to be identical, and yet they don't merge. I went and looked at my saved player file, and I see that in at least one case, the difference is one has "no_skill_ident 1" while the other doesn't, though both items are identified. Was there a bug where identifying an object that you had failed to identify with a skill previously left this flag set? If so, has it been fixed? --PC For reference, here are the two objects that should merge: arch emerald title of great value face pretty_emerald.111 speed 0.000000 nrof 5 value 1600 weight 55 is_animated 0 been_applied 1 no_skill_ident 1 end arch emerald title of great value face pretty_emerald.111 speed 0.000000 nrof 2 value 1600 weight 55 is_animated 0 been_applied 1 end From mwedel at scruz.net Wed Apr 4 00:15:49 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:00:22 2005 Subject: [CF-Devel] object movers References: <200104032134.f33LYSM16052@bear.cs.dartmouth.edu> Message-ID: <3ACAAE05.E79EF13C@scruz.net> Preston Crow wrote: > > Based on feedback here and some more thoughts of my own, I've updated my > generic mover. I actually have it coded, though I haven't tested it. The > major changes since I last discussed it are that I added the ability to > move based on the type of an object, and I made it so that you can use it > like a teleporter, moving to a non-adjacent square. > > Personally, I would like to have it be able to move to another map (loading > and adjusting the timeout value of that map as appropriate), but I haven't > looked into that. Since there currently is no way to move anything between > maps besides players, I suspect that there would be some complications. It seems to me that the ability to move to a non adjacent square or to another map isn't really what the player movers should be used for. The way they have been used in the past, they just move to adjacent squares. With the changes you have made above, I really wonder if that is what the player movers should be used for, or if the teleporters should just be used for that. Player movers are obviously not a really good term anymore, since they certainly move more than players. I'm unsure where the line should be drawn, but it seems pretty clear that you are moving beyond what the player movers did and into what teleporters already do. I don't know what teleporters are missing so they just can't be used in this case, but it would seem that it may make more sense to modify teleporters to have these features and not have movers do that job. Now there could be some debate on how crossfire should deal with objects type - the current method is basically to have each object type do some fairly specific actions, and linking objects with other objects allows for more powerful operations. The other would be to reduce the number of object types (ignoring the type/subtype idea in the TODO list) - just have a limited number of object types, but one type may do many different things (ie, a mover/teleporter/exit/trapdoor/...). > As to my code, I have several questions: > > What do I need to do to make sure it doesn't move things like other movers, > the floor, directors, and such? Should I have a list of object types that > are by default excluded? first check would be to check for FLAG_NO_PICK and FLAG_FLOOR (or it might be FLAG_IS_FLOOR) - these should probably not be things to get moved. Likewise, invisible objects should not get moved. I don't know if that will cover all objects or not - certainly the checks will need to be hard coded into the server. using object types is not really ideal, as I can certainly see object types getting added and the list not being updated. > > In using these, how much do I have to worry about CPU time? If no object > arrives on the same square as the mover, will the mover still have to scan > through the objects on the square? Depends on how the mover operates. If the mover operates via the walk_on/fly_on flags, then the apply function will get called with the object that entered the space. Its then up to the coding in the apply to call the mover function with the appropriate object. If the mover operates via a timed method (ie, time .1 so it does something every 10 ticks), then in that case it will need to look through all the objects on the square. there is no tracking to no if something has entered the square, and if something has, no way to know what it might be. From mwedel at scruz.net Wed Apr 4 00:24:56 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:00:22 2005 Subject: [CF-Devel] Re: [CF-maps] Just some idle thoughts References: <200104031849.f33InPF27003@alfven.EECS.Berkeley.EDU> Message-ID: <3ACAB028.8E0D9363@scruz.net> Peter Mardahl wrote: > > > On Tue, Apr 03, 2001 at 05:41:03PM +0200, Philipp Currlin wrote: > > > > This reminds me -- somebody on metalforge (a semi-newbie) suggested that > > we should have quests that reward exp for solving a puzzle or completing > > the quest. For example, a quest might be to retrieve some stolen item, and > > when the player gets the item (or safely reaches the map exit with the > > item), he should get some exp for it. > > You're right, and this has been suggested before. > > If anyone wants to code this, I suggest an addition to the > player changer, which is what adds a class to a player in the > Hall of Selection. > > It should not be hard. Right - should not be hard to add exp. But what skill does the exp go to? I can see this as much a problem as not giving out exp. If the player can control the category (through readied skill or whatever), this may open up abuses. IF this is hard coded to go to specific categories, it proves mostly useless if the character isn't using that skill. I suppose you could give out the exp based on the current distribution in the skill, so it goes mostly to what the player already has. From mwedel at scruz.net Wed Apr 4 00:46:17 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:00:22 2005 Subject: [CF-Devel] Just some idle thoughts References: Message-ID: <3ACAB529.EECA82E0@scruz.net> dnh wrote: > Recently a new player came into #crossfire (puff) and said he > favoured rogues when playing. What strikes me, is how useless most of the > theifs skills are, stealing? hardly ever works.. and exp is practically > worthless. Not only that, but if you fail the monster attacks you (ouch, > watch out level 1 players). Hiding is also pretty much useless I can see > its uses but the way crossfire is played it simply isn't worth the time. The fact of the matter is that crossfire (and most computer RPG's for that matter) are largely kill anything that moves. Perhaps some of the problem is suggestions in crossfire that this isn't really the case (some of the skills mentioned, as well as the classes provided). I think trying to make one map be doable in many different ways may be difficult. IT would probably be better to make some maps more doable by one class/skill set. Problem is balance. Some problem is the maps themselves. Many of the maps are very congested with monsters, so even if you want to try to be stealthy or whatever, the simple fact is that the corriders are often filled up with monsters, so you just can't sneak around them. > > a) Skills tend to be deep rooted, if we change something the effects may > cause some unforseen unbalance thus causing more and more problems The problem to some extent is probably balance. for example, being able to steal from most anything if your level 100 is probably not an issue, but it is an issue if your level 20 and able to steal some really good items from monsters, the > > For mapmakers, all I can do is plea to who ever is busy working on maps to > consider ALL the characters not just your current one =). For server > developers I wonder if we can start a thread discussing problems areas and > possible solutions. While I am currently busy fixing images, I think the > discussion can occur, I hope to have all the problem images done withing a > month or two, then I can start working on these problems. As a possible > example, should we consider changing items in current mapsets? I recently > changed a few but they were minor changes, and just things like an extra > +10 to resistance caused quite abit of checking with everyone to make sure > it is fair and balanced. If we start changing this sword to a new glove, > it may upset players who have come to enjoy the prize for the challenge, > it may also upset the author and it may upset other maps that require a > weapon of that type. Therefore should we just leave items as they are? Chaning a sword to a glove may not appear to be a big deal, but if that glove is a lot better than any other glove out there, that then does prove a problem, as there will certainly still be good weapons out there, and so the combination now makes things more powerful. I don't have a problem with discussion on whatever issues are needed. From mwedel at scruz.net Wed Apr 4 01:07:12 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:00:22 2005 Subject: [CF-Devel] GTK client still has big problems References: Message-ID: <3ACABA10.1FF1565D@scruz.net> dnh wrote: > > Using latest CVS client. > > Any pile over about 20 flashes so much you can neither scroll down, nor > pick up anything. To do anything with my item piles.. I have to pick > everything up.. drop what I want.. move to a different spot then drop all. > Nor entirely user friendly. This is a server problem I am certain, and I > am fairly certain MichToen has already said what the problem is. If anyone > can look into this I would be most grateful, thanks. Well, I need more info, as I can't reproduce it. IT may have to do what you have in your pile - I don't know. I would also be curious as to why you think this is a server problem - there may very well be a good reason, like if you got the stock 0.97.0 client and it happens with that client on the same server. From mwedel at scruz.net Wed Apr 4 00:54:16 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:00:22 2005 Subject: [CF-Devel] non-merging items References: <200104040431.f344V1k16880@bear.cs.dartmouth.edu> Message-ID: <3ACAB708.4BCE3934@scruz.net> I've fixed this in CVS: common/item.c: Modify identify function to clear the NO_SKILL_IDENT flag so objects will now merge. Also, once the object has been identified, the no_skill_ident doesn't have meaning anymore. MSW 2001-04-03 Note that this will only apply for new object identified - it won't fix problems with existing save files. From peterm at alfven.EECS.Berkeley.EDU Wed Apr 4 02:47:56 2001 From: peterm at alfven.EECS.Berkeley.EDU (Peter Mardahl) Date: Thu Jan 13 18:00:22 2005 Subject: [CF-Devel] Re: [CF-maps] Just some idle thoughts In-Reply-To: Your message of "Tue, 03 Apr 2001 22:24:56 PDT." <3ACAB028.8E0D9363@scruz.net> Message-ID: <200104040747.f347lvS28024@alfven.EECS.Berkeley.EDU> > > But what skill does the exp go to? I can see this as much a problem as not > giving out exp. If the player can control the category (through readied skil >l > or whatever), this may open up abuses. IF this is hard coded to go to specif >ic > categories, it proves mostly useless if the character isn't using that skill. > > I suppose you could give out the exp based on the current distribution in th >e > skill, so it goes mostly to what the player already has. No, it should go into something map-maker specified. Like thief-experience for solving a big puzzle or something, priest experience for completing a holy quest.... PeterM From dnh at hawthorn.csse.monash.edu.au Wed Apr 4 03:35:54 2001 From: dnh at hawthorn.csse.monash.edu.au (dnh) Date: Thu Jan 13 18:00:22 2005 Subject: [CF-Devel] Re: [CF-maps] Just some idle thoughts In-Reply-To: <200104040747.f347lvS28024@alfven.EECS.Berkeley.EDU> Message-ID: On Wed, 4 Apr 2001, Peter Mardahl wrote: > > > > But what skill does the exp go to? I can see this as much a problem as not > > giving out exp. If the player can control the category (through readied skil > >l > > or whatever), this may open up abuses. IF this is hard coded to go to specif > >ic > > categories, it proves mostly useless if the character isn't using that skill. > > > > I suppose you could give out the exp based on the current distribution in th > >e > > skill, so it goes mostly to what the player already has. > > No, it should go into something map-maker specified. > Like thief-experience for solving a big puzzle or something, > priest experience for completing a holy quest.... > > PeterM Yeah that makes sense. Designated exp given for solving an entire mapset from beginning to end would probably be a very good idea. Also, Mark, when I was talking about theifs you said most of this type of game (crossfire, rogue etc) are just hack and kill. The point I was making, was that this particular player found the theif enjoyable because it had skills other than that. It is for that reason that I was wondering about how we might improve the crossfire experience, by making _such_ skills as theivery more powerful, or even more useful. dnh > > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > From andi.vogl at gmx.net Wed Apr 4 09:48:07 2001 From: andi.vogl at gmx.net (Andreas Vogl) Date: Thu Jan 13 18:00:22 2005 Subject: [CF-Devel] object movers In-Reply-To: <200104032134.f33LYSM16052@bear.cs.dartmouth.edu> Message-ID: <000001c0bd16$45e157a0$d43efea9@kyle> > As to my code, I have several questions: > > What do I need to do to make sure it doesn't move things like other movers, > the floor, directors, and such? Should I have a list of object types that > are by default excluded? Yes, this surely is neccessary. A mover that is screwing up maps would be terrible. Keep in mind that movers are often placed below the floor. Like Mark said, exclude objects with the following "flags" from movement: FLAG_IS_FLOOR, FLAG_NO_PICK, invisible Also exclude everything with "weight 0". This should prevent moving spell effects/ connected stuff (triggers,detectors,gates etc) and the likes. I hope none of them uses weight for internal calculations or other forms of mess..? > In using these, how much do I have to worry about CPU time? If no object > rrives on the same square as the mover, will the mover still have to scan > through the objects on the square? CPU time, say "performance", is an important issue. Try to make your mover function as efficient as possible. E.g.: Loop through the items on the mover's square only once. If possible, avoid checking every tick - instead check only when an item was added. Exclude spell effects (-> "weight 0") from all checks and loops at first. In addition, I have a small feature request for the new movers: =) If movers have the connected value set, have them move objects only by activation. This would allow some cool things. Like moving NPCs "on command" for example: You speak a keyword to the guards - and they step aside to let you pass. Andreas V. From crow at bear.cs.dartmouth.edu Wed Apr 4 16:30:22 2001 From: crow at bear.cs.dartmouth.edu (Preston Crow) Date: Thu Jan 13 18:00:22 2005 Subject: [CF-Devel] food bug? Message-ID: <200104042130.f34LUMn18822@bear.cs.dartmouth.edu> I've noticed that when I eat food that has some specail protection characteristics, it seems to have no effect on my character (other than filling his stomach). Are the protections added without telling the client, or are they ignored? Either way, it doesn't seem right. --PC From crow at bear.cs.dartmouth.edu Wed Apr 4 16:54:49 2001 From: crow at bear.cs.dartmouth.edu (Preston Crow) Date: Thu Jan 13 18:00:22 2005 Subject: [CF-Devel] container overstuffing Message-ID: <200104042154.f34Lsnv18874@bear.cs.dartmouth.edu> I like this one, but I guess it really should be fixed. When you pickup an item that would normally go in a container, and there is some space available, it will put it in the container, even if the result is a container exceeding capacity. Or at least, it usually does this. If you pick up a specific count, it won't. --PC From crow at bear.cs.dartmouth.edu Wed Apr 4 16:56:13 2001 From: crow at bear.cs.dartmouth.edu (Preston Crow) Date: Thu Jan 13 18:00:22 2005 Subject: [CF-Devel] quiver of bolts? Message-ID: <200104042156.f34LuDJ18878@bear.cs.dartmouth.edu> How come I never see a "quiver of bolts?" When I find a quiver of holding, half the time it will be for bolts, but with the non-magical variety, it's always arrows. --PC From crow at bear.cs.dartmouth.edu Wed Apr 4 17:24:36 2001 From: crow at bear.cs.dartmouth.edu (Preston Crow) Date: Thu Jan 13 18:00:23 2005 Subject: [CF-Devel] magic bullet Message-ID: <200104042224.f34MOag18968@bear.cs.dartmouth.edu> I just examined a grimoire of magic bullet, and it didn't tell me the spell level. Does this have something to do with it being the first spell in the table (spell number zero)? Another silly little thing that's probably an easy fix. --PC From crow at bear.cs.dartmouth.edu Wed Apr 4 17:54:38 2001 From: crow at bear.cs.dartmouth.edu (Preston Crow) Date: Thu Jan 13 18:00:23 2005 Subject: [CF-Devel] item sorting Message-ID: <200104042254.f34MscG19109@bear.cs.dartmouth.edu> Occasionally there is a particular item that is not sorted into the right place in my inventory. I'm using the GTK client, though I suspect this is a server issue. For example, if I pick up a bunch of treatises, they're all together, except for the treatise of dancing sword, which is up near my containers. Likewise, a few of the artifact weapons will show up down near the end of my inventory instead of with the other weapons. --PC, hoping for a clean 1.0 From peterm at alfven.EECS.Berkeley.EDU Wed Apr 4 20:49:18 2001 From: peterm at alfven.EECS.Berkeley.EDU (Peter Mardahl) Date: Thu Jan 13 18:00:23 2005 Subject: [CF-Devel] Raffle2 in pupland broken? Message-ID: <200104050149.f351nIl29661@alfven.EECS.Berkeley.EDU> Hello, I looked at raffle2 in pupland via the map editor. SPOILER ALERT!! It seems like what is needed to solve the map with the teleporters in it (the one with the cyclops and the trolls), is for a player on each side of the map to send appropriate items across and perform appropriate actions. The first of these actions seemingly is for the left-hand player to melt the ice cube. >From my examination of the map, it should only be necessary to do this: 1) First, reveal the lever to open the secret door using show invisible. 2) Toggle the lever and fire a spell at the ice cube. However, the gates controlled by the button under the ice cube don't seem to be in the correct state at map initializaton. I checked this by going into the map via DM mode and examining the device. EVEN THOUGH THE BUTTON IS PRESSED BY THE ICE CUBE, THE GATES ARE IN THE WRONG POSITION. The upshot is that to solve the map, at great difficulty, I had to press AND release the button under the ice cube again. Now, this ice cube is defended: (or rather the button under it is) 1) Directors shut aside any thrown objects or spells. You cannot throw something on it. 2) Movers stop the player, his golems, and his pets from walking onto it. 3) Earth wall will not depress the button if put on top. So, um, with these problems, how the HELL did I solve it? a) I put earthwalls over everything near the ice cube. b) I ran diagonally-left-up from the door into the forbidden area c) the attack-run-speed bug allowed me to leap over the player changer through the earthwall. briefly, you get a huge burst of speed when you are attacking something and kill it: you fly through it very fast d) I ended up diagonally-down from the player changer e) after many tries, I was able to step onto the button (throwing objects did NOT work) This was WAY harder than is reasonable, IMHO. Is raffle2 broken or is this extreme hoop jumping intended? PeterM From pjka at cc.jyu.fi Thu Apr 5 01:18:39 2001 From: pjka at cc.jyu.fi (Pertti Karppinen (OH6KTR)) Date: Thu Jan 13 18:00:23 2005 Subject: [CF-Devel] Raffle2 in pupland broken? In-Reply-To: <200104050149.f351nIl29661@alfven.EECS.Berkeley.EDU>; from peterm@alfven.EECS.Berkeley.EDU on Wed, Apr 04, 2001 at 06:49:18PM -0700 References: <200104050149.f351nIl29661@alfven.EECS.Berkeley.EDU> Message-ID: <20010405091839.A20719@tukki.jyu.fi> On Wed, Apr 04, 2001 at 06:49:18PM -0700, Peter Mardahl wrote: <...> > EVEN THOUGH THE BUTTON IS PRESSED BY THE ICE CUBE, THE GATES ARE IN THE > WRONG POSITION. > > The upshot is that to solve the map, at great difficulty, I had > to press AND release the button under the ice cube again. <..> > > This was WAY harder than is reasonable, IMHO. Is raffle2 broken or > is this extreme hoop jumping intended? Nope. Melting of the ice cube should do the trick. This needs no fancy moves to achieve. The map is obviously suffering from the button code change which broke a lot of pup_land maps, most of which have been corrected. -- BSc. Pertti Karppinen |'Bridge Players | Systems Designer, University of Jyvaskyla, Finland | Do | http://www.iki.fi/~pjka/ | Office : +358 14 260 2088 | It | HAM: OH6KTR QTH: KP22UF | Cellular: +358 40 564 0786 | on the Table' | From andi.vogl at gmx.net Thu Apr 5 05:48:54 2001 From: andi.vogl at gmx.net (Andreas Vogl) Date: Thu Jan 13 18:00:23 2005 Subject: [CF-Devel] Raffle2 in pupland broken? In-Reply-To: <20010405091839.A20719@tukki.jyu.fi> Message-ID: <000001c0bdbe$08243380$9402fea9@kyle> > On Wed, Apr 04, 2001 at 06:49:18PM -0700, Peter Mardahl wrote: > <...> > > EVEN THOUGH THE BUTTON IS PRESSED BY THE ICE CUBE, THE GATES ARE IN THE > > WRONG POSITION. > > > > The upshot is that to solve the map, at great difficulty, I had > > to press AND release the button under the ice cube again. > <..> > > > > This was WAY harder than is reasonable, IMHO. Is raffle2 broken or > > is this extreme hoop jumping intended? > > Nope. Melting of the ice cube should do the trick. This needs no fancy moves > to achieve. The map is obviously suffering from the button code change which > broke a lot of pup_land maps, most of which have been corrected. You should both update your servers pals. I have fixed whole raffle2 a few days ago: Copy from the CVS-list: > Update of /cvsroot/crossfire/maps/pup_land/raffle > In directory usw-pr-cvs1:/tmp/cvs-serv12268/pup_land/raffle > > Modified Files: > raffle1 raffle1_u1 raffle1_u2 raffle1_u3 raffle2 raffle2_u1 > raffle2_u2_a raffle2_u2_b raffle2_u3 raffle2_u3a raffle2_u4 > raffle3 raffle3_u1 raffle3_u2 > Log Message: > pup_land/raffle: > > Cleanup for the raffle maps. Cosmetics, bugfixes > and more. Main feature: All three raffles are > fully funcional now. No more broken parts (as far as I > can see). > The maps are not perfect but at least they work. Look at the updated raffle maps and I hope you will find all that stuff corrected. IMPORTANT NOTE: This mail thread definitly belongs to the cf-maps list! Please subscribe to cf-maps and in future post map-related issues there. Andreas V. From crow at bear.cs.dartmouth.edu Thu Apr 5 12:39:49 2001 From: crow at bear.cs.dartmouth.edu (Preston Crow) Date: Thu Jan 13 18:00:23 2005 Subject: [CF-Devel] random maps Message-ID: <200104051739.f35Hdns21084@bear.cs.dartmouth.edu> I've noticed a few issues with random maps. With the treasure maps (the ones where you find a hole and the contain mostly coins or alchemy resources), sometimes there's a special feature (shrine or such). In those cases, I've seen walls with coins on them. Also, on those treasure maps, if the style is open grass, you'll see exactly where it would have laid out the walls if there had been any. This is more of an aesthetic issue. By the way, when a small store is added to a random map, it seems that while I can buy things, I can't sell. Is that intentional? Oh, and if small shops can show up in random maps, why not money changers? --PC From crow at bear.cs.dartmouth.edu Thu Apr 5 12:50:29 2001 From: crow at bear.cs.dartmouth.edu (Preston Crow) Date: Thu Jan 13 18:00:23 2005 Subject: [CF-Devel] server crash Message-ID: <200104051750.f35HoTf21098@bear.cs.dartmouth.edu> I've had two server crashes in the last week or so. One was with a pet monster when I went from the Scorn port to the Lake Country map. The other was upon entering a new random map (with no pets). Neither of these is easily recreated. So since I can't provide useful debugging information right now, I was wondering if there was a standard way of doing so? Could we have a script to run the server in a loop, only do it under gdb so that a crash produces a stack trace? Or maybe a script that upon a crash will run gdb in batch mode on the core file to produce the stack trace? We could even have it set up to email someone with the crash report automatically, provided someone wants to receive them. --PC From hsteoh at quickfur.yi.org Thu Apr 5 13:58:37 2001 From: hsteoh at quickfur.yi.org (H. S. Teoh) Date: Thu Jan 13 18:00:23 2005 Subject: [CF-Devel] Arrow bug Message-ID: <20010405145837.A22215@crystal> I just found a rather funny bug: 1) get a longbow (not sure if this happens with ordinary bows) and arrow, and make sure you have poor wc 2) wear some armour with very good ac 3) fire an arrow at yourself and step away Now you're created an infinitely travelling arrow that stays in one spot. Step on it and it will start trying to hit you. If your ac is high enough, it will infinitely miss you. T -- "I'm running Windows '98." "Yes." "My computer isn't working now." "Yes, you already said that." -- User-Friendly From mwedel at scruz.net Thu Apr 5 22:45:46 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:00:23 2005 Subject: [CF-Devel] server crash References: <200104051750.f35HoTf21098@bear.cs.dartmouth.edu> Message-ID: <3ACD3BEA.C3DAA77@scruz.net> Preston Crow wrote: > > I've had two server crashes in the last week or so. One was with a pet > monster when I went from the Scorn port to the Lake Country map. The other > was upon entering a new random map (with no pets). Neither of these is > easily recreated. > > So since I can't provide useful debugging information right now, I was > wondering if there was a standard way of doing so? Could we have a script > to run the server in a loop, only do it under gdb so that a crash produces > a stack trace? Or maybe a script that upon a crash will run gdb in batch > mode on the core file to produce the stack trace? We could even have it > set up to email someone with the crash report automatically, provided > someone wants to receive them. the crossloop skills do exist which does do this to an extent - it at least compresses (gzips) the core files and renames them. It wouldn't be hard to modify the script to do other stuff also. With the core file, you can then get the stack trace at a later time (presuming the server it was generated from has not changed.). Now it would not be hard to extend that script to also do something like: gdb --command=/some/file server/crossfire core > /some/other/file where the --command file lists the commands you want gdb to do (probably where, q). I'm not sure if I would want to default crossloop scripts to do this - after all, gdb isn't installed on every system. From mwedel at scruz.net Thu Apr 5 22:49:43 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:00:23 2005 Subject: [CF-Devel] item sorting References: <200104042254.f34MscG19109@bear.cs.dartmouth.edu> Message-ID: <3ACD3CD7.559DC624@scruz.net> Preston Crow wrote: > > Occasionally there is a particular item that is not sorted into the right > place in my inventory. I'm using the GTK client, though I suspect this is > a server issue. For example, if I pick up a bunch of treatises, they're > all together, except for the treatise of dancing sword, which is up near my > containers. Likewise, a few of the artifact weapons will show up down near > the end of my inventory instead of with the other weapons. > Actually, its a client issue. The client deals with all sorting of objects. Look at the item_types file and adjust as needed. In retrospect, it may not have been the best idea to leave all the sorting responsibility to the client. A better approach probably would have been for the item type (as in define.h) to get sent along with the item, and then the client could have a translation table on how to order those (ie, I want type 65 at the top, top 4 near the bottom, group type 20, 25, 28 together, etc). From peterm at alfven.EECS.Berkeley.EDU Fri Apr 6 00:08:07 2001 From: peterm at alfven.EECS.Berkeley.EDU (Peter Mardahl) Date: Thu Jan 13 18:00:23 2005 Subject: [CF-Devel] Suggestion for human race-- faster advancement Message-ID: <200104060508.f36587a31865@alfven.EECS.Berkeley.EDU> Hello, Since the human race has no other advantages, someone proposed (on a crossfire server) allowing them quicker advancement. How about it? PeterM From mwedel at scruz.net Thu Apr 5 23:26:58 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:00:23 2005 Subject: [CF-Devel] magic bullet References: <200104042224.f34MOag18968@bear.cs.dartmouth.edu> Message-ID: <3ACD4592.B67AF908@scruz.net> Preston Crow wrote: > > I just examined a grimoire of magic bullet, and it didn't tell me the spell > level. Does this have something to do with it being the first spell in the > table (spell number zero)? I've fixed this in CVS. If for whatever reason someone wants to make s spellbook that doesn't have a spell, they should set the sp negative now. From mwedel at scruz.net Thu Apr 5 23:37:01 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:00:23 2005 Subject: [CF-Devel] Suggestion for human race-- faster advancement References: <200104060508.f36587a31865@alfven.EECS.Berkeley.EDU> Message-ID: <3ACD47ED.41ED73A9@scruz.net> Peter Mardahl wrote: > > Hello, > > Since the human race has no other advantages, someone > proposed (on a crossfire server) allowing them quicker > advancement. > > How about it? I thought the races were already balanced by those that actually get good benefits have a net stat penalty. I have no problem with giving whatever is needed to better balance the classes/races. I just thought they had already been balanced. From mwedel at scruz.net Fri Apr 6 00:03:06 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:00:23 2005 Subject: [CF-Devel] food bug? References: <200104042130.f34LUMn18822@bear.cs.dartmouth.edu> Message-ID: <3ACD4E0A.E4ECBC08@scruz.net> Preston Crow wrote: > > I've noticed that when I eat food that has some specail protection > characteristics, it seems to have no effect on my character (other than > filling his stomach). Are the protections added without telling the > client, or are they ignored? Either way, it doesn't seem right. Its trickier than that. If your resistance changes, the client will get updated. However, the resistance the food gives may not be done as obviously as one may thing - basically, the a food has resistance, it casts the appropriate resistance spell. So if you already have the spell up, it doesn't really do anything. Likewise, the resistance value of the food has no effect of the resistance value you get when you eat it. In all cases, the resistance spell of the same power gets cast. What should really happen is a special force just for food effects gets added to the players inventory, with its resistance value based on the reistance value of the food, and the duration based on the food value - so eating that ogre finger won't get you a very long duration, but that ogre corpse would. Anyone want to do this change? From mwedel at scruz.net Fri Apr 6 01:25:28 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:00:23 2005 Subject: [CF-Devel] object movers References: <200103292315.f2TNFEn27926@bear.cs.dartmouth.edu> Message-ID: <3ACD6158.AD363BFA@scruz.net> Preston Crow wrote: > > On a side note, I think I found a bug in the current player_mover code in > time.c:move_player_mover(). > > The code checks to see if the mover is moving the object to another > playermover. However, the direction of movement is random if op->stats.sp > is zero, and the random direction hasn't yet been determined. > > I doubt that there are many movers with random direction, so it's not a big > deal. I've fixed this in CVS. Basically, if the player mover does have a random direction, the function determines the direction it will go this time around, and then use appropriate direction for all future checks. From mwedel at scruz.net Fri Apr 6 01:40:01 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:00:23 2005 Subject: [CF-Devel] container overstuffing References: <200104042154.f34Lsnv18874@bear.cs.dartmouth.edu> Message-ID: <3ACD64C1.2C190CA3@scruz.net> Preston Crow wrote: > > I like this one, but I guess it really should be fixed. > > When you pickup an item that would normally go in a container, and there is > some space available, it will put it in the container, even if the result > is a container exceeding capacity. Or at least, it usually does this. If > you pick up a specific count, it won't. Just want to get clarifcation on this: If say you have 100 arrows in your inventory, you can drop all 100 into a container (by not specifying a number - just dropping them), but dropping 99 will not? From dnh at hawthorn.csse.monash.edu.au Fri Apr 6 02:16:47 2001 From: dnh at hawthorn.csse.monash.edu.au (dnh) Date: Thu Jan 13 18:00:23 2005 Subject: [CF-Devel] Suggestion for human race-- faster advancement In-Reply-To: <200104060508.f36587a31865@alfven.EECS.Berkeley.EDU> Message-ID: On Thu, 5 Apr 2001, Peter Mardahl wrote: > > Hello, > > Since the human race has no other advantages, someone > proposed (on a crossfire server) allowing them quicker > advancement. > > How about it? Humans advantage is that its stats are completely balanced. This is an advantage in itself, as a human can therefore be a jack of all trade (although perhaps a master of none). I don't know that the amount of work required would be worth the benefit to the game, I would say fixing Fireborn and Monk to the be the current most important issues. At high level any 'standard' race is prety much the same, the only difference being what rings and items you wear. dnh > PeterM > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > From peterm at alfven.EECS.Berkeley.EDU Fri Apr 6 03:56:56 2001 From: peterm at alfven.EECS.Berkeley.EDU (Peter Mardahl) Date: Thu Jan 13 18:00:23 2005 Subject: [CF-Devel] Suggestion for human race-- faster advancement In-Reply-To: Your message of "Thu, 05 Apr 2001 21:37:01 PDT." <3ACD47ED.41ED73A9@scruz.net> Message-ID: <200104060856.f368uu332262@alfven.EECS.Berkeley.EDU> > > I thought the races were already balanced by those that actually get good > benefits have a net stat penalty. > I have no problem with giving whatever is needed to better balance the > classes/races. I just thought they had already been balanced. I wouldn't call it "unbalanced", just uninteresting. No race has a "net stat" negative. However, every race, but humans, has a skewing of stats which makes it more suitable for particular purposes, and more fun! For example, Elves make good spellcasters, but middling fighters gnomes make good priests, but poor thief/fighters, Fireborn make awesome spellcaster/priests and horrible fighters, Quetzalcoatls are good at fighting and roasting things, but horrible at learning any new magic.... Dwarves, orcs, and trolls make decent fighters, and bad spellcasters and halflings make good thieves and terrible priests. Humans aren't attractive because they aren't exceptionally good at anything: even with class bonuses they can't start with any really high stats. It's not actually that they're unbalanced, just extremely boring. PeterM From andi.vogl at gmx.net Fri Apr 6 05:09:31 2001 From: andi.vogl at gmx.net (Andreas Vogl) Date: Thu Jan 13 18:00:23 2005 Subject: [CF-Devel] food bug? In-Reply-To: <3ACD4E0A.E4ECBC08@scruz.net> Message-ID: <000201c0be81$aedab000$801dfea9@kyle> > Preston Crow wrote: > > > > I've noticed that when I eat food that has some specail protection > > characteristics, it seems to have no effect on my character (other than > > filling his stomach). Are the protections added without telling the > > client, or are they ignored? Either way, it doesn't seem right. > > Its trickier than that. > > If your resistance changes, the client will get updated. > > However, the resistance the food gives may not be done as obviously as one > may thing - basically, the a food has resistance, it casts the appropriate > resistance spell. So if you already have the spell up, it doesn't really > do anything. No, you are wrong. Eating flesh (bodyparts) with resistance does not have any effect other than filling the stomache. And it was not intended another way. The resistance on flesh serves the sole purpose to prevent it getting destroyed by spells. For example: Dragonsteaks are resistant to fire. so when I kill a group of twenty dragons, I actually have a chance to find some bodyparts after killing. Now the real "bug" is only the fact that the resistance on flesh gets printed to the player on identify/examine. And this is only the case because the examine-function for weapons (->resistance important) and flesh is the same. > Likewise, the resistance value of the food has no effect of the resistance > value you get when you eat it. In all cases, the resistance spell of the > same power gets cast. > > What should really happen is a special force just for food effects gets > added to the players inventory, with its resistance value based on the > reistance value of the food, and the duration based on the food value - > so eating that ogre finger won't get you a very long duration, but that > ogre corpse would. > > Anyone want to do this change? I think casting protection spells on eating flesh is a bad idea. Flesh is just much too common. It would no longer be neccessary to cast any prot. spells by magic. That again would strengthen the warriors and make wizards/priests more lame in comparison. And sorig, for example has "denied protection" as major penalty - That would get obsolete too. Just a note: I plan to reshape the quetzal race to gain small bits of (permanent) resistance by eating appropriate flesh items. I already done most of the coding and it's a real interesting alternative to other races. But I currently stopped working on it, waiting for after 1.0. Andreas V. From andi.vogl at gmx.net Fri Apr 6 05:19:47 2001 From: andi.vogl at gmx.net (Andreas Vogl) Date: Thu Jan 13 18:00:23 2005 Subject: [CF-Devel] Suggestion for human race-- faster advancement In-Reply-To: Message-ID: <000301c0be83$249f8080$801dfea9@kyle> dnh wrote: > > Since the human race has no other advantages, someone > > proposed (on a crossfire server) allowing them quicker > > advancement. > > > > How about it? > > Humans advantage is that its stats are completely balanced. This is an > advantage in itself, as a human can therefore be a jack of all trade > (although perhaps a master of none). I don't know that the amount of work > required would be worth the benefit to the game, I would say fixing > Fireborn and Monk to the be the current most important issues. > > At high level any 'standard' race is prety much the same, the only > difference being what rings and items you wear. Yes, that is a good point. Most race benefits get obsolete at a certain level. So we should do the same to humans in order to keep it balanced. What if we make humans gain experience (slightly) faster, but the effect decreases by level? Say, at overall level 30 the effect is almost gone. Andreas V. From crow at bear.cs.dartmouth.edu Fri Apr 6 11:11:14 2001 From: crow at bear.cs.dartmouth.edu (Preston Crow) Date: Thu Jan 13 18:00:24 2005 Subject: [CF-Devel] server crash Message-ID: <200104061611.f36GBEo23458@bear.cs.dartmouth.edu> > Now it would not be hard to extend that script to also do something like: > gdb --command=/some/file server/crossfire core > /some/other/file > > where the --command file lists the commands you want gdb to do (probably where, >q). I'm not sure if I would want to default crossloop scripts to do this - >after all, gdb isn't installed on every system. How about a separate 'crossloop-debug' script? Or have the regular script check to see if gdb is present and only run it on the core file if it is? --PC From crow at bear.cs.dartmouth.edu Fri Apr 6 11:20:02 2001 From: crow at bear.cs.dartmouth.edu (Preston Crow) Date: Thu Jan 13 18:00:24 2005 Subject: [CF-Devel] item sorting Message-ID: <200104061620.f36GK2q23470@bear.cs.dartmouth.edu> > Actually, its a client issue. The client deals with all sorting of objects. > > Look at the item_types file and adjust as needed. The item_types file is correct. It lists the Katana of Masamune in with other artifact weapons, but it isn't sorted with them. As to the treatise of dancing sword, it's matching "sword." I don't see a good solution there without having the server pass the item type code. (I suppose it could sort on a combination of the name and the icon, but that gets ugly.) Oh, it looks like "Passport" should be added near the end, right above "Port Pass." Could someone with CVS access do that? --PC From crow at bear.cs.dartmouth.edu Fri Apr 6 11:29:11 2001 From: crow at bear.cs.dartmouth.edu (Preston Crow) Date: Thu Jan 13 18:00:24 2005 Subject: [CF-Devel] item sorting Message-ID: <200104061629.f36GTBH23570@bear.cs.dartmouth.edu> >The item_types file is correct. It lists the Katana of Masamune in with >other artifact weapons, but it isn't sorted with them. Oops. I didn't do a `make depend`. Now that one is fixed. Sorry. --PC From crow at bear.cs.dartmouth.edu Fri Apr 6 11:50:27 2001 From: crow at bear.cs.dartmouth.edu (Preston Crow) Date: Thu Jan 13 18:00:24 2005 Subject: [CF-Devel] container overstuffing Message-ID: <200104061650.f36GoR823828@bear.cs.dartmouth.edu> > Just want to get clarifcation on this: > > If say you have 100 arrows in your inventory, you can drop all 100 into a >container (by not specifying a number - just dropping them), but dropping 99 >will not? Ok, I just did the following: Put 10 Bonecrushers in my inventory. Open sack of holding. Drop them into the sack--this fails as it should. Put 10 Bonecrushers on the floor. Make my sack of holding active. Set the count to 10. Hit the comma key to pick them up. (They go into my inventory, not the sack, which is right.) Put 10 Bonecrushers on the floor. Make my sack of holding active. Set the count to 0. Hit the comma key to pick them up. (They go into my sack of holding, not my regular inventory, which is wrong.) On a related note, if I want to pick something up that is too heavy for me to carry, but if I were to pick it up, it would go into an active container which would reduce its weight enough to make it possible to carry, it still refuses to let me carry it. Now I haven't tried this in a case where the first bug wasn't the reason it was fitting into the container, so I'm not sure how real this is. Also, it may not be unreasonable to say that if I can't carry the object, I can't pick it up and then put it in my sack of holding. --PC From michael.toennies at nord-com.net Fri Apr 6 19:48:57 2001 From: michael.toennies at nord-com.net (Michael Toennies) Date: Thu Jan 13 18:00:24 2005 Subject: [CF-Devel] button bug Message-ID: got this log... ake_path_tofile /home/unitel/cf/crossfire/var/crossfire/players/Khalad/Khalad.pl... LOGOUT: Player named Khalad from ip 217.2.99.192 Trying to load map /home/unitel/cf/crossfire/share/crossfire/maps/pup_land/raffle/raffle1_u3. load_original_map: /pup_land/raffle/raffle1_u3 (0) make_path_tofile /home/unitel/cf/crossfire/var/crossfire/players/Rascal/Rascal.pl... CS: connection from client of type X11 C Client Initializing gods...done. enter_map: supplied coordinates are not within the map! (/HallOfSelection: -1, -1) get_nearest_player: Found free/non friendly object on friendly list Saving map /pup_land/pplant/pplant_ud1 Checksums: 961c785a 961c785a LOGIN: Player named Khalad from ip 217.2.99.192 make_path_tofile /home/unitel/cf/crossfire/var/crossfire/players/Son-Goten/Son-Goten.pl... Saving map /brittany/Brest/jes.admini.1 Resetting map /random/0000000000000023. Trying to load map /home/unitel/cf/crossfire/share/crossfire/maps/pup_land/pplant/pplant2. load_original_map: /pup_land/pplant/pplant2 (0) Using stored map difficulty: 6 Trying to load map /home/unitel/cf/crossfire/share/crossfire/maps/brittany/Brest/nasty_house. load_original_map: /brittany/Brest/nasty_house (0) Saving map /pup_land/raffle/raffle1_u2 Resetting map /HallOfSelection. Player 'Son-Goten' tried apply the unknown object (1177293) Saving map /pup_land/pplant/pplant1 Saving map /brittany/Brest/info_first Saving map /brittany/Brest/brest Saving map /pup_land/raffle/raffle1_u3 Player 'Son-Goten' tried apply the unknown object (1176528) Player 'Son-Goten' tried apply the unknown object (1176612) Player 'Son-Goten' tried apply the unknown object (1176528) Player 'Son-Goten' tried apply the unknown object (1176528) Player 'Son-Goten' tried apply the unknown object (1176528) Saving map /pup_land/raffle/raffle1_u2 Saving map /pup_land/raffle/raffle1_u1 @match chain CHAIN Chain Oh you know the password! You must be a citizen of scorn. Pass Citizen. @match chain CHAIN Chain Oh you know the password! You must be a citizen of scorn. Pass Citizen. Resetting map /random/0000000000000024. make_path_tofile /home/unitel/cf/crossfire/var/crossfire/players/Garfir/Garfir.pl... remove_friendly_object called with empty friendly list, remove ob=Garfir Trying to load map /home/unitel/cf/crossfire/share/crossfire/maps/HallOfSelection. load_original_map: /HallOfSelection (0) enter_map: supplied coordinates are not within the map! (/HallOfSelection: -1, -1) get_nearest_player: Found free/non friendly object on friendly list Checksums: d19e330a d19e330a LOGIN: Player named Garfir from ip 62.158.113.85 CSSTAT: Sat Apr 7 02:42 tot 1854244 22606815 9 19200 inc 91384 1049787 1 600 Saving map /pup_land/terminal_u1 Saving map /pup_land/terminal Resetting map /pup_land/raffle/raffle1. Internal error in update_button (6666). Internal error in update_button (6666). Internal error in update_button (6666). Internal error in update_button (small button). Internal error in update_button (small button). Internal error in update_button (small button). Internal error in update_button (small button). Internal error in update_button (small button). Internal error in update_button (small button). Internal error in update_button (small button). Internal error in update_button (small button). Internal error in update_button (small button). Internal error in update_button (large button). Internal error in update_button (large button). Internal error in update_button (small button). Internal error in update_button (small button). Internal error in update_button (small button). Internal error in update_button (small button). Internal error in update_button (small button). Internal error in update_button (large button). Internal error in update_button (large button). Internal error in update_button (small button). Internal error in update_button (small button). Internal error in update_button (small button). Internal error in update_button (small button). Internal error in update_button (small button). Emergency saves disabled, no save attempted Fatal: Too many errors Emergency saves disabled, no save attempted Cleaning up... Saving map /city/city Saving map /city/anthony/portgate Saving map /pup_land/raffle/raffle1 Saving map /city/shops/magicshop Player on map that is being saved Player on map that is being saved make_path_tofile /home/unitel/cf/crossfire/var/crossfire/players/Logger/_city_apartment_apart ments... Saving map /home/unitel/cf/crossfire/var/crossfire/players/Logger/_city_apartment_apart ments Player on map that is being saved Player on map that is being saved make_path_tofile /home/unitel/cf/crossfire/var/crossfire/players/Garfir/_city_apartment_apart ments... Saving map /home/unitel/cf/crossfire/var/crossfire/players/Garfir/_city_apartment_apart ments Player on map that is being saved Player on map that is being saved make_path_tofile /home/unitel/cf/crossfire/var/crossfire/players/Khalad/_city_apartment_apart ments... Saving map /home/unitel/cf/crossfire/var/crossfire/players/Khalad/_city_apartment_apart ments Player on map that is being saved Player on map that is being saved Saving map /pup_land/pplant/pplant2 Player on map that is being saved Player on map that is being saved Saving map /brittany/Brest/nasty_house Player on map that is being saved Player on map that is being saved Saving map /HallOfSelection Exiting... the wall name is gwall the wall name is dun the wall name is mine the wall name is dun the wall name is flagstone the wall name is stwall the wall name is cwall the wall name is dun the wall name is dun the wall name is dun the wall name is mine the wall name is mine the wall name is dun the wall name is dun the wall name is mine the wall name is dun the wall name is dun the wall name is mine the wall name is mine the wall name is mine the wall name is dun the wall name is mine the wall name is mine the wall name is mine the wall name is mine the wall name is mine the wall name is dun the wall name is mine the wall name is mine the wall name is dun the wall name is dun the wall name is dun the wall name is mine the wall name is dun the wall name is dun the wall name is mine the wall name is mine the wall name is dun the wall name is dun the wall name is mine the wall name is mine the wall name is cwall the wall name is stwall the wall name is dwall the wall name is stwall the wall name is cwall the wall name is flagstone the wall name is dwall From michael.toennies at nord-com.net Fri Apr 6 23:04:32 2001 From: michael.toennies at nord-com.net (Michael Toennies) Date: Thu Jan 13 18:00:24 2005 Subject: [CF-Devel] setup cmd Message-ID: I'll check the setup cmd in the cvs. I had to advance VERSION_CS from 1022 to 1023. Every server which sends now VERSION_CS >= 1023 back, can handle the setup cmd in future. The form is: setup .... At this stage, the setup cmd has only one regular cmd: cmd parameter --------------------------------------------------------------- sound 0 / 1 So, we can set with this cmd only sound on/off like with the setsound cmd. (in future then we can rip off the setsound cmd). So, a valid setup cmd looks like setup sound 1 The server then will collect the cmds and send the status back to client. The client recieve from upper setup cmd, a "setup sound 1" back. If the server can't send sound commands (in fact he will EVER do it yet, but perhaps we code a version which can't), he sends a "setup sound 0" back to the client. This shows the client, that the server has got the cmd right, but this is, what the server has set it. Means, the set to 1 has failed. Also, you can send this to the server: setup sound 1 bla 22 foo 4 Then the server will send back to client: setup sound 1 bla FALSE foo FALSE This will show the client, the server knows and set the sound cmd like expected, but bla and foo are unknown to him. Well, then the client can decide what it want to do. The setup cmd use a list for settings, so its easy to include cmds. From dnh at hawthorn.csse.monash.edu.au Fri Apr 6 23:33:17 2001 From: dnh at hawthorn.csse.monash.edu.au (dnh) Date: Thu Jan 13 18:00:24 2005 Subject: [CF-Devel] New food eating Message-ID: I have modified apply.c so that you can now eat food no matter how hungry you are. This is because I got fed up with waybread etc being to hard to use, you have to wait till it finally reaches 499 before you can eat. If you apply any food even at 998 food units you will eat it, although it would be a waste of food. I recently discovered a smallish bug with it, by eating food you build back some hp, now you can use food as healing potions by eating a whole heap quickly. I am not sure how this should be fixed, and I don't think I could do it even if I did. Some suggestions? dnh ps. peterm has also modified food so as the player increases Wisdom Experience the weight of each food produced by create food is less (by level 110 I believe waybread only ways 1/6). This may compound my bug. From crow at bear.cs.dartmouth.edu Fri Apr 6 14:53:46 2001 From: crow at bear.cs.dartmouth.edu (Preston Crow) Date: Thu Jan 13 18:00:24 2005 Subject: [CF-Devel] object movers Message-ID: <200104061953.f36Jrkj24508@bear.cs.dartmouth.edu> > It seems to me that the ability to move to a non adjacent square or to another >map isn't really what the player movers should be used for. > > The way they have been used in the past, they just move to adjacent squares. >With the changes you have made above, I really wonder if that is what the player >movers should be used for, or if the teleporters should just be used for that. Is there really any fundamental difference between a mover and a teleporter? I could probably make a good argument for a teleporter with all the same options for selecting what gets teleported. Is there really any reason to have a separate object? > Player movers are obviously not a really good term anymore, since they >certainly move more than players. I'm unsure where the line should be drawn, >but it seems pretty clear that you are moving beyond what the player movers did >and into what teleporters already do. I don't know what teleporters are missing >so they just can't be used in this case, but it would seem that it may make more >sense to modify teleporters to have these features and not have movers do that >job. The main thing I want is the ability to move an object selectively. For example, it might be nice to have the dancing trees set up so that the movers only move trees, so the assorted ghosts and skeletons move as normal. As to the name, I'm calling my mover a "generic mover," as it will move almost anything. > Now there could be some debate on how crossfire should deal with objects type >- the current method is basically to have each object type do some fairly >specific actions, and linking objects with other objects allows for more >powerful operations. > > The other would be to reduce the number of object types (ignoring the >type/subtype idea in the TODO list) - just have a limited number of object >types, but one type may do many different things (ie, a >mover/teleporter/exit/trapdoor/...). I guess I would argue that the best way to decide if you should have one object type or several is to figure out which way leaves you with better code. If you're reusing most of the same code for two different objects, it's probably better to have a single object. If you're having too many conditionals, then it might be time to split it into multiple objects. Of course, that's rather subjective. --PC From mwedel at scruz.net Sat Apr 7 00:38:32 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:00:24 2005 Subject: [CF-Devel] item sorting References: <200104061620.f36GK2q23470@bear.cs.dartmouth.edu> Message-ID: <3ACEA7D8.52C2D50A@scruz.net> Preston Crow wrote: > As to the treatise of dancing sword, it's matching "sword." I don't see a > good solution there without having the server pass the item type code. (I > suppose it could sort on a combination of the name and the icon, but that > gets ugly.) I've add the Passport below, as well as made some changes to the sword matching in the item_types file so it may work better now. From peterm at alfven.EECS.Berkeley.EDU Sat Apr 7 13:34:21 2001 From: peterm at alfven.EECS.Berkeley.EDU (Peter Mardahl) Date: Thu Jan 13 18:00:24 2005 Subject: [CF-Devel] object movers In-Reply-To: Your message of "Fri, 06 Apr 2001 15:53:46 EDT." <200104061953.f36Jrkj24508@bear.cs.dartmouth.edu> Message-ID: <200104071834.f37IYL602560@alfven.EECS.Berkeley.EDU> > > Is there really any fundamental difference between a mover and a teleporter? > > I could probably make a good argument for a teleporter with all the same > options for selecting what gets teleported. Is there really any reason to > have a separate object? Well, movers are very easy to set up in chains because they're directed. I suppose you could do the same thing with a teleporter--but when I first implemented it I considered it enough of a difference in action not to add all this stuff to a teleporter but rather simply create a new object, which would have all these extra properties that a generic teleporter doesn't really need: 1) A habit of moving something 1 square instead of arbitrary, the direction of motion being easily determined by where the mover points 2) the ability to FORCE whatever-it-is to move in that track by paralyzing him 3) an ability to define the speed of movement If you muck around and break the existing implementation, I expect you to fix all the maps! I think it's sensible to have a separate object rather than some sort of monstrous, do-all teleporter.... I mean, why don't we get rid of "teleporters" and simply put all mover and teleporter functionality into an exit???? PeterM > I guess I would argue that the best way to decide if you should have one > object type or several is to figure out which way leaves you with better > code. If you're reusing most of the same code for two different objects, > it's probably better to have a single object. If you're having too many > conditionals, then it might be time to split it into multiple objects. > > Of course, that's rather subjective. Well, I'm definitely on the side of a separate object for exits, movers, and teleporters. I think they're all different "enough". PeterM From andi.vogl at gmx.net Sat Apr 7 15:44:44 2001 From: andi.vogl at gmx.net (Andreas Vogl) Date: Thu Jan 13 18:00:24 2005 Subject: [CF-Devel] New food eating In-Reply-To: Message-ID: <000001c0bfa3$9b2d8500$d6b8fea9@kyle> dnh wrote: > I have modified apply.c so that you can now eat food no matter how hungry > you are. This is because I got fed up with waybread etc being to hard to > use, you have to wait till it finally reaches 499 before you can eat. > > If you apply any food even at 998 food units you will eat it, although it > would be a waste of food. > > I recently discovered a smallish bug with it, by eating food you build > back some hp, now you can use food as healing potions by eating a whole > heap quickly. I am not sure how this should be fixed, and I don't think I > could do it even if I did. Some suggestions? > > dnh Hey, you should ask before making such fundamental changes! Now food is healing potions for free, that is not at all okay IMHO. And how do you want to "fix" this? The "fix" is not allowing players to eat more than the stomache can hold. I was perfectly happy with how it used to work. Andreas V. From peterm at alfven.EECS.Berkeley.EDU Sat Apr 7 16:39:24 2001 From: peterm at alfven.EECS.Berkeley.EDU (Peter Mardahl) Date: Thu Jan 13 18:00:24 2005 Subject: [CF-Devel] Food eating suggestion Message-ID: <200104072139.f37LdOP02741@alfven.EECS.Berkeley.EDU> Rather than give full healing for eating food, how about give healing in proportion to the food actually eaten? So... if you used a waybread at 998, you'd only get 1/500 of the waybread's healing. PeterM From michael.toennies at nord-com.net Sat Apr 7 16:40:36 2001 From: michael.toennies at nord-com.net (Michael Toennies) Date: Thu Jan 13 18:00:24 2005 Subject: [CF-Devel] New food eating In-Reply-To: <000001c0bfa3$9b2d8500$d6b8fea9@kyle> Message-ID: Change it, that you can eat much as you can/want even when it not fit, but change the hp/resistance effect when food will if (oldfood > 900 && newfood >1000) then no_effect_on_hp no_effect_on_resistance this will bring it back to balance. > -----Original Message----- > From: crossfire-devel-admin@lists.real-time.com > [mailto:crossfire-devel-admin@lists.real-time.com]On Behalf Of Andreas > Vogl > Sent: Saturday, April 07, 2001 10:45 PM > To: Crossfire Devel List (E-mail) > Subject: RE: [CF-Devel] New food eating > > > dnh wrote: > > > I have modified apply.c so that you can now eat food no matter > how hungry > > you are. This is because I got fed up with waybread etc being to hard to > > use, you have to wait till it finally reaches 499 before you can eat. > > > > If you apply any food even at 998 food units you will eat it, > although it > > would be a waste of food. > > > > I recently discovered a smallish bug with it, by eating food you build > > back some hp, now you can use food as healing potions by eating a whole > > heap quickly. I am not sure how this should be fixed, and I > don't think I > > could do it even if I did. Some suggestions? > > > > dnh > > Hey, you should ask before making such fundamental changes! > Now food is healing potions for free, that is not at all okay IMHO. > And how do you want to "fix" this? The "fix" is not allowing players > to eat more than the stomache can hold. > I was perfectly happy with how it used to work. > > > Andreas V. > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > From andi.vogl at gmx.net Sat Apr 7 17:22:28 2001 From: andi.vogl at gmx.net (Andreas Vogl) Date: Thu Jan 13 18:00:24 2005 Subject: [CF-Devel] resistance on flesh In-Reply-To: <3ACEBAC0.8FC86D16@scruz.net> Message-ID: <000201c0bfb1$a4179760$d6b8fea9@kyle> Mark W. wrote: > Now IMO, it may be a nice feature to actually have bodyparts transfer > their effects to the player for some amount of time. This would > actually make some bodyparts more useful, and probably wouldn't unbalance > things much with the PR code. Hm... maybe an interesting thing if we do it right. A few questions and suggestions: o There is only one "food-effect"? I suppose additional eating will not rise resistance, rather change it. o How much resistance do we actually hand out? Taking the exact value from the flesh is a very bad idea. Even low level stuff like "beholder's tongue" has values up to 50%. And shouldn't there be more benefit from a "Dread's eye" than from a "beholder's tongue"? I think we should make value dependant on level difference between flesh<->player. (Flesh should inherit level from the killed monster for that purpose.) And, when I eat flesh with 50% resistance (that is kinda default) from a monster with equal level, I should get only low resistance like 20%. Maybe less, depending on how important we want flesh to get. o What about duration? Mabye fix, maybe level dependant... We could eventually make the duration shorter if the player already has a lot of resistance in that cathegory, for additional balancing. That way, flesh would be great help for low levels and "hard races", but less help for the high level freaks. Bad point: We'd need to adjust duration when the player changes equipment. Or we calculate it independand every tick, a bit like digestion. > Now with the latest food patch, probably the delta of how much food > actually gets added should count (ie, if you at 990, eat a 500 food > dragon stake, you only get 10/500 or 2% of normal duration). Yes, certainly. Same should be done for gaining health by eating btw. -------------------- A few answers regarding the previous mail from Mark: > > I think casting protection spells on eating flesh is a bad idea. Flesh is > > just much too common. It would no longer be neccessary to cast any prot. > > spells by magic. That again would strengthen the warriors and make > > wizards/priests more lame in comparison. And sorig, for example has > > "denied protection" as major penalty - That would get obsolete too. > > Aren't scrolls immune to that anyways? So for sorig, all your really > forcing the person to do is find appropriate scrolls of protection? Protection scrolls are rare, flesh is not. > Note if we do it via special food effects, then presumably the benefits > would be given to everyone equally, as you could still stack it with > the protection spell. It would basically mean that you could get a bit > more protection by carrying around appropriate food, but with PR, this > probably isn't a really big deal. After all, if you know what your > about to face, you do the same thing by equipping the appropriate items > with the right protections. That very much depends on the amount of resistance flesh items give. If the value is too high, it could be a serious blow to balance. Don't forget: I can wear all my equipment AND cast protection spells AND eat flesh items. Andreas V. From mwedel at scruz.net Sat Apr 7 01:59:12 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:00:24 2005 Subject: [CF-Devel] food bug? References: <000201c0be81$aedab000$801dfea9@kyle> Message-ID: <3ACEBAC0.8FC86D16@scruz.net> Andreas Vogl wrote: > > No, you are wrong. Eating flesh (bodyparts) with resistance does not have > any effect other than filling the stomache. And it was not intended another > way. The resistance on flesh serves the sole purpose to prevent it getting > destroyed by spells. > For example: Dragonsteaks are resistant to fire. so when I kill a group of > twenty dragons, I actually have a chance to find some bodyparts after > killing. IT depends. I looked at the code and actually saw this behaviour while running on my server with special foods. Its actually a little trickier - the food actually needs to have a tile, so I'm not sure if bodyparts do, but I think some artifact foods do. If it has a title, you do get the special properties, and it is done via spell. > > Now the real "bug" is only the fact that the resistance on flesh gets > printed to the player on identify/examine. And this is only the case > because the examine-function for weapons (->resistance important) > and flesh is the same. Well, if the food has a title, the information actually is somewhat relevant, as you will get special properties (albeit done via spellcasting). Now IMO, it may be a nice feature to actually have bodyparts transfer their effects to the player for some amount of time. This would actually make some bodyparts more useful, and probably wouldn't unbalance things much with the PR code. Now with the latest food patch, probably the delta of how much food actually gets added should count (ie, if you at 990, eat a 500 food dragon stake, you only get 10/500 or 2% of normal duration). > I think casting protection spells on eating flesh is a bad idea. Flesh is > just much too common. It would no longer be neccessary to cast any prot. > spells by magic. That again would strengthen the warriors and make > wizards/priests more lame in comparison. And sorig, for example has > "denied protection" as major penalty - That would get obsolete too. Aren't scrolls immune to that anyways? So for sorig, all your really forcing the person to do is find appropriate scrolls of protection? Note if we do it via special food effects, then presumably the benefits would be given to everyone equally, as you could still stack it with the protection spell. It would basically mean that you could get a bit more protection by carrying around appropriate food, but with PR, this probably isn't a really big deal. After all, if you know what your about to face, you do the same thing by equipping the appropriate items with the right protections. This wouldn't give anyone any real advantage then - as everyone would have the benefit, and it wouldn't take any benefit away. From dnh at hawthorn.csse.monash.edu.au Sat Apr 7 08:30:38 2001 From: dnh at hawthorn.csse.monash.edu.au (dnh) Date: Thu Jan 13 18:00:24 2005 Subject: [CF-Devel] Bug with AV's PR? Message-ID: I am a troll wizard worshipping mostrai. When i get +30 to fire I only get +21 to fire This is because it calculates that I have +30 +30 = +51, and yet really I have -30 + 30 +30 which = +30. Am I mistaken? Or is this just making it REALLY hard for a poor old troll. dnh From michael.toennies at nord-com.net Sat Apr 7 09:34:26 2001 From: michael.toennies at nord-com.net (Michael Toennies) Date: Thu Jan 13 18:00:24 2005 Subject: [CF-Devel] strange bug 1 Message-ID: oad_original_map: /styles/specialmaps/minichapel_rugguli (8) Trying to insert in null-map! arch Balrog_14 name Balrog face jessyb.E11 animation Balrog_14 x 6 y 12 weight 300000 alive 1 no_pick 1 is_animated 1 monster 1 end Trying to insert in null-map! arch Balrog_15 name Balrog face jessyb.F11 animation Balrog_15 x 7 y 12 weight 300000 alive 1 no_pick 1 is_animated 1 monster 1 end Trying to insert in null-map! arch Balrog_16 name Balrog face jessyb.G11 animation Balrog_16 x 8 y 12 weight 300000 alive 1 no_pick 1 is_animated 1 monster 1 end Trying to insert in null-map! arch Balrog_13 name Balrog face jessyb.D11 animation Balrog_13 x 1 y 13 weight 300000 alive 1 no_pick 1 is_animated 1 monster 1 end Trying to insert in null-map! arch Balrog_14 name Balrog face jessyb.E11 animation Balrog_14 x 2 y 13 weight 300000 alive 1 no_pick 1 is_animated 1 monster 1 end Trying to insert in null-map! arch Balrog_15 name Balrog face jessyb.F11 animation Balrog_15 x 3 y 13 weight 300000 alive 1 no_pick 1 is_animated 1 monster 1 end Trying to insert in null-map! arch Balrog_16 name Balrog face jessyb.G11 animation Balrog_16 x 4 y 13 weight 300000 alive 1 no_pick 1 is_animated 1 monster 1 end enter_map: Could not find free spot for player - will dump on top of object (/random/0000000000000048: 28, 1) SIGSEGV received. Emergency saves disabled, no save attempted Cleaning up... From michael.toennies at nord-com.net Sat Apr 7 09:36:07 2001 From: michael.toennies at nord-com.net (Michael Toennies) Date: Thu Jan 13 18:00:25 2005 Subject: [CF-Devel] strange bug 2 - any ideas? Message-ID: Resetting map /HallOfSelection. Trying to load map /home/unitel/cf/crossfire/share/crossfire/maps/city/shops/weaponshop. load_original_map: /city/shops/weaponshop (0) Saving map /city/shops/magicshop Saving map /city/city Trying to load map /home/unitel/cf/crossfire/share/crossfire/maps/city/shops/generalshop. load_original_map: /city/shops/generalshop (0) Saving map /city/shops/weaponshop Saving map /city/city Trying to load map /home/unitel/cf/crossfire/share/crossfire/maps/HallOfSelection. load_original_map: /HallOfSelection (0) enter_exit: Exit (none) (0,0) on map (none) is 0 destination coordinates make_path_tofile /home/unitel/cf/crossfire/var/crossfire/players/Maroon/Maroon.pl...Was not dir... make_path_tofile /home/unitel/cf/crossfire/var/crossfire/players/Maroon/Maroon.pl... Saving map /city/shops/generalshop Saving map /city/anthony/portgate Trying to load map /home/unitel/cf/crossfire/share/crossfire/maps/city/houses/house1. load_original_map: /city/houses/house1 (0) Resetting map /HallOfSelection. make_path_tofile /home/unitel/cf/crossfire/var/crossfire/players/Maroon/Maroon.pl... Trying to load map /home/unitel/cf/crossfire/share/crossfire/maps/city/misc/HouseofHealing. load_original_map: /city/misc/HouseofHealing (0) Adding friendly object priest of healing. CSSTAT: Sat Apr 7 04:24 tot 246080 4013818 1 6076 inc 7622 354541 1 600 Saving map /city/houses/house1 Saving map /city/city Trying to load map /home/unitel/cf/crossfire/share/crossfire/maps/HallOfSelection. load_original_map: /HallOfSelection (0) enter_map: supplied coordinates are not within the map! (/HallOfSelection: -1, -1) get_nearest_player: Found free/non friendly object on friendly list SIGSEGV received. Emergency saves disabled, no save attempted Cleaning up... Saving map /city/misc/HouseofHealing SIGSEGV received. Emergency saves disabled, no save attempted Cleaning up... SIGSEGV received. Emergency saves disabled, no save attempted Cleaning up... SIGSEGV received. Emergency saves disabled, no save attempted Cleaning up... SIGSEGV received. Emergency saves disabled, no save attempted Cleaning up... From mwedel at scruz.net Sat Apr 7 19:18:45 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:00:25 2005 Subject: [CF-Devel] resistance on flesh References: <000201c0bfb1$a4179760$d6b8fea9@kyle> Message-ID: <3ACFAE65.F50998B2@scruz.net> Andreas Vogl wrote: > > Mark W. wrote: > > > Now IMO, it may be a nice feature to actually have bodyparts transfer > > their effects to the player for some amount of time. This would > > actually make some bodyparts more useful, and probably wouldn't unbalance > > things much with the PR code. > > Hm... maybe an interesting thing if we do it right. > A few questions and suggestions: > > o There is only one "food-effect"? I suppose additional > eating will not rise resistance, rather change it. I figure one food effect, but you could have different resistences. ie, if you eat something that gives cold res +50 and then something that gives fire res +50, you would have both, but if you ate two things of cold res +50, you still only get cold res +50. > > o How much resistance do we actually hand out? Taking the exact value > from the flesh is a very bad idea. Even low level stuff like "beholder's > tongue" has values up to 50%. And shouldn't there be more benefit from > a "Dread's eye" than from a "beholder's tongue"? > I think we should make value dependant on level difference between > flesh<->player. (Flesh should inherit level from the killed monster > for that purpose.) It doesn't make sense to me to make it a level diff between flesh and player. What, at higher levels your body is somehow immune? At higher levels, the usefulness will be lessened in any case, simply because the player probably already has lots of good resistences. Ideally, the resistence values on the flesh objects should somewhat match the difficulty of the monster. So that dreads tongue would have more resistence than that beholder tongue. This makes the eating code easier. It probably wouldn't be too terrible - that low level stuff wouldn't have a high resistence, so it would get destroyed easier by spells and whatnot, but at the same time, because it is lower level, it is almost certainly more common. I would probably say as a rough guess, max bonus would be 25% - thats useful, not not really incredible. > o What about duration? Mabye fix, maybe level dependant... > We could eventually make the duration shorter if the player > already has a lot of resistance in that cathegory, for additional > balancing. > That way, flesh would be great help for low levels and "hard races", > but less help for the high level freaks. > Bad point: We'd need to adjust duration when the player changes > equipment. Or we calculate it independand every tick, a bit like > digestion. My initial thought would be duration is based on the food value of the flesh. This may mean some flesh is simply less useful (eyes for example). There could be a field in the flesh item itself which contains duration, so special flesh items for some monsters could override this simplistic default. I don't really want to try and adjust it by the characters current resistences - that is just a lot of work (whenever player changes equipment, we once again need to re-evaluate). And with PR, you get less benefit as your resistences get higher. > > Note if we do it via special food effects, then presumably the benefits > > would be given to everyone equally, as you could still stack it with > > the protection spell. It would basically mean that you could get a bit > > more protection by carrying around appropriate food, but with PR, this > > probably isn't a really big deal. After all, if you know what your > > about to face, you do the same thing by equipping the appropriate items > > with the right protections. > > That very much depends on the amount of resistance flesh items give. > If the value is too high, it could be a serious blow to balance. > Don't forget: I can wear all my equipment AND cast protection spells > AND eat flesh items. Right, but you get diminishing returns. If you already have 6 items that give you resist fire 30, eating that bit of flesh isn't going to get you a lot. Yes, it will mean that you may not need to find as many protection devices and wear them all at the same time. OTOH, carrying around all the different types flesh may not be a winning proposition - most flesh is pretty heavy, and to carry around sufficient quantities of the various types would add a bit of weight to the character - certainly more so than rings, scrolls and amulets do (which you can then select to choose your different resistences.) I would still like to add some rot factor to flesh, so it doesn't last forever (like the demon icor for example). To simplify this, perhaps only flesh in the players inventory or container rots, so you don't need to worry about grabbing all the flesh on the ground (this can be rationalized that the player is not properly storing it, while most dungeons are cool so it stays good longer). To prevent issues of having 20 flesh items that are the same save for a slight difference in their rot timing, flesh items with close rot values could be merged, taking the shortest of the group (one contaminates the other basically). Perhaps add an icebox container type that reduces rot speed but has a limited duration so that players can still get ingredients out of the dungeon for alchemy. Adding rotting to flesh would also reduce the usefulness some. This is certainly a post 1.0 idea, so would presumably have a while to balance. My general guess is that there will be some mods made after 1.0 that will really shift balance around, requiring tuning. From mwedel at scruz.net Sat Apr 7 19:23:36 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:00:25 2005 Subject: [CF-Devel] New food eating References: <000001c0bfa3$9b2d8500$d6b8fea9@kyle> Message-ID: <3ACFAF88.F29456EF@scruz.net> > > Hey, you should ask before making such fundamental changes! > Now food is healing potions for free, that is not at all okay IMHO. > And how do you want to "fix" this? The "fix" is not allowing players > to eat more than the stomache can hold. > I was perfectly happy with how it used to work. Actually, this change should not have been made at this time. THE ONLY CHANGES THAT SHOULD BE GETTING CHECKED IN NOW ARE CHANGES THAT FIX BUGS! This is the case until 1.0 comes out. I'm trying to fix all the bugs so that 1.0 will be relatively bug free, but any change, no matter how small, has the potential to introduce some bug/issue. Now granted, not all the changes I have made recently fall into this category. But looking over the changelog, all but one of the changes I have done since 0.97.0 fall into the bug fix category (one that doesn't is the naming of spellbooks based on level). From mwedel at scruz.net Sat Apr 7 19:25:50 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:00:25 2005 Subject: [CF-Devel] strange bug 2 - any ideas? References: Message-ID: <3ACFB00E.F4B4A66C@scruz.net> As a general note - the log messages produced by the server are generally not very useful for tracking down bugs unless the bug is something the server caught and exited in (ie, couldn't find some critical map or the like). If the error is SIGSEGV or SIGBUS, then basically the only way to debug it is through the debugger. From mwedel at scruz.net Sat Apr 7 19:33:02 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:00:25 2005 Subject: [CF-Devel] object movers References: <200104061953.f36Jrkj24508@bear.cs.dartmouth.edu> Message-ID: <3ACFB1BE.91A3A7C1@scruz.net> Preston Crow wrote: > > Is there really any fundamental difference between a mover and a teleporter? Yes - a mover can only move the object to an adjacent space, while a teleporter can move the object to any space, and potentially to another map I believe. > > I could probably make a good argument for a teleporter with all the same > options for selecting what gets teleported. Is there really any reason to > have a separate object? As you said, it is rather subjective. However, I find it preferable to look at a map someone else did, look at the archetype, and know 'hey - thats a mover - it moves the player one space'. A simple solution here would be to have a function like 'find_mover_object_match' or the like, which takes a teleporter/mover/exit (and potentially more, like checkers), and uses the information in the object we are matching against to see if a matching object on the space exists, and if so, return that object. Note that many objects have very similiar code (food vs flesh). But they can still be seperate. The problem with a 'super mover' is basically you probably need a flag in the object which says what it does, ie, does it shift the object based onthe direction, or teleport them to another space? You could have defaults (if the destination for teleporter type stuff is zero, then move, etc), but that gets messy. And if you need a flag or the like within the object to say what to do, why not just use the object type as the flag effectively? Just because the object types differ does not mean all the code has to be replicated - good use of functions and if statements can deal with that. From dnh at hawthorn.csse.monash.edu.au Sat Apr 7 20:22:36 2001 From: dnh at hawthorn.csse.monash.edu.au (dnh) Date: Thu Jan 13 18:00:25 2005 Subject: [CF-Devel] Grump Message-ID: I would like to point out, that many game changes are being made (see peterms recent change to food weight). I consider that a fairly major change, and yet no one even raises an eye brow. Now that I make a small change that has an EASILY fixed bug every cracks the shits. I personally consider it a bug that you CAN'T eat food even when you are hungry simply because you aren't hungry enough. If you are a troll, with two rings of war, your food goes down so fast you don't get a chance to wait around for it to get below 500, you wanna be able to down it when ever you can. I asked peterm about this change, and showed him what I wanted to do. Then I tested it on my own server, it works fine. So I say " okay, im commiting it now" and that gets the ok. It was not a major change, I removed one return; and edited two messages. Balance wise, only the hp gained is a bug and I sent a message saying I knew of its existance (I realised after I had commited) but did not know how to do it. Then I get all sorts of RUDE messages like "how could he do that?" and "You should have asked me first". I believe I am given the right to make small changes and this is a small change, that has a bug that needs to be fixed. I checked with peterm, who i believe has the right to okay something going in, and thus I preceded. In future if you have a problem with a change, DO NOT be rude it is not a good way to solve a problem. DO NOT repeat something I already know, don't rush in guns ablaze, I knew the problem no point shouting at me to fix something I don't know how to fix. Now I am grumpy and defn not in the mood to make any fixes today, so what have we achieved? Remove my change, I don't really care, I thought it would make the game more fun and sensible, if you want to eat you can eat any time that makes sense to me. I didn't think it would make that much of a change to game play, and most players wouldn't even know of its existance yet. Yours grumpily, dnh ps. I often have problems with changes, but I don't ever run about telling people to fix this or else. I mention to the person what my problem with it is, and usually it is either explained to me, or fixed. I ask for mutual respect. From mwedel at scruz.net Sat Apr 7 20:24:17 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:00:25 2005 Subject: [CF-Devel] server crash References: <200104061611.f36GBEo23458@bear.cs.dartmouth.edu> Message-ID: <3ACFBDC1.11CF7327@scruz.net> Preston Crow wrote: > > > Now it would not be hard to extend that script to also do something like: > > gdb --command=/some/file server/crossfire core > /some/other/file > > > > where the --command file lists the commands you want gdb to do (probably where, > >q). I'm not sure if I would want to default crossloop scripts to do this - > >after all, gdb isn't installed on every system. > > How about a separate 'crossloop-debug' script? > > Or have the regular script check to see if gdb is present and only run it > on the core file if it is? I'm actually not sure of the usefulness of this. Yes, it gives the administrator some quick feedback on the crash. But realisticly, if the admin wants to really debug and fix the problem, they will almost certainly want more than just the coredump, and so will run the debugger interactively. Sometimes, I'm able to figure the cause of a crash just by a stack trace, but usually not (in cases where I can, there is usually a pretty obvious problem in the code) If your really concerned about this, do what I do on tavern - run the program under gdb. Sure, it if crashes, it doesn't respawn, but this lets me do very thorough debugging. From peterm at alfven.EECS.Berkeley.EDU Sat Apr 7 20:56:59 2001 From: peterm at alfven.EECS.Berkeley.EDU (Peter Mardahl) Date: Thu Jan 13 18:00:25 2005 Subject: [CF-Devel] Grump In-Reply-To: Your message of "Sun, 08 Apr 2001 11:22:36 +1000." Message-ID: <200104080157.f381uxU03035@alfven.EECS.Berkeley.EDU> > I would like to point out, that many game changes are being made (see > peterms recent change to food weight). I consider that a fairly major > change, and yet no one even raises an eye brow. Now that I make a small > change that has an EASILY fixed bug every cracks the shits. Well, I have to admit I forgot about the code freeze. The "food lightening" change I made was therefore out-of-line, and I was wrong to do it. However, the change to reduce the performance impact of multiple burnouts and firetrails was legitimate. > ever you can. I asked peterm about this change, and showed him what I > wanted to do. Then I tested it on my own server, it works fine. So I say > " okay, im commiting it now" and that gets the ok. I did do as DB said: I forgot about the code freeze, and being able to eat food and waste some seemed like a fine idea to me. > how to do it. Then I get all sorts of RUDE messages like "how could he do > that?" and "You should have asked me first". I believe I am given the Well, DB, I think a thicker skin is called for at this point. The fast-healing-bug really DOES need to be fixed, and the smallness of a change is sometimes in the eyes of the beholder, i.e., you and me vs. others. But even AV agrees that the change is OK so long as we remove the fast-healing bug. So the criticism about the bug is justified, and complaints about making a change during the code freeze are also justified, and I accept part of the blame because I encouraged you to do it! (We've got to encourage new developers, eh?) To address another point, yes, in general, those of us with CVS access *are* allowed to make small changes at our discretion. Everything doesn't have to be discussed to death, and I truly think it'll be uncontroversial to put this into effect provided we remove the fast-healing-bug. PeterM From mwedel at scruz.net Sat Apr 7 21:17:12 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:00:25 2005 Subject: [CF-Devel] Grump References: Message-ID: <3ACFCA28.866E5C78@scruz.net> Don't feel singled out. I just took that change to use as a reminder to all developers. There has been a lot more checkins recently which IMO should not be getting checked in right now. The determination of what is a bug, and whether it should be fixed now is pretty arbitrary. I've certainly fixed some things which were bugs, but could have existed in 1.0 without any real harm (lack of spell level for magic bullet for example). That said, there are a few more bugs I want to fix - at that point, I would think we're ready for 1.0, but it seems that I get a lot more bug reports on real versions than CVS snapshots, so will probably still roll out a 0.98.0. From mwedel at scruz.net Sat Apr 7 21:44:33 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:00:25 2005 Subject: [CF-Devel] Arrow bug References: <20010405145837.A22215@crystal> Message-ID: <3ACFD091.D71FBAF5@scruz.net> "H. S. Teoh" wrote: > > I just found a rather funny bug: > > 1) get a longbow (not sure if this happens with ordinary bows) and arrow, > and make sure you have poor wc > 2) wear some armour with very good ac > 3) fire an arrow at yourself and step away > > Now you're created an infinitely travelling arrow that stays in one spot. > Step on it and it will start trying to hit you. If your ac is high enough, > it will infinitely miss you. Fixed in CVS. maybe it shouldn't have been fixed, as it would create an interesting way to make traps. Now theres an idea for the rogues - let them create traps, and when a monster is killed by one, they get the exp for it (and rogues can pass over their own traps safely). From mwedel at scruz.net Sat Apr 7 21:58:59 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:00:25 2005 Subject: [CF-Devel] container overstuffing References: <200104042154.f34Lsnv18874@bear.cs.dartmouth.edu> Message-ID: <3ACFD3F3.1E00849B@scruz.net> Ok. I've fixed this in CVS. Preston Crow wrote: > > I like this one, but I guess it really should be fixed. > > When you pickup an item that would normally go in a container, and there is > some space available, it will put it in the container, even if the result > is a container exceeding capacity. Or at least, it usually does this. If > you pick up a specific count, it won't. > > --PC > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel From michael.toennies at nord-com.net Sat Apr 7 22:02:44 2001 From: michael.toennies at nord-com.net (Michael Toennies) Date: Thu Jan 13 18:00:25 2005 Subject: [CF-Devel] strange bug 3 Message-ID: rying to load map /home/unitel/cf/crossfire/share/crossfire/maps/Lake_Country/snake_pit/snakep it_2. load_original_map: /Lake_Country/snake_pit/snakepit_2 (0) Change object (Nurlin, the dwarven priest) without other_arch error. Change object (Kasnuk, the high priest) without other_arch error. Change object (Nurlin, the dwarven priest) without other_arch error. Change object (Kasnuk, the high priest) without other_arch error. Change object (Nurlin, the dwarven priest) without other_arch error. Change object (Kasnuk, the high priest) without other_arch error. Change object (Nurlin, the dwarven priest) without other_arch error. Change object (Kasnuk, the high priest) without other_arch error. Change object (Nurlin, the dwarven priest) without other_arch error. Change object (Kasnuk, the high priest) without other_arch error. Saving map /dragonisland/hangar2 Change object (Nurlin, the dwarven priest) without other_arch error. Change object (Kasnuk, the high priest) without other_arch error. Change object (Nurlin, the dwarven priest) without other_arch error. Change object (Kasnuk, the high priest) without other_arch error. Change object (Nurlin, the dwarven priest) without other_arch error. Change object (Kasnuk, the high priest) without other_arch error. Change object (Nurlin, the dwarven priest) without other_arch error. Change object (Kasnuk, the high priest) without other_arch error. Change object (Nurlin, the dwarven priest) without other_arch error. Change object (Kasnuk, the high priest) without other_arch error. Change object (Nurlin, the dwarven priest) without other_arch error. Change object (Kasnuk, the high priest) without other_arch error. Change object (Nurlin, the dwarven priest) without other_arch error. Change object (Kasnuk, the high priest) without other_arch error. Change object (Nurlin, the dwarven priest) without other_arch error. Change object (Kasnuk, the high priest) without other_arch error. Change object (Nurlin, the dwarven priest) without other_arch error. Change object (Kasnuk, the high priest) without other_arch error. Change object (Nurlin, the dwarven priest) without other_arch error. Change object (Kasnuk, the high priest) without other_arch error. Change object (Nurlin, the dwarven priest) without other_arch error. Change object (Kasnuk, the high priest) without other_arch error. Change object (Nurlin, the dwarven priest) without other_arch error. Change object (Kasnuk, the high priest) without other_arch error. Change object (Nurlin, the dwarven priest) without other_arch error. Change object (Kasnuk, the high priest) without other_arch error. Change object (Nurlin, the dwarven priest) without other_arch error. Change object (Kasnuk, the high priest) without other_arch error. Change object (Nurlin, the dwarven priest) without other_arch error. Change object (Kasnuk, the high priest) without other_arch error. Change object (Nurlin, the dwarven priest) without other_arch error. Change object (Kasnuk, the high priest) without other_arch error. Change object (Nurlin, the dwarven priest) without other_arch error. Change object (Kasnuk, the high priest) without other_arch error. Change object (Nurlin, the dwarven priest) without other_arch error. Change object (Kasnuk, the high priest) without other_arch error. Change object (Nurlin, the dwarven priest) without other_arch error. Change object (Kasnuk, the high priest) without other_arch error. Change object (Nurlin, the dwarven priest) without other_arch error. Change object (Kasnuk, the high priest) without other_arch error. Change object (Nurlin, the dwarven priest) without other_arch error. Change object (Kasnuk, the high priest) without other_arch error. Change object (Nurlin, the dwarven priest) without other_arch error. Change object (Kasnuk, the high priest) without other_arch error. Change object (Nurlin, the dwarven priest) without other_arch error. Change object (Kasnuk, the high priest) without other_arch error. Change object (Nurlin, the dwarven priest) without other_arch error. Change object (Kasnuk, the high priest) without other_arch error. Change object (Nurlin, the dwarven priest) without other_arch error. Change object (Kasnuk, the high priest) without other_arch error. Change object (Nurlin, the dwarven priest) without other_arch error. Change object (Kasnuk, the high priest) without other_arch error. Change object (Nurlin, the dwarven priest) without other_arch error. Change object (Kasnuk, the high priest) without other_arch error. Change object (Nurlin, the dwarven priest) without other_arch error. Change object (Kasnuk, the high priest) without other_arch error. Change object (Nurlin, the dwarven priest) without other_arch error. Change object (Kasnuk, the high priest) without other_arch error. Change object (Nurlin, the dwarven priest) without other_arch error. Change object (Kasnuk, the high priest) without other_arch error. Saving map /city/temples/sorig Change object (Nurlin, the dwarven priest) without other_arch error. Change object (Kasnuk, the high priest) without other_arch error. Change object (Nurlin, the dwarven priest) without other_arch error. Change object (Kasnuk, the high priest) without other_arch error. Change object (Nurlin, the dwarven priest) without other_arch error. Change object (Kasnuk, the high priest) without other_arch error. Change object (Nurlin, the dwarven priest) without other_arch error. Change object (Kasnuk, the high priest) without other_arch error. Change object (Nurlin, the dwarven priest) without other_arch error. Change object (Kasnuk, the high priest) without other_arch error. Change object (Nurlin, the dwarven priest) without other_arch error. Change object (Kasnuk, the high priest) without other_arch error. Change object (Nurlin, the dwarven priest) without other_arch error. Change object (Kasnuk, the high priest) without other_arch error. Change object (Nurlin, the dwarven priest) without other_arch error. Change object (Kasnuk, the high priest) without other_arch error. Change object (Nurlin, the dwarven priest) without other_arch error. Change object (Kasnuk, the high priest) without other_arch error. Change object (Nurlin, the dwarven priest) without other_arch error. Change object (Kasnuk, the high priest) without other_arch error. Change object (Nurlin, the dwarven priest) without other_arch error. Change object (Kasnuk, the high priest) without other_arch error. Change object (Nurlin, the dwarven priest) without other_arch error. Change object (Kasnuk, the high priest) without other_arch error. Change object (Nurlin, the dwarven priest) without other_arch error. Change object (Kasnuk, the high priest) without other_arch error. Change object (Nurlin, the dwarven priest) without other_arch error. Change object (Kasnuk, the high priest) without other_arch error. Change object (Nurlin, the dwarven priest) without other_arch error. Change object (Kasnuk, the high priest) without other_arch error. Change object (Nurlin, the dwarven priest) without other_arch error. Change object (Kasnuk, the high priest) without other_arch error. From michael.toennies at nord-com.net Sat Apr 7 22:03:48 2001 From: michael.toennies at nord-com.net (Michael Toennies) Date: Thu Jan 13 18:00:25 2005 Subject: [CF-Devel] map bug Message-ID: ad_original_map: /city/temples/gorokh (0) Saving map /random/0000000000000001 load_original_map: /styles/floorstyles/lightdirt (8) load_original_map: /styles/wallstyles/dungeon2 (8) load_original_map: /styles/doorstyles/vdoors/door_look (8) load_original_map: /styles/doorstyles/hdoors/door_look (8) load_original_map: /styles/exitstyles/up/sstair (8) load_original_map: /styles/exitstyles/down/sstair (8) load_original_map: /styles/specialmaps/turrettrap (8) load_original_map: /styles/monsterstyles/demon/demon_1 (8) load_original_map: /styles/decorstyles/religious_gorokh (8) BUG: process_events(): Object lbulletwall_4 has no speed, but is on active list BUG: process_events(): Object lbulletwall_3 has no speed, but is on active list BUG: process_events(): Object lbulletwall_2 has no speed, but is on active list BUG: process_events(): Object lbulletwall_5 has no speed, but is on active list BUG: process_events(): Object lbulletwall_1 has no speed, but is on active list BUG: process_events(): Object lbulletwall_6 has no speed, but is on active list BUG: process_events(): Object lbulletwall_7 has no speed, but is on active list BUG: process_events(): Object lbulletwall_8 has no speed, but is on active list Saving map /random/0000000000000000 Saving map /dragonisland/hangar Saving map /dragonisland/stoneville make_path_tofile /home/unitel/cf/crossfire/var/crossfire/players/Son-Goten/Son-Goten.pl... Saving map /santo_dominion/town Saving map /world/world_a1 From michael.toennies at nord-com.net Sat Apr 7 22:04:53 2001 From: michael.toennies at nord-com.net (Michael Toennies) Date: Thu Jan 13 18:00:25 2005 Subject: [CF-Devel] map bug Message-ID: ake_path_tofile /home/unitel/cf/crossfire/var/crossfire/players/Khalad/_city_apartment_apart ments... Saving map /home/unitel/cf/crossfire/var/crossfire/players/Khalad/_city_apartment_apart ments Saving map /city/city Saving map /brittany/Brest/brest.food Fixed inventory in Khalad (71726 -> 71736) Saving map /city/temples/gorokh make_path_tofile /home/unitel/cf/crossfire/var/crossfire/players/AngeluS/AngeluS.pl... BUG: SK_level(arch rune_burning_hands, name Rune of Burning Hands): level <= 0 BUG: SK_level(arch rune_burning_hands, name Rune of Burning Hands): level <= 0 BUG: SK_level(arch rune_burning_hands, name Rune of Burning Hands): level <= 0 BUG: SK_level(arch rune_burning_hands, name Rune of Burning Hands): level <= 0 BUG: SK_level(arch rune_burning_hands, name Rune of Burning Hands): level <= 0 BUG: SK_level(arch rune_burning_hands, name Rune of Burning Hands): level <= 0 BUG: SK_level(arch rune_burning_hands, name Rune of Burning Hands): level <= 0 BUG: SK_level(arch rune_burning_hands, name Rune of Burning Hands): level <= 0 BUG: SK_level(arch rune_burning_hands, name Rune of Burning Hands): level <= 0 BUG: SK_level(arch rune_burning_hands, name Rune of Burning Hands): level <= 0 load_original_map: /styles/specialmaps/abattoir (8) load_original_map: /styles/monsterstyles/demon/demon_2 (8) Trying to load map /home/unitel/cf/crossfire/var/crossfire/players/Khalad/_city_apartment_apart ments. load_original_map: /home/unitel From mwedel at scruz.net Sat Apr 7 22:25:01 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:00:25 2005 Subject: [CF-Devel] strange bug 3 References: Message-ID: <3ACFDA0D.3C5E4B40@scruz.net> This is a bug in the map - those two objects have changing 1 set for some reason, which results in these messages. I've fixed this in CVS. Michael Toennies wrote: > > rying to load map > /home/unitel/cf/crossfire/share/crossfire/maps/Lake_Country/snake_pit/snakep > it_2. > load_original_map: /Lake_Country/snake_pit/snakepit_2 (0) > Change object (Nurlin, the dwarven priest) without other_arch error. > Change object (Kasnuk, the high priest) without other_arch error. > Change object (Nurlin, the dwarven priest) without other_arch error. > Change object (Kasnuk, the high priest) without other_arch error. From michael.toennies at nord-com.net Sat Apr 7 23:00:12 2001 From: michael.toennies at nord-com.net (Michael Toennies) Date: Thu Jan 13 18:00:25 2005 Subject: [CF-Devel] map bug In-Reply-To: Message-ID: This bug is very common with runes and door traps. I got in a 250k log about 10-20 of this in different places. > > ake_path_tofile > /home/unitel/cf/crossfire/var/crossfire/players/Khalad/_city_apart > ment_apart > ments... > Saving map > /home/unitel/cf/crossfire/var/crossfire/players/Khalad/_city_apart > ment_apart > ments > Saving map /city/city > Saving map /brittany/Brest/brest.food > Fixed inventory in Khalad (71726 -> 71736) > Saving map /city/temples/gorokh > make_path_tofile > /home/unitel/cf/crossfire/var/crossfire/players/AngeluS/AngeluS.pl... > BUG: SK_level(arch rune_burning_hands, name Rune of Burning > Hands): level <= > 0 > BUG: SK_level(arch rune_burning_hands, name Rune of Burning > Hands): level <= > 0 > BUG: SK_level(arch rune_burning_hands, name Rune of Burning > Hands): level <= > 0 > BUG: SK_level(arch rune_burning_hands, name Rune of Burning > Hands): level <= > 0 > BUG: SK_level(arch rune_burning_hands, name Rune of Burning > Hands): level <= > 0 > BUG: SK_level(arch rune_burning_hands, name Rune of Burning > Hands): level <= > 0 > BUG: SK_level(arch rune_burning_hands, name Rune of Burning > Hands): level <= > 0 > BUG: SK_level(arch rune_burning_hands, name Rune of Burning > Hands): level <= > 0 > BUG: SK_level(arch rune_burning_hands, name Rune of Burning > Hands): level <= > 0 > BUG: SK_level(arch rune_burning_hands, name Rune of Burning > Hands): level <= > 0 > load_original_map: /styles/specialmaps/abattoir (8) > load_original_map: /styles/monsterstyles/demon/demon_2 (8) > Trying to load map > /home/unitel/cf/crossfire/var/crossfire/players/Khalad/_city_apart > ment_apart > ments. > load_original_map: /home/unitel > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > From michael.toennies at nord-com.net Sat Apr 7 23:02:05 2001 From: michael.toennies at nord-com.net (Michael Toennies) Date: Thu Jan 13 18:00:25 2005 Subject: [CF-Devel] Arrow bug In-Reply-To: <3ACFD091.D71FBAF5@scruz.net> Message-ID: We have since ages these skill "set traps" or whatever. In yarids house in scorn you can find the skill scroll in a hidden place. Ever this skill was really implemented? > > "H. S. Teoh" wrote: > > > > I just found a rather funny bug: > > > > 1) get a longbow (not sure if this happens with ordinary bows) > and arrow, > > and make sure you have poor wc > > 2) wear some armour with very good ac > > 3) fire an arrow at yourself and step away > > > > Now you're created an infinitely travelling arrow that stays in > one spot. > > Step on it and it will start trying to hit you. If your ac is > high enough, > > it will infinitely miss you. > > Fixed in CVS. maybe it shouldn't have been fixed, as it would create an > interesting way to make traps. > > Now theres an idea for the rogues - let them create traps, and > when a monster > is killed by one, they get the exp for it (and rogues can pass > over their own > traps safely). > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > From mwedel at scruz.net Sat Apr 7 23:09:40 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:00:26 2005 Subject: [CF-Devel] map bug References: Message-ID: <3ACFE484.88749293@scruz.net> > BUG: process_events(): Object lbulletwall_4 has no speed, but is on active > list I see the problem with this one, and have an idea how to fix it, but sort of want to wait, as if it doesn't do the right thing, it will break all sorts of things. What I believe is happening is that the lbulletwall's by default have speed, and thus are on the active list. So when when loading the map, the loader sees that, sees the object has speed, and gets put on the active list. However, for some of these random maps, the objects have zero speed. by default, if the map is a style map, we don't call update_ob_speed, so the objects are not on the active list (no reason to process these objects that no one ever sees). This works as expected when the object has speed, and thus is not on the list, but doesn't do as expected when we want to remove the object from the active list. This is not really hard to fix, but isn't IMO a really important bug, and I'm a little fearful of something getting broken. > BUG: SK_level(arch rune_burning_hands, name Rune of Burning Hands): level <= > 0 Its easy to see where these messages come from, but harder to know the cause. My guess is that it may be a map bug (runes on the map, but no level set in the runes). From mwedel at scruz.net Sun Apr 8 01:07:15 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:00:26 2005 Subject: [CF-Devel] Crossfire 0.98.0 released. Message-ID: <3AD00013.520B3DCB@scruz.net> Crossfire 0.98.0 has been released. Once again, unless serious bugs are detected, this will be the last release before 1.0. It seems that that lots of bugs get reported off releases of official versions and not from CVS snapshots. Main changes: Mostly just a bunch of small bug fixes. List is at the end of the file. NOTE TO MIRROR SITES: The primary site (ftp.scruz.net) has limited download bandwidth per day. You can also get this release off of sourceforge.net. Files released for this version: sums (bsd) filename 13320 1549 crossfire-0.98.0.arch.tar.bz2 23828 1832 crossfire-0.98.0.arch.tar.gz 39314 2789 crossfire-0.98.0.maps.tar.bz2 46406 4017 crossfire-0.98.0.maps.tar.gz 17403 2683 crossfire-0.98.0.tar.bz2 62663 3012 crossfire-0.98.0.tar.gz 33843 239 crossfire-client-0.98.0.tar.gz Sums (md5) b633eba0e53234710c6d15ad4b04d8be crossfire-0.98.0.arch.tar.bz2 f004c95912e3ab0b71692f63a01db24c crossfire-0.98.0.arch.tar.gz 075ee95d823ea78f965867d6313ece42 crossfire-0.98.0.maps.tar.bz2 ae7cf5c6c6d554b647a1cf0a9e8014ce crossfire-0.98.0.maps.tar.gz 00000bab0b2e114e80d7f9c19fc87986 crossfire-0.98.0.tar.bz2 06b91c418538c06d8ec5a195bb105c0b crossfire-0.98.0.tar.gz 95c07464cfbc980ec8eccffeb4834259 crossfire-client-0.98.0.tar.gz crossfire-client-0.98.0 is the client (X11) distribution - standard X11 and gtk interfaces are provided. crossfire-0.98.0.tar.{gz/bz2} contains the server code with prebuilt archetype and image files. crossfire-0.98.0.arch.tar.{gz/bz2} contains the unpacked archetype changes. This is not needed if you only want to compile the server and play the game. crossfire-0.98.0-maps.tar.{gz/bz2} contains the maps. This is needed with the server distribution. FOR FIRST TIME USERS: You will only need the appropriate server, map and client file. You do not need the arch file. If you are a first time user, you may want the doc file unless you are using a web based player referance. If you just want to play the game at some remote server, you need the client and perhaps some version of the doc file. Crossfire is avaible on the following ftp sites Primary: ftp://ftp.scruz.net:/users/mwedel/public (165.227.192.254) ftp://ftp.sourceforge.net:/pub/sourceforge/crossfire (64.28.67.101) ftp://ftp.ifi.uio.no:/pub/crossfire (129.240.64.44) Secondary: ftp://ftp.real-time.com/pub/games/crossfire (206.10.252.12) ftp://ftp.cs.city.ac.uk:/pub/games/crossfire/ ftp://ftp.sunet.se:/pub/unix/games/crossfire (130.238.127.3) ftp://ftp.cs.titech.ac.jp:/pub/games/crossfire ftp://mirror.aarnet.edu.au/games/roguelike/crossfire/ ftp://crossfire.futt.org//pub/crossfire I uploaded this version to just ftp.scruz.net - it should be on the other ftp sites in a short time. Mark Wedel mwedel@scruz.net ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Changes: Client: Changes for 0.98.0: item_types,item_types.h: Change matching for sword - hopefully this should fix problems with dancing sword spellbooks. MSW 2001/04/06 gx11.c, item.c: move animations of the look window to the client. All the necessary was already being sent to the client - it was just needed for the client to use this information. Also remove some #if 0 code from gx11.c. MSW 2001/03/28 item.c: set_item_values - only resort items based on name if the name has changed. This fixes a problem with items moving around in the inventory if you lock/apply/unapply/unlock them. MSW 2001/03/23 ------------------------------------------------------------------------------ Server: Changes for 0.98.0: server/skills.c: Modify inscription so that when inscribing cleric spells, it reduces grace. Before, reduced mana no matter the type of spell. server/c_object.c: Fix bug in pick_up where it was not using the right count for picking up objects if the player did not specify one. This allowed players to put objects into containers that should not really fit. server/player.c: Don't let players shoot arrows at themself. Also, minor changes to use new_draw_info_format. server/swap.c: If recycle temp maps, don't save out random maps to get recycled. MSW 2001/04/07 PeterM 2001/04/06: include/libproto.h common/object.c server/apply.c server/spell_util.c Added a new function: instead of stacking many burnout or firetrail objects, only 1 per square is added. Real reduction in server overhead. No reduction in cosmetic effect. common/porting.c: Fix compile warnings/bugs introduced by Win32 changes. server/time.c: Modify move_player_mover so that it determines direction of the mover and then process accordingly, as well as formatting changes. server/c_object.c: modify examine so that it properly shows info about magic bullet spell books. MSW 2001-04-05 common/item.c: Modify identify function to clear the NO_SKILL_IDENT flag so objects will now merge. Also, once the object has been identified, the no_skill_ident doesn't have meaning anymore. MSW 2001-04-03 server/c_object: Modify examine command to only be able to examine valid objects, and not whatever is on top of the space, which may be insivisible. MSW 2001-04-01 include/sproto.h, server/c_wiz.c server/main.c server/player.c socket/loop.c: Modify leave function to take a second parameter that determines if it should print a message about the player leaving the game or not. Proper use of this prevents duplicate XXX left the game messages. MSW 2001-03-29 common/image.c, include/define.h, include/global.h: Add empty_face structure and appropriate code to initialize it. This is used for the server side look selection. include/newserver.h: Add NUM_LOOK_OBJECTS to control number of look objects to send at any one time. add look_position field to the newsocket structure. server/move.c: clear look position as player moves. server/player.c: initalize look_position element in structure. socket/item.c: modify esrv_draw_look to sne NUM_LOOK_OBJECTS at any one time, and to also send pseudo objects that lets the player scroll up and down . modify ApplyCmd so that if it detects the application of one pseudo objects to adjust the look_position. MSW 2001-03-29 common/readable.c: Name spellbooks based on level of spell, and not just randomly. Patch by Preston Crow, applied by Mark Wedel 2001-03-29 configure, configure.in, include/autoconf.h, includes.h: add check for time.h and include it if we find it. socket/item.c: esrv_move_object - have it check to see if the object is already on the ground before we try to re-drop it. Likewise, check to see if it is already in players inventory before we try to pick it up. common/object.c: Don't send face updates to the client or make the space as needing to be redrawn. Client now deals with animation of the look window on its own. utils/(metaserver.pl crossloop add_throw.perl crossloop.pl) lib/(Makefie.in, checkarch.pl collect.pl xpmtopix.pl) - - deleted from CVS - '.in' versions of these files now exist and the real versions are created as part of the configure process. Update Makefile.in to reflect this change. MSW 2001/03/28 common/object.c: have update_position just update the flag that the server needs to send the look window to the client and don't send the item at this point, as sending the look will do that. server/main.c: process_players1: Remove call to draw (which updates the client map) - the handle newclient in socket/loop.c already does this and there is no reason to send multiple instances of the same map. MSW 2001/03/23 server/c_object.c: drop_object function: send delete item to client as item is dropped. This fixes a problem of phantom objects in the inventory. Unrelated change to not call esrv_send_item for objects that are dropped - esrv_draw_look will get called later on and will update this at that time. MSW 2001/03/23 server/c_object.c: Update the return value for some matches - they function was returning immediately when it got a match, but did not give them a high match value, so searching for 'key ring' used to return a match value of 6 or so on the key ring, but a 14 on a key. common/object.c: Modify find_free_spot to call arch_out_of_map so that it properly deals with multipart objects. server/main.c: Fix enter_map so that we first use the golem (and not player) when calling find_free_spot. Also, modify code so that it properly updates coordinates of the multipart golem. MSW 2001/03/20 server/skills.c: Fix orate so that we check for a positive chance (and just not nonzero chance) for successful oration. Due to adjustments, at low levels, the oratory chance can be negative. MSW 2001/03/20 server/spell_effect.c: Change cast_change_attr to find an enemy (and not friend) when casting the curse spell. MSW 2001/03/20 server/apply.c: Increase size of buf to be a HUGE_BUF to very long item names don't cause a stack overflow. MSW 2001/03/20 common/object.c: Modify update_position so that we don't show invisible players to other players. MSW 2001/03/20 From michael.toennies at nord-com.net Sun Apr 8 08:25:26 2001 From: michael.toennies at nord-com.net (Michael Toennies) Date: Thu Jan 13 18:00:26 2005 Subject: [CF-Devel] case sensitive maps names Message-ID: I noticed, that in the maps are case sensitive maps. Of course, when you entpack them on non case sensitive OS, we run in some problems. I found pup_land/ancient/mountain/Tower.1 pup_land/ancient/mountain/Tower.2 pup_land/ancient/mountain/Tower.3 pup_land/ancient/mountain/Tower.4 pup_land/ancient/mountain/Tower.B1 pup_land/lone_town/cave/B1 pup_land/lone_town/cave/B2 pup_land/lone_town/cave/B3 just false checkins? When not, please change this to a lower case name. From crossfire at suckfuell.net Sun Apr 8 07:48:28 2001 From: crossfire at suckfuell.net (Jochen Suckfuell) Date: Thu Jan 13 18:00:26 2005 Subject: [CF-Devel] Retributive Strike and Ruggilli In-Reply-To: <3ACFCA28.866E5C78@scruz.net> Message-ID: Hi! Has the prayer retributive strike been removed from Ruggilli? I have wis 27, wis lvl 40 and grace (on the altar) 602, and didn't get it after praying 20 minutes! Without this prayer, Ruggilli is quite useless, since he has denied turning (->no holy word, banishment etc.). The only effective means to get wis exp is using the avatar (size: 2x2). Bye Jochen -- Nothing is rich but the inexhaustible wealth of nature. She shows us only surfaces, but she is a million fathoms deep. -- Ralph Waldo Emerson --- eMail jochen@suckfuell.net ----- http://www.suckfuell.net/jochen/ -------- From peterm at alfven.EECS.Berkeley.EDU Sun Apr 8 13:33:54 2001 From: peterm at alfven.EECS.Berkeley.EDU (Peter Mardahl) Date: Thu Jan 13 18:00:26 2005 Subject: [CF-Devel] Retributive Strike and Ruggilli In-Reply-To: Your message of "Sun, 08 Apr 2001 14:48:28 +0200." Message-ID: <200104081833.f38IXsQ10123@alfven.EECS.Berkeley.EDU> Useless? What about flaming aura? Rage? All the cause wounds spells? diseases? Although the avatar should ABSOLUTELY be fixed. We should eliminate *all* 2x2 avatars. PeterM > Has the prayer retributive strike been removed from Ruggilli? I have wis 27, > wis lvl 40 and grace (on the altar) 602, and didn't get it after praying 20 > minutes! > > Without this prayer, Ruggilli is quite useless, since he has denied turning > (->no holy word, banishment etc.). The only effective means to get wis exp is > using the avatar (size: 2x2). > > > Bye > Jochen > > -- > Nothing is rich but the inexhaustible wealth of nature. > She shows us only surfaces, but she is a million fathoms deep. > -- Ralph Waldo Emerson > > --- eMail jochen@suckfuell.net ----- http://www.suckfuell.net/jochen/ ------- >- > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel From mwedel at scruz.net Sun Apr 8 14:34:18 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:00:26 2005 Subject: [CF-Devel] case sensitive maps names References: Message-ID: <3AD0BD3A.B9E20E9A@scruz.net> I would think this should only be a problem in cases where two different maps match to the same name because of case insensitivity (ie, a tower.1 and Tower.1 in the same dir). Looking at the pup land maps, it appears that the lower case versions are already used. the B vs b maps appear to only differ in their exit names (so that b1 links to b2, as B1 links to B2). I can not find any reference to an exit using the Tower maps, so it looks like these have already been fixed as you suggested. Of course, the real is why the capitalized versions are still around when they don't seem to be needed anymore. Michael Toennies wrote: > > I noticed, that in the maps are case sensitive maps. > > Of course, when you entpack them on non case sensitive OS, > we run in some problems. > > I found > > pup_land/ancient/mountain/Tower.1 > pup_land/ancient/mountain/Tower.2 > pup_land/ancient/mountain/Tower.3 > pup_land/ancient/mountain/Tower.4 > pup_land/ancient/mountain/Tower.B1 > > pup_land/lone_town/cave/B1 > pup_land/lone_town/cave/B2 > pup_land/lone_town/cave/B3 > > just false checkins? > When not, please change this to a lower case name. > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel From peterm at alfven.EECS.Berkeley.EDU Sun Apr 8 15:03:38 2001 From: peterm at alfven.EECS.Berkeley.EDU (Peter Mardahl) Date: Thu Jan 13 18:00:26 2005 Subject: [CF-Devel] Possible hint on mana-regen-slowing problem? Message-ID: <200104082003.f38K3cE10275@alfven.EECS.Berkeley.EDU> It may follow immediately on gaining a level in magic. The slowness persists across a save/restore cycle of the player. Wearing/unwearing items grating magic+ still effects the rate, just not as strongly. Wearing/unwearing items of armour has no effect. The player involved had a "magic +7" "regen -2". PeterM From peterm at alfven.EECS.Berkeley.EDU Sun Apr 8 18:12:33 2001 From: peterm at alfven.EECS.Berkeley.EDU (Peter Mardahl) Date: Thu Jan 13 18:00:26 2005 Subject: [CF-Devel] How can this have happened? (crashing bug) Message-ID: <200104082312.f38NCXi10584@alfven.EECS.Berkeley.EDU> Hello, I've noticed some instability on entering random maps. Sometimes it'll instantly crash. Very irritating. I caught one such crash here: #0 0x4009ad21 in __kill () from /lib/libc.so.6 #1 0x4009a996 in raise (sig=6) at ../sysdeps/posix/raise.c:27 #2 0x4009c0b8 in abort () at ../sysdeps/generic/abort.c:88 #3 0x80cc5c1 in remove_ob (op=0x8a64bd0) at object.c:1098 #4 0x80cc6f7 in remove_ob (op=0x8a774c0) at object.c:1117 #5 0x80a1676 in explosion (op=0x8a774c0) at spell_util.c:1319 #6 0x80a95ec in process_object (op=0x8a774c0) at time.c:1033 #7 0x807054f in process_events (map=0x0) at main.c:862 #8 0x8070c39 in main (argc=1, argv=0xbffff83c) at main.c:1056 More debugging info: at level 3, "op" is an arch angel, who has no map, and is removed. level 3 is at abort(); at level 4, "op" is a fireball, which is in a random map, and which is unfortunately also having its "more" pointer point to the archangel. level 4 is at remove_ob(op->more) at level 5, op is still a fireball, and it still has the invalid (op->more) is an angel. This is a full dump of the object: (gdb) p *op (gdb) p *op $21 = {contr = 0x0, next = 0x8f84de8, prev = 0x8a64bd0, active_next = 0xbffff684, active_prev = 0x8954364, below = 0x89725b4, above = 0x8b46d28, inv = 0x0, container = 0x0, env = 0x0, more = 0x8a64bd0, head = 0x8af2b10, map = 0x931c5f0, count = 345935, refcount = 0, sk_list = 0x0, name = 0x81af2b2 "fireball", title = 0x0, race = 0x0, slaying = 0x0, msg = 0x0, x = 20, y = 16, ox = 20, oy = 16, speed = 0.200000003, speed_left = -0.899999976, nrof = 0, face = 0x81a5490, direction = 0 '\000', facing = 0 '\000', type = 11 '\013', resist = { 0 }, attacktype = 6, path_attuned = 0, path_repelled = 0, path_denied = 0, material = 0, magic = 0 '\000', thrownthaco = 0 '\000', state = 1 '\001', value = 0, level = 0, last_heal = 0, last_sp = 0, last_grace = 0, last_eat = 0, invisible = 0, pick_up = 0 '\000', owner = 0x89725b4, enemy = 0x0, arch = 0x8217718, other_arch = 0x0, weight = 0, carrying = 0, flags = {10496, 1073741824, 0, 0}, ownercount = 345864, randomitems = 0x0, run_away = 0, chosen_skill = 0x0, exp_obj = 0x0, hide = 0, lights = 0x0, glow_radius = 1, move_status = 0, move_type = 0, weight_limit = 0, can_apply = 0 '\000', will_apply = 0 '\000', animation_id = 299, anim_speed = 0 '\000', last_anim = 2 '\002', stats = {Str = 0 '\000', Dex = 0 '\000', Con = 0 '\000', Wis = 0 '\000', Cha = 0 '\000', Int = 0 '\000', Pow = 0 '\000', wc = -', ac = 0 '\000', hp = 13, maxhp = 18254, sp = 0, maxsp = 0, grace = 0, maxgrace = 0, exp = 0, food = 0, dam = 11, luck = 0 '\000'}, spellitem = 0x0, expmul = 1} Those flags mean: NO_PICK FLAG_ANIMATE FLAG_FLYING And, I think... FLAG_NO_APPLY It is IN a map. Even at the top level, op->more points to the angel. So it all boils down to: why does this fireball have "op->more"? PeterM From andi.vogl at gmx.net Sun Apr 8 18:29:31 2001 From: andi.vogl at gmx.net (Andreas Vogl) Date: Thu Jan 13 18:00:26 2005 Subject: [CF-Devel] case sensitive maps names In-Reply-To: <3AD0BD3A.B9E20E9A@scruz.net> Message-ID: <000001c0c083$c5ceff60$e137fea9@kyle> Mark W. wrote: > > > > I noticed, that in the maps are case sensitive maps. > > > > Of course, when you entpack them on non case sensitive OS, > > we run in some problems. > > > > I found > > > > pup_land/ancient/mountain/Tower.1 > > pup_land/ancient/mountain/Tower.2 > > pup_land/ancient/mountain/Tower.3 > > pup_land/ancient/mountain/Tower.4 > > pup_land/ancient/mountain/Tower.B1 > > > > pup_land/lone_town/cave/B1 > > pup_land/lone_town/cave/B2 > > pup_land/lone_town/cave/B3 > > > > just false checkins? > > When not, please change this to a lower case name. Only the lower case maps are used. I dunno why, but it looks like I forgot to remove the upper-case versions from cvs some time ago. Did that now. > I would think this should only be a problem in cases where two > different maps match to the same name because of case insensitivity > (ie, a tower.1 and Tower.1 in the same dir). > > Looking at the pup land maps, it appears that the lower case versions > are already used. the B vs b maps appear to only differ in their exit > names (so that b1 links to b2, as B1 links to B2). > > I can not find any reference to an exit using the Tower maps, so it > looks like these have already been fixed as you suggested. Of course, > the real is why the capitalized versions are still around when they don't > seem to be needed anymore. We should make map (and directory) names interpreted non-case-sensitive. That way we automatically prevent conflicts. Andreas V. From mwedel at scruz.net Sun Apr 8 18:58:28 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:00:26 2005 Subject: [CF-Devel] case sensitive maps names References: <000001c0c083$c5ceff60$e137fea9@kyle> Message-ID: <3AD0FB24.167D7F56@scruz.net> Andreas Vogl wrote: > We should make map (and directory) names interpreted non-case-sensitive. > That way we automatically prevent conflicts. interperting them in case insensitive gets trickier on the unix side (the efficient way to do it would be to read the directory entries and see if we get a match, but this certainly adds overhead) However, making sure there are no conflicts should be a given (ie, no two files should match in name in a case insensitive matter) - in this way, the files can be unpacked on a system with case insensitive names and not get anything clobbered. For things like faces, treating them case insensitive would not be too hard, as once the archs and relevant face files are generated, we never have to search the directory again. From Philipp.Currlin at t-online.de Sun Apr 8 19:12:57 2001 From: Philipp.Currlin at t-online.de (Philipp Currlin) Date: Thu Jan 13 18:00:26 2005 Subject: [CF-Devel] weight of keyrings Message-ID: <3AD0FE89.7060308@epost.de> Hi The (shown) weight of keyrings does not get fixed when the keys are removed, e.g. the keyring may show a weight of 3.0 but when you open it you don't have any keys in it, or only 2 or 3 with a weight of 0.1. Removing ALL keys from the keyring and putting them back in will show the correct weight. Phil From Philipp.Currlin at t-online.de Sun Apr 8 19:25:13 2001 From: Philipp.Currlin at t-online.de (Philipp Currlin) Date: Thu Jan 13 18:00:26 2005 Subject: [CF-Devel] Retributive Strike and Ruggilli References: Message-ID: <3AD10169.6020703@epost.de> Hi We had a short look at the code of retributive strike earlier today but it seemed okay. However even after praying for more than 30 minutes with wis lvl 40 and 602 grace the player still didn't get the spell. It would be nice if someone could take a more serious look at the code of that spell please. Thanks Phil Jochen Suckfuell wrote: > Hi! > > Has the prayer retributive strike been removed from Ruggilli? I have wis 27, > wis lvl 40 and grace (on the altar) 602, and didn't get it after praying 20 > minutes! > > Without this prayer, Ruggilli is quite useless, since he has denied turning > (->no holy word, banishment etc.). The only effective means to get wis exp is > using the avatar (size: 2x2). > > > Bye > Jochen > From michael.toennies at nord-com.net Sun Apr 8 20:33:33 2001 From: michael.toennies at nord-com.net (Michael Toennies) Date: Thu Jan 13 18:00:26 2005 Subject: [CF-Devel] case sensitive maps names In-Reply-To: <3AD0FB24.167D7F56@scruz.net> Message-ID: To this issue: The really crazy one thing is, that you CAN store filenames and Directorys in windows9x and higher case intensive lie BlaBla or BLABLA - it will saved and shown on file system. Of course, it handles BLABLA as the same as BlaBla. Bad point is, when someone then save a map as Tower.1 and this can/get commited in this style (i can't see this, but there is 100% a way to do it). Well, there is always a way to make it more complicate... > Andreas Vogl wrote: > > We should make map (and directory) names interpreted non-case-sensitive. > > That way we automatically prevent conflicts. > > interperting them in case insensitive gets trickier on the unix side (the > efficient way to do it would be to read the directory entries and > see if we get > a match, but this certainly adds overhead) > > However, making sure there are no conflicts should be a given > (ie, no two files > should match in name in a case insensitive matter) - in this way, > the files can > be unpacked on a system with case insensitive names and not get anything > clobbered. > > For things like faces, treating them case insensitive would not > be too hard, as > once the archs and relevant face files are generated, we never > have to search > the directory again. > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > From the_real_tomble at hotmail.com Sun Apr 8 23:15:58 2001 From: the_real_tomble at hotmail.com (Tom Barnes-Lawrence) Date: Thu Jan 13 18:00:26 2005 Subject: [CF-Devel] Hey, slow down a bit! Message-ID: Hi, me again- I'd just like to say, that I think maybe these new releases could be a bit less frequent? When I rejoined the list around a month ago, I decided to set up a 2nd linux box as a stand alone CF server (I don't want to trample over Debian's nicely packaged old version), and set about to download 0.96.0 that had been released maybe a week or 2 earlier. It was only available on one server, the mirrors still hadn't got it by then! Having got all the files, I tried to get that P100 box to come to life. No luck. Then, 2 weeks later, out comes 0.97! Obviously, that had a lot of bugfixes since 0.96, and getting them out makes other bugs easier to spot, which is good. But then, another 2 weeks later, 0.98!! Thankfully for me, I've FINALLY sorted out the P100, and expect the latest CF to be running on it by tommorow night, so *I'm* happy... ...BUT The problem I see is, there must be a good many people who are into CF, but not *all the time*. They may get really into it for a while, then go off and do something else for a few weeks. And whilst most of the bugs sound like they're going (I'll finally get to SEE for myself now), it tends to be that certain problems aren't noticed when a system is already unstable. Now the game is approaching stability, there are people reporting connections dropping when too much happens, and such things. Even though this may be well understood by most/all of the dev-team, and has had patches to reduce the traffic, it does sound like maybe a pretty big problem, and one that could require a lot of work. .. So I guess what I'm asking is, when the game really does seem stable, can we wait more than 2 weeks before releasing V1.0?? Just to let those people who don't work on it or play it all year round check it all out thoroughly? Having BIG changes in a "stable" version to solve a serious bug is not nice for anyone. Thanks for hearing my POV, Tomble (Tom Barnes-Lawrence) PS-Whats the policy for including new mapsets right now or within the stable releases? Mine should prolly be usable some time soon... _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. From mwedel at scruz.net Sun Apr 8 23:58:44 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:00:26 2005 Subject: [CF-Devel] Hey, slow down a bit! References: Message-ID: <3AD14183.227816F2@scruz.net> Just for reference: 0.96.0 released Feb 12 0.97.0 released Mar 19 0.98.0 released April 7 The reason for the short turnaround is to simply get people to run the latest released and find out if there are any bugs so 1.0 can get released Having people running 0.97.0 for another month reporting this problem and that doesn't do any good if those have already been fixed. So it seems the only way to verify stability (and that the expected fixes do in fact really fix the problem) is to put out a new release and see what gets reported. I have no real idea how many people are running what version (I can look at the metaserver and see that information, but presumably a lot of people are running on private connections or are not reporting to the metaserver). So its really hard for me to gauge just how reliable a release is. And looking at the metaserver, with its abou 10 or so listings, show 3 running 0.96.0 or earlier. I do know that it was shortly after the release of 0.97.0 that a bunch of bugs got reported, so I do sort of base my conclusions that it takes real releases to know stability. As for time between release of 0.98 and 1.0? Ideally, just a couple weeks - it will probably depend a lot of how many bugs get reported - if there are very few bugs reported, I'll take that to mean that the release doesn't have bugs and not that people are not running it. The fact is that it seems that by and large, a lot of developers (me included) want to get a 1.0 release out soon. So the release cycle right now is sped up a bit to help this out. After 1.0 is released, I would expect it to be quite a while before there are any subsequent releases. From dnh at hawthorn.csse.monash.edu.au Mon Apr 9 06:00:01 2001 From: dnh at hawthorn.csse.monash.edu.au (dnh) Date: Thu Jan 13 18:00:27 2005 Subject: [CF-Devel] Further bugs with regen rates. Message-ID: Another bug has just been noticed and proven (by me this time). If you pray over an altar (or indeed if you pray anywhere) your hp regen rate is increased. The proof of this is that when you pray, your food goes down at an increased rate. I believe somehow praying is affecting more than just grace regen. On the same point, praying also seems to speed up sp regen although I don't have proof of that. dnh From crossfire at suckfuell.net Mon Apr 9 06:06:33 2001 From: crossfire at suckfuell.net (Jochen Suckfuell) Date: Thu Jan 13 18:00:27 2005 Subject: [CF-Devel] Further bugs with regen rates. In-Reply-To: Message-ID: I can't tell about the hp regeneration, but it's definitely true that praying increases sp regeneration. This is an (_the_) important means to get sp back: cast several holy possessions and pray, and your sp increase really fast if you have magic+5. They increase even faster than grace itself (considering that I have 600 sp max but only 250 grace max). On 09-Apr-2001 dnh wrote: > Another bug has just been noticed and proven (by me this time). If you > pray over an altar (or indeed if you pray anywhere) your hp regen rate is > increased. The proof of this is that when you pray, your food goes down at > an increased rate. I believe somehow praying is affecting more than just > grace regen. On the same point, praying also seems to speed up sp regen > although I don't have proof of that. > > dnh Bye Jochen -- This is the ____LAST time I take travel suggestions from Ray Bradbury! --- eMail jochen@suckfuell.net ----- http://www.suckfuell.net/jochen/ -------- From dnh at hawthorn.csse.monash.edu.au Mon Apr 9 07:13:42 2001 From: dnh at hawthorn.csse.monash.edu.au (dnh) Date: Thu Jan 13 18:00:27 2005 Subject: [CF-Devel] Further bugs with regen rates. In-Reply-To: Message-ID: On Mon, 9 Apr 2001, Jochen Suckfuell wrote: > I can't tell about the hp regeneration, but it's definitely true that praying > increases sp regeneration. This is an (_the_) important means to get sp back: > cast several holy possessions and pray, and your sp increase really fast if you > have magic+5. Hmm I don't experience this, what god do you worship? I know that when you pray back grace points it speeds up sp regen, but not at such a rate as you describe. I know that by habit, when ever I am using lots of sp and I run out.. I restore and pray, restore and pray to get it to go faster... dnh They increase even faster than grace itself (considering that I > have 600 sp max but only 250 grace max). > > On 09-Apr-2001 dnh wrote: > > Another bug has just been noticed and proven (by me this time). If you > > pray over an altar (or indeed if you pray anywhere) your hp regen rate is > > increased. The proof of this is that when you pray, your food goes down at > > an increased rate. I believe somehow praying is affecting more than just > > grace regen. On the same point, praying also seems to speed up sp regen > > although I don't have proof of that. > > > > dnh > > Bye > Jochen > > -- > This is the ____LAST time I take travel suggestions from Ray Bradbury! > > --- eMail jochen@suckfuell.net ----- http://www.suckfuell.net/jochen/ -------- > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > From dnh at hawthorn.csse.monash.edu.au Mon Apr 9 08:24:53 2001 From: dnh at hawthorn.csse.monash.edu.au (dnh) Date: Thu Jan 13 18:00:28 2005 Subject: [CF-Devel] post V1.0 Message-ID: I think we should considering beginning monsters. I have recently been informed that on some servers, advanced players are handing over such items as -> 'and got a flametongue of valriel +7... demonspawn shield/dragon shield + dragon mail, 100k platinum and 10k diamonds....' The only thing I can think of for players needing all that is that our current new player learning curve is too steep. This is a very serious problem, if players have to much trouble at low levels, then they will just leave. This I fear maybe the MAJOR cause of crossfire's low population. If players don't give crossfire enough chance to be good because the start is to tough we should consider changing it. For example, perhaps low level chars need to gain exp faster? perhaps get better stat bonus'? better initial equipment, more money? perhaps even a stronger char? this of course will make it easy for advanced players, BUT, I point out that advanced players are advanced because they are good (thus you would expect the start to be easier than it would for other players. I fear we need to tone down some aspects like damage of spells to low level players compared to high level players. Perhaps we need to boost the level of certain monsters and decrease it for others? I don't really have an answer but I truely believe this is a very important issue we must start thinking about for post V1.0 crossfire. dnh ps. Just another thought ;) From highway at cstone.net Mon Apr 9 09:05:34 2001 From: highway at cstone.net (Sean Michael Whipkey) Date: Thu Jan 13 18:00:28 2005 Subject: [CF-Devel] post V1.0 References: Message-ID: <3AD1C1AE.F8F86461@cstone.net> dnh wrote: > The only thing I can think of for players needing all that is that our > current new player learning curve is too steep. This is a very serious > problem, if players have to much trouble at low levels, then they will > just leave. This I fear maybe the MAJOR cause of crossfire's low > population. If players don't give crossfire enough chance to be good > because the start is to tough we should consider changing it. Well, still being a fairly new player I thought I'd chime in... I play off a .95.1 server that a friend of mine runs. My first character was a Viking, who died a lot. One of my coworkers who plays (we all play at work) gave him some decent equipment, which I gave on to my next character, a barbarian who is now level 14. I also just started a mage who is currently (IIRC) level six. I think the biggest thing in the way of newbie characters is the fact that most of the beginner's maps are, well, boring. If you push too hard, you get killed very fast (heck, my mage died from a poisoned orc chop when I clicked on the wrong button), but if you don't push on, you're stuck with the "same ole same ole". This is particularly true if you have people who like to play on a map where they go through and clear out certain areas over and over and over again. Personally, I think some more beginning monsters - or, even, more named monsters in quests and interesting houses - are needed. It'd also be cool if there was an entire beginner's area, where higher level characters are prohibited and it's set up to get beginner's some decent equipment. SeanMike From michael.toennies at nord-com.net Mon Apr 9 10:00:25 2001 From: michael.toennies at nord-com.net (Michael Toennies) Date: Thu Jan 13 18:00:28 2005 Subject: [CF-Devel] bye Message-ID: I had insert space to show the the spell exp stats (level and experience of wisdom/magic/physical/mental, etc) since the first dx client version. I had asked for it some time, but no one want or was able to do it. So i coded it for myself, after the time i spend to the dxclient, because it was some work to go i the server source. The damn server runs since several weeks with the code and there was no problems with it. And it will only be activated, when ordered with setup cmd from client. So again: This patch is tested. Its safe. It don't effect anything in game, it hooks on exp objects and monitoring the exp/level values in a very safe way. There are no "wild pointers" and i am not an idiot, so again THERE ARE NO PROBLEMS in data flow or whatever. Peters and dhns food patch are effecting data flow, not mine. Also, i included a small version cmd patch, which drop out a message when a old directx client log in to warn about old version. Now, Mark removed all this without any reason. Freeze source means to include not anything which can effect data flow or working functions without reason. Of course, this NOT means bug fixes OR additional code which helps. I need the version cmd part (its nothing more than a strcmp() and 2 sended drawinfos) to rid of the bunch of old dx clients which has small bugs are will not help to find bugs. Or you really want see the next weeks again and again mails about the non animated below item windows? Well, however i don't like the style of this. I spend time here to code and i don't like to be handled like a payed coder. Mark is not my boss and its better not to think he is. I had yet time to code, this will change in near future. Because i don't think my work is welcome here, i skip it now. I can better waste my time. So, whoever wants work on the windows source, there is minor to do, he can contact me. bye From crossfire at suckfuell.net Mon Apr 9 09:24:31 2001 From: crossfire at suckfuell.net (Jochen Suckfuell) Date: Thu Jan 13 18:00:28 2005 Subject: [CF-Devel] Further bugs with regen rates. In-Reply-To: Message-ID: >> I can't tell about the hp regeneration, but it's definitely true that >> praying >> increases sp regeneration. This is an (_the_) important means to get sp >> back: >> cast several holy possessions and pray, and your sp increase really fast if >> you >> have magic+5. > > Hmm I don't experience this, what god do you worship? I know that when you > pray back grace points it speeds up sp regen, but not at such a rate as > you describe. I know that by habit, when ever I am using lots of sp and I > run out.. I restore and pray, restore and pray to get it to go faster... > I'm playing a Quez, so maybe you should take off all armour and try then. Bye Jochen -- Mosher's Law of Software Engineering: Don't worry if it doesn't work right. If everything did, you'd be out of a job. --- eMail jochen@suckfuell.net ----- http://www.suckfuell.net/jochen/ -------- From crow at bear.cs.dartmouth.edu Mon Apr 9 10:39:07 2001 From: crow at bear.cs.dartmouth.edu (Preston Crow) Date: Thu Jan 13 18:00:28 2005 Subject: [CF-Devel] Hey, slow down a bit! Message-ID: <200104091539.f39Fd7u04091@bear.cs.dartmouth.edu> >PS-Whats the policy for including new mapsets right now or within >the stable releases? Mine should prolly be usable some time soon... While I have no real say in the matter, it seems that it should be a no-brainer to include more mapsets in the main distribution. What should be debated is when they're ready to be linked in to the standard maps. For example, if I were to include my maps (which aren't ready by any means), I would include: /preston/README A description of the maps, explanation that they're not linked in, and instructions on how to link them in. /preston/patch A patch file that will update one of the main maps to link my maps in, as explained in the README. I sure wish the Grey Shield maps were included in that fashion. (Actually, I wish they were standard--they're better than a good number of the older maps.) Does anyone know where they are now? --PC From crow at bear.cs.dartmouth.edu Mon Apr 9 10:44:38 2001 From: crow at bear.cs.dartmouth.edu (Preston Crow) Date: Thu Jan 13 18:00:28 2005 Subject: [CF-Devel] post V1.0 Message-ID: <200104091544.f39FicF04100@bear.cs.dartmouth.edu> How about making death less painful for lower-level characters? Currently, I believe the standard death is a 20% experience loss and one point depletion of a random stat. How about making it phase in to that over the course of 20 levels? So, experience loss is the same percentage as your current level, with a maximum of 20%. (Whether this is your overall level or your level in that skill is up for debate.) Stat point depletion should be only a 5% chance at first level, increasing to 100% at level 20. How does that sound? --PC From crow at bear.cs.dartmouth.edu Mon Apr 9 11:28:01 2001 From: crow at bear.cs.dartmouth.edu (Preston Crow) Date: Thu Jan 13 18:00:28 2005 Subject: [CF-Devel] object movers Message-ID: <200104091628.f39GS1d04195@bear.cs.dartmouth.edu> Mark wrote: > As you said, it is rather subjective. > > However, I find it preferable to look at a map someone else did, look at the >archetype, and know 'hey - thats a mover - it moves the player one space'. > > A simple solution here would be to have a function like >'find_mover_object_match' or the like, which takes a teleporter/mover/exit (and >potentially more, like checkers), and uses the information in the object we are >matching against to see if a matching object on the space exists, and if so, >return that object. Ok, that makes sense. I'll just be sure that the fields that I do my matching against won't touch those that will be used by movers, teleporters, and such. Peter wrote: >If you muck around and break the existing implementation, I expect you >to fix all the maps! Just to be clear: I'm using a new object type (63, which was unused) for my new mover. The plan is to get it fully-tested (it's already working for the cases I've tried), and get it included in the server. The next step is to create new arch types for the new mover (and set up crossedit to make them available). Then I convert the existing maps over from using the old mover to using the new mover. Then, if everyone is happy, we eliminate the old mover and associate arch types. Now I have some questions about the code. As it is now, the mover works by having a speed. As I understand it, that means that it will periodically scan through all the objects above it and move them if they match the move criteria. If I drop a few hundred non-matching items on a mover, this could be bad for performance. It would make a lot more sense to have the object activated anytime something changes on that square that might matter. How should I go about this? Someone suggested the possibility of having a mover have a connected value. Can someone give me an outline of how the code handles connected objects? Thanks! --PC From lusena at cs.uky.edu Mon Apr 9 11:06:51 2001 From: lusena at cs.uky.edu (Chris Lusena) Date: Thu Jan 13 18:00:28 2005 Subject: [CF-Devel] post V1.0 In-Reply-To: <200104091544.f39FicF04100@bear.cs.dartmouth.edu>; from crow@bear.cs.dartmouth.edu on Mon, Apr 09, 2001 at 11:44:38AM -0400 References: <200104091544.f39FicF04100@bear.cs.dartmouth.edu> Message-ID: <20010409120651.D28046@mars.cs.engr.uky.edu> On Mon, Apr 09, 2001 at 11:44:38AM -0400, Preston Crow wrote: > How about making death less painful for lower-level characters? [snip] > Stat point depletion should be only a 5% chance at first level, increasing > to 100% at level 20. agreed, the other problem is money/equipment I think. When I start a character it takes a long time to get enough stuff/spells so that money is not a constant problem. Take two standard beginner quest. Friendly Giant Tower and Gorks Grovel. After you work it out you net about 3-400 pp which is about 3 spells, or some +2 equipment, etc. or 1/2 a potion of life. with a 2-4 level character I can do this in maybe 30 minutes. This is the most a character at that level can do I think. and there is a change of ding (thinking about 90% for beginner but I don't know. Experience player much less) The chainmail quest. You get again about 6-700 pp and a not usefull item Mirthrial chainmail. It is about as good as +2 chain though it weights less. You need a 5-6 level charater and quit a bit of +2 stuff to do this. Net gain maybe 1 spell. So at the start if your as expert you don't die much and no how to do this you can go to the big money quest and level up quickly. But if you a beginner with not much knowledge of the game and how to make money, getting equipment is a problem. Plus you die and that potion of life is very expensive. The new spell store that always as useful spells is nice but it is very expensive. Either it should be cheaper or they need to be auto spell learn books. (like starting) Auto learning has a side effect that the Q can learn some spells early without massive artifacts, potions etc. -- Chris Lusena Office: 762 AH Department of Computer Science Phone: 859-257-3678 773 Anderson Hall Fax: 859-323-1971 University of Kentucky Email: lusena@cs.uky.edu Lexington, KY 40506-0046 U.S.A. http://www.cs.uky.edu/~lusena From crossfire at suckfuell.net Mon Apr 9 11:36:26 2001 From: crossfire at suckfuell.net (Jochen Suckfuell) Date: Thu Jan 13 18:00:28 2005 Subject: [CF-Devel] post V1.0 In-Reply-To: <200104091544.f39FicF04100@bear.cs.dartmouth.edu> Message-ID: On 09-Apr-2001 Preston Crow wrote: > How about making death less painful for lower-level characters? I think that death is much more painful in high levels! If a newbie loses 20% exp that may be about a few hundred thousand. You can get that back within an hour. But if you lose over 50 mio, it takes many hours of playing to get that back! And depletion isn't such a big deal, since (at least on public servers) there's always someone who will help out with a potion of life. > Currently, I believe the standard death is a 20% experience loss and one > point depletion of a random stat. Bye Jochen -- Some don't prefer the pursuit of happiness to the happiness of pursuit. --- eMail jochen@suckfuell.net ----- http://www.suckfuell.net/jochen/ -------- From echter at informatik.uni-rostock.de Mon Apr 9 14:14:50 2001 From: echter at informatik.uni-rostock.de (Jan Echternach) Date: Thu Jan 13 18:00:28 2005 Subject: [CF-Devel] How can this have happened? (crashing bug) In-Reply-To: <200104082312.f38NCXi10584@alfven.EECS.Berkeley.EDU>; from peterm@alfven.EECS.Berkeley.EDU on Sun, Apr 08, 2001 at 04:12:33PM -0700 References: <200104082312.f38NCXi10584@alfven.EECS.Berkeley.EDU> Message-ID: <20010409211450.A27812@hokkaido.informatik.uni-rostock.de> On Sun, Apr 08, 2001 at 04:12:33PM -0700, Peter Mardahl wrote: > So it all boils down to: why does this fireball have "op->more"? I only have a 0.95.7-cvs version around here, so maybe the following comments don't apply anymore: The random map code uses insert_ob_in_map() without checks for destroyed objects. I'm especially worried about insert_multisquare_ob_in_map() because it first inserts the head of the object (which may get destroyed by that operation) before creating the other parts of the object (which would get a freed object as their head!) and some other breakage of that kind. Another likely candidate for not checking for freed objects is server/monster.c. Anyhow, using pointers to freed objects is the most likely cause of that kind of object corruption, and insert_ob_in_map() may free objects rather unexpectedly. A problem can be that the broken code doesn't need to have any relation to fireballs or arch angels. BTW, do you now where the fireball was coming from? Was it put on the random map when the map was created? I've also noticed some unreliable code in nuke_map_region() and remove_monsters(). Both functions require that there is a floor object on each map square (they effectively perform a tmp = get_map_ob(...)->above; whenever they have something deleted). Fix would be to move that tmp = tmp->above into the loop body as an else branch. -- Jan From peterm at alfven.EECS.Berkeley.EDU Mon Apr 9 14:22:22 2001 From: peterm at alfven.EECS.Berkeley.EDU (Peter Mardahl) Date: Thu Jan 13 18:00:28 2005 Subject: [CF-Devel] praying improves mana/hp regen In-Reply-To: Your message of "Mon, 09 Apr 2001 21:00:01 +1000." Message-ID: <200104091922.f39JMMA12172@alfven.EECS.Berkeley.EDU> I noticed this a long time ago, and i rather thought it was an intended feature. Indeed, I use it *all* the time. If we decide this is bug rather than a feature, I vote to keep this as our pet bug, and name it "Charlie", and let it continue to exist. Personally, I think of praying as a lesser brother to meditation, and this makes sense to me. PeterM > Another bug has just been noticed and proven (by me this time). If you > pray over an altar (or indeed if you pray anywhere) your hp regen rate is > increased. The proof of this is that when you pray, your food goes down at > an increased rate. I believe somehow praying is affecting more than just > grace regen. On the same point, praying also seems to speed up sp regen > although I don't have proof of that. > > dnh > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel From peterm at alfven.EECS.Berkeley.EDU Mon Apr 9 14:34:35 2001 From: peterm at alfven.EECS.Berkeley.EDU (Peter Mardahl) Date: Thu Jan 13 18:00:28 2005 Subject: [CF-Devel] missing maps, grey shield In-Reply-To: Your message of "Mon, 09 Apr 2001 11:39:07 EDT." <200104091539.f39Fd7u04091@bear.cs.dartmouth.edu> Message-ID: <200104091934.f39JYZs12201@alfven.EECS.Berkeley.EDU> Sadly, we can't include maps which were never given to us. I really, really encourage people to contribute their maps to us so that they can be included in the main distribution, even if we don't link them into the standard map set. There may come a day when someone wants to work with your old maps.... PeterM > >PS-Whats the policy for including new mapsets right now or within > >the stable releases? Mine should prolly be usable some time soon... > > While I have no real say in the matter, it seems that it should be a > no-brainer to include more mapsets in the main distribution. What should > be debated is when they're ready to be linked in to the standard maps. > > For example, if I were to include my maps (which aren't ready by any > means), I would include: > > /preston/README > A description of the maps, explanation that they're not linked in, an >d > instructions on how to link them in. > /preston/patch > A patch file that will update one of the main maps to link my maps in >, > as explained in the README. > > I sure wish the Grey Shield maps were included in that fashion. (Actually, > I wish they were standard--they're better than a good number of the older > maps.) Does anyone know where they are now? > > --PC > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel From peterm at alfven.EECS.Berkeley.EDU Mon Apr 9 14:50:45 2001 From: peterm at alfven.EECS.Berkeley.EDU (Peter Mardahl) Date: Thu Jan 13 18:00:28 2005 Subject: [CF-Devel] How can this have happened? (crashing bug) In-Reply-To: Your message of "Mon, 09 Apr 2001 21:14:50 +0200." <20010409211450.A27812@hokkaido.informatik.uni-rostock.de> Message-ID: <200104091950.f39JojU12237@alfven.EECS.Berkeley.EDU> Hmm, thanks for your remarks. I had no idea that "insert_multisquare_ob_in_map" wasn't "atomic". I take it a better implementation would be to create the whole thing and then insert it into the map? I think I tried that at one point with rather annoying results: 1) Either only the head square of the monster would be put in at the start, witht he rest appearing only when the monster moved (inserting only the head) 2) Or the monster would have 1 haed, 2 of the second thing, 3 of the 3rd thing..... I could use a little bit of help here, I guess. > BTW, do you now where the fireball was coming from? Was it put on the > random map when the map was created? I have no idea if the fireball was on the map I was just leaving or if it was on the map I was entering. There should not have been a fireball on the map I was just entering: I know of no way for a random map to have a fireball on it to start unless there are runes on the floor, which generally there are not and in this case there were not. There were a great many fireballs on the map I was just leaving. > I've also noticed some unreliable code in nuke_map_region() and > remove_monsters(). Both functions require that there is a floor object > on each map square (they effectively perform a > tmp = get_map_ob(...)->above; whenever they have something deleted). > Fix would be to move that tmp = tmp->above into the loop body as an > else branch. Hmm, the random map code always places a floor and therefore assumes that there is a floor. Given that, would you still say these changes are necessary? PeterM From leaf at real-time.com Mon Apr 9 15:36:39 2001 From: leaf at real-time.com (Rick Tanner) Date: Thu Jan 13 18:00:28 2005 Subject: [CF-Devel] missing maps, grey shield In-Reply-To: <200104091934.f39JYZs12201@alfven.EECS.Berkeley.EDU> Message-ID: Are the grey shield maps the same as grey island? If so, they can be obtained from ftp://ftp.real-time.com/pub/games/crossfire/ - Rick Tanner leaf@real-time.com On Mon, 9 Apr 2001, Peter Mardahl wrote: > > Sadly, we can't include maps which were never given to us. > > I really, really encourage people to contribute their maps > to us so that they can be included in the main distribution, > even if we don't link them into the standard map set. > > There may come a day when someone wants to work with your old > maps.... > > PeterM > > > From crow at bear.cs.dartmouth.edu Mon Apr 9 16:05:36 2001 From: crow at bear.cs.dartmouth.edu (Preston Crow) Date: Thu Jan 13 18:00:28 2005 Subject: [CF-Devel] minor map fix Message-ID: <200104092105.f39L5aw05121@bear.cs.dartmouth.edu> Could someone apply this patch? It fixes an exit to move to the right square. --PC %cvs diff -u eeur/tower1.2 Index: eeur/tower1.2 =================================================================== RCS file: /cvsroot/crossfire/maps/eeur/tower1.2,v retrieving revision 1.1.1.1 diff -u -r1.1.1.1 tower1.2 --- eeur/tower1.2 1999/03/29 04:00:18 1.1.1.1 +++ eeur/tower1.2 2001/04/09 21:02:57 @@ -4474,7 +4474,7 @@ arch stair2_down slaying tower1.1 hp 20 -sp 19 +sp 18 x 15 y 17 end From andi.vogl at gmx.net Mon Apr 9 18:27:33 2001 From: andi.vogl at gmx.net (Andreas Vogl) Date: Thu Jan 13 18:00:28 2005 Subject: [CF-Devel] bug in the keyword-matching code Message-ID: <000001c0c14c$a8fb7160$e6c2fea9@kyle> When I put a phrase *before* the keyword, there is no longer a match. This is a bad bug! Example: The keyword is "open", in a magic_ear. - When I say "open", there is a match. - When I say "open the gate", there is a match. - When I say "dude open", there is NO match. Andreas V. From peterm at alfven.EECS.Berkeley.EDU Mon Apr 9 19:18:59 2001 From: peterm at alfven.EECS.Berkeley.EDU (Peter Mardahl) Date: Thu Jan 13 18:00:28 2005 Subject: [CF-Devel] dnh and I were wrong to put new code in during a freeze. (fwd) Message-ID: <200104100019.f3A0IxB12840@alfven.EECS.Berkeley.EDU> > Peters and dhns food patch are effecting data flow, not mine. Mich, dnh and I were wrong to put new code in during the code freeze. Regardless of whether Mark leaves that patch in or not, (his call) DB AND I WERE WRONG. (My fault really, I forgot about the freeze.) Mark might yet decide to toss out DB's and my patch, and he has the right to do that. If Mark is to do his job, he has to be able to enforce code-freezes. We owe Mark a great deal of respect and gratitude for the years of work he has done as lead maintainer of crossfire, and at the least, I think we can make an effort to respect his judgement. That's not to say you should not try to persuade him to make an exception and include these patches of yours. If they are well-tested and have genuine merit and are important for crossfire 1.0, Mark may change his mind, *if* you can make arguments Mark finds persuasive. By all accounts the DX client is cool and a great piece of work and very useful for the Windows crowd. I hope that either you can persuade Mark to include your patches or that you are OK with waiting for 1.0.1 for these to go in. Regards, PeterM > Also, i included a small version cmd patch, which drop out a message when a > old > directx client log in to warn about old version. > > Now, Mark removed all this without any reason. Freeze source means to > include not anything > which can effect data flow or working functions without reason. > > Of course, this NOT means bug fixes OR additional code which helps. I need > the version cmd > part (its nothing more than a strcmp() and 2 sended drawinfos) to rid of > the bunch of old > dx clients which has small bugs are will not help to find bugs. > > Or you really want see the next weeks again and again mails about the non > animated below item > windows? > > Well, however i don't like the style of this. I spend time here to code and > i don't like to > be handled like a payed coder. Mark is not my boss and its better not to > think he is. > > I had yet time to code, this will change in near future. Because i don't > think my work is welcome > here, i skip it now. I can better waste my time. > > So, whoever wants work on the windows source, there is minor to do, he can > contact me. > > bye > From mwedel at scruz.net Mon Apr 9 23:31:49 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:00:28 2005 Subject: [CF-Devel] Further bugs with regen rates. References: Message-ID: <3AD28CB5.B7F5A5CB@scruz.net> dnh wrote: > > Another bug has just been noticed and proven (by me this time). If you > pray over an altar (or indeed if you pray anywhere) your hp regen rate is > increased. The proof of this is that when you pray, your food goes down at > an increased rate. I believe somehow praying is affecting more than just > grace regen. On the same point, praying also seems to speed up sp regen > although I don't have proof of that. There is code intentionally to do this. Whether it should may be there is a different question. When you pray, (not just over altars), and you are not at max grace, it makes an extra call to do_some_living. This is the function for regaining hp and sp (as well as food consumption). Is this a big bug, or a nice feature? I note meditate basically does the same thing, so if your grace was below half max, it would speed up your grace also. I have a feeling that the calls to do_some_living are in fact in error - but removing them would reduce the speed of the grace (praying and sp/hp (meditation) regen that those skills currently do. the drop may not be big enough to worry about. From mwedel at scruz.net Mon Apr 9 23:44:32 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:00:28 2005 Subject: [CF-Devel] post V1.0 References: Message-ID: <3AD28FB0.F47D43A3@scruz.net> Just as a note - if a new player decides to do the newbie tower, you can generally be level 3 by the time you finish that, and typically it doesn't take much time to clear. Granted, it is a boring map. But if I'm making a new character, that the first place to go. Now there could certainly be some improvements. If your unlikely, you get a trapped door or two on the map where if you fail to disarm it, you are dead. Traps should be dangerous, but it is probably discouraging to try and disarm a trap (or accidentally run into a door) and end up dead. The problem with the newbie tower is that for spellcasters, you do end up spending a lot of time waiting to get your spells back. A spell caster basically has to brute force some portion of that map if they have any hope. A lot of commerical games give out exp for solving quests that may not in fact be dangerous (take X to Y, or find Z or the like) - that may also be useful. Other thoughts for improvements: spellbooks with low level spells should probably be made to show up in more low level maps. That would help the spellcasting players some (as especially at low levels, the cost delta for buying vs selling is pretty high, so this wouldn't add a tremendous amount of money to low level characters). Perhaps more scattering of potions of life in some places. As above, probably wouldn't change cost very much. A few at the end of the quests, on the basis the player will have died at least once trying to do it. I do like the idea of a newbie starting area. It would in fact not be very hard to do - basically, you may it so that the hall of selection dumps you in some dinky town, and that town has a few quests/maps to do, but once you leave that town, you can't re-enter it (or if you do, you get a map that looks the same, but in fact all the dungeons aren't there any more). Since map paths don't need to map back to each other, as said, this can be really easy to do. From mwedel at scruz.net Mon Apr 9 23:51:01 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:00:29 2005 Subject: [CF-Devel] Hey, slow down a bit! References: <200104091539.f39Fd7u04091@bear.cs.dartmouth.edu> Message-ID: <3AD29135.14E81EF7@scruz.net> Preston Crow wrote: > > >PS-Whats the policy for including new mapsets right now or within > >the stable releases? Mine should prolly be usable some time soon... > > While I have no real say in the matter, it seems that it should be a > no-brainer to include more mapsets in the main distribution. What should > be debated is when they're ready to be linked in to the standard maps. > > For example, if I were to include my maps (which aren't ready by any > means), I would include: > > /preston/README > A description of the maps, explanation that they're not linked in, and > instructions on how to link them in. > /preston/patch > A patch file that will update one of the main maps to link my maps in, > as explained in the README. > > I sure wish the Grey Shield maps were included in that fashion. (Actually, > I wish they were standard--they're better than a good number of the older > maps.) Does anyone know where they are now? This is actually a reasonable idea. I would suggest that manual directions for including/linking in the map may be needed. If several people do this, it is possible that the patches included may conflict with each other, which is why I suggest this. Someone else is taking care of maps as I recall, although with CVS, that isn't need as much. I would suggest that no new maps should probably be linked in to active maps until after 1.0. But there is a question of why include stuff that is not ready yet? The only real reason I could see is if you hope other people will work/finish up the maps (or if they're mostly ready - ie, need some debugging/balance issues). From mwedel at scruz.net Mon Apr 9 23:59:22 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:00:29 2005 Subject: [CF-Devel] object movers References: <200104091628.f39GS1d04195@bear.cs.dartmouth.edu> Message-ID: <3AD2932A.4DF61421@scruz.net> Preston Crow wrote: > Just to be clear: I'm using a new object type (63, which was unused) for my > new mover. The plan is to get it fully-tested (it's already working for > the cases I've tried), and get it included in the server. The next step is > to create new arch types for the new mover (and set up crossedit to make > them available). Then I convert the existing maps over from using the old > mover to using the new mover. Then, if everyone is happy, we eliminate the > old mover and associate arch types. Is there any good reason to actually remove all the old ones? It just seems that that would be a lot of work, and if the movers and code still works, why not leave them in? More reasonable may be to make new mover icons (really just change the color), so you can tell if it is an old mover or new one. Certainly, if maps can benefit from the new movers, update them. And perhaps as updates are done to old maps for whatever reason, also update to the new movers. The old movers support would need to stick around for some amount of time simply because there may be non standard maps that use them. > As it is now, the mover works by having a speed. As I understand it, that > means that it will periodically scan through all the objects above it and > move them if they match the move criteria. If I drop a few hundred > non-matching items on a mover, this could be bad for performance. It would > make a lot more sense to have the object activated anytime something > changes on that square that might matter. How should I go about this? set the walk_on and fly_on flag. In this way, whenever something walks or flys onto the space, the apply code gets called, and you should have a case statement for your mover in the apply loop to then call your processing (the object that entered will get passed to apply as well I believe) Your understanding of using speed is correct. > > Someone suggested the possibility of having a mover have a connected value. > Can someone give me an outline of how the code handles connected objects? You really want to look at common/button.c. Typically, op->value controls if the object is active or not (but its really up to your mover code to look at that). but you would need to put a case statement in tehre to deal with your movers. Some also change animations or have other special affects when activated (ie, set something else so they can't be de-activated, or if so they activate only once, etc) From mwedel at scruz.net Tue Apr 10 00:11:54 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:00:29 2005 Subject: [CF-Devel] How can this have happened? (crashing bug) References: <200104091950.f39JojU12237@alfven.EECS.Berkeley.EDU> Message-ID: <3AD2961A.A11BA5CC@scruz.net> Peter Mardahl wrote: > > Hmm, thanks for your remarks. > > I had no idea that "insert_multisquare_ob_in_map" wasn't "atomic". > > I take it a better implementation would be to create the whole > thing and then insert it into the map? I think I tried that at one > point with rather annoying results: I'm a little unclear of why insert_multisquare_ob_in_map is even needed. insert_ob_in_map deals with inserting all the parts. If you want to insert an object with minimal processing (ie, don't check walk on/fly on flags), insert_ob_in_map_simple should work - it doesn't do those checks. > > I've also noticed some unreliable code in nuke_map_region() and > > remove_monsters(). Both functions require that there is a floor object > > on each map square (they effectively perform a > > tmp = get_map_ob(...)->above; whenever they have something deleted). > > Fix would be to move that tmp = tmp->above into the loop body as an > > else branch. > > Hmm, the random map code always places a floor and therefore assumes > that there is a floor. Given that, would you still say these changes > are necessary? nuke_map_region looks ok. after the call to get_map_ob in both areas, we do a check to see if tmp is NULL, and do the proper thing. remove_monsters is missing a tmp==NULL check after the tmp=get_map_ob... call. That should probably be added - you never know when someone may try to re-use your code. From mwedel at scruz.net Tue Apr 10 00:17:26 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:00:29 2005 Subject: [CF-Devel] bug in the keyword-matching code References: <000001c0c14c$a8fb7160$e6c2fea9@kyle> Message-ID: <3AD29766.AECA0F5B@scruz.net> Andreas Vogl wrote: > > When I put a phrase *before* the keyword, there is no > longer a match. This is a bad bug! > > Example: The keyword is "open", in a magic_ear. > > - When I say "open", there is a match. > - When I say "open the gate", there is a match. > - When I say "dude open", there is NO match. Problem is no one really knows all the working of that code (the matching code, which is really in regex I think). This is not something I want to look into right now. I think the entire conversation stuff needs to get redone at some point. I think the regex currently in crossfire is actually fairly out of date, and certainly has a few custom hacks. It should probably get redone/updated, but I don't really want to touch that right now - if even some obscure bug in new code, that could really break a fair number of maps. From dnh at hawthorn.csse.monash.edu.au Tue Apr 10 00:39:39 2001 From: dnh at hawthorn.csse.monash.edu.au (dnh) Date: Thu Jan 13 18:00:29 2005 Subject: [CF-Devel] Further bugs with regen rates. In-Reply-To: <3AD28CB5.B7F5A5CB@scruz.net> Message-ID: Could not this strange bug peterm has been experiencing then be the same code? I remember awhile ago, there was a 50% chance of the talisman or holy symbol being applyed before the skill, until Mark made it always apply talismans first. I suddenly get the suspicion that this same effect is working on peterm's Torquemada character. dnh On Mon, 9 Apr 2001, Mark Wedel wrote: > dnh wrote: > > > > Another bug has just been noticed and proven (by me this time). If you > > pray over an altar (or indeed if you pray anywhere) your hp regen rate is > > increased. The proof of this is that when you pray, your food goes down at > > an increased rate. I believe somehow praying is affecting more than just > > grace regen. On the same point, praying also seems to speed up sp regen > > although I don't have proof of that. > > There is code intentionally to do this. Whether it should may be there is a > different question. > > When you pray, (not just over altars), and you are not at max grace, it makes > an extra call to do_some_living. This is the function for regaining hp and sp > (as well as food consumption). Is this a big bug, or a nice feature? I note > meditate basically does the same thing, so if your grace was below half max, it > would speed up your grace also. > > I have a feeling that the calls to do_some_living are in fact in error - but > removing them would reduce the speed of the grace (praying and sp/hp > (meditation) regen that those skills currently do. the drop may not be big > enough to worry about. > From echter at informatik.uni-rostock.de Tue Apr 10 05:37:25 2001 From: echter at informatik.uni-rostock.de (Jan Echternach) Date: Thu Jan 13 18:00:29 2005 Subject: [CF-Devel] How can this have happened? (crashing bug) In-Reply-To: <3AD2961A.A11BA5CC@scruz.net>; from mwedel@scruz.net on Mon, Apr 09, 2001 at 10:11:54PM -0700 References: <200104091950.f39JojU12237@alfven.EECS.Berkeley.EDU> <3AD2961A.A11BA5CC@scruz.net> Message-ID: <20010410123725.A22577@hokkaido.informatik.uni-rostock.de> On Mon, Apr 09, 2001 at 10:11:54PM -0700, Mark Wedel wrote: > Peter Mardahl wrote: > > I take it a better implementation would be to create the whole > > thing and then insert it into the map? I think I tried that at one > > point with rather annoying results: I suppose the attempt where you got one head, two pieces of the second part, three the third and so on was almost right - the only problem was that you called insert_ob_in_map() in a loop for all parts inserting all parts except the head multiple times. One insert_ob_in_map() for the head would have been enough. The problem with only the head being on the map was that you didn't link the parts together before calling insert_ob_in_map(), i.e. you called insert_ob_in_map() too early. > > Hmm, the random map code always places a floor and therefore assumes > > that there is a floor. Given that, would you still say these changes > > are necessary? It isn't necessary, but I prefer code that makes fewer assumptions (i.e. that doesn't assume that there is always a floor object) because it doesn't break as easily. > nuke_map_region looks ok. after the call to get_map_ob in both areas, we do a > check to see if tmp is NULL, and do the proper thing. Though the loop is a bit complicated. > remove_monsters is missing a tmp==NULL check after the tmp=get_map_ob... call. > That should probably be added - you never know when someone may try to re-use > your code. Both functions could be coded as simply as for (tmp = get_map_ob(...); tmp != NULL; ) if (want_to_remove_this (tmp)) { ... tmp = get_map_ob(...); } else { tmp = tmp->above; } but I don't see any reason to make that change before 1.0, and even after that I'd give it a very low priority. -- Jan From andi.vogl at gmx.net Tue Apr 10 07:51:03 2001 From: andi.vogl at gmx.net (Andreas Vogl) Date: Thu Jan 13 18:00:29 2005 Subject: [CF-Devel] bug in the keyword-matching code In-Reply-To: <3AD29766.AECA0F5B@scruz.net> Message-ID: <000001c0c1bc$e8a03600$a81afea9@kyle> Mark W. wrote: > > When I put a phrase *before* the keyword, there is no > > longer a match. This is a bad bug! > > > > Example: The keyword is "open", in a magic_ear. > > > > - When I say "open", there is a match. > > - When I say "open the gate", there is a match. > > - When I say "dude open", there is NO match. > > Problem is no one really knows all the working of that code (the matching > code, which is really in regex I think). > > This is not something I want to look into right now. I think the entire > conversation stuff needs to get redone at some point. > > I think the regex currently in crossfire is actually fairly out of date, > and certainly has a few custom hacks. It should probably get redone/updated, > but I don't really want to touch that right now - if even some obscure bug > in new code, that could really break a fair number of maps. If you don't want to waste time on this issue, it's okay. But I just wanted to make clear that this bug in fact does brake a lot of maps already. Take the map "/pup_land/lone_town/guild_freedom" for example. In a quest (Tower of Ordeal), the player is told to speak "let's protect nature" to the reception guy in guild_freedom. But because of the apostrophy-compatibility problem, the magic_ear matches only for "protect nature". With the current code, there is no longer a match for speaking the correct keywords. I believe there are quite many cases like this one. Unfortunately, Mark, you are right about the matching code being a mess. If it's too hard to fix the code, should I try to change those maps? Andreas V. From hsteoh at quickfur.yi.org Tue Apr 10 12:40:26 2001 From: hsteoh at quickfur.yi.org (H. S. Teoh) Date: Thu Jan 13 18:00:29 2005 Subject: [CF-Devel] post V1.0 In-Reply-To: <3AD28FB0.F47D43A3@scruz.net>; from mwedel@scruz.net on Mon, Apr 09, 2001 at 09:44:32PM -0700 References: <3AD28FB0.F47D43A3@scruz.net> Message-ID: <20010410134026.A16141@crystal> On Mon, Apr 09, 2001 at 09:44:32PM -0700, Mark Wedel wrote: [snip] > I do like the idea of a newbie starting area. It would in fact not be very > hard to do - basically, you may it so that the hall of selection dumps you in > some dinky town, and that town has a few quests/maps to do, but once you leave > that town, you can't re-enter it (or if you do, you get a map that looks the > same, but in fact all the dungeons aren't there any more). Since map paths > don't need to map back to each other, as said, this can be really easy to do. OK, I just had an idea for a newbie starting area... New players, after the Hall of Selection, get put into a little slum city with a few smallish shops, and lots of small monsters (kobolds, orcs, etc) and child thieves. The player then has to fight for survival, and then finally track down the mastermind of the rogues (a medium-low level monster, maybe an ogre or something). Once he kills the mastermind, there is a reward, probably basic eq needed for survival in the "real world", and then the player gets teleported out of that city, never to return again. So the city can be tailored specifically with easy monsters for new players, with helpful basic eq, etc.. Perhaps even better prices at the magic shop for spells, etc.. Just a thought I have. Hopefully somebody can develop this idea? I'm busy with another mapset of mine at the moment. T -- Why is the sea always restless? It's bed is too rocky to sleep on. From highway at cstone.net Tue Apr 10 12:48:05 2001 From: highway at cstone.net (Sean Michael Whipkey) Date: Thu Jan 13 18:00:29 2005 Subject: [CF-Devel] post V1.0 References: <200104091544.f39FicF04100@bear.cs.dartmouth.edu> Message-ID: <3AD34755.CC5884D@cstone.net> Preston Crow wrote: > How does that sound? I think that sounds good to me. Of course, I've been playing for a couple of months now and still haven't reached 20...:-) SeanMike From highway at cstone.net Tue Apr 10 12:49:21 2001 From: highway at cstone.net (Sean Michael Whipkey) Date: Thu Jan 13 18:00:29 2005 Subject: [CF-Devel] post V1.0 References: <3AD28FB0.F47D43A3@scruz.net> <20010410134026.A16141@crystal> Message-ID: <3AD347A1.C59AC9E@cstone.net> "H. S. Teoh" wrote: > Just a thought I have. Hopefully somebody can develop this idea? I'm busy > with another mapset of mine at the moment. I do like the ideas of a newbie starting area. I'm setting up a new linux box at work this afternoon and I'm going to throw the latest copy of the server on there. Some of my friends and I have been talking about making our own maps; this might make an interesting project. We could make it an off-shoot of Scorn... SeanMike From peterm at alfven.EECS.Berkeley.EDU Tue Apr 10 13:18:49 2001 From: peterm at alfven.EECS.Berkeley.EDU (Peter Mardahl) Date: Thu Jan 13 18:00:29 2005 Subject: [CF-Devel] button problem? Unnecessary instability? Message-ID: <200104101818.f3AIInS14288@alfven.EECS.Berkeley.EDU> Hello, crossfire.csua seems to be crashing lots because of this: Internal error in update_button (small button). Emergency saves disabled, no save attempted Fatal: Too many errors Emergency saves disabled, no save attempted MT has noted the same problem. This is causing my server to go down frequently. Has this been fixed? This crash is not strictly necessary because it simply crashes because of too many error messages. PeterM From crow at bear.cs.dartmouth.edu Tue Apr 10 13:41:07 2001 From: crow at bear.cs.dartmouth.edu (Preston Crow) Date: Thu Jan 13 18:00:29 2005 Subject: [CF-Devel] Hey, slow down a bit! Message-ID: <200104101841.f3AIf7o10558@bear.cs.dartmouth.edu> Mark Wedel wrote: > But there is a question of why include stuff that is not ready yet? The only >real reason I could see is if you hope other people will work/finish up the maps >(or if they're mostly ready - ie, need some debugging/balance issues). It has several advantages: If someone is messing with code that changes some little-used feature, they may grep around and find that the unfinished map is using it. If the person developing the map doesn't finish it, someone else can. (It's being distributed under the GPL, so that's fair game.) People can look at the new maps (in dm mode, someone can just jump in and play). This can provide a source of feedback for the map developer. Also, feedback can be the best way to get someone to get around to completing the map; it will get them thinking about it again. Also, there are different levels of unfinished maps. Some are completely worthless to players. Others may have interesting quests, but just not have the final touches on some parts. On the other hand, the unfinished maps that are in the main distribution haven't seen much work in a long time. Look at Skud's tower, for example. Or Lake_Country/Sunset_Lake. --PC From peterm at alfven.EECS.Berkeley.EDU Tue Apr 10 14:59:48 2001 From: peterm at alfven.EECS.Berkeley.EDU (Peter Mardahl) Date: Thu Jan 13 18:00:29 2005 Subject: [CF-Devel] Odd change in behavior of holy-worded monsters (v 97?) Message-ID: <200104101959.f3AJxmD14519@alfven.EECS.Berkeley.EDU> Hello, Holy-worded monsters now seem to run AT the caster in fear insteady of *away*. What is up with that? PeterM From hsteoh at quickfur.yi.org Tue Apr 10 15:13:38 2001 From: hsteoh at quickfur.yi.org (H. S. Teoh) Date: Thu Jan 13 18:00:29 2005 Subject: [CF-Devel] Odd change in behavior of holy-worded monsters (v 97?) In-Reply-To: <200104101959.f3AJxmD14519@alfven.EECS.Berkeley.EDU>; from peterm@alfven.EECS.Berkeley.EDU on Tue, Apr 10, 2001 at 12:59:48PM -0700 References: <200104101959.f3AJxmD14519@alfven.EECS.Berkeley.EDU> Message-ID: <20010410161338.A16498@crystal> On Tue, Apr 10, 2001 at 12:59:48PM -0700, Peter Mardahl wrote: > > Hello, > > Holy-worded monsters now seem to run AT the caster > in fear insteady of *away*. Same problem with fear spells. Somebody said it was fixed, but apparently not. T -- Real Programmers use "cat > a.out". From dnh at hawthorn.csse.monash.edu.au Wed Apr 11 05:08:21 2001 From: dnh at hawthorn.csse.monash.edu.au (dnh) Date: Thu Jan 13 18:00:29 2005 Subject: [CF-Devel] Odd change in behavior of holy-worded monsters (v 97?) In-Reply-To: <20010410161338.A16498@crystal> Message-ID: it is simply the attack code of the monsters (AI) is broken. Currently if the monster at any stages gets the call to run away it instead runs at the player and darts around it. Everytime it gets hit it moves to the other side, thus it is an ABSOLUTE bitch to kill. Try kill something with hp > 20000 that moves really fast.. you have to use the paralyze spell of just ignore it.. I don't know when it was broken or by who, but if anyone knows about that area of code I think it is in desperate need of BUG FIXING. dnh On Tue, 10 Apr 2001, H. S. Teoh wrote: > On Tue, Apr 10, 2001 at 12:59:48PM -0700, Peter Mardahl wrote: > > > > Hello, > > > > Holy-worded monsters now seem to run AT the caster > > in fear insteady of *away*. > > Same problem with fear spells. Somebody said it was fixed, but apparently > not. > > > T > > -- > Real Programmers use "cat > a.out". > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > From dnh at hawthorn.csse.monash.edu.au Wed Apr 11 05:16:17 2001 From: dnh at hawthorn.csse.monash.edu.au (dnh) Date: Thu Jan 13 18:00:29 2005 Subject: [CF-Devel] Weapon prices Message-ID: I think the current cost of standard items is way WAY to high, for example; That is sword +4 (unpaid) (dam+8)(Attacks: physical) It would cost you 1134 platinum coins, 3 gold coins and 8 silver coins. Now this weapon isn't even very valueable to a player except for money. Not only this, but a player tends to lack money alot at the start, where as later on has WAY to much. I think Post V1 we need to consider the current economic system. Should players be walking around with more money than the Earth's entire Platinum supplys could provide? ;) Perhaps the value should go right up, and the amount right down? well anyway, i request we change the current system of magic bonus costs soon. dnh From hsteoh at quickfur.yi.org Wed Apr 11 11:06:50 2001 From: hsteoh at quickfur.yi.org (H. S. Teoh) Date: Thu Jan 13 18:00:29 2005 Subject: [CF-Devel] Strange bug Message-ID: <20010411120650.A19266@crystal> OK, I'm not sure if this is purely a csua/beholder problem, but I just met a new beholder player on csua "SnuggleB" who's experiencing a strange problem: he fires once, and all his mana disappears, and he's completely paralysed (can't move at all). Crashing the client and restarting solves the problem. He's using 0.97 and I told him to upgrade, but I'm posting this anyway since I'm sure many people are still using the 0.97 client. T -- Real Programmers use "cat > a.out". From crow at bear.cs.dartmouth.edu Wed Apr 11 11:12:48 2001 From: crow at bear.cs.dartmouth.edu (Preston Crow) Date: Thu Jan 13 18:00:29 2005 Subject: [CF-Devel] issues with random maps Message-ID: <200104111612.f3BGCmR16020@bear.cs.dartmouth.edu> I've been playing the random maps a lot recently. (High-level undead maps are great for experience.) In doing so, I've run into a number of issues that need to be examined and probably fixed. Exits on Exits: I sometimes see exits stacked on top of each other. I think I may have once seen the up and down stairs on each other, but I've often seen a hole to a special treasure map on top of the stairs. Monsters on Entrance: Monsters should never be placed on the entrance to the map. When this happens, you have to fight your way out, as you get placed a square or two away from the way back. Similarly, generators should not be placed on the entrance. Traps Bypassed: When there is a chest that requires a key to open, it often will have a large number of traps. However, you can ignore them. I find that if I pick up the chest, activate it, and drop the contents, I'm free to pick them up, drop the chest, and walk away without ever setting of a single trap. (Of course, I like to disarm them anyway so as to get the experience.) Traps on Walls: I've seen some maps generated that had traps on most of the walls. I was able to search and disarm them, though running into the walls would not set them off. Either they shouldn't be there, or they should be set off by bumping into the wall (which would require some new code, I suspect). Disconnected Maps: I discovered this by casting "show invisible" to locate spectres. I was on a map that had two separate areas. The walls separating them were three squares thick at the narrowest point. (I went into dm mode to see what was up.) There was no way to get over to the other area. Fortunately, the stairs down were in the same area as the stairs up, so it didn't really mess anything up that time. Impossible to Reach Area Due to Keys: I found one map where one walled-off area was accessible only by using strange keys to open the walls around a chest. Unfortunately, the keys in question were all in that walled-off area, so I couldn't reach them. I suppose there's a chance that one was in an icecube, but I don't think so. --PC From crow at bear.cs.dartmouth.edu Wed Apr 11 11:54:56 2001 From: crow at bear.cs.dartmouth.edu (Preston Crow) Date: Thu Jan 13 18:00:29 2005 Subject: [CF-Devel] client pickup/sorting issue Message-ID: <200104111654.f3BGsuQ16208@bear.cs.dartmouth.edu> There's a problem with the client sorting messing up picking up. If you use the comma key to pick up the top item, but you have a container open, the client will have sorted the contents of the container, which will make the item that is picked up be essentially random from the player's perspective. I'm not sure what the right solution is, but if nothing else, this could be added to the to-do list as issues to solve eventually. --PC From hsteoh at quickfur.yi.org Wed Apr 11 12:42:12 2001 From: hsteoh at quickfur.yi.org (H. S. Teoh) Date: Thu Jan 13 18:00:29 2005 Subject: [CF-Devel] Strange bug In-Reply-To: <20010411120650.A19266@crystal>; from hsteoh@quickfur.yi.org on Wed, Apr 11, 2001 at 12:06:50PM -0400 References: <20010411120650.A19266@crystal> Message-ID: <20010411134212.A19519@crystal> On Wed, Apr 11, 2001 at 12:06:50PM -0400, H. S. Teoh wrote: > OK, I'm not sure if this is purely a csua/beholder problem, but I just met > a new beholder player on csua "SnuggleB" who's experiencing a strange > problem: he fires once, and all his mana disappears, and he's completely > paralysed (can't move at all). Crashing the client and restarting solves > the problem. He's using 0.97 and I told him to upgrade, but I'm posting > this anyway since I'm sure many people are still using the 0.97 client. [snip] FYI, he has just upgraded to 0.98, and it still didn't work. T -- Almost all proofs have bugs, but almost all theorems are true. -- Paul Pedersen From mwedel at scruz.net Thu Apr 12 01:07:14 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:00:30 2005 Subject: [CF-Devel] Spellpoints recharge rate oddity References: Message-ID: <3AD54612.C84AB8FA@scruz.net> I believe this is now fixed in CVS: common/living.c: Don't use the last_heal object in experience objects as sp regen penalty. This should fix the problem of inconsistent sp regen rates - last_heal is used in experience objects if the permanent experience option is turned on. MSW 2001-04-11 If the real-time server could get updated to CVS soon so we can really see if the problem goes away, that would be great. From mwedel at scruz.net Thu Apr 12 01:45:19 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:00:30 2005 Subject: [CF-Devel] post V1.0 References: <3AD28FB0.F47D43A3@scruz.net> <20010410134026.A16141@crystal> Message-ID: <3AD54EFF.D62545D0@scruz.net> A few of my thoughts on this: The maps should probably be set to reset very quickly - since lots of new players will be coming through, youu want the maps to be available. Potentially, the maps could reset immediately, with warning messages to that effect. My personal thought is that there should be a few maps - maybe enough to get to level 5 or so. There should also be a relatively easy way for the player to leave the beginner area so they can go play some of the beginner maps located in other cities (I don't necessary think that all the beginner maps should be in the starting city). reduced cost for some items could be useful. I'm not sure how easy we want to make it - I would rather keep it rather small so a player can explore all of it. Maybe just have on multi purpose shop. Doing this also creates more awe when they do get to one of the real cities - if the starting city is jsut as big and complete as later city, you won't get that awe and thats neat factor. So for the same reason, some higher priced items, like cauldrons, have no reason being in the newbie area. > New players, after the Hall of Selection, get put into a little slum city > with a few smallish shops, and lots of small monsters (kobolds, orcs, etc) > and child thieves. The player then has to fight for survival, and then > finally track down the mastermind of the rogues (a medium-low level > monster, maybe an ogre or something). Once he kills the mastermind, there > is a reward, probably basic eq needed for survival in the "real world", > and then the player gets teleported out of that city, never to return > again. > > So the city can be tailored specifically with easy monsters for new > players, with helpful basic eq, etc.. Perhaps even better prices at the > magic shop for spells, etc.. > > Just a thought I have. Hopefully somebody can develop this idea? I'm busy > with another mapset of mine at the moment. > > T > > -- > Why is the sea always restless? It's bed is too rocky to sleep on. > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel From mwedel at scruz.net Thu Apr 12 02:02:52 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:00:30 2005 Subject: [CF-Devel] Hey, slow down a bit! References: <200104101841.f3AIf7o10558@bear.cs.dartmouth.edu> Message-ID: <3AD5531C.46A182A9@scruz.net> Preston Crow wrote: > If someone is messing with code that changes some little-used feature, they > may grep around and find that the unfinished map is using it. we can hope this happens, but I'm not sure how often this will really happen. > > If the person developing the map doesn't finish it, someone else can. > (It's being distributed under the GPL, so that's fair game.) yep - and certainly there have been cases in the past where this has happened. Of course, you have to be careful that someone else doesn't start working on it while you are. > > People can look at the new maps (in dm mode, someone can just jump in and > play). This can provide a source of feedback for the map developer. Also, > feedback can be the best way to get someone to get around to completing the > map; it will get them thinking about it again. True. > > Also, there are different levels of unfinished maps. Some are completely > worthless to players. Others may have interesting quests, but just not > have the final touches on some parts. True. > > On the other hand, the unfinished maps that are in the main distribution > haven't seen much work in a long time. Look at Skud's tower, for example. > Or Lake_Country/Sunset_Lake. Also true. I would suggest that maps far from being used/ready get put in something like a maps/dev (or maybe an alternate distribution). This will make it easier to include these extra maps from the official distributions, and also keep it easier to know what maps are in development and what are ready for playing. I don't really want 60 directories in /maps as everyone checks in their maps which are not close to being ready. From mwedel at scruz.net Thu Apr 12 02:17:15 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:00:30 2005 Subject: [CF-Devel] Strange bug References: <20010411120650.A19266@crystal> Message-ID: <3AD5567B.4F9DFCD0@scruz.net> "H. S. Teoh" wrote: > > OK, I'm not sure if this is purely a csua/beholder problem, but I just met > a new beholder player on csua "SnuggleB" who's experiencing a strange > problem: he fires once, and all his mana disappears, and he's completely > paralysed (can't move at all). Crashing the client and restarting solves > the problem. He's using 0.97 and I told him to upgrade, but I'm posting > this anyway since I'm sure many people are still using the 0.97 client. I have seen behavior of getting 'paralyzed' for no good reason. The typical reason is having typed a ' or otherwise being in command mode. It could be a bound keybinding. I strongly suspect this is user error, and not an actual problem in the code of either the client or server. From peterm at alfven.EECS.Berkeley.EDU Thu Apr 12 02:17:01 2001 From: peterm at alfven.EECS.Berkeley.EDU (Peter Mardahl) Date: Thu Jan 13 18:00:30 2005 Subject: [CF-Devel] Maps in progress can go in maps/unlinked In-Reply-To: Your message of "Thu, 12 Apr 2001 00:02:52 PDT." <3AD5531C.46A182A9@scruz.net> Message-ID: <200104120717.f3C7H1G17828@alfven.EECS.Berkeley.EDU> > > I would suggest that maps far from being used/ready get put in something lik > maps/dev (or maybe an alternate distribution). This will make it easier to > include these extra maps from the official distributions, and also keep it > easier to know what maps are in development and what are ready for playing. > don't really want 60 directories in /maps as everyone checks in their maps wh > are not close to being ready. Andi Vogl and I have anticipated you a bit. Maps which are not ready for prime time can go in maps/unlinked in the CVS. That is the present home of the greyshield maps, for which we created the maps/unlinked directory. Regards, PeterM From mwedel at scruz.net Thu Apr 12 02:31:27 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:00:30 2005 Subject: [CF-Devel] client pickup/sorting issue References: <200104111654.f3BGsuQ16208@bear.cs.dartmouth.edu> Message-ID: <3AD559CF.C548A833@scruz.net> Preston Crow wrote: > > There's a problem with the client sorting messing up picking up. If you > use the comma key to pick up the top item, but you have a container open, > the client will have sorted the contents of the container, which will make > the item that is picked up be essentially random from the player's > perspective. > > I'm not sure what the right solution is, but if nothing else, this could be > added to the to-do list as issues to solve eventually. The right thing is for the client not to assume the stacking of the objects beneath it or in any containers. The client should be changed not to send arbitrary pickup command without options - if you just use the comma key, for example, the client should look and see what object appears to it to be picked up, and send that tag to the server. Doing this has another advantage in that preserving the ordering of the look window would no longer be needed. When the player picks up/drops on item, instead of resending the entire stack, we could just resend that one item that changed, making things more efficient. From peterm at alfven.EECS.Berkeley.EDU Thu Apr 12 02:46:25 2001 From: peterm at alfven.EECS.Berkeley.EDU (Peter Mardahl) Date: Thu Jan 13 18:00:30 2005 Subject: [CF-Devel] issues with random maps In-Reply-To: Your message of "Wed, 11 Apr 2001 12:12:48 EDT." <200104111612.f3BGCmR16020@bear.cs.dartmouth.edu> Message-ID: <200104120746.f3C7kPq17889@alfven.EECS.Berkeley.EDU> > Exits on Exits: > > I sometimes see exits stacked on top of each other. I think I may have > once seen the up and down stairs on each other, but I've often seen a hole > to a special treasure map on top of the stairs. Some of the exits on exits were intentional: one is an exit to the previous level, the other is an exit out of the whole random map. As for the other, yeah, it's a bit ugly, but a player can simply select the appropriate exit with his mouse. > Monsters on Entrance: > > Monsters should never be placed on the entrance to the map. When this > happens, you have to fight your way out, as you get placed a square or two > away from the way back. Similarly, generators should not be placed on the > entrance. Well, I agree with you here: the problem is that the code for placing monsters is unaware of exits: I borrowed it from crossfire at large, and the crossfire-at-large code for placing things doesn't care about exits. A phase of monster-removal might be added, but great care would have to be taken not to remove an important key from the map. > Traps Bypassed: > > When there is a chest that requires a key to open, it often will have a > large number of traps. However, you can ignore them. I find that if I > pick up the chest, activate it, and drop the contents, I'm free to pick > them up, drop the chest, and walk away without ever setting of a single > trap. (Of course, I like to disarm them anyway so as to get the > experience.) Arguably, this isn't a problem with random maps but rather with the container code. This could be repaired easily, though, if we cease ever requiring a key to open these treasure chests. Then I could switch them over to the other type, which spring their traps when they're apllied and drop everything onto the floor. > Traps on Walls: > > I've seen some maps generated that had traps on most of the walls. I was > able to search and disarm them, though running into the walls would not set > them off. Either they shouldn't be there, or they should be set off by > bumping into the wall (which would require some new code, I suspect). I've never seen this. Ever. Where did you see this? > Disconnected Maps: > > I discovered this by casting "show invisible" to locate spectres. I was on > a map that had two separate areas. The walls separating them were three > squares thick at the narrowest point. (I went into dm mode to see what was > up.) There was no way to get over to the other area. Fortunately, the > stairs down were in the same area as the stairs up, so it didn't really > mess anything up that time. What crossfire version and what type of layout was it? I've gone to some trouble to ensure that ALL maps are fully connected: i.e., you can get anywhere in the map from anywhere in the map. I ran hundreds of test cases to see if this actually worked out. > Impossible to Reach Area Due to Keys: > > I found one map where one walled-off area was accessible only by using > strange keys to open the walls around a chest. Unfortunately, the keys in > question were all in that walled-off area, so I couldn't reach them. I > suppose there's a chance that one was in an icecube, but I don't think so. Here I think you simply failed to look hard enough for keys. When I put in any keyed door, I make *two* keys for it: one on either side of the door. When a monster cannot be found in which to put the key, it is dropped onto the ground, which is why you saw a pile of keys inside. It's not possible for a key to be in an icecube. The only things that can harm keys are alchemy or the matching doors. PeterM From crow at bear.cs.dartmouth.edu Thu Apr 12 10:42:33 2001 From: crow at bear.cs.dartmouth.edu (Preston Crow) Date: Thu Jan 13 18:00:30 2005 Subject: [CF-Devel] issues with random maps Message-ID: <200104121542.f3CFgX722749@bear.cs.dartmouth.edu> PeterM wrote: > Preston wrote: >> Traps Bypassed: >> >> When there is a chest that requires a key to open, it often will have a >> large number of traps. However, you can ignore them. I find that if I >> pick up the chest, activate it, and drop the contents, I'm free to pick >> them up, drop the chest, and walk away without ever setting of a single >> trap. (Of course, I like to disarm them anyway so as to get the >> experience.) > >Arguably, this isn't a problem with random maps but rather >with the container code. This could be repaired easily, though, >if we cease ever requiring a key to open these treasure chests. >Then I could switch them over to the other type, which spring >their traps when they're apllied and drop everything onto the floor. Personally, I prefer chests that go away instead of acting like regular containers. If a code fix is required, would it be simpler to have chests that use up special keys (like doors) when opened but are otherwise ordinary chests? I've also had the traps go off in really weird situations--after I've emptied the chest and picked up everything, I then dropped everything, and the traps seemed to get dropped, as well. It wasn't fun seeing them all go off in my apartment. I'm not 100% sure what I did to make that happen. The current behaviour is rather quirky. >> Traps on Walls: >> >> I've seen some maps generated that had traps on most of the walls. I was >> able to search and disarm them, though running into the walls would not set >> them off. Either they shouldn't be there, or they should be set off by >> bumping into the wall (which would require some new code, I suspect). > >I've never seen this. Ever. Where did you see this? I was going through the 50-level undead map. I think it was a map with narrow spiral passages. The passages were separated by more than one square. I've only seen it once or twice. >> Disconnected Maps: >> >> I discovered this by casting "show invisible" to locate spectres. I was on >> a map that had two separate areas. The walls separating them were three >> squares thick at the narrowest point. (I went into dm mode to see what was >> up.) There was no way to get over to the other area. Fortunately, the >> stairs down were in the same area as the stairs up, so it didn't really >> mess anything up that time. > >What crossfire version and what type of layout was it? I've gone >to some trouble to ensure that ALL maps are fully connected: i.e., >you can get anywhere in the map from anywhere in the map. >I ran hundreds of test cases to see if this actually worked out. I'm pretty sure on this one, and it was with the current CVS code on Tuesday night. I don't remember the exact layout; the walls were black/grey. The playable area was roughly circular, perhaps 10 squares in diameter with walls making it into passages. If I see it again, I'll save the file for you. >> Impossible to Reach Area Due to Keys: >> >> I found one map where one walled-off area was accessible only by using >> strange keys to open the walls around a chest. Unfortunately, the keys in >> question were all in that walled-off area, so I couldn't reach them. I >> suppose there's a chance that one was in an icecube, but I don't think so. > >Here I think you simply failed to look hard enough for keys. When I >put in any keyed door, I make *two* keys for it: one on either side >of the door. When a monster cannot be found in which to put the key, >it is dropped onto the ground, which is why you saw a pile of keys >inside. > >It's not possible for a key to be in an icecube. The only things that >can harm keys are alchemy or the matching doors. Next time I'll melt all my icecubes and make sure. Would it be possible to save all the parameters and random number seed as comments in the map file so that it would be possible to reconstruct the original map? Then if there were an issue with keys, you could go back and see exactly where they were (or weren't). In theory, we could then just email a few lines and easily reconstruct the maps in discussion. --PC From Philipp.Currlin at t-online.de Thu Apr 12 15:53:08 2001 From: Philipp.Currlin at t-online.de (Philipp Currlin) Date: Thu Jan 13 18:00:30 2005 Subject: [CF-Devel] reduction of data when casting spells Message-ID: <3AD615B4.4030403@epost.de> Hello I know only small changes should be made now, however I think gameplay got _slower_ since Mark reduced the time for updates of tiles. Now even one dragon can be enough to make me stop moving for one second. For me it is still possible to play, but sometimes it can really reduce the fun of it. My suggestion is to reduce the amount of spells shown per tile. I don't think we really need to show poison cloud and icestorm ten times on every tile on the screen when you are fighting a chinese dragon. If it is shown once you still see what is going on but your connection will be a lot faster. What I mean is to keep the monsters casting their spells and the damage should be calculated the same way as before but the client shouldn't be allowed to show each spell more than once. It is a big change of the code but I would agree to hold off with 1.0 if we could reduce the dataflow by more than 50% that way. Phil PS: I hope you know what I mean, I don't really know how to explain it. From dnh at hawthorn.csse.monash.edu.au Thu Apr 12 19:46:07 2001 From: dnh at hawthorn.csse.monash.edu.au (dnh) Date: Thu Jan 13 18:00:30 2005 Subject: [CF-Devel] reduction of data when casting spells In-Reply-To: <3AD615B4.4030403@epost.de> Message-ID: This is exactly what I asked peterm to do, but he said it was impossible. I think the problem is it is impossible to keep track of what is on top constantly, infact it would be almost as much work, and the server would still have to calculate where all the spells were going. dnh On Thu, 12 Apr 2001, Philipp Currlin wrote: > Hello > > > I know only small changes should be made now, however I think gameplay > got _slower_ since Mark reduced the time for updates of tiles. > Now even one dragon can be enough to make me stop moving for one second. > For me it is still possible to play, but sometimes it can really reduce > the fun of it. > > My suggestion is to reduce the amount of spells shown per tile. I don't > think we really need to show poison cloud and icestorm ten times on > every tile on the screen when you are fighting a chinese dragon. If it > is shown once you still see what is going on but your connection will be > a lot faster. > What I mean is to keep the monsters casting their spells and the damage > should be calculated the same way as before but the client shouldn't be > allowed to show each spell more than once. > > It is a big change of the code but I would agree to hold off with 1.0 if > we could reduce the dataflow by more than 50% that way. > > > Phil > > PS: I hope you know what I mean, I don't really know how to explain it. > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > From mwedel at scruz.net Thu Apr 12 23:31:50 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:00:30 2005 Subject: [CF-Devel] issues with random maps References: <200104120746.f3C7kPq17889@alfven.EECS.Berkeley.EDU> Message-ID: <3AD68135.C51B5522@scruz.net> Peter Mardahl wrote: > Well, I agree with you here: the problem is that the code for placing > monsters is unaware of exits: I borrowed it from crossfire at large, > and the crossfire-at-large code for placing things doesn't care > about exits. > > A phase of monster-removal might be added, but great care > would have to be taken not to remove an important key from the map. Actually, probably better placement would be the thing to do. You can't control where monsters move to after the map has been loaded, but I believe what PC is describing is the first time you enter a map, monsters are on top of exits. It would seem that we could modify the code to not place monsters on top of exits. I have also noticed chests on top of exits. This is really annoying when the exit is a type that is automatically applied when you move on top - you go to look at the chest, and find yourself on the next map. > > Traps on Walls: > > > > I've seen some maps generated that had traps on most of the walls. I was > > able to search and disarm them, though running into the walls would not set > > them off. Either they shouldn't be there, or they should be set off by > > bumping into the wall (which would require some new code, I suspect). > > I've never seen this. Ever. Where did you see this? Might the rune placing code not be smart enough to know there is a wall on some space, and thus is placing a trap on top of it? > > Next time I'll melt all my icecubes and make sure. > > Would it be possible to save all the parameters and random number seed as > comments in the map file so that it would be possible to reconstruct the > original map? Then if there were an issue with keys, you could go back and > see exactly where they were (or weren't). In theory, we could then just > email a few lines and easily reconstruct the maps in discussion. You could try, but it probably would not work. First, I am not sure if we can reliably get the random seed that is being used (note some systems could potentially not be using random generation methods that even have a seed or are computed, but rather use one of the more truly random methods of getting values). But even if you could, the random generation on one system does not match that of another, so the only real use might be to run it on the same system. This is even more likely if the two systems are not even using the same random libraries (there is a bit of code in crossfire to try and use the best random number generator available on the machine). But I do note that both my intel/linux/gcc machine and my sparc/solaris/workshop 5.0 cc machine do generate the same results for the following program: #include main() { srand48(50000); printf("%d ", lrand48()); printf("%d ", lrand48()); printf("%d ", lrand48()); printf("%d ", lrand48()); printf("%d ", lrand48()); printf("\n"); } results being: 614741494 586508200 804230098 1955543993 1872910808 From the_real_tomble at hotmail.com Thu Apr 12 23:39:06 2001 From: the_real_tomble at hotmail.com (Tom Barnes-Lawrence) Date: Thu Jan 13 18:00:30 2005 Subject: [CF-Devel] Hey, slow down a bit! Message-ID: Mark Wedel wrote: >Preston Crow wrote: >>If the person developing the map doesn't finish it, someone else >> >>can.(It's being distributed under the GPL, so that's fair game.) >yep - and certainly there have been cases in the past where this >has >happened. As I already have something in mind for about 90% of my mapset, I would rather finish those parts myself, but if I were to stop doings stuff with CF completely or drop dead or something, then I'd certainly prefer my maps didn't just sit there and fester. >>People can look at the new maps (in dm mode, someone can just jump >>in >>and play). This can provide a source of feedback for the map >>developer. >> Also, feedback can be the best way to get someone to >>get around to >>completing the map; it will get them thinking about >>it again. > True. Also, I haven't contributed anything to the game so far other than a bunch of opinions, an idea or 2, and lengthy postings. If I were to have my mapset in the game, it would make me feel like an actual contributor rather than someone who just likes the sound of their own posts. That would encourage me to look more thoroughly at the source and so be able to help with actual useful stuff ;) And yes, I do intend to finish my maps, but it'll take a while and so it'd be nice for me to have others see it, as you both say. As was also mentioned, there are bits where I *could* do with a bit of help from others, where stuff is complicated, but that's only a little help with very few maps. Knowing others can use my maps is more of a catalyst to me. >>On the other hand, the unfinished maps that are in the main >>distribution >>haven't seen much work in a long time. Look at >>Skud's tower, for example. >>Or Lake_Country/Sunset_Lake. > Also true. And as you say, these maps are in the distribution... Last time I checked, my mapset was far larger than sunset castle (though certainly not as large as lake_country as a whole :P). > I would suggest that maps far from being used/ready get put in >something like a maps/dev (or maybe an alternate distribution). >This will make it easier to include these extra maps from the >official distributions, and also keep it easier to know what maps >are in development and what are ready for playing. This sounds sensible, and personally I would be more than happy if my maps were in an "in-development" directory (when there is more to them). > I don't really want 60 directories in /maps as everyone checks >in their maps which are not close to being ready. I can well understand that. When I asked that question before, I didn't mean that I wanted my maps to go in as they are, because like you say, they are not nearly ready. ... I was asking mainly because we have the feature freeze, and I wanted to know if there was also a new-map freeze: If I know that my mapset could *possibly* go into the distribution some time soon (supposing people think its OK), that would encourage me to spend even more time on it. It has mainly civic maps, IE- not very many monsters, little in way of quests (though I am working on that), but it has (will have) some things that AFAIK are nowhere else in CF, such as: A player-run market, a slum with rentable rooms (a bit like the scorn appartment rooms, but different), a castle (to live in, like Brxls house in stoneville) that also has guest keys to give to friends, a kennel (to keep pets in), and an Auction (40% done, 80% planned, theory is fine, so should work!).And so on. Most of these aren't quite in keeping with rest of CF, but I think they're neat ;). CF is supposed to be a graphical MUD, and with V1 approaching I would expect many more players appearing; I think these sort of things could go down well... Tomble (Tom Barnes-LawrencE) PS-Considering the tensions that seem to have been arising in recent weeks with the feature freeze, I guess you're probably right to try to get V1 out ASAP. I'd really just meant it was good to be sure that anything awkward to fix should be done before saying CF is stable- plus, we could maybe do with some small cosmetic improvements before officially unleashing it? _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. From mwedel at scruz.net Thu Apr 12 23:47:57 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:00:30 2005 Subject: [CF-Devel] reduction of data when casting spells References: <3AD615B4.4030403@epost.de> Message-ID: <3AD684FD.1CB1E4C0@scruz.net> Philipp Currlin wrote: > > Hello > > I know only small changes should be made now, however I think gameplay > got _slower_ since Mark reduced the time for updates of tiles. > Now even one dragon can be enough to make me stop moving for one second. > For me it is still possible to play, but sometimes it can really reduce > the fun of it. Its possible my changes may have effected this, but I'm unsure how. > > My suggestion is to reduce the amount of spells shown per tile. I don't > think we really need to show poison cloud and icestorm ten times on > every tile on the screen when you are fighting a chinese dragon. If it > is shown once you still see what is going on but your connection will be > a lot faster. > What I mean is to keep the monsters casting their spells and the damage > should be calculated the same way as before but the client shouldn't be > allowed to show each spell more than once. tile in what regard? There are two areas you may be using to refer to tile here: 1) The tiles as they appear in the map window (where the player icon is). In that case, no more than 3 tiles will ever be sent for any space (and its typically a floor plus two objects above it). One of the things on the drawing board is to have the number of objects send here more settable - if you're on a slow connectiion, you may only want the floor + the top object, and ignore that middle one for bandwidth savings. Certainly, right now, anyone playing that uses the xbm graphics would really want just the top object, since the xbm graphics don't have transparencies. But xbm graphics will go away, so that contingent should not be very large. 2) The look window is a different category. Currently, 50 objects can get sent to the client each tick. Note the number of spells shown could be reduced or even eliminated in this window. However, to selectively show each one as unique would be a pain (ie, if you were being hit by 10 fires, 3 slows and 8 fears, and the order was fire, fear, fire, fire, slow, fear, fire, fire.. .. and you only wanted to see the top 3, you would get fire, fear, fire. It would be too compute intensive to try to reduce that stack to just fire, fear, slow, as it would basically require an O(n^2) operation on each tick. The problem is that even with this, it won't help out if your standing on a stack of 50 items, as the server will still send the entire stack each tick - now you'll just get 5 spells and 45 items instead of 40 spells and 10 items. From mwedel at scruz.net Thu Apr 12 23:51:43 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:00:30 2005 Subject: Futre of Maps, was Re: [CF-Devel] Hey, slow down a bit! References: Message-ID: <3AD685DF.2682F9C4@scruz.net> Peter and AV have already created an unlinked directory for such maps. Remember to run cvs update -d to get the new directory. I have no real problem of people putting their work in progress maps in there (before 1.0). I would say that the map should not get linked in (ie, person downloading the maps would need to do something to be able to play that map, like create an exit for it). From mwedel at scruz.net Fri Apr 13 00:22:35 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:00:30 2005 Subject: [CF-Devel] bug in the keyword-matching code References: <000001c0c1bc$e8a03600$a81afea9@kyle> Message-ID: <3AD68D1B.D16A98B8@scruz.net> OK. I've fixed this. The change wasn't that bad, and I checked it against many of the citizens in goths taverns, and all seemed to work properly. other than the |, it doesn't look like there are many cases where the maps really use the regular expession features - if there are, I could see some potential problems with those. Andreas Vogl wrote: > > Mark W. wrote: > > > When I put a phrase *before* the keyword, there is no > > > longer a match. This is a bad bug! > > > > > > Example: The keyword is "open", in a magic_ear. > > > > > > - When I say "open", there is a match. > > > - When I say "open the gate", there is a match. > > > - When I say "dude open", there is NO match. > > > > Problem is no one really knows all the working of that code (the matching > > code, which is really in regex I think). > > > > This is not something I want to look into right now. I think the entire > > conversation stuff needs to get redone at some point. > > > > I think the regex currently in crossfire is actually fairly out of date, > > and certainly has a few custom hacks. It should probably get > redone/updated, > > but I don't really want to touch that right now - if even some obscure bug > > in new code, that could really break a fair number of maps. > > If you don't want to waste time on this issue, it's okay. > But I just wanted to make clear that this bug in fact does brake a lot > of maps already. > Take the map "/pup_land/lone_town/guild_freedom" for example. In a quest > (Tower of Ordeal), the player is told to speak "let's protect nature" to > the reception guy in guild_freedom. But because of the > apostrophy-compatibility > problem, the magic_ear matches only for "protect nature". > With the current code, there is no longer a match for speaking the correct > keywords. > I believe there are quite many cases like this one. Unfortunately, > Mark, you are right about the matching code being a mess. > If it's too hard to fix the code, should I try to change those maps? > > Andreas V. > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel From peterm at alfven.EECS.Berkeley.EDU Fri Apr 13 03:20:07 2001 From: peterm at alfven.EECS.Berkeley.EDU (Peter Mardahl) Date: Thu Jan 13 18:00:30 2005 Subject: [CF-Devel] reduction of data when casting spells In-Reply-To: Your message of "Fri, 13 Apr 2001 10:46:07 +1000." Message-ID: <200104130820.f3D8K7820069@alfven.EECS.Berkeley.EDU> Er, if this is *exactly* what you asked me to do, then I misunderstood you. What he's talking about is not SENDING everything to the client. What I thought we discussed was merging, on the server, the various spells. PeterM > This is exactly what I asked peterm to do, but he said it was impossible. > I think the problem is it is impossible to keep track of what is on top > constantly, infact it would be almost as much work, and the server would > still have to calculate where all the spells were going. > > dnh > > On Thu, 12 Apr 2001, Philipp Currlin wrote: > > > Hello > > > > > > I know only small changes should be made now, however I think gameplay > > got _slower_ since Mark reduced the time for updates of tiles. > > Now even one dragon can be enough to make me stop moving for one second. > > For me it is still possible to play, but sometimes it can really reduce > > the fun of it. > > > > My suggestion is to reduce the amount of spells shown per tile. I don't > > think we really need to show poison cloud and icestorm ten times on > > every tile on the screen when you are fighting a chinese dragon. If it > > is shown once you still see what is going on but your connection will be > > a lot faster. > > What I mean is to keep the monsters casting their spells and the damage > > should be calculated the same way as before but the client shouldn't be > > allowed to show each spell more than once. > > > > It is a big change of the code but I would agree to hold off with 1.0 if > > we could reduce the dataflow by more than 50% that way. > > > > > > Phil > > > > PS: I hope you know what I mean, I don't really know how to explain it. > > > > _______________________________________________ > > crossfire-devel mailing list > > crossfire-devel@lists.real-time.com > > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > > > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel From Philipp.Currlin at t-online.de Fri Apr 13 06:21:21 2001 From: Philipp.Currlin at t-online.de (Philipp Currlin) Date: Thu Jan 13 18:00:31 2005 Subject: [CF-Devel] reduction of data when casting spells References: <200104130820.f3D8K7820069@alfven.EECS.Berkeley.EDU> Message-ID: <3AD6E131.7060003@epost.de> Peter Mardahl wrote: > Er, if this is *exactly* what you asked me to do, then I misunderstood you. > What he's talking about is not SENDING everything to the client. > > What I thought we discussed was merging, on the server, the various > spells. > > PeterM What I meant was merging all the spells of one type, so if you get hit by cold cold fear cold fear poison you only see cold fear poison. It would still be slow when standing on a pile with lots of stuff but then it usually isn't as dangerous as when fighting certain monsters. And the more spells a monsters casts the more dangerous that monster usually is, but then the connection is also slower so it gets yet more dangerous than the monster itself is. I don't really mind when it's a bit slower while I'm identifying everything I found but I do mind if I get killed because I wasn't able to heal myself when I hit the key. I died fairly often that way because I hit restoration but it took more than 5 seconds till my spell got applied. Sometimes too late because I was already standing on my bed in Scorn with a lot of levels less. That is really annoying for me and also for lots of others that's why I've been asking if it was possible to reduce the amount of data in that way. Phil From crow at bear.cs.dartmouth.edu Fri Apr 13 08:58:57 2001 From: crow at bear.cs.dartmouth.edu (Preston Crow) Date: Thu Jan 13 18:00:31 2005 Subject: [CF-Devel] reduction of data when casting spells Message-ID: <200104131358.f3DDwvD24964@bear.cs.dartmouth.edu> Philipp Currlin wrote: >What I meant was merging all the spells of one type, so if you get hit >by cold cold fear cold fear poison you only see cold fear poison. You mean letting spell effects merge like ordinary items so you see: 7 fires 3 slows 2 colds floor This probably would require special code, since I doubt you can merge the objects internally, since they have different timeout values, and they probably have other values that are different. However, it would be possible to make this a special case for the code that sends items to the client, where any time it sees a spell effect, it counts the number in the stack and sends it with that count, noting on the side not to send that effect again this tick. Mark Wedel wrote: >1) The tiles as they appear in the map window (where the player icon >is). In that case, no more than 3 tiles will ever be sent for any >space (and its typically a floor plus two objects above it). One of >the things on the drawing board is to have the number of objects send >here more settable That would be a great idea. Even better would be if the server could detect lag (how much data is in the send buffer for the connection at the start of the tick) and adjust the setting dynamically. >2) The look window is a different category. Currently, 50 objects can >get sent to the client each tick. Note the number of spells shown >could be reduced or even eliminated in this window. Again that could be dynamic. I've thought that it would be cool if the server could only send, say, 5 items per tick, but if the square doesn't change, they would be the next five items down from where it left off. This probably isn't supported in the protocol, unfortunately. Otherwise, you could sit on a large stack, and if you wait long enough, you would eventually see all the items. By the way, currently the fake item at the end of the sent items says to click on it to see the rest of the items. That doesn't seem to work, at least from the GTK client. Perhaps it should just say "more items you can't see" or something like that. --PC From Philipp.Currlin at t-online.de Fri Apr 13 09:18:28 2001 From: Philipp.Currlin at t-online.de (Philipp Currlin) Date: Thu Jan 13 18:00:31 2005 Subject: [CF-Devel] fake item at end of list References: <200104131358.f3DDwvD24964@bear.cs.dartmouth.edu> Message-ID: <3AD70AB4.2070803@epost.de> > > By the way, currently the fake item at the end of the sent items says > to click on it to see the rest of the items. That doesn't seem to > work, at least from the GTK client. Perhaps it should just say "more > items you can't see" or something like that. > > --PC That does work, you need to click with the middle mouse button Phil From peterm at alfven.EECS.Berkeley.EDU Fri Apr 13 13:30:18 2001 From: peterm at alfven.EECS.Berkeley.EDU (Peter Mardahl) Date: Thu Jan 13 18:00:31 2005 Subject: [CF-Devel] reduction of data when casting spells In-Reply-To: Your message of "Fri, 13 Apr 2001 13:21:21 +0200." <3AD6E131.7060003@epost.de> Message-ID: <200104131830.f3DIUIB20749@alfven.EECS.Berkeley.EDU> > Peter Mardahl wrote: > > > Er, if this is *exactly* what you asked me to do, then I misunderstood you. > > What he's talking about is not SENDING everything to the client. > > > > What I thought we discussed was merging, on the server, the various > > spells. > > > > PeterM > > What I meant was merging all the spells of one type, so if you get hit Please never use the word "merging spells" ever again, or people will ignore your idea. We've discussed "merging spell objects", and the consensus is it's either impossible or so difficult that it's not worth the effort. Now, what you're saying, is if we have 5 icestorms in a particular square, we send 1 icestorm object to the client only so the player sees an icestorm. There's no merging going on. Hell, maybe we can send 1 icestorm with nrof 5, and if the player clicks, he'll see "5 icestorms." I don't know how easy this would be to implement, but it's at least possible, while merging the spell objects on the server is practically impossible. PeterM > by cold cold fear cold fear poison you only see cold fear poison. > It would still be slow when standing on a pile with lots of stuff but > then it usually isn't as dangerous as when fighting certain monsters. > And the more spells a monsters casts the more dangerous that monster > usually is, but then the connection is also slower so it gets yet more > dangerous than the monster itself is. > I don't really mind when it's a bit slower while I'm identifying > everything I found but I do mind if I get killed because I wasn't able > to heal myself when I hit the key. I died fairly often that way because > I hit restoration but it took more than 5 seconds till my spell got > applied. Sometimes too late because I was already standing on my bed in > Scorn with a lot of levels less. > That is really annoying for me and also for lots of others that's why > I've been asking if it was possible to reduce the amount of data in that > way. > > > Phil > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel From dnh at hawthorn.csse.monash.edu.au Fri Apr 13 21:11:08 2001 From: dnh at hawthorn.csse.monash.edu.au (dnh) Date: Thu Jan 13 18:00:31 2005 Subject: [CF-Devel] reduction of data when casting spells In-Reply-To: <200104130820.f3D8K7820069@alfven.EECS.Berkeley.EDU> Message-ID: On Fri, 13 Apr 2001, Peter Mardahl wrote: > Er, if this is *exactly* what you asked me to do, then I misunderstood you. > What he's talking about is not SENDING everything to the client. > > What I thought we discussed was merging, on the server, the various > spells. > > PeterM > Umm, what I meant was that we just don't display all the information of the client in the hopes of less work on the server. dnh > > > This is exactly what I asked peterm to do, but he said it was impossible. > > I think the problem is it is impossible to keep track of what is on top > > constantly, infact it would be almost as much work, and the server would > > still have to calculate where all the spells were going. > > > > dnh > > > > On Thu, 12 Apr 2001, Philipp Currlin wrote: > > > > > Hello > > > > > > > > > I know only small changes should be made now, however I think gameplay > > > got _slower_ since Mark reduced the time for updates of tiles. > > > Now even one dragon can be enough to make me stop moving for one second. > > > For me it is still possible to play, but sometimes it can really reduce > > > the fun of it. > > > > > > My suggestion is to reduce the amount of spells shown per tile. I don't > > > think we really need to show poison cloud and icestorm ten times on > > > every tile on the screen when you are fighting a chinese dragon. If it > > > is shown once you still see what is going on but your connection will be > > > a lot faster. > > > What I mean is to keep the monsters casting their spells and the damage > > > should be calculated the same way as before but the client shouldn't be > > > allowed to show each spell more than once. > > > > > > It is a big change of the code but I would agree to hold off with 1.0 if > > > we could reduce the dataflow by more than 50% that way. > > > > > > > > > Phil > > > > > > PS: I hope you know what I mean, I don't really know how to explain it. > > > > > > _______________________________________________ > > > crossfire-devel mailing list > > > crossfire-devel@lists.real-time.com > > > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > > > > > > > _______________________________________________ > > crossfire-devel mailing list > > crossfire-devel@lists.real-time.com > > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > From mwedel at scruz.net Sat Apr 14 00:01:42 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:00:31 2005 Subject: [CF-Devel] reduction of data when casting spells References: <200104130820.f3D8K7820069@alfven.EECS.Berkeley.EDU> <3AD6E131.7060003@epost.de> Message-ID: <3AD7D9B6.4721818F@scruz.net> I'll try to sum up the points, and limit quoting to a minimum. First, trying to be more intelligent about what we send to the client is actually more work for the server (although less bandwidth). This is because the server now needs to go through and try to find duplicates. Second, I believe slowness on the server is generally caused by processing lots of spell objects on the same space internally, and not bandwidth to the client. This is because any time a new spell object is added to the space, it has to look at all the other spell objects to see if might affect them. This basically means that if you have 50 spell objects, and another gets added, it needs to examine 51 objects. And to get to having 50 spell objects, it will have had to do 1275 examines. This can only really be fixed by trying to limit use of lots of spell casting monsters on the same map, and a complete re-design of how this processing happens. I've given some thoughts to this, and all and all, its not a simple matter. It would be an interesting experiment to change the nrof 0 to nrof 1 in all the spell effect objects and just see what happens in terms of how many objects may actually get merged. I know that doing this will almost certainly break other places (as I don't think the spell effect propogation is currently intelligent enough to look at the nrof field to know how many it should put on the next space, and I also bet the damage function doesn't look at nrof either). I have a feeling there may be some amount of merging, but not enough to make a real difference. PC's scheme of identifying spell effects and counting the number to only send one with a proper nrof would work, but gets sort of complicated. First, the code has to know what all the potential effects are (might just presume that flag_flying is the right thing, or no_pick or the like) - the code certainly has to be smart enough so that it doesn't do that to a bunch of different arrow types. It is also tricky in that whenever we run into a spell effect, we either need to record the effect type (maybe by looking at the arch it points to, or name?), and then record someplace we've sent that effect type. This does mean that whenever we get another affect, we need to look at that record to see if its already been sent - that could be costly. And alternative would be to have temporary flag that we clear on all objects in the space, and then when we get a spell effect, look through the rest of the objects on that space setting the flag on matches - when the processing happens, if that flag is set, it knows not to send it. Proper clearing of that flag would be a must for things to work properly. Note that the knowing how many spell objects of that type needs to be determined when we get the first object of that type - to try and go back through the packet structure and change that value after the fact would be a real pain. For number of objects in the look window - my thought is to make that dynamic at some point. I didn't do that in my implementation as that would add a bit of complication I didn't want to add at that point. In terms of dynamic, I was meaning dynamic player settable (and not something the server figures out). This, when your going into the dungeon to clear out all the monsters, you probably have that set to a low value and use pickup mode 10 or the like which won't care about that setting. Then when you go back in vacuum mode, you may set that to a higher value to better examine the stacks. Gradually sending more items each tick would be fairly tricky, and the number sent per tick would have to be settable (if on a fast link, you probably want a whole bunch, if a slow link, just a few). I would prefer to make the number of objects viewable in the look window settable - easier to do. As previously said, the handling of sending of data to the look window probably needs to get redone for 2.0. Adjusting the amount of data based on size of pending output might be possible - first, getting the size of the OS pending output buffer would be needed. But once again, this would need to be settable - if your playing on a fast link, a lot of data may get sent to you in a tick, and thus a large ouptut buffer, but it will get cleared very quickly (remember, the server basically forms all the data it will send to the client at the same time, and then lets the OS sending that over the intervening time until the next tick). But also, crossfire does try to be intelligent in caching in some regards. For example, for the map, it only sends what has changed. So if we skip sending the map for a tick or two, chances are that then when we finally get around to sending it, it will have many more changes (OTOH, we do avoid the network overhead). But its also tricky on knowing how to catch up on some of these changes. For example, data is backlogged a bit, and the player kills the monster, and moves onto the space with its treasure. Server sees this backlog, and decides not to send the look window (which is probably the biggest hog in terms of bandwidth). Server does need to know to try to resend that later. IT may work on the fact that we haven't cleared the flag - I'd actually have to think about that further. Its also unclear what can miss a tick. Can you afford to miss an stat update until the connection is speedy? If your hp has just dropped from to 10, you probably want to get that information ASAP, even if it means going on the back of a decent sized backlog. From dnh at hawthorn.csse.monash.edu.au Sat Apr 14 09:48:07 2001 From: dnh at hawthorn.csse.monash.edu.au (dnh) Date: Thu Jan 13 18:00:31 2005 Subject: [CF-Devel] Regarding Vulnerabilites Message-ID: Hmm I think, we shouldn't really have any classes with > 20 for any of the major attack types (fire, ice, elec). It makes the game unplayable or not fun in most cases. For example, the troll currently gets fire -30, that means with every single fire improving item it can only get to 69 fire resistance. This makes life very dull. It would be alot better if 80 could be attained, this at least would be useful against demons etc. But to be honest, I get the defn feeling having no vuns is alot more important than any other factor. dnh From peterm at alfven.EECS.Berkeley.EDU Sat Apr 14 13:29:53 2001 From: peterm at alfven.EECS.Berkeley.EDU (Peter Mardahl) Date: Thu Jan 13 18:00:31 2005 Subject: [CF-Devel] Regarding Vulnerabilites In-Reply-To: Your message of "Sun, 15 Apr 2001 00:48:07 +1000." Message-ID: <200104141829.f3EITr524412@alfven.EECS.Berkeley.EDU> I would MUCH rather REPEAL the "you can never overcome a disadvantage" code AV has put in. I.e., if you have -30 with a troll, you CAN overcome it and get > 70, with the right equipment. PeterM > Hmm I think, we shouldn't really have any classes with > 20 for any of the > major attack types (fire, ice, elec). It makes the game unplayable or not > fun in most cases. For example, the troll currently gets fire -30, that > means with every single fire improving item it can only get to 69 fire > resistance. This makes life very dull. It would be alot better if 80 could > be attained, this at least would be useful against demons etc. But to be > honest, I get the defn feeling having no vuns is alot more important than > any other factor. > > dnh > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel From andi.vogl at gmx.net Sat Apr 14 22:12:42 2001 From: andi.vogl at gmx.net (Andreas Vogl) Date: Thu Jan 13 18:00:31 2005 Subject: [CF-Devel] Regarding Vulnerabilites In-Reply-To: <200104141829.f3EITr524412@alfven.EECS.Berkeley.EDU> Message-ID: <000001c0c559$f1d05f20$303cfea9@kyle> > > Hmm I think, we shouldn't really have any classes with > 20 for any > > of the major attack types (fire, ice, elec). It makes the game unplayable > > or not fun in most cases. > I would MUCH rather REPEAL the "you can never overcome a disadvantage" > code AV has put in. I.e., if you have -30 with a troll, you CAN > overcome it and get > 70, with the right equipment. I believe the current calculation with PR and caps is all fine, except for the fact that vulnerabilities on races suck a little. If we really wanted to remove caps we had to toss the whole calculation- scheme overboard and that would almost certainly make things worse. After discussing with peter and bob on IRC, we came up with the idea to have protection spells override race-vulnerabilities. I'll have a look at the code and see if that can be implemented in a proper way. (I don't plan to check in such a change before V1.0 of course) Andreas V. From peterm at alfven.EECS.Berkeley.EDU Sun Apr 15 19:36:07 2001 From: peterm at alfven.EECS.Berkeley.EDU (Peter Mardahl) Date: Thu Jan 13 18:00:31 2005 Subject: [CF-Devel] Logs from several crashes on crossfire.csua Message-ID: <200104160036.f3G0a7T32067@alfven.EECS.Berkeley.EDU> Hello, Excerpted below are relevant crash logs from crossfire.csua. Crossfire.csua doesn't have the button "fix" I put in (which just prevents a crash but doesn't fix anything). Crash #0-#12: (This one always happens on FreeBSD for some reason). Checking formulae lists...done. Reading skill_params from /home/crosfire/share/crossfire/skill_params...done. Initialize new client/server data error on bind command: Address already in use error on bind command Crash #1: oad_original_map: /styles/specialmaps/powerroom (8) load_original_map: /styles/monsterstyles/undead/undead_2 (8) load_original_map: /styles/treasurestyles/gold_and_gems (8) load_original_map: /styles/trapstyles/traps (8) Adding friendly object Fog. Adding friendly object tourist. Adding friendly object Amy. Saving map /random/0000000000000000 Saving map /pup_land/begin/p1 Resetting map /pup_land/raffle/raffle1. Internal error in update_button (6666). Internal error in update_button (6666). Internal error in update_button (6666). Internal error in update_button (small button). Internal error in update_button (small button). Internal error in update_button (small button). Internal error in update_button (small button). Internal error in update_button (small button). .... (crash.) Crash #14: (Button bug) Trying to load map /home/crosfire/share/crossfire/maps/HallOfSelection. load_original_map: /HallOfSelection (0) enter_map: supplied coordinates are not within the map! (/HallOfSelection: -1, - 1) get_nearest_player: Found free/non friendly object on friendly list Trying to load map /home/crosfire/var/crossfire/players/Son_of_Sam/_city_apartme nt_apartments. load_original_map: /home/crosfire/var/crossfire/players/Son_of_Sam/_city_apartme nt_apartments (2) Checksums: 157c90f5 157c90f5 LOGIN: Player named Son_of_Sam from ip 144.132.33.242 Saving map /pup_land/raffle/raffle2_u1 Resetting map /pup_land/raffle/raffle2. Internal error in update_button (6666). Internal error in update_button (6666). Internal error in update_button (6666). Internal error in update_button (small button). Internal error in update_button (small button). ....(crash) Crash #15: (button bug) LOGOUT: Player named Torg from ip 147.210.12.77 make_path_tofile /home/crosfire/var/crossfire/players/loic/loic.pl... Saving map /pup_land/lone_town/tavern remove_friendly_object called with empty friendly list, remove ob=loic Trying to load map /home/crosfire/share/crossfire/maps/HallOfSelection. load_original_map: /HallOfSelection (0) enter_map: supplied coordinates are not within the map! (/HallOfSelection: -1, - 1) get_nearest_player: Found free/non friendly object on friendly list LOGOUT: Player named loic from ip 147.210.12.74 Saving map /city/oldcity/oldcity12 Saving map /city/oldcity/oldcity10 Saving map /pup_land/lone_town/town Saving map /pup_land/raffle/raffle2_u1 Resetting map /pup_land/raffle/raffle2. Internal error in update_button (6666). Internal error in update_button (6666). Internal error in update_button (6666). Internal error in update_button (small button). Internal error in update_button (small button). Internal error in update_button (small button). Internal error in update_button (small button). Crash #18: (other restarts were due to manual kills) Saving map /pup_land/lone_town/town load_original_map: /styles/floorstyles/lightdirt (8) load_original_map: /styles/monsterstyles/undead/undead_1 (8) load_original_map: /styles/decorstyles/creepy (8) CS: connection from client of type CF DX CLIENT ReadPacket got an error.: Connection reset by peer ReadPacket got error 54, returning 0 Saving map /pup_land/raffle/raffle2_u1 Resetting map /pup_land/raffle/raffle2. Internal error in update_button (6666). Internal error in update_button (6666). Internal error in update_button (6666). Internal error in update_button (small button). Internal error in update_button (small button). Internal error in update_button (small button). Internal error in update_button (small button). Crash #19: Saving map /pup_land/raffle/raffle2_u1 Trying to load map /home/crosfire/var/crossfire/players/San/_city_apartment_apar tments. load_original_map: /home/crosfire/var/crossfire/players/San/_city_apartment_apar tments (2) Resetting map /pup_land/raffle/raffle2. Internal error in update_button (6666). Internal error in update_button (6666). Internal error in update_button (6666). Internal error in update_button (small button). Internal error in update_button (small button). Internal error in update_button (small button). Internal error in update_button (small button). Internal error in update_button (small button). Internal error in update_button (small button). Internal error in update_button (small button). Internal error in update_button (small button). Internal error in update_button (small button). Internal error in update_button (large button). Internal error in update_button (large button). Internal error in update_button (small button). Crash #22: (Some sort of golem bug?) load_original_map: /home/crosfire/var/crossfire/players/Haze/_city_apartment_apa rtments (2) Adding friendly object gatehouse guard. Adding friendly object gatehouse guard. Adding friendly object gatehouse guard. Adding friendly object gatehouse guard. @match chain Chain CHAIN Well, you know the password, so you must be ok. Pass Friend. BUG: hit_player(): Encountered golem without owner. SIGSEGV received. Emergency saves disabled, no save attempted Cleaning up... Saving map /city/city Saving map /city/misc/gatehouse Saving map /world/world_a3 Crash #23: (Unidentified Seg Fault) load_original_map: /wolfsburg/magara/castle/floor_1 (0) Saving map /city/city Resetting map /city/shops/generalshop. Saving map /wolfsburg/dept_store Saving map /wolfsburg/piratetown Resetting map /city/shops/bank. make_path_tofile /home/crosfire/var/crossfire/players/loic/loic.pl... Resetting map /city/misc/HouseofHealing. Resetting map /city/misc/library. CSSTAT: Wed Apr 11 23:55 tot 4005902 45420367 3 74284 inc 41781 366383 1 600 make_path_tofile /home/crosfire/var/crossfire/players/loic/loic.pl... CSSTAT: Thu Apr 12 00:05 tot 4075046 45829762 3 74884 inc 69144 409395 1 600 make_path_tofile /home/crosfire/var/crossfire/players/loic/loic.pl... Fixed inventory in loic (295730 -> 295732) Trying to load map /home/crosfire/share/crossfire/maps/wolfsburg/magara/castle/c ellar. load_original_map: /wolfsburg/magara/castle/cellar (0) SIGSEGV received. Emergency saves disabled, no save attempted Cleaning up... Saving map /wolfsburg/magara/castle/floor_1 Saving map /wolfsburg/magara/castle/cellar Player on map that is being saved Player on map that is being saved the wall name is wwall the wall name is woodwall Crash #24: (button bug) aving map /pup_land/raffle/raffle2_u1 Saving map /pup_land/raffle/raffle2 Saving map /pup_land/terminal_u1 Trying to load map /home/crosfire/share/crossfire/maps/pup_land/raffle/raffle3_u 1. load_original_map: /pup_land/raffle/raffle3_u1 (0) Trying to load map /home/crosfire/share/crossfire/maps/pup_land/hall_of_fame. load_original_map: /pup_land/hall_of_fame (0) Adding friendly object sage. Resetting map /pup_land/raffle/raffle1. Internal error in update_button (6666). Internal error in update_button (6666). Internal error in update_button (6666). Internal error in update_button (small button). Internal error in update_button (small button). Internal error in update_button (small button). Internal error in update_button (small button). Internal error in update_button (small button). Internal error in update_button (small button). Internal error in update_button (small button). Internal error in update_button (small button). From dnh at hawthorn.csse.monash.edu.au Sun Apr 15 20:31:47 2001 From: dnh at hawthorn.csse.monash.edu.au (dnh) Date: Thu Jan 13 18:00:31 2005 Subject: [CF-Devel] Massive problems with crossedit Message-ID: I am getting a crash every 10 mins now. Is anyone getting this? i am using the latest debian release and it is happening when I run pngs. I have yet to see it happen with xpm's. Is there some way I can provide you with more information? dnh From mwedel at scruz.net Sun Apr 15 22:16:00 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:00:31 2005 Subject: [CF-Devel] Massive problems with crossedit References: Message-ID: <3ADA63F0.F79BF80C@scruz.net> dnh wrote: > > I am getting a crash every 10 mins now. Is anyone getting this? i am using > the latest debian release and it is happening when I run pngs. I have yet > to see it happen with xpm's. Is there some way I can provide you with more > information? Any error messages in the window you run crossedit from that might give a clue? run it under gdb ('gdb crossedit, then type run -png in gdb). that will let you see where it crashed, and you can then do a 'where' and see the stacktrace which is useful. From andi.vogl at gmx.net Mon Apr 16 08:18:22 2001 From: andi.vogl at gmx.net (Andreas Vogl) Date: Thu Jan 13 18:00:31 2005 Subject: [CF-Devel] Internal error in update_button() In-Reply-To: <200104160036.f3G0a7T32067@alfven.EECS.Berkeley.EDU> Message-ID: <000001c0c677$b9282e40$7078fea9@kyle> The following bug is causing the great instability of our servers these days. Let's try to fix it. > [...] > Saving map /pup_land/begin/p1 > Resetting map /pup_land/raffle/raffle1. > Internal error in update_button (6666). > Internal error in update_button (6666). > Internal error in update_button (6666). > Internal error in update_button (small button). > Internal error in update_button (small button). > Internal error in update_button (small button). > Internal error in update_button (small button). > Internal error in update_button (small button). > > .... (crash.) First of all, the bug is very easy to reproduce: - Take the map "/pup_land/raffle/raffle1" and set the fixed reset down to 10. - Then start a crossfire server, log in with a char - Enter the raffle1, leave it again, and wait for a short while => server crashes, the log looks pretty much like above. Now, what causes the bug? The bug happens on any map that has a fixed reset and a large number of buttons/pedestals. Shortly *after* the map has been reset (->call to swap_map in swap.c) there are calls to update_button() for that map. (It looks like these calls are unnessecary and wrong, but I couldn't figure out where these calls happen.) The object link - pointers do still exist by that time (leftover?), but the adresses they point to are wrong. update_button actually does the right thing by skipping the calls and printing an error-message. Unfortunately, there are so many errormessages that the server exits. Now, the easiest fix would be to change "llevError" to "llevDebug" for the "Internal error in update_button (...)."-message. But that is somehow a dirty fix. Maybe someone can track the bug to it's roots? Andreas V. From dnh at hawthorn.csse.monash.edu.au Mon Apr 16 09:42:09 2001 From: dnh at hawthorn.csse.monash.edu.au (dnh) Date: Thu Jan 13 18:00:31 2005 Subject: [CF-Devel] After discussing.. Message-ID: Well after all that, is it okay if I change all the players that have anything >20 on the three major resistances to have it reduced? These monsters include, wraith -> fire -30 fireborn -> cold -30 Q -> cold -30 troll -> fire -30 The reason being it is simply to much to have players not being able to reach even 80. Although 80 in itself is not alot, if the player wants to try some of the harder maps, potions of frost and lava will give cold and fire +95 which should be enough. dnh ps. If anyone thinks it is going to far, I suggest we make a compromise, perhaps reduce some other resistance etc. From andi.vogl at gmx.net Mon Apr 16 10:55:39 2001 From: andi.vogl at gmx.net (Andreas Vogl) Date: Thu Jan 13 18:00:31 2005 Subject: [CF-Devel] discussing... race vulns. In-Reply-To: Message-ID: <000001c0c68d$baac0d20$b296fea9@kyle> > Well after all that, is it okay if I change all the players that have > anything >20 on the three major resistances to have it reduced? > > These monsters include, > > wraith -> fire -30 > fireborn -> cold -30 > Q -> cold -30 > troll -> fire -30 > > The reason being it is simply to much to have players not being able to > reach even 80. Although 80 in itself is not alot, if the player wants to > try some of the harder maps, potions of frost and lava will give cold and > fire +95 which should be enough. I've already written a patch to make protection spells overrule race vulnerabilities. (only the "protection from xxx"-spells, not holy word or blessings!) For example: o I play a troll with fire -30, then I cast "protection from fire" which has a bonus of fire +20 (level dependant). => My race vuln is reduced from -30 to -10 temporarily. o I play a troll with fire -30 and cast protection from fire, with fire +45. => My race vuln is reduced to 0, and I get an additional protection of +15 (the latter calculated with diminishing return). o I play northman with cold +30, or human for example. => Everything works like it used to be. I know, having protection spells overrule race vulns isn't very logical, but concerning gameplay and balance I think it really is the best we can do: Since those spells are only temporare, race vulns are still nasty. But they no longer hinder a character to develop properly and have fun. Besides, the protection spell gets increased bonus and duration at higher levels, a nice motivation to advance in wisdom. At some point, a player can reach the "break even" where his protection spell completely negates the race vuln... Considered that spellpath-attunements and WIS-stat also affects the bonus of protection spells, this could be a lot of fun. Anyways, Mark will surely not want me to check in that patch before V1.0. Hence, darth bob you can do what you want for now. But I guess the vulns will be turned up to the old values after 1.0, if my patch is accepted. Andreas V. From andi.vogl at gmx.net Mon Apr 16 11:11:02 2001 From: andi.vogl at gmx.net (Andreas Vogl) Date: Thu Jan 13 18:00:31 2005 Subject: [CF-Devel] BUG: hit_player(): Encountered golem without owner Message-ID: <000101c0c68f$d79282a0$b296fea9@kyle> peterm wrote: > Crash #22: (Some sort of golem bug?) > > Adding friendly object gatehouse guard. > Adding friendly object gatehouse guard. > Adding friendly object gatehouse guard. > Adding friendly object gatehouse guard. > [...] > > BUG: hit_player(): Encountered golem without owner. This bug has been around for quite a while now. It appears frequently in the server logs, so I looked what causes that. The answer is very simple: Whenever a player kills an npc (monster) with the friendly flag set, we get this bug message in the logs "BUG: hit_player(): Encountered golem without owner". Now looking at the code (hit_player in server/attack.c), I discovered that this bug message is totally misplaced and just wrong. Even worse, it has "llevError" set, so if there are too many of em, the server might exit. The reason why this message is in the code: Someone obviously expected every monster with "friendly 1" to be a golem. And if a golem has no owner, that is a bug. But this assumption is totally wrong. There's plenty of friendly npcs, and they are NOT golems, nor do they have an owner. Therefor, unless someone proves me wrong, I'd like the remove this misplaced bug-message from hit_player(). Andreas V. From peterm at alfven.EECS.Berkeley.EDU Mon Apr 16 12:17:58 2001 From: peterm at alfven.EECS.Berkeley.EDU (Peter Mardahl) Date: Thu Jan 13 18:00:31 2005 Subject: [CF-Devel] Internal error in update_button() In-Reply-To: Your message of "Mon, 16 Apr 2001 15:18:22 +0200." <000001c0c677$b9282e40$7078fea9@kyle> Message-ID: <200104161717.f3GHHwj01011@alfven.EECS.Berkeley.EDU> I have already checked in a change to llevDebug into CVS, and had done this some days ago. However, it'd be good if this got fixed. From peterm at alfven.EECS.Berkeley.EDU Mon Apr 16 12:20:43 2001 From: peterm at alfven.EECS.Berkeley.EDU (Peter Mardahl) Date: Thu Jan 13 18:00:32 2005 Subject: [CF-Devel] discussing... race vulns. In-Reply-To: Your message of "Mon, 16 Apr 2001 17:55:39 +0200." <000001c0c68d$baac0d20$b296fea9@kyle> Message-ID: <200104161720.f3GHKh601032@alfven.EECS.Berkeley.EDU> Leave it as it is. It can wait until AV's patch goes in. Mark, this is a patch to improve balance. May it go in before 1.0? PeterM > > Well after all that, is it okay if I change all the players that have > > anything >20 on the three major resistances to have it reduced? > > > > These monsters include, > > > > wraith -> fire -30 > > fireborn -> cold -30 > > Q -> cold -30 > > troll -> fire -30 > > > > The reason being it is simply to much to have players not being able to > > reach even 80. Although 80 in itself is not alot, if the player wants to > > try some of the harder maps, potions of frost and lava will give cold and > > fire +95 which should be enough. > > I've already written a patch to make protection spells overrule race > vulnerabilities. (only the "protection from xxx"-spells, not holy word > or blessings!) > For example: > o I play a troll with fire -30, then I cast "protection from > fire" which has a bonus of fire +20 (level dependant). => My race vuln is > reduced from -30 to -10 temporarily. > o I play a troll with fire -30 and cast protection from fire, with > fire +45. => My race vuln is reduced to 0, and I get an additional > protection of +15 (the latter calculated with diminishing return). > o I play northman with cold +30, or human for example. > => Everything works like it used to be. > > I know, having protection spells overrule race vulns isn't very logical, > but concerning gameplay and balance I think it really is the best we can do: > Since those spells are only temporare, race vulns are still nasty. > But they no longer hinder a character to develop properly and have fun. > Besides, the protection spell gets increased bonus and duration at > higher levels, a nice motivation to advance in wisdom. At some point, > a player can reach the "break even" where his protection spell completely > negates the race vuln... > Considered that spellpath-attunements and WIS-stat also affects the bonus > of protection spells, this could be a lot of fun. > > > Anyways, Mark will surely not want me to check in that patch before V1.0. > Hence, darth bob you can do what you want for now. But I guess the vulns > will be turned up to the old values after 1.0, if my patch is accepted. > > > Andreas V. > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel From hsteoh at quickfur.yi.org Mon Apr 16 13:03:16 2001 From: hsteoh at quickfur.yi.org (H. S. Teoh) Date: Thu Jan 13 18:00:32 2005 Subject: [CF-Devel] Massive problems with crossedit In-Reply-To: ; from dnh@hawthorn.csse.monash.edu.au on Mon, Apr 16, 2001 at 11:31:47AM +1000 References: Message-ID: <20010416140316.A8275@crystal> On Mon, Apr 16, 2001 at 11:31:47AM +1000, dnh wrote: > I am getting a crash every 10 mins now. Is anyone getting this? i am using > the latest debian release and it is happening when I run pngs. I have yet > to see it happen with xpm's. Is there some way I can provide you with more > information? [snip] I'm using Debian as well. The problem is with the Xaw libraries AFAIK. Try linking crossedit *statically* with the Xaw library objects. For me, I installed the XF4 source and compiled the Xaw subdirectory manually, and then instead of -lXaw in crossedit's link line, I inserted the object files from the manually compiled Xaw. Crossedit is very stable for me now. (If this is too troublesome to you, I can send you the binary. Just ask.) T -- You are only young once, but you can stay immature indefinitely. -- azephrahel From dnh at hawthorn.csse.monash.edu.au Mon Apr 16 17:55:30 2001 From: dnh at hawthorn.csse.monash.edu.au (dnh) Date: Thu Jan 13 18:00:32 2005 Subject: [CF-Devel] discussing... race vulns. In-Reply-To: <000001c0c68d$baac0d20$b296fea9@kyle> Message-ID: Okay, this is very cool AV. I wont bother fiddleing considering 1.0 is coming out in a week. dnh On Mon, 16 Apr 2001, Andreas Vogl wrote: > > Well after all that, is it okay if I change all the players that have > > anything >20 on the three major resistances to have it reduced? > > > > These monsters include, > > > > wraith -> fire -30 > > fireborn -> cold -30 > > Q -> cold -30 > > troll -> fire -30 > > > > The reason being it is simply to much to have players not being able to > > reach even 80. Although 80 in itself is not alot, if the player wants to > > try some of the harder maps, potions of frost and lava will give cold and > > fire +95 which should be enough. > > I've already written a patch to make protection spells overrule race > vulnerabilities. (only the "protection from xxx"-spells, not holy word > or blessings!) > For example: > o I play a troll with fire -30, then I cast "protection from > fire" which has a bonus of fire +20 (level dependant). => My race vuln is > reduced from -30 to -10 temporarily. > o I play a troll with fire -30 and cast protection from fire, with > fire +45. => My race vuln is reduced to 0, and I get an additional > protection of +15 (the latter calculated with diminishing return). > o I play northman with cold +30, or human for example. > => Everything works like it used to be. > > I know, having protection spells overrule race vulns isn't very logical, > but concerning gameplay and balance I think it really is the best we can do: > Since those spells are only temporare, race vulns are still nasty. > But they no longer hinder a character to develop properly and have fun. > Besides, the protection spell gets increased bonus and duration at > higher levels, a nice motivation to advance in wisdom. At some point, > a player can reach the "break even" where his protection spell completely > negates the race vuln... > Considered that spellpath-attunements and WIS-stat also affects the bonus > of protection spells, this could be a lot of fun. > > > Anyways, Mark will surely not want me to check in that patch before V1.0. > Hence, darth bob you can do what you want for now. But I guess the vulns > will be turned up to the old values after 1.0, if my patch is accepted. > > > Andreas V. > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > From mwedel at scruz.net Tue Apr 17 00:02:52 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:00:32 2005 Subject: [CF-Devel] Internal error in update_button() References: <000001c0c677$b9282e40$7078fea9@kyle> Message-ID: <3ADBCE7C.78681B36@scruz.net> Andreas Vogl wrote: > > The following bug is causing the great instability of > our servers these days. Let's try to fix it. > > > [...] > > Saving map /pup_land/begin/p1 > > Resetting map /pup_land/raffle/raffle1. > > Internal error in update_button (6666). > > Internal error in update_button (6666). > > Internal error in update_button (6666). > > Internal error in update_button (small button). > > Internal error in update_button (small button). > > Internal error in update_button (small button). > > Internal error in update_button (small button). > > Internal error in update_button (small button). > > > > .... (crash.) > > First of all, the bug is very easy to reproduce: > - Take the map "/pup_land/raffle/raffle1" and set the fixed reset down to > 10. > - Then start a crossfire server, log in with a char > - Enter the raffle1, leave it again, and wait for a short while > => server crashes, the log looks pretty much like above. Thanks for letting me know how to reproduce it. I always like bugs that are easy to reproduce. The real cause is harmless, or at least mostly harmless. What is happening when we delete the map (without saving it), is that delete_map is called, which then calls free_all_objects (which does as it suggests - frees all the objects on the map). This is fine and dandy, but then that goes through and calls remove_ob, which then goes and checks walk on/fly on/ other flags, and if it gets one, calls move_apply, which then looks at the space, and trys to do something. What is happening now is that some of the objects in the button links have gotten freed by the time remove_ob does it stuff, resulting in the error message. I have a simple fix that I'll check in later tonight - basically, if we set the map status to MAP_SAVING, remove_ob does a lot less processing (skips all the walk on/fly on stuff), which is why you don't get those errors on normal map savings. So before calling the free_all_objects, I just set that flag. Seems to work fine. From mwedel at scruz.net Tue Apr 17 00:27:31 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:00:32 2005 Subject: [CF-Devel] BUG: hit_player(): Encountered golem without owner References: <000101c0c68f$d79282a0$b296fea9@kyle> Message-ID: <3ADBD443.D355E640@scruz.net> Andreas Vogl wrote: > > The reason why this message is in the code: Someone > obviously expected every monster with "friendly 1" to be a golem. > And if a golem has no owner, that is a bug. But this assumption > is totally wrong. There's plenty of friendly npcs, and they are NOT > golems, nor do they have an owner. > > Therefor, unless someone proves me wrong, I'd like the remove this > misplaced bug-message from hit_player(). I see no reason for that error to really be there. I agree - while it may be nice to do sanity checking, finding out that a golem is missing an owner when it is killed isn't all important. Doing it when it is attacking may be reasonable. I've removed that debug message, and also put some code in to reaealy check if the object type is in fact a golem. This is now in CVS. From mwedel at scruz.net Tue Apr 17 00:30:17 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:00:32 2005 Subject: [CF-Devel] discussing... race vulns. References: <000001c0c68d$baac0d20$b296fea9@kyle> Message-ID: <3ADBD4E9.93892FC2@scruz.net> As I said on CVS: I don't really want AV's patch in for 1.0. But I thinks its highly likely there will be a 1.01, and potentially more minor patch versions, and it being in there makes sense to me. From highway at cstone.net Tue Apr 17 14:37:16 2001 From: highway at cstone.net (Sean Michael Whipkey) Date: Thu Jan 13 18:00:32 2005 Subject: [CF-Devel] Sustenance Message-ID: <3ADC9B6C.ED8BA68B@cstone.net> It looks like a bug from .97 hasn't been fixed yet. Steven Lembark reported that his sustenance went to -29 when worshipping the Devourers (this was before I got on the list, but I saw Mark Wedel's response). Today, on my .98 server, one character (a Wraith) decided to worship the Devourers and immediately died, due to the same thing. A quick other question: I'm going to hack his save file to fix that. I take it I just need to change "digestion" to -3, as per Mark's comments on 4/5/01 about the proper number for it, correct? SeanMike From peterm at alfven.EECS.Berkeley.EDU Tue Apr 17 17:39:39 2001 From: peterm at alfven.EECS.Berkeley.EDU (Peter Mardahl) Date: Thu Jan 13 18:00:32 2005 Subject: [CF-Devel] Sustenance In-Reply-To: Your message of "Tue, 17 Apr 2001 15:37:16 EDT." <3ADC9B6C.ED8BA68B@cstone.net> Message-ID: <200104172239.f3HMddf03412@alfven.EECS.Berkeley.EDU> > It looks like a bug from .97 hasn't been fixed yet. Indeed, it had not. The problem is that the sustenance from being a wraith is very high: 127. Also, you get a great deal of sustenance from Devourers: 100. Guess what happens when you use 8 bits to represent 100 + 127. In CVS I fixed it so that wraith/devourers get 60 sustenance each. I hope no one gets themselves a +7 ring of sustenance! This should fix it. For hacking your char, set 'digestion' to -3, yes, but also look for your wisdom experience object, and set "food" to "60" or to 0, whichever. Then also edit the "wraith_player_force" to do the same. (Set it to 60.) PeterM > Steven Lembark reported that his sustenance went to -29 when worshipping > the Devourers (this was before I got on the list, but I saw Mark Wedel's > response). > > Today, on my .98 server, one character (a Wraith) decided to worship the > Devourers and immediately died, due to the same thing. > > A quick other question: I'm going to hack his save file to fix that. I > take it I just need to change "digestion" to -3, as per Mark's comments > on 4/5/01 about the proper number for it, correct? > > SeanMike > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel From andi.vogl at gmx.net Tue Apr 17 18:18:45 2001 From: andi.vogl at gmx.net (Andreas Vogl) Date: Thu Jan 13 18:00:32 2005 Subject: [CF-Devel] sleep_delta() doesn't work on windows Message-ID: <000101c0c794$c64260a0$0df7fea9@kyle> The crossfire server compiles and runs under windows without any trouble. Except for the fact that the sleep doesn't work. As you can imagine, this makes the winserver run at lightning speed. We should definitly try to fix that before V1.0. It's the function sleep_delta() in "common/time.c". If all else fails we could make an #ifdef and specify a seperate sleep procedure for windows. When this is fixed, you know what that means for us? The whole friggin world can host a crossfire server!!! :-) Andreas V. From mwedel at scruz.net Tue Apr 17 23:11:30 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:00:32 2005 Subject: [CF-Devel] sleep_delta() doesn't work on windows References: <000101c0c794$c64260a0$0df7fea9@kyle> Message-ID: <3ADD13F2.3C93DA50@scruz.net> Andreas Vogl wrote: > > The crossfire server compiles and runs under windows > without any trouble. Except for the fact that the sleep > doesn't work. As you can imagine, this makes the winserver > run at lightning speed. > > We should definitly try to fix that before V1.0. > It's the function sleep_delta() in "common/time.c". > If all else fails we could make an #ifdef and specify > a seperate sleep procedure for windows. Note that I don't develop on windows, or even use windows if I can at all help it, so don't look at me to fix it or any other windows related code. Note a simple fix may be to put in whatever window call you can use to sleep for 120 ms and ignore the rest of the logic in sleep_delta. You won't lose a lot using that appproach. all the logic in sleep_delta really does is try to make sure that there are 120 ms (or whatever MAXTIME is defined to in config.h) between ticks. So if it took 20 ms to process everything last tick, then it sleeps for 100 ms instead of 120. The cpu power of systems has increased faster than map complexity in crossfire, so in most cases, most ticks only take a few ms. The bigger hit is in loading and saving maps. My hope there is for 2.0 to make that operation threaded. It may very well happen that each map gets its own thread, so one slow map doesn't slow things down for everyone else (except for the cpu time it is taking from the system as a whole). This should also make crossfire actually scale for multi cpu systems. From gros at magellan.fpms.ac.be Wed Apr 18 07:54:38 2001 From: gros at magellan.fpms.ac.be (gros) Date: Thu Jan 13 18:00:32 2005 Subject: [CF-Devel] Crossfire Scripting language Message-ID: <01041808543800.01852@Terminus.magellan.fpms.ac.be> I've found the idea of implementing a scripting language into Crossfire in the 1999-2000 mail archives (Perl was suggested). Is it still planned (perhaps for Crossfire 2.0) or was it cancelled because of lack of interest in such a language ? Commander Gros Ad Dwarvam Aeternam ! From peterm at alfven.EECS.Berkeley.EDU Wed Apr 18 03:16:09 2001 From: peterm at alfven.EECS.Berkeley.EDU (Peter Mardahl) Date: Thu Jan 13 18:00:32 2005 Subject: [CF-Devel] Crossfire Scripting language In-Reply-To: Your message of "Wed, 18 Apr 2001 08:54:38 EDT." <01041808543800.01852@Terminus.magellan.fpms.ac.be> Message-ID: <200104180816.f3I8G9e04443@alfven.EECS.Berkeley.EDU> The consensus is that a scripting language of some sort for crossfire would be very nice. Beyond that, nothing's been decided. Furthermore, no one has volunteered to spearhead this project, so in practice, it has gone nowhere. I personally would be happiest if it were python. Many who would script are not veteran programmers and perl is, I believe, much harder to learn than python. I also like python better because I think it is far more readable. In any case, scripting ought to wait at least a few weeks, until crossfire 1.0 is out. PeterM > I've found the idea of implementing a scripting language into Crossfire in > the 1999-2000 mail archives (Perl was suggested). > Is it still planned (perhaps for Crossfire 2.0) or was it cancelled because > of lack of interest in such a language ? > > Commander Gros > Ad Dwarvam Aeternam ! > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel From dnh at hawthorn.csse.monash.edu.au Wed Apr 18 04:47:49 2001 From: dnh at hawthorn.csse.monash.edu.au (dnh) Date: Thu Jan 13 18:00:32 2005 Subject: [CF-Devel] WTF? Message-ID: Ummm can we PLEASE turn down Dancing Swords? An EDK attacked me with one.. I lost 100hp in one hit. Tell me how you are meant to survive that? It moved as fast as me and I have a speed of 1.7. I got one restore then I was dead.. I WAS level 56 in wisdom but I didn't get enough time to recall.. COME ON. I have lost 15 levels. dnh From andi.vogl at gmx.net Wed Apr 18 12:31:46 2001 From: andi.vogl at gmx.net (Andreas Vogl) Date: Thu Jan 13 18:00:32 2005 Subject: [CF-Devel] sleep_delta() doesn't work on windows In-Reply-To: <3ADD13F2.3C93DA50@scruz.net> Message-ID: <000101c0c82d$743b49e0$bad2fea9@kyle> Mark W. wrote: > > The crossfire server compiles and runs under windows > > without any trouble. Except for the fact that the sleep > > doesn't work. As you can imagine, this makes the winserver > > run at lightning speed. > > Note that I don't develop on windows, or even use windows if I can at > all help it, so don't look at me to fix it or any other windows > related code. I fixed it myself. Now it works as good as it does on Unix. Since the Winserver is doing so fine, I added some Win-Installation Docu. What we could need now is some kind of crossloop script for windows. Is anyone out there capable of doing this? Actually such a thing should already exist somewhere, but I have no idea where to search. Andreas V. From mwedel at scruz.net Wed Apr 18 22:49:56 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:00:32 2005 Subject: [CF-Devel] Crossfire Scripting language References: <200104180816.f3I8G9e04443@alfven.EECS.Berkeley.EDU> Message-ID: <3ADE6064.44660619@scruz.net> Peter Mardahl wrote: > > The consensus is that a scripting language of some sort for > crossfire would be very nice. Beyond that, nothing's been > decided. Furthermore, no one has volunteered to spearhead > this project, so in practice, it has gone nowhere. correct. There are lots of things on the TODO list or that have otherwise been discussed which is just waiting for someone to do them (or for one of the current developers time to free up). My personal thought is that the language for the scripting isn't very important - I don't see the actual scripts being really complicated. What is going to be the big issue is how the scripts can interact with the server code itself. For example, I see the following abilities of the scripting language to be relevant: take some object give some object cast a spell move to some location say something. listen for something watch for something given this, I have a feeling checking status of most of these will make up the bulk of the program. Beyond that, I would see a pretty simple if then/else if type structure. ie: heal = listen_for_something("heal me"); money = take_some_object("500 money") if (heal) { if (money) { say("I hope you feel better)" cast_a_spell("healing") } else { say("Healing will cost 500 silver"); } } else { say("How can I help you?") } Now the above does get into nesting and checking, but is not so complicated that we probably need features of most languages (ie, I doubt we will need arrays, hashes, or many other things). As I was thinking about this today, I realized the other issue is how to store these values accross map saves. you may have something like: if (listen_for_something("password")) { if (given_away_object) { say("Sorry - I don't have that anymore") } else { say("Use this for the betterment of good"); give_some_object("artifact"); given_away_object=1; } } now artifact would start in the npc's inventory, so once he's given it away, he can't give it away again until the map resets. However, between the time the map saves and it resets, if another player visits, we probably still what given_away_object to have the right value, so we get teh first message (I don't have it), instead of the second (use this ...), as the player won't be able to get the object. so given_away_object has to be stored someplace. My idea would be to use just a generic object, with perhaps a type like 'npc_var_holder'. the set and check for variables would use that object. Variable names would have to match the names in the structure, but using such an approach means the state can accurately get saved, and gives a lot of variables to play with (including some strings and floats for example). So in my last example, you could even set some field to the character the object was given to, and adjust the given_Away_object case to be like 'I've given that to $name' or the like. So in short summary: I don't think the language itself will make a big difference - what will really make the difference is how easy it can interact with the C code. My personal preferance would be perl for the following reasons: 1) Perl is already required by crossfire, so if we need to link in any perl libraries, they are already installed. This may not be the case for python or other scripting languages (this is not a big deal if the scipting language has all the parts it needs with crossfire) 2) Going with #1, there may be more perl knowledge with people dealing with crossfire. Ie, to develop, you would only need to know C and perl, which means that more people could potentially fix/help in scripting issues (say a broken npc), compared to using some other language which then means the developers need to know 3 or more languages (but this may noot be a big deal, as the scripting language may not get complicated enough). From dnh at hawthorn.csse.monash.edu.au Thu Apr 19 18:56:58 2001 From: dnh at hawthorn.csse.monash.edu.au (dnh) Date: Thu Jan 13 18:00:32 2005 Subject: [CF-Devel] Re: Updating on metalforge server In-Reply-To: Message-ID: Hello again Rick, I know you lack the access to do so, but could you pass on to bob that Metalforge really needs to be updated. There are some major bugs in 0.97 that are causing undue deaths and broken characters. Very soon version 1.0 will come out (either this weekend on next), could I stress to you it is highly important that as many bug testers are out there before the release. If people aren't playing 0.98 or higher, we can't fix problems cause no one will be playing it to be sure. This applies to all server admins. If anyone is interested I have, and Joris has (and probably Mich) scripts which will auto update using cvs. thanks for you consideration, dnh From mwedel at scruz.net Fri Apr 20 00:16:13 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:00:33 2005 Subject: [CF-Devel] Crossfire Scripting language References: <200104180816.f3I8G9e04443@alfven.EECS.Berkeley.EDU> <3ADE6064.44660619@scruz.net> <01041911032700.02066@Terminus.magellan.fpms.ac.be> Message-ID: <3ADFC61D.FBE76A44@scruz.net> gros wrote: > Suggestion - could anyone try to make a complete list of needed scripting > abilities ? you only sent the reply to me, not the entire list. So I recopy most of the message here. > > > > > given this, I have a feeling checking status of most of these will make up > > the bulk of the program. > > Agree, but do not forget event handling is also an important part. > Some examples: > drop give/take I would think would do this. > apply/unapply unsure how often this may happen in terms of armor/weapons. But having those is probably not a bad idea. > attack more likely, some way to change the status of npc's (peaceful, neutral, aggressive, pet, etc). Similar to what some skills do. > speak I thought I included that. > > Suggestion - could anyone try to make a complete list of interesting events ? This is always hard to do - new features may come out, or someone may think of a new use for an npc. one way to achieve expandibility is to have npc's execute actual commands (who, apply, use_skill, etc). Now most of those functions specifically look to see if a player is doing that command, and if not, doesn't do anything. But allowing the script to execute commands like that would basically mean the npc can do most anything a player could do. > We could use existing Crossfire objects to store script variables, or to pass > variables between different scripts. I used the invisible force object in my > scripting implementation to do just that. For example, I created a sword with > the following script: > > ;;Test Nr 8 - A weapon script_use test > > ;;Get the name of the attacked monster: > (define fobname (get-name (who-is-other))); > ;;Search an invisible inside the sword with that monster name: > (define fob (check-invisible-object-inside fobname (who-am-I))); > (if (zero? fob) > (crossfire-message "Your sword suddenly emits bright light !") > ); > (if (zero? fob) > (create-invisible-object-inside fobname (who-am-I)) > ); > (if (zero? fob) > (kill-object (who-is-activator) (who-is-other) 1) > ); > (if (zero? fob) > (crossfire-message "The light disappears !") > ); > > When attacking a monster, the sword first check if such a monster as already > been encountered. If no, it immediately kills it and an invisible force > object with the name of the killed monster is put inside the sword. If yes, > it behaves like a normal sword. The list of killed monster types is so saved > within the sword. > To save variables between map savings, why not using the mechanism applied > for the Adventurer's Guild to save objects dropped on the floor ? That mechanism still uses normal crossfire objects. The problem is if your holding variables in your script or passing them between scripts, they are external to how crossfire sees them, and so will not be saved. The point is that variables used within the script somehow have to be linked back to crossfire objects, or some external implementation to save these variables would be needed. > If a common language is used, this may not be a problem. Python and others > are widespread if not installed by default on many UNIX-Systems. This is a very dangerous misconception. Just because its widely used hardly means its installed default on many unix systems. I personally find it really annoying when I go to try and install something cool and find out I have a dozen dependancies I need to install first (or some of those may have other ones). > Never forget that people who want to make maps may not be crossfire > developers, so they could know nothing about Perl. I think the scripting > language must be easy to learn so anyone able to use crossedit could also be > able to understand it. That's one of the reasons I didn't choose Perl when > writing script extensions, because it was seen as too complicated by many > people. I didn't knew anything about Scheme/Guile but it only took me a day > to understand it, so I think it is not a bad choice. Note if they are not developers, any language can potentially be difficult to learn. As said, I don't expect the scripts to be going much beyond if something else something else type scripts, which I would hope most people would be able to understand. If anything, a scripting helper in the editor could be added. Many commercial games do that. I also would noto expect the first time map maker to go and make some really complicated NPC script. So you could very well have a simple primer (do this/that to get something done), and of course the advanced developers may be able to use some more advanced features. Easy to learn is only one consideration - to me, one that is just as big is readability of the scripts by others, since almost certainly someone will need to do something with it later on. And scheme has never gone into that category in my mind. From gros at magellan.fpms.ac.be Fri Apr 20 10:05:42 2001 From: gros at magellan.fpms.ac.be (gros) Date: Thu Jan 13 18:00:33 2005 Subject: [CF-Devel] Crossfire Scripting language In-Reply-To: <3ADFC61D.FBE76A44@scruz.net> References: <200104180816.f3I8G9e04443@alfven.EECS.Berkeley.EDU> <01041911032700.02066@Terminus.magellan.fpms.ac.be> <3ADFC61D.FBE76A44@scruz.net> Message-ID: <01042011054200.01588@Terminus.magellan.fpms.ac.be> Le Vendredi 20 Avril 2001 01:16, vous avez ?crit : > gros wrote: > > Suggestion - could anyone try to make a complete list of needed scripting > > abilities ? > > you only sent the reply to me, not the entire list. So I recopy most of > the message here. Ooops... Sorry. This will not happen again > > > We could use existing Crossfire objects to store script variables, or to > > pass variables between different scripts. I used the invisible force > > object in my scripting implementation to do just that. For example, I > That mechanism still uses normal crossfire objects. The problem is if > your holding variables in your script or passing them between scripts, they > are external to how crossfire sees them, and so will not be saved. The > point is that variables used within the script somehow have to be linked > back to crossfire objects, or some external implementation to save these > variables would be needed. In a previous message, you suggested the use of a generic object ('npc_var_holder') to store vars. What I was trying to say is that I used force objects just like that and so a new object was unneeded. > If anything, a scripting helper in the editor could be added. Many > commercial games do that. I also would noto expect the first time map > maker to go and make some really complicated NPC script. So you could very > well have a simple primer (do this/that to get something done), and of > course the advanced developers may be able to use some more advanced > features. > In fact, I was thinking of such a tool. > Easy to learn is only one consideration - to me, one that is just as big > is readability of the scripts by others, since almost certainly someone > will need to do something with it later on. And scheme has never gone into > that category in my mind. That's right - I'll try to use something more easy to read, probably Python. Thank you for your suggestions. Commander Gros Ad Dwarvam Aeternam ! From leaf at real-time.com Fri Apr 20 23:12:26 2001 From: leaf at real-time.com (Rick Tanner) Date: Thu Jan 13 18:00:33 2005 Subject: [CF-Devel] Update for the FAQ Message-ID: Looking at the crossfire FAQ, http://crossfire.real-time.com/FAQs/faq.html I see some new topics that should be added. Here is a few that I have come up with. Yes, I based some of thse questions off the Netrek FAQ list at http://www.best.com/~doosh/netrek/netrekFAQ.html ;) Anyone have some to add? Is there a Windows Client? Has the server been ported over to Windows? How do I create a map? What is crossedit? How do I use crossedit? How do I get one of my maps into the offical distribution? I'm designing a map of my own, where can I get help or feedback on it? I found a bug, what should I do? I have an idea for a new monster/spell/weapon/race/class/NPC/etc. Where should I send it? I would like to start a new server; what kind of hardware will I need? I'm trying to start a new server, and I'm having probems. Where can I get help? How do I get people to play on my server? How do I find other public servers to play on? My character is loosing teeth/skin/other_disease_symptoms. What is that? - Rick Tanner leaf@real-time.com -- From mwedel at scruz.net Fri Apr 20 23:32:52 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:00:33 2005 Subject: [CF-Devel] Re: [Crossfire-cvs] CVS: crossfire/common item.c,1.15,1.16 treasure.c,1.9,1.10 References: Message-ID: <3AE10D74.11EDF28A@scruz.net> Just as a note: What the code below does is hides the face of a potion until it is identfied. In this way, when you find a potion, you don't instantly know its a strength potion by the face it has. Now this feature may not be a real big deal - after all, the potions could still be cursed, so you will still want to do a detect curse before drinking one. But it does mean to some extent that you may not need to identify potions as often. I have looked at all the potion images, so this may not be quite as relevant as it once before (when all the potions were very distinct in appearance, so a potion of strenght had a very unique appearance that nothing else was close to. If thats no longer the case (ie, just looking at a potion face can't tell you what it is), this may not be as big a deal. And even if that is not the case, this may not be that big a deal. But I thought I'd at least bring it up to the developers what this change may really mean for additional comments. crossfire-cvs-admin@lists.sourceforge.net wrote: > > Update of /cvsroot/crossfire/crossfire/common > In directory usw-pr-cvs1:/tmp/cvs-serv29322 > > Modified Files: > item.c treasure.c > Log Message: > Make the faces of potions look better. Required commenting out > some code is all. > > Index: item.c > =================================================================== > RCS file: /cvsroot/crossfire/crossfire/common/item.c,v > retrieving revision 1.15 > retrieving revision 1.16 > diff -C2 -r1.15 -r1.16 > *** item.c 2001/04/04 06:52:31 1.15 > --- item.c 2001/04/21 01:22:43 1.16 > *************** > *** 963,967 **** > > if (op->type == POTION && op->arch != (archetype *) NULL) { > ! op->face = op->arch->clone.face; > free_string(op->name); > op->name = add_refcount(op->arch->clone.name); > --- 963,967 ---- > > if (op->type == POTION && op->arch != (archetype *) NULL) { > ! /*op->face = op->arch->clone.face; */ > free_string(op->name); > op->name = add_refcount(op->arch->clone.name); > > Index: treasure.c > =================================================================== > RCS file: /cvsroot/crossfire/crossfire/common/treasure.c,v > retrieving revision 1.9 > retrieving revision 1.10 > diff -C2 -r1.9 -r1.10 > *** treasure.c 2001/03/28 06:37:48 1.9 > --- treasure.c 2001/04/21 01:22:43 1.10 > *************** > *** 859,863 **** > } > if (op->type == POTION && special_potion(op)) { > ! op->face = potion_face; > free_string(op->name); > op->name = add_string("potion"); > --- 859,863 ---- > } > if (op->type == POTION && special_potion(op)) { > ! /*if(op->face==blank_face) op->face = potion_face;*/ > free_string(op->name); > op->name = add_string("potion"); > > _______________________________________________ > Crossfire-cvs mailing list > Crossfire-cvs@lists.sourceforge.net > http://lists.sourceforge.net/lists/listinfo/crossfire-cvs From meeg at mamia.prninfo.com Fri Apr 20 19:19:02 2001 From: meeg at mamia.prninfo.com (Meegwun South) Date: Thu Jan 13 18:00:33 2005 Subject: [CF-Devel] Literacy Message-ID: <200104210019.UAA05383@mamia.prninfo.com> As the character Uggilly the troll I don't know literacy so then I use literacy and it identifide the scrolls as a troll I can't use them but it identifise them.please fix this.Thank you. Meegwun Southall meeg@prninfo.com From peterm at alfven.EECS.Berkeley.EDU Sat Apr 21 00:32:32 2001 From: peterm at alfven.EECS.Berkeley.EDU (Peter Mardahl) Date: Thu Jan 13 18:00:33 2005 Subject: [CF-Devel] Re: [Crossfire-cvs] CVS: crossfire/common item.c,1.15,1.16 treasure.c,1.9,1.10 In-Reply-To: Your message of "Fri, 20 Apr 2001 21:32:52 PDT." <3AE10D74.11EDF28A@scruz.net> Message-ID: <200104210532.f3L5WWY10699@alfven.EECS.Berkeley.EDU> Yes, what you would have before this change is a blue potion before you identified it. Then, it would turn to another color when you had identified it. Very amazing. Now how about if weapons worked the same way.... First, you start with a generic unidentified weapon: we use a sword image for all unidentified weapons. Then, when you identified it, it turned into an axe, or a quarterstaff. :) OK, so the analogy isn't perfect. But most people can tell the difference between beer and wine and water pretty easily. Why not a potion of cha and a potion of str? After this change, you'll be able to tell without identification something about what sort of potion it is, but as you point out, you won't know if it is cursed or not. This is pretty analogous to spotting cursed or enhanced weapons by their weight difference from standard models. And what do we get from it? Well, new potion images for resist * potions, shock immunity, magic immunity, utility potions (such as speed and self knowledge), and cure* potions. For the alternate set anyway. If people object strongly to not having most potions (heal, magic pow, and heroism already can be identified by looks ) look alike before they're identified, I can do some more coding to make that continue to happen, but that code will involve more than just commenting some stuff out, so it'll have to wait > 1.0. Regards, PeterM > Just as a note: > > What the code below does is hides the face of a potion until it is identfied >. > In this way, when you find a potion, you don't instantly know its a strength > potion by the face it has. > > Now this feature may not be a real big deal - after all, the potions could > still be cursed, so you will still want to do a detect curse before drinking > one. But it does mean to some extent that you may not need to identify potio >ns > as often. > > I have looked at all the potion images, so this may not be quite as relevant > as > it once before (when all the potions were very distinct in appearance, so a > potion of strenght had a very unique appearance that nothing else was close t >o. > If thats no longer the case (ie, just looking at a potion face can't tell you > what it is), this may not be as big a deal. > > And even if that is not the case, this may not be that big a deal. But I > thought I'd at least bring it up to the developers what this change may reall >y > mean for additional comments. > > > crossfire-cvs-admin@lists.sourceforge.net wrote: > > > > Update of /cvsroot/crossfire/crossfire/common > > In directory usw-pr-cvs1:/tmp/cvs-serv29322 > > > > Modified Files: > > item.c treasure.c > > Log Message: > > Make the faces of potions look better. Required commenting out > > some code is all. > > > > Index: item.c > > =================================================================== > > RCS file: /cvsroot/crossfire/crossfire/common/item.c,v > > retrieving revision 1.15 > > retrieving revision 1.16 > > diff -C2 -r1.15 -r1.16 > > *** item.c 2001/04/04 06:52:31 1.15 > > --- item.c 2001/04/21 01:22:43 1.16 > > *************** > > *** 963,967 **** > > > > if (op->type == POTION && op->arch != (archetype *) NULL) { > > ! op->face = op->arch->clone.face; > > free_string(op->name); > > op->name = add_refcount(op->arch->clone.name); > > --- 963,967 ---- > > > > if (op->type == POTION && op->arch != (archetype *) NULL) { > > ! /*op->face = op->arch->clone.face; */ > > free_string(op->name); > > op->name = add_refcount(op->arch->clone.name); > > > > Index: treasure.c > > =================================================================== > > RCS file: /cvsroot/crossfire/crossfire/common/treasure.c,v > > retrieving revision 1.9 > > retrieving revision 1.10 > > diff -C2 -r1.9 -r1.10 > > *** treasure.c 2001/03/28 06:37:48 1.9 > > --- treasure.c 2001/04/21 01:22:43 1.10 > > *************** > > *** 859,863 **** > > } > > if (op->type == POTION && special_potion(op)) { > > ! op->face = potion_face; > > free_string(op->name); > > op->name = add_string("potion"); > > --- 859,863 ---- > > } > > if (op->type == POTION && special_potion(op)) { > > ! /*if(op->face==blank_face) op->face = potion_face;*/ > > free_string(op->name); > > op->name = add_string("potion"); > > > > _______________________________________________ > > Crossfire-cvs mailing list > > Crossfire-cvs@lists.sourceforge.net > > http://lists.sourceforge.net/lists/listinfo/crossfire-cvs > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel From dnh at hawthorn.csse.monash.edu.au Sat Apr 21 03:35:06 2001 From: dnh at hawthorn.csse.monash.edu.au (dnh) Date: Thu Jan 13 18:00:33 2005 Subject: [CF-Devel] Arrrr Message-ID: Mich or AV, could you explain to me why potions in the alternate set have white backgrounds? I am being told by a dxclient user (^TooL^) that they have, even though in the Gimp I would swear they are fine. I told him to delete the cache and he tells me he did that, but they are still white. What is wrong with them? they are 256 indexed pngs without alphachannels AFAICS. They appear identical to other items, which do work. HELP! =) dnh From dnh at hawthorn.csse.monash.edu.au Sat Apr 21 08:42:52 2001 From: dnh at hawthorn.csse.monash.edu.au (dnh) Date: Thu Jan 13 18:00:33 2005 Subject: [CF-Devel] Umm Message-ID: Could someone please send an email explaining exactly; a) how one 'collects arches' b) when one should 'collect arches' c) what to avoid when 'collecting arches' d) the reason for 'collecting arches' thanks very much, dnh From hsteoh at quickfur.yi.org Sat Apr 21 12:08:08 2001 From: hsteoh at quickfur.yi.org (H. S. Teoh) Date: Thu Jan 13 18:00:33 2005 Subject: [CF-Devel] Crossfire Scripting language In-Reply-To: <3ADFC61D.FBE76A44@scruz.net>; from mwedel@scruz.net on Thu, Apr 19, 2001 at 10:16:13PM -0700 References: <200104180816.f3I8G9e04443@alfven.EECS.Berkeley.EDU> <3ADE6064.44660619@scruz.net> <01041911032700.02066@Terminus.magellan.fpms.ac.be> <3ADFC61D.FBE76A44@scruz.net> Message-ID: <20010421130808.A25106@crystal> On Thu, Apr 19, 2001 at 10:16:13PM -0700, Mark Wedel wrote: [snip] > > If a common language is used, this may not be a problem. Python and others > > are widespread if not installed by default on many UNIX-Systems. Do we really need a full-fledged scripting language in CF? I was thinking that a simple, internal scripting language would be sufficient (if-then-else constructs, and a few @apply, @say, @give, etc., should be sufficient for our purposes.) [snip] > Note if they are not developers, any language can potentially be difficult to > learn. As said, I don't expect the scripts to be going much beyond if something > else something else type scripts, which I would hope most people would be able > to understand. [snip] I'm a bit wary of doing an overly-powerful scripting language. It seems to me that a simple internal language should be sufficient; no reason to use Python/Perl/etc.. (In fact, although I myself prefer Perl, I'd say, don't use Perl or Scheme by any means; those languages are meant for computer scientists not ordinary map designers.) Of course, if we *do* decide to go that route, we might be able to build more clever AI into monsters/NPC's than we currently do. Prime example: holy-wording monsters behind earthwalls -- or anything behind earthwalls, really -- even if they're too dumb to break the walls, why should they stand there and let themselves get hurt? Also, it might be helpful if you can actually instruct your pets/followers to do something. Maybe simple commands like "sickem" or "flee" or "stay" (don't attack). T -- MASM = Mana Ada Sistem, Man! From peterm at alfven.EECS.Berkeley.EDU Sat Apr 21 12:19:01 2001 From: peterm at alfven.EECS.Berkeley.EDU (Peter Mardahl) Date: Thu Jan 13 18:00:33 2005 Subject: [CF-Devel] Crossfire Scripting language In-Reply-To: Your message of "Sat, 21 Apr 2001 13:08:08 EDT." <20010421130808.A25106@crystal> Message-ID: <200104211719.f3LHJ1B11447@alfven.EECS.Berkeley.EDU> > On Thu, Apr 19, 2001 at 10:16:13PM -0700, Mark Wedel wrote: > [snip] > > > If a common language is used, this may not be a problem. Python and other >s > > > are widespread if not installed by default on many UNIX-Systems. > > > Do we really need a full-fledged scripting language in CF? I was thinking No, we absolutely don't. I can't imagine using more than 5% of python's capabilities, for example. However, incorporating someone else's scripting language is way easier than writing a simple one of our own. Yes, even a simple one. Furthermore, if we do need more capabilities, they'll be there, instead of needing to be implemented. At least, that's my opinion on it. The most complex interpreter I've implemented myself is a calculator, and THAT done by borrowing lots of code from GNU. (Well, I GLP'd the result, so it is not theft.) PeterM From Philipp.Currlin at t-online.de Sat Apr 21 15:26:19 2001 From: Philipp.Currlin at t-online.de (Philipp Currlin) Date: Thu Jan 13 18:00:33 2005 Subject: [CF-Devel] wrong prices for items Message-ID: <3AE1ECEB.903@epost.de> Hi I just sold gauntlets of Sorig (by mistake). I then picked them up from the floor and it said: gauntlets of Sorig (unpaid) will cost you 227500 platinum coins. Since they were put into my bag I dropped them into my inventory and suddenly I got: gauntlets of Sorig (unpaid) will cost you 1092000 platinum coins. I tried it a second time, and got the same messages again Phil From dnh at hawthorn.csse.monash.edu.au Sat Apr 21 18:54:51 2001 From: dnh at hawthorn.csse.monash.edu.au (dnh) Date: Thu Jan 13 18:00:33 2005 Subject: [CF-Devel] new directx client 1.16 In-Reply-To: Message-ID: Thanks again MichToen, I was getting really worried about all this =). dnh On Thu, 22 Mar 2001, Michael Toennies wrote: > Direct Client 1.16 is out now. > > I fixed a bug with the png transparency loading. > > As i try some out in the last versions with png loading, i forget > a code line in the loader, so it don't handle a special palette > index situation right. > > This is fixed now. > > Notice, that the dx client reads in gray color (which uses alpha mask for > transparency) > and alpha masks with transparency, but the client don't show the > transparency right. > > Thats because in future the png loader is changed, so it tranfers the alpha > mask in a > native format to directX or openGL. > > For true color pngs the client handles all pixel with the RGB value 0 as > transparent, > so its IS possible to use true color pngs with transparency- even without > alpha mask. > > Perhaps the unix client can handle this too, then we have a easy transparent > format for > true color. > > ** Notice that even the Netscape Navigator and Internet Explorer have > problems to handle all > true color pngs with alpha mask and 8bit alpha masks too. Both are counted > from png host as not > 100% compatible. ** > > T > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > From dnh at hawthorn.csse.monash.edu.au Sun Apr 22 03:36:00 2001 From: dnh at hawthorn.csse.monash.edu.au (dnh) Date: Thu Jan 13 18:00:33 2005 Subject: [CF-Devel] Roll call Message-ID: Just a repeat announcement, anyone who is, or should be on the developers list should send a pic + alittle snippet of their life to me. This will then be put on this website; http://mids.student.utwente.nl/~dnh/roll-call/roll_call.html It is a private page for developers to chuckle at.. People I can think of who still haven't sent anything to me are, * MichToen (yes Mich I haven't forgotten.. ) * Bob Tanner * H. S. Teoh * Philc Thanks for your participation and I hope your chuckles are loud and rawkus, dnh ps. Please send image in a format easily recognised in linux (png/jpg/gif are nice). Snippet of life can be any damn thing you want (try not to be too obsecene Mich) if you can't think of anything read through the page for some ideas. From crossfire at suckfuell.net Sun Apr 22 04:55:43 2001 From: crossfire at suckfuell.net (Jochen Suckfuell) Date: Thu Jan 13 18:00:33 2005 Subject: [CF-Devel] Playing Ruggilli and other things Message-ID: Hi! Playing Ruggilli I've been playing Ruggilli with a Quez for a while now. Here's my impression: It was very hard to come by enough wisdom exp so that I could learn the ultimate retributive strike. Since turning is denied, I have to use the Avatar (2x2) or flaming aura to kill monsters. Flaming aura is mainly against smaller monsters, I can't kill the really big ones with it. The Avatar is strong, that's good, but over level 30 wis, it becomes quite boring to always use the avatar. Then I finally got the retributive strike (the server admin was so kind as to add it to my player, since I didn't get it even after excessive praying with high stats and grace). I didn't use it very often though, since it's very dangerous to handle (like snowstorm, you better not stand inside). I would like to see this immolation thing work, but it didn't for me. If this adds exp to wisdom, it would be very interesting. Immolation itself sound pretty cool. (It didn't work in the latest CVS though.) Fact is, I never came over level 45 wis and finally changed the god to Valriel. Although "perceive self" didn't say so, I think Ruggilli must have had a luck penalty: I didn't learn retributive strike, and uncursing items on the altar also takes a _very_ long time. With Valriel, I get items uncursed within seconds! Calculation of resistances I tried Devourer with a Quez and saw that the fire immunity was reduced to 70%! I thought that's multiplicative (in which case -30 wouldn't have done anything to the immunity). Then I tried a Ring of Fire (+30), but I still had only 70%, the ring didn't work!? This was a test character, and when I quit, the ring of fire I had given him was gone, instead of lying on the ground where he quit. Logging in after connection died It happens that the connection is closed while I'm playing, in which case my character remains in the game for about 10 minutes. I can't log in again during that time. If I kick the character (using DM), the player is removed from the game, but still can't log in. If I kick him again, the server crashes. Maybe you can change the login procedure, that if you log in and the player is already there, then he's first removed and then logged in properly. Since password authentication has been done, this should not be an issue. Bye Jochen -- A farmer is a man outstanding in his field. --- eMail jochen@suckfuell.net ----- http://www.suckfuell.net/jochen/ -------- From peterm at alfven.EECS.Berkeley.EDU Sun Apr 22 15:10:54 2001 From: peterm at alfven.EECS.Berkeley.EDU (Peter Mardahl) Date: Thu Jan 13 18:00:34 2005 Subject: [CF-Devel] Word of recall can screw players Message-ID: <200104222010.f3MKAsI19430@alfven.EECS.Berkeley.EDU> Hello, a player at my server Word of Recalled into his apartment. However, he hadn't brought his key, and now he is trapped: somethiing should probably be done about this so it doesn't happen to more people. ------- Forwarded Message From: "Grant Carman" To: Subject: Peter! It's ^TooL^ here, i need help. Date: Sun, 22 Apr 2001 18:35:08 +1000 I cast word of recall, and it sent me to the small apartment building instead of my apartment (since it was the last bed i slept in). I left the key to the small apartment in MY apartment. I can't get out of the small apartment building. No-one but you can help me. I need you to either go into my apartment and get my key, or wait until i come online, then do your 'summon player' thing. ^TooL^ ------- End of Forwarded Message From hsteoh at quickfur.yi.org Sun Apr 22 15:40:12 2001 From: hsteoh at quickfur.yi.org (H. S. Teoh) Date: Thu Jan 13 18:00:34 2005 Subject: [CF-Devel] Word of recall can screw players In-Reply-To: <200104222010.f3MKAsI19430@alfven.EECS.Berkeley.EDU>; from peterm@alfven.EECS.Berkeley.EDU on Sun, Apr 22, 2001 at 01:10:54PM -0700 References: <200104222010.f3MKAsI19430@alfven.EECS.Berkeley.EDU> Message-ID: <20010422164012.A29554@crystal> On Sun, Apr 22, 2001 at 01:10:54PM -0700, Peter Mardahl wrote: > > Hello, a player at my server Word of Recalled into his > apartment. However, he hadn't brought his key, and now he is trapped: > > somethiing should probably be done about this so it doesn't happen to > more people. [snip] Simple. Replace the CheckInv object inside the small apartment with a button that opens the door. I.e., make the door always openable from inside. If someone manages to get inside the apartment, obviously he's the owner, so there's no reason to use CheckInv inside as well as outside. T -- The diminished 7th chord is the most flexible and fear-instilling chord. Use it often, use it unsparingly, to subdue your listeners into submission! From david.delbecq at usa.net Sun Apr 22 15:51:14 2001 From: david.delbecq at usa.net (DAVID DELBECQ) Date: Thu Jan 13 18:00:34 2005 Subject: [CF-Devel] spell: town portal Message-ID: <20010422205114.22046.qmail@www0q.netaddress.usa.net> Dear friends, here follows a patch for crossfire 0.98.0 to add the spell of town portal. Just check out. David Delbecq David.delbecq@usa.net ____________________________________________________________________ Get free email and a permanent address at http://www.netaddress.com/?N=1 -------------- next part -------------- A non-text attachment was scrubbed... Name: patch_crossfire.spell.townportal.0.98.0 Type: application/octet-stream Size: 15759 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20010422/f98b7bcf/patch_crossfire.spell.townportal.0.98.obj From mwedel at scruz.net Sun Apr 22 22:24:47 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:00:34 2005 Subject: [CF-Devel] Umm References: Message-ID: <3AE3A07F.C2B66168@scruz.net> dnh wrote: > > Could someone please send an email explaining exactly; > > a) how one 'collects arches' > b) when one should 'collect arches' > c) what to avoid when 'collecting arches' > d) the reason for 'collecting arches' Note: I use 'you' a lot in the message below, but this meant as a general term, and not you as in darth bob. Requirements to collect the archetypes: 1) Have a copy of the server installed on your system. 2) In the lib directory of the server source, have the 'arch' directory available. Available here means that either this is the location of the arch distribution (ie, where you unpacked it), or is a symlink (ln -s ... ...) to where you have unpacked/cvs checkout the arch directory. To answer your questions: a) From the lib directory described above, type 'rm archetypes; make'. This should do the right thing. b) Simple answer is anytime you change entries in the arch tree, you need to collect them and then install them to take effect. In terms of CVS, whenever changes are made to the arch tree, after the changes are verified to work, you should collect the archs and check them into CVS (so for example, remote sites only need to checkout/update the server, and not have to check out the arch's and rebuild for their own seerver. Note that collecting the archs does not mean your local server (or in the case of a cvs update) will necessarily use them. You still need to do a make install for the arch's (and images) to get copied to where the server expects to find them. The one exception to this case is if you have set up your crossfire installation such that the install directory is the same as your working directory. c) Bugs. As with all checkins to CVS, it should be verified there are no bugs in the built archs. This is hard to test 100%, as the definition of a bug can very (ie, if some monster is worth too much exp, that may be a bug, but not really the type I am thinkg of here). What I am thinking of here are things like typos, bad reference to other items (ie, randomitems, other_arch, face, ...). Most of the last case will be caught by crossfire when it runs, so watch the output of the server at startup to see if it complains about missing archs/faces or other things. Note that a collect of the arch and testing as described above should be done even when just changing the the individual .arc file. After all, some servers may have added their custom archs, and hence rebuild them on a regular basis, so checking in a bad .arc file will still mess them up, even if you haven't checked in a collected version. Or similarly, perhaps someone else has done a cvs update of their arch directory and grabbed your changes, and made some other changes they are committing, and do run the collect process - even though their arc's may be find, your arch's would still cause problems in the collected version. Also, if you are collecting and checking in images, make sure you don't collect the alternate image set and check those in (crossfire.png). this will happen if you have a alternate_image directory/symlink in your lib directory that contains images. d) see answeer to b above. Basically, if you don't collect them, someone will have to at some point in order to use them. the arch tree is not used at all by the server - its existance is to make editing and find files easier. Now this doesn't need to be done for every change you make. For example, if you change 5 things, and you know you are going to change 5 more things tomorrow, you could just wait until then to run the collect. But then by the same token, you should probably wait until then before you run a commit in the arch directory, and commit all 10 at the same time. Now it would be possible for someone to set up a cron job that does an make collect each night, and if any of the relevant files are different, automatically commit them. In this case, when you make a change to the arch directory, youu wouldn't need to run the collect - the nightly collect process would do that for you (and all other developers). OTOH, the creation of such a script is more than just a make collect, cvs commit - some sanity checking should also be done to make sure that make collect did not have errors, that the output files are in fact intact (and not truncated for any of a variety of reasons), etc. From the_real_tomble at hotmail.com Sun Apr 22 22:35:07 2001 From: the_real_tomble at hotmail.com (Tom Barnes-Lawrence) Date: Thu Jan 13 18:00:34 2005 Subject: [CF-Devel] Tentative featurelet request... Message-ID: I know its cruddy timing, but other things are still getting put in anyway, so: At least one of my maps would benefit from a slight change to *either* the creator *or* check_inv code: Currently, creator objects may only specify the base arch and a different name for the object created; The check_inv can only check the object type, slaying field, or name of the *base arch* of items checked for. So if you want a checkinv to respond to an item from a creator, there will still be other items in the game that can also trigger it. For my purposes, this is A Bad Thing. ... I am trying to implement a ticket-dispenser type thing, a bit like the gate-pass dispenser in scorn, but for various reasons, I can't use the method used there. So, I would be grateful if either the creators were patched such that the slaying field of objects could be set too, *or* the checkinv tiles changed to also be able to recognise the *actual* name of items (they currently don't). Presumably, if some unused field could be found for this purpose, such a patch could be applied with minimal effort, without breaking existing maps, and without any sort of side effects. Obviously there would be no changes in playbalance either (depending on what mapmakers use the changes for, I guess). I think the change would make sense in the creator objects, but the slaying field is already used there to specify object name. I could kind-of implement the map with trigger-altars, but it would not work very well IMHO, and there have been other times in the past when I've wanted this feature, and it would be more flexible. Thanks for your time (again), Tomble (Tom Barnes-Lawrence) PS- has any thought been given to making a new type to work like firewalls *used* to, ie- throw out an arch? A few things are still affected by that change, such as the cannons, and the entrance to peterm's firetemple, and I heard someone on the map-list who wanted a wall to fire arrows. Presumably the original code is still around somewhere. _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. From crow at bear.cs.dartmouth.edu Sun Apr 22 22:50:54 2001 From: crow at bear.cs.dartmouth.edu (Preston Crow) Date: Thu Jan 13 18:00:34 2005 Subject: [CF-Devel] random map bugs Message-ID: <200104230350.f3N3osK24170@bear.cs.dartmouth.edu> I've mentioned some bugs with random maps before, and now I have saved files demonstrating what I've observed. Unfortunately, I don't have the original unplayed maps--that would be quite difficult unless there was an option to save the original with a different name for debugging purposes. The maps are at http://www.crowcastle.net/preston/maps/. They demonstrate three bugs: * Traps placed on top of walls. * Sections of the map that are unreachable. * Maps where it is impossible to get a needed key. Unfortunately, it's hard to prove the last one without the unplayed map. I hope this helps. --PC From mwedel at scruz.net Sun Apr 22 23:07:40 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:00:34 2005 Subject: [CF-Devel] Crossfire Scripting language References: <200104211719.f3LHJ1B11447@alfven.EECS.Berkeley.EDU> Message-ID: <3AE3AA8C.3637F0CD@scruz.net> I agree that we don't need a full fledged scripting language. To me, the big question (which I don't know the answer for) is how hard will it be to integate one of these other scripting languages into crossfire. You could very well get into some for of tradeoff, like: roll our own basic scripting language, which is really well integrated with crossfire (as it would use things like @apply and what not, so our interperter would know to directly call the appropriate function with appropriate args, which basically means we need to write the interperter, but not the item actions) vs: We use some other interperter, but have to add glue so it can use the internal crossfire objects (ie, apply, pickup, drop stuff). This may not be too bad if it can use an abstract interface, ie using a call that takes a generic string command like a player may use. There are of course advantages and disadvantages to both beyond just the above. If we use someone elses, it means that there is a very powerful language (but what exactly it can do will largely depend on how well it can access crossfire objects. For example, if the script can't access the map, knowing to do the right thing about earthwalls won't help if it can't find the earthwalls). There is also the problem of someone potentially creating a very complicated script which is needed (ie, key npc) but difficult for anyone else to ever modify (and for a new map maker, who decides to look at said npc to see how to do things, may get overly discouraged by the complexity). I also have some worry about the scripting language performance (just in terms of how much cpu time we will be spending executing scripts), but more worrysome is issues like the script getting in some infinite loop. Granted, that means the script is broken, but that basically means every scripted npc has to be evaluated to make sure they don't do anything bad - this makes adding new maps a little harder. The advantage of using our own is that the script language could certainly lack looping features, so other than it getting called really often, it can't really harm the server. To get back to the original question, and something that may be at least partially related here, one thing that may help determine what abilities the scripting language needs is some idea of what people want npc's to be able to do. Now less keep the ideas realistic here - while theoretically possible to write an npc scripting language so npc's could adventure on their own, I wouldn't expect that to happen. While it may be nice for enemy monsters to have scripts for tactics, that may not only get tricky (as script would need to be a lot more complicated), but it may make just as much sense to improve hte monster movement code to look forr some events. So to me, the short list of things it might be nice for npcs to do: 1) listen/talk to player. 2) give/take items from player. 3) become friendly/agressive towards player. 4) cast spells on player. 5) be able to move to specific coordinates within the same map (in this way you could create a script such that the npc wanders around). Currently, only players use exits, but conceivably, we could allow npc's to use exits, so the npc could traverse maps by going to the correct exit on one map and applying it. 6) apply and unapply items. 7) Perhaps some specials not allowed to player, like teleport to other map or specific coordinates on same map (in this way, for example, you could have a dragon guarding a pass, and given the right events, he 'flys' away and lets the party pass. From mwedel at scruz.net Mon Apr 23 00:00:29 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:00:34 2005 Subject: [CF-Devel] Word of recall can screw players References: <200104222010.f3MKAsI19430@alfven.EECS.Berkeley.EDU> <20010422164012.A29554@crystal> Message-ID: <3AE3B6ED.46FCD65D@scruz.net> "H. S. Teoh" wrote: > > Simple. Replace the CheckInv object inside the small apartment with a > button that opens the door. I.e., make the door always openable from > inside. If someone manages to get inside the apartment, obviously he's the > owner, so there's no reason to use CheckInv inside as well as outside. when that apartment was originally done, that was not an issue (ie, the only way to get in your apartment would have been through the door). Having a checkinv would basically mean you couldn't leave your key behind. I would suggest a button might be a bad idea, as someone may leave stuff on the button, thus unintentionally leaving their apartment open. OTOH, maybe that wouldn't be a terrible thing (when you leave your house, you could leave your front door open also, and if you do so, you deserve what youu get (well sort of - more so in crossfire than real life)) From mwedel at scruz.net Mon Apr 23 00:17:41 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:00:34 2005 Subject: [CF-Devel] Tentative featurelet request... (creators) References: Message-ID: <3AE3BAF5.5F7207F5@scruz.net> To me, the ideal solution is for the creators to have an object in their inventory, and they just duplicate that. this then means that youu can basically make any special object available via a creator. don't expect that code to pop up really quickly. From peterm at alfven.EECS.Berkeley.EDU Mon Apr 23 00:44:30 2001 From: peterm at alfven.EECS.Berkeley.EDU (Peter Mardahl) Date: Thu Jan 13 18:00:34 2005 Subject: [CF-Devel] random map bugs In-Reply-To: Your message of "Sun, 22 Apr 2001 23:50:54 EDT." <200104230350.f3N3osK24170@bear.cs.dartmouth.edu> Message-ID: <200104230544.f3N5iUK20082@alfven.EECS.Berkeley.EDU> Thanks for coming up with these examples. > They demonstrate three bugs: > > * Traps placed on top of walls. Not exactly. The trap is in a chest which is underneath the wall. You can't see the chest, but when you search, it looks under the wall and finds the trapped chest. I guess "find_free_spot" isn't working right, maybe because it gives up and fails, and the chest gets stuck right there. > * Sections of the map that are unreachable. "map-disconected" (sic) The example that you gave me of a disconnected map was one in fact connected, *provided* a key to a door was on your side. There was a wall-like door which needed a key to get through it. > * Maps where it is impossible to get a needed key. I don't understand why you couldn't find the key. As I've said before, keys are made in pairs for every door. One key for one side, the other key for the other side. In the map you showed to me, it's possible both keys could have ended up on the other side of some OTHER door which you could not pass. HOWEVER in this case, both keys should be on the map you showed me. There was ONE key to the door blocking you on the map. Not two. I have to ask, what happened to the other key? Might you have alchemized it? Perhaps in an ice cube? Maybe in your inventory? Slurped up by a pet vampire? Furthermore, the door placement was non-pathological. I.e., I can't see any reason for that placement of door to make a disconnected map: both "sides" of the door were well-defined: i.e., it's just like the routine case where the keyplacement for the door works well. You also showed me a case of a totally disconnected map: map-walltrap-disconnected Yeah, it really is disconnected. It also presumably suffers from the poor chest placement. However, I just can't get excited about the disconnected part. The disconnected part is merely a special map that got plunked down. Not getting access to a special sub map is unimportant. This goes firmly into the "will not fix" bin. I'll look over the code to try to spot any failures in keyplacement, and eliminate the placement of treasures underneath walls. For reporting problems in the future: 1) If you can't get from the entrance to the exit, and you're sure there should be an exit, SHOW ME THAT MAP. Not all disconnected maps are broken. I know I said "you should be able to get from any place in the map to any other place", but these special maps are an exception where it is OK. 2) Please don't use alchemy or pets. 3) Please realized that some "walls" aren't "walls" but in fact, hidden doors. PeterM > Unfortunately, it's hard to prove the last one without the unplayed map. > > I hope this helps. > > --PC > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel From gros at magellan.fpms.ac.be Mon Apr 23 07:11:02 2001 From: gros at magellan.fpms.ac.be (gros) Date: Thu Jan 13 18:00:34 2005 Subject: [CF-Devel] Wall of Thorns map bug Message-ID: <01042308110203.01595@Terminus.magellan.fpms.ac.be> If someone dies on a wall of thorns in the arena, it will be a real death, and not an "arena-death" (-> house of healing). It seems that wall of thorns erases all squares behind it, and that includes the "arena floor" map markers. Is that bug known and already corrected ? Commander Gros Ad Dwarvam Aeternam ! From gros at magellan.fpms.ac.be Mon Apr 23 06:58:10 2001 From: gros at magellan.fpms.ac.be (gros) Date: Thu Jan 13 18:00:34 2005 Subject: Fwd: Re: [CF-Devel] Crossfire Scripting language Message-ID: <01042307581001.01595@Terminus.magellan.fpms.ac.be> Le Lundi 23 Avril 2001 00:07, vous avez ?crit : > I agree that we don't need a full fledged scripting language. The real problem is: do we have time to spend to create a new scripting language from zero ? Indeed, we don't need advanced scripting infrastructure, but that's not the point. Writing an interpreter from zero is a very time-consuming task, and I think extending an existing language is easier (it took me only two weeks to get basic crossfire functions working on Guile, and I am not a professionnal coder). > I also have some worry about the scripting language performance (just in > terms of how much cpu time we will be spending executing scripts), but more > worrysome is issues like the script getting in some infinite loop. > Granted, that means the script is broken, but that basically means every > scripted npc has to be evaluated to make sure they don't do anything bad - > this makes adding new maps a little harder. The advantage of using our own > is that the script language could certainly lack looping features, so other > than it getting called really often, it can't really harm the server. That's a real problem no yet deeply studied. The hard point is that crossfire is not a multi-threaded program. with my current script implementation, a script must end to let the game continue, and there is no lock prevention: if a script takes one hour to terminate, the game will be frozen for all that time ! With the current crossfire architecture, I can see two "simple" solutions: 1 - Refusing badly-written scripts, which means scripted map would have to be extensively tested; impose a maximal script execution time to map-makers. 2 - Implementing some kind of "script server" running in a separate thread, and thus not able to lock crossfire for long periods of time. Following me, 1 is sufficient for now - My own tests showed that you can do quite a lot of things with a script in only a small quantum of time. And intensive map testing is often already done when a new map is submitted. > So to me, the short list of things it might be nice for npcs to do: > 1) listen/talk to player. > 2) give/take items from player. > 3) become friendly/agressive towards player. > 4) cast spells on player. > 5) be able to move to specific coordinates within the same map (in this way > you could create a script such that the npc wanders around). Currently, > only players use exits, but conceivably, we could allow npc's to use exits, > so the npc could traverse maps by going to the correct exit on one map and > applying it. 6) apply and unapply items. > 7) Perhaps some specials not allowed to player, like teleport to other map > or specific coordinates on same map (in this way, for example, you could > have a dragon guarding a pass, and given the right events, he 'flys' away > and lets the party pass. I now consider the above list as my "official" todo list, so if someone thinks npcs should do other things, please tell me. What's currently done for events: 1 - listen/talk: fully implemented. 2 - give/take: implemented, although I'm working on complementary functions. 3 - become friendly/aggressive: implemented. 4 - cast spells on player: fully implemented. 5 - moving: implemented. Basic functions for npc move are present, but I still didn't used them for extensive npc movements. 6 - apply/unapply: work in progress. 7 - npc specials: nothing done yet. I'll also put this week a modified release of crossfire-0.98.0 with scripting support. An old version (0.97.0) is still available on: http://www.chachkoff.f2s.com/crossfire/crossscript.tb2 (tar-bz2) http://www.chachkoff.f2s.com/crossfire/crossscript-maps.tb2 (tar-bz2) Commander Gros Ad Dwarvam Aeternam ! From mwedel at scruz.net Mon Apr 23 01:34:53 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:00:34 2005 Subject: [CF-Devel] wrong prices for items References: <3AE1ECEB.903@epost.de> Message-ID: <3AE3CD0D.F9E16D6B@scruz.net> Philipp Currlin wrote: > > Hi > > I just sold gauntlets of Sorig (by mistake). I then picked them up from > the floor and it said: > gauntlets of Sorig (unpaid) will cost you 227500 platinum coins. > Since they were put into my bag I dropped them into my inventory and > suddenly I got: > gauntlets of Sorig (unpaid) will cost you 1092000 platinum coins. > > I tried it a second time, and got the same messages again I've fixed this up in CVS. Note I believe that while it would display the wrong cost, it would still use the right price when paying if they're in a container. The bug was basically it was passing the container object for it to figure the price from, and not the player object. so its computations were not correct. From mwedel at scruz.net Mon Apr 23 01:46:04 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:00:34 2005 Subject: [CF-Devel] Wall of Thorns map bug References: <01042308110203.01595@Terminus.magellan.fpms.ac.be> Message-ID: <3AE3CFAC.71CB39EF@scruz.net> gros wrote: > > If someone dies on a wall of thorns in the arena, it will be a real death, > and not an "arena-death" (-> house of healing). It seems that wall of thorns > erases all squares behind it, and that includes the "arena floor" map > markers. Is that bug known and already corrected ? no and maybe. The problem here is op_on_battleground (which is the key call to determine if the player is on a battleground) stops when it finds the first floor object. Wall of thorns is another floor object. So player dies, op_on_battlground goes through, finds the wall of thorns is a floor, and says that space is not a battleground. Its a very easy change to modify op_on_battleground to look at all objects beneath the player, and hence go through all the floor objects. Now the comment says: /* A battleground-tile needs the following attributes to be valid: * is_floor 1 (has to be the FIRST floor beneath the player's feet), * name="battleground", no_pick 1, type=58 (type BATTLEGROUND) * and the exit-coordinates sp/hp must both be > 0. * => The intention here is to prevent abuse of the battleground- * feature (like pickable or hidden battleground tiles). */ So from this comment, it having to be the first floor seems intentional, and is in fact emphasized. Can anyone provide illuminatiion why it has to be the first floor object? From dnh at hawthorn.csse.monash.edu.au Mon Apr 23 02:12:39 2001 From: dnh at hawthorn.csse.monash.edu.au (dnh) Date: Thu Jan 13 18:00:34 2005 Subject: [CF-Devel] Word of recall can screw players In-Reply-To: <3AE3B6ED.46FCD65D@scruz.net> Message-ID: Just add a pedestal that only connects when a player is on top, this would protect against this issue. dnh On Sun, 22 Apr 2001, Mark Wedel wrote: > "H. S. Teoh" wrote: > > > > Simple. Replace the CheckInv object inside the small apartment with a > > button that opens the door. I.e., make the door always openable from > > inside. If someone manages to get inside the apartment, obviously he's the > > owner, so there's no reason to use CheckInv inside as well as outside. > > when that apartment was originally done, that was not an issue (ie, the only > way to get in your apartment would have been through the door). Having a > checkinv would basically mean you couldn't leave your key behind. > > I would suggest a button might be a bad idea, as someone may leave stuff on the > button, thus unintentionally leaving their apartment open. OTOH, maybe that > wouldn't be a terrible thing (when you leave your house, you could leave your > front door open also, and if you do so, you deserve what youu get (well sort of > - more so in crossfire than real life)) > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > From mwedel at scruz.net Mon Apr 23 02:23:29 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:00:34 2005 Subject: [CF-Devel] spell: town portal References: <20010422205114.22046.qmail@www0q.netaddress.usa.net> Message-ID: <3AE3D871.B461850C@scruz.net> General suggestion: Please include a description of what any code patch submitted does. It makes it much more useful. Looking at the code, it appears it lets players create 2 and only 2 gates that are linked back to each other. Thus, someone could set up a gate that goes from scorn to santo dominion. It also appears that anyone can use the gates so created. One question/concern: Is there any checks such that players can make their link from say their apartments (where the gate will exist for ever) to some really juicy treasure chamber? Such that the player logs in each day (or every 2 hours really) hops through the gates, grabs the treasure, and logs out again? From jbontje at suespammers.org Mon Apr 23 02:57:50 2001 From: jbontje at suespammers.org (Joris Bontje) Date: Thu Jan 13 18:00:35 2005 Subject: [CF-Devel] spell: town portal In-Reply-To: <3AE3D871.B461850C@scruz.net>; from mwedel@scruz.net on Mon, Apr 23, 2001 at 12:23:29AM -0700 References: <20010422205114.22046.qmail@www0q.netaddress.usa.net> <3AE3D871.B461850C@scruz.net> Message-ID: <20010423095750.A13337@mids.student.utwente.nl> On Mon, Apr 23, 2001 at 12:23:29AM -0700, Mark Wedel wrote: > Town Portal spell... It works splendid, it didn't merge 100% into the latest CVS version, but thats a minor issue. I think this is very usefull and should be put into crossfire AFTER version 1.0 Note to tchize: As you probably know there is some kind of function freeze in the code... because of the 1.0 release > One question/concern: Is there any checks such that players can make their > link from say their apartments (where the gate will exist for ever) to some > really juicy treasure chamber? Such that the player logs in each day (or every > 2 hours really) hops through the gates, grabs the treasure, and logs out again? That works, but it will be one way then... the 'treasure' portal doesn't get saved... (but you can use word or recall to get back) Another item: Town Portal also allows other users to enter your appartment and maybe steal everything... Yet another item: because town portals cant be destroyed or picked up, I already see my appartment filling up with portals. (possible solution: let users be able to 'pickup' their own portals. the pickup action should destroy that portal) Suggestion: Make it possible to destroy portals Make it unable to use town portal in personal maps (like appartments). and/or let the townportals have different strenghts based on the spell level of the user: 1-10: one way town portal, single user, nonsaveble 11-20: two way town portal, single user, nonsaveble 21-: two way town portal, multi user, nonsaveble Userlevel of 110: allow saving (in private maps) Town portal is a very powerfull spell, very handy but also has some risks. Joris Bontje / MiDS From gros at magellan.fpms.ac.be Mon Apr 23 09:33:16 2001 From: gros at magellan.fpms.ac.be (gros) Date: Thu Jan 13 18:00:35 2005 Subject: [CF-Devel] Scriptfire 0.98.0 available Message-ID: <01042310331604.01595@Terminus.magellan.fpms.ac.be> This patch adds Scripting support to Crossfire-0.98.0. Please note this code is still considered beta and far from complete. I put it here only to receive maximum feedback and suggestions about the script extension. Scriptfire requires the GNU Guile/Scheme interpreter in order to be compiled. Commander Gros Ad Dwarvam Aeternam ! -------------- next part -------------- A non-text attachment was scrubbed... Name: patch-crossfire-0.98.0.tb2 Type: application/x-bzip2 Size: 156577 bytes Desc: Scriptfire patch Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20010423/c4e0ea79/patch-crossfire-0.98.0.bin From david.delbecq at usa.net Mon Apr 23 04:04:53 2001 From: david.delbecq at usa.net (DAVID DELBECQ) Date: Thu Jan 13 18:00:35 2005 Subject: [Re: [CF-Devel] spell: town portal] Message-ID: <20010423090453.18929.qmail@nwcst319.netaddress.usa.net> Mark Wedel wrote: General suggestion: Please include a description of what any code patch submitted does. It makes it much more useful. Looking at the code, it appears it lets players create 2 and only 2 gates that are linked back to each other. Thus, someone could set up a gate that goes from scorn to santo dominion. It also appears that anyone can use the gates so created. One question/concern: Is there any checks such that players can make their link from say their apartments (where the gate will exist for ever) to some really juicy treasure chamber? Such that the player logs in each day (or every 2 hours really) hops through the gates, grabs the treasure, and logs out again? --------------- For the link to treasures, it really is a problem, the solution will be to block the portal if the other part is dead (need an apply on teleporters modification, but will do). I don't think it is important to prevent other people to pass through th portal. However, it could be interesting to limit it to people of the same party. I shall also try to make the portal disappear after a certain amount of time. David Delbecq David.delbecq@usa.net ____________________________________________________________________ Get free email and a permanent address at http://www.netaddress.com/?N=1 From david.delbecq at usa.net Mon Apr 23 04:11:17 2001 From: david.delbecq at usa.net (DAVID DELBECQ) Date: Thu Jan 13 18:00:35 2005 Subject: [Re: [CF-Devel] spell: town portal] Message-ID: <20010423091117.11809.qmail@nwcst284.netaddress.usa.net> Joris Bontje wrote: On Mon, Apr 23, 2001 at 12:23:29AM -0700, Mark Wedel wrote: > Town Portal spell... It works splendid, it didn't merge 100% into the latest CVS version, but thats a minor issue. I think this is very usefull and should be put into crossfire AFTER version 1.0 Note to tchize: As you probably know there is some kind of function freeze in the code... because of the 1.0 release > One question/concern: Is there any checks such that players can make their > link from say their apartments (where the gate will exist for ever) to some > really juicy treasure chamber? Such that the player logs in each day (or every > 2 hours really) hops through the gates, grabs the treasure, and logs out again? That works, but it will be one way then... the 'treasure' portal doesn't get saved... (but you can use word or recall to get back) Another item: Town Portal also allows other users to enter your appartment and maybe steal everything... ---> Yes, but in a certain way, making a town portal to your appartements ---> is a way to delibarately say people: ok, am opened, you can come in. Yet another item: because town portals cant be destroyed or picked up, I already see my appartment filling up with portals. (possible solution: let users be able to 'pickup' their own portals. the pickup action should destroy that portal) ---> If you haven't check the things, casting an new pair of portals ---> leads to the destruction of the previous one, so your apps ---> can't get filled with portals and people who makes portals ---> to treasure room shouldn't cast another one to keep the first one ---> alive. Suggestion: Make it possible to destroy portals ---> As said, already done. Make it unable to use town portal in personal maps (like appartments). and/or let the townportals have different strenghts based on the spell level of the user: 1-10: one way town portal, single user, nonsaveble 11-20: two way town portal, single user, nonsaveble 21-: two way town portal, multi user, nonsaveble Userlevel of 110: allow saving (in private maps) ---> And? Town portal is a very powerfull spell, very handy but also has some risks. David Delbecq David.delbecq@usa.net ____________________________________________________________________ Get free email and a permanent address at http://www.netaddress.com/?N=1 From peterm at alfven.EECS.Berkeley.EDU Mon Apr 23 04:23:56 2001 From: peterm at alfven.EECS.Berkeley.EDU (Peter Mardahl) Date: Thu Jan 13 18:00:35 2005 Subject: [CF-Devel] Changes to random map code Message-ID: <200104230923.f3N9NuP20487@alfven.EECS.Berkeley.EDU> Hello, 1) Treasure chests will no longer be dropped under walls, which was the cause of the 'trap in wall' problem Preston Crow noted. 2) Monsters and chests won't appear on exits anymore. 3) Keyplacement code is improved. I fixed this case, which could fail: ######D###### # # As far as I could tell, the two "no key" cases that Preston showed me should have worked even with the old code. PeterM From dnh at hawthorn.csse.monash.edu.au Mon Apr 23 05:33:01 2001 From: dnh at hawthorn.csse.monash.edu.au (dnh) Date: Thu Jan 13 18:00:35 2005 Subject: [CF-Devel] Mark's new GTK client Message-ID: Mark there appears to be a bug.. somewhere along the line you destroyed the up arrow to view histroy. I believe it as the last upgrade you made, but it was working before my upgrade today, and it is now no longer working. MiDS also experiences this problem. thanks, dnh ps. What EXACTLY is the cvs command to grab the client? From jbontje at suespammers.org Mon Apr 23 06:29:44 2001 From: jbontje at suespammers.org (Joris Bontje) Date: Thu Jan 13 18:00:35 2005 Subject: [CF-Devel] Mark's new GTK client In-Reply-To: ; from dnh@hawthorn.csse.monash.edu.au on Mon, Apr 23, 2001 at 08:33:01PM +1000 References: Message-ID: <20010423132944.A15881@mids.student.utwente.nl> Use these commands to define keybindings for the previous and next keys in the command history: bind prevkey bind nextkey after you have done that things work like they should Joris Bontje / MiDS From andi.vogl at gmx.net Mon Apr 23 08:33:36 2001 From: andi.vogl at gmx.net (Andreas Vogl) Date: Thu Jan 13 18:00:35 2005 Subject: [CF-Devel] Wall of Thorns map bug Message-ID: <15120.988032816@www37.gmx.net> > gros wrote: > > > > If someone dies on a wall of thorns in the arena, it will be a > > real death, and not an "arena-death" (-> house of healing). It > > seems that wall of thorns erases all squares behind it, and > > that includes the "arena floor" map markers. Is that bug known > > and already corrected ? > > no and maybe. > > The problem here is op_on_battleground (which is the key call to > determine if the player is on a battleground) stops when it finds > the first floor object. > > Wall of thorns is another floor object. So player dies, > op_on_battlground goes through, finds the wall of thorns is a floor, > and says that space is not a battleground. > > Its a very easy change to modify op_on_battleground to look at > all objects beneath the player, and hence go through all the > floor objects. > > Now the comment says: > /* A battleground-tile needs the following attributes to be valid: > * is_floor 1 (has to be the FIRST floor beneath the player's feet), > * name="battleground", no_pick 1, type=58 (type BATTLEGROUND) > * and the exit-coordinates sp/hp must both be > 0. > * => The intention here is to prevent abuse of the battleground- > * feature (like pickable or hidden battleground tiles). */ > > So from this comment, it having to be the first floor seems > intentional, and is in fact emphasized. Can anyone provide > illuminatiion why it has to be the first floor object? Like stated in the comment, the intention was not to allow hidden- placed battleground tiles. The matter of exp-loss is so important in CF, a player should always know if it is active or not. (And I know from past experiences that "rules" must be hardcoded or mapmakers will always try to break them. ;) ) I certainly didn't know about wall of thorns being of "is_floor 1". And frankly, that is quite stupid for several reasons: The is_floor flag should determine the *floor* tile. Thorns are definitly not floor. That way, thorns will hide all objects below and they can break teleporters. We should take out the is_floor from thorns. If that requires code changes, we do it after 1.0. To prevent such bugs in future, it also seems wise to make op_on_battleground cycle through all floor tiles, not to stop at the first one. Andreas V. -- GMX - Die Kommunikationsplattform im Internet. http://www.gmx.net From hsteoh at quickfur.yi.org Mon Apr 23 08:43:17 2001 From: hsteoh at quickfur.yi.org (H. S. Teoh) Date: Thu Jan 13 18:00:35 2005 Subject: Fwd: Re: [CF-Devel] Crossfire Scripting language In-Reply-To: <01042307581001.01595@Terminus.magellan.fpms.ac.be>; from gros@magellan.fpms.ac.be on Mon, Apr 23, 2001 at 07:58:10AM -0400 References: <01042307581001.01595@Terminus.magellan.fpms.ac.be> Message-ID: <20010423094317.A31728@crystal> On Mon, Apr 23, 2001 at 07:58:10AM -0400, gros wrote: [snip] > That's a real problem no yet deeply studied. The hard point is that crossfire > is not a multi-threaded program. with my current script implementation, a > script must end to let the game continue, and there is no lock prevention: if > a script takes one hour to terminate, the game will be frozen for all that > time ! With the current crossfire architecture, I can see two "simple" > solutions: Actually, this is a very good argument for writing our own script interpreter. This way, we can actually "multithread" scripts -- so a script that takes a long time can actually be broken up across several server ticks. Doing it that way might also make it possible to write scripts that an NPC continually executes (eg. an NPC elf can be continually practising his archery skills by shooting arrows at a target). > 1 - Refusing badly-written scripts, which means scripted map would have to be > extensively tested; impose a maximal script execution time to map-makers. The problem with this is, if we use Guile or Python or whatever else, it's very difficult (if not impossible) to determine the script's execution time. Given a script of sufficient complexity, it may be very difficult even for human examination; auto-verification is out the window. > 2 - Implementing some kind of "script server" running in a separate thread, > and thus not able to lock crossfire for long periods of time. [snip] This sounds plausible, although synchronization might become quite a big issue -- for example, you might get very different results if the server machine for some reason runs the CF server more often than the script server -- the scripts could then get out of sync with the server. And it might produce very different outcomes depending on which machine/OS you run it on, esp. if scripts rely on timing. One thing I like about writing our own scripting language is that the scripts can be run in lockstep with the server, so that timing is always 100% accurate. T -- You've gotten under my skin. That you got there speaks ill of me. That you like it there speaks ill of you. -- Speek, K5 From gros at magellan.fpms.ac.be Mon Apr 23 15:12:58 2001 From: gros at magellan.fpms.ac.be (gros) Date: Thu Jan 13 18:00:35 2005 Subject: Fwd: Re: [CF-Devel] Crossfire Scripting language In-Reply-To: <20010423094317.A31728@crystal> References: <01042307581001.01595@Terminus.magellan.fpms.ac.be> <20010423094317.A31728@crystal> Message-ID: <01042316125801.21498@Terminus.magellan.fpms.ac.be> Le Lundi 23 Avril 2001 09:43, vous avez ?crit : > Actually, this is a very good argument for writing our own script > interpreter. This way, we can actually "multithread" scripts -- so a > script that takes a long time can actually be broken up across several > server ticks. Doing it that way might also make it possible to write > scripts that an NPC continually executes (eg. an NPC elf can be > continually practising his archery skills by shooting arrows at a target). Agree, even if your example is wrong. If you want the Elf to shoot arrows at a target, you only need to assign the script used to fire an arrow to an event called each time he gets the occasion to move (what I called a "time" event). > The problem with this is, if we use Guile or Python or whatever else, it's > very difficult (if not impossible) to determine the script's execution > time. Given a script of sufficient complexity, it may be very difficult > even for human examination; auto-verification is out the window. > 100% true. > This sounds plausible, although synchronization might become quite a big > issue -- for example, you might get very different results if the server > machine for some reason runs the CF server more often than the script > server -- the scripts could then get out of sync with the server. And it > might produce very different outcomes depending on which machine/OS you > run it on, esp. if scripts rely on timing. > Again, 100% true. This would be more or less like programming player bots (through they could get more control over the game). > One thing I like about writing our own scripting language is that the > scripts can be run in lockstep with the server, so that timing is always > 100% accurate. > And true again. The problem with writing our own scripting language is development time (as I said before). But if you are ready to write one, I'm ready to help you. Commander Gros Ad Dwarvam Aeternam ! From crow at bear.cs.dartmouth.edu Mon Apr 23 11:25:46 2001 From: crow at bear.cs.dartmouth.edu (Preston Crow) Date: Thu Jan 13 18:00:35 2005 Subject: [CF-Devel] spell: town portal Message-ID: <200104231625.f3NGPkg25852@bear.cs.dartmouth.edu> I think it would be cool to have a portal spell that would create a pair of portals, but would only work if the portals are on permanent maps. That way you could only use it to link your apartments. This would be much like the teleporters that are pre-installed in the apartments in Scorn, but not pre-configured. I haven't looked at the new spell as it is, but one way that this could work would be: invoke create portal crystals of "name" This creates a pair of linked portal crystals. When a portal crystal is applied in a valid location, a portal named "name" is created. Once both crystals have been applied, the portals will be connected, allowing instant transportation between the two locations. invoke destroy portal This destroys a player-created portal. This would allow a player to create a portal in his apartment and then give the matching crystal to a friend (or another one of his characters), allowing them to connect their apartments. I was thinking of having all the apartments connect to one common room, but have access to it restricted by doors that have the keys in the regular apartments. Hence, you can't get to an apartment until you've bought it. The spell would be a nicer solution. --PC From crow at bear.cs.dartmouth.edu Mon Apr 23 11:37:25 2001 From: crow at bear.cs.dartmouth.edu (Preston Crow) Date: Thu Jan 13 18:00:35 2005 Subject: [CF-Devel] random map bugs Message-ID: <200104231637.f3NGbPh25905@bear.cs.dartmouth.edu> Thanks for fixing the chests in walls. That was confusing. >For reporting problems in the future: >1) If you can't get from the entrance to the exit, and you're sure >there should be an exit, SHOW ME THAT MAP. Not all disconnected >maps are broken. I know I said "you should be able to get from >any place in the map to any other place", but these special maps >are an exception where it is OK. I did once see a map much like the disconnected one I showed you where it was a regular area, not a special area. If I see that again, I'll save it. >2) Please don't use alchemy or pets. I didn't use alchemy or pets. I often use burning hands to clean out the spider webs and junk, but that's not relevant for keys. I also melted all my ice with my flint. I'll watch for this again. >3) Please realized that some "walls" aren't "walls" but in fact, >hidden doors. Yes, I thought I had checked all of that. Sorry. --PC From dluhos at humusoft.cz Mon Apr 23 03:45:45 2001 From: dluhos at humusoft.cz (Jiri Dluhos) Date: Thu Jan 13 18:00:35 2005 Subject: [CF-Devel] (Beginner question) How to add new faces to crossfire.png? Message-ID: <810FD00DE4@humusoft.cz> Hello, I'm a Crossfire beginner so please forgive my stupid questions... I have created some new PNG faces and I'd like to add them to my crossfire.png file. How I rebuild that file? I've downloaded all arch images, added my ones, then used collect.pl but it only rebuilds the index files but not the image files. Is it possible to use truecolor PNGs as faces? I've noticed that some PNGs in the archetype image set are in truecolor format, but they all seems to use some predefined color palette. However, it seems to me that truecolor PNGs could look better? Have a nice day, and lots of sunshine. Sincerely, Jiri "BlueBear" Dluhos From david.delbecq at usa.net Mon Apr 23 12:09:44 2001 From: david.delbecq at usa.net (DAVID DELBECQ) Date: Thu Jan 13 18:00:36 2005 Subject: [CF-Devel] Town portal, party version Message-ID: <20010423170945.4910.qmail@nw173.netaddress.usa.net> Hi, everybody, here is the second version of the spell of town portal Here follow the modifications: modified spell_effects.c (function added: cast_create_town_portal) modified spell_util.c to cast the town portal spellist.h and spells.h to reference the new spell modified apply.c to identify the 2 ways townportal inside apply_manual () the function is_2ways_exit () is used for it. Now the portal only work for his owner and peoples of the same party. It is also blocked if the exit of the portal doesn't exist anymore. It also implements a modified archetype of exit with the tag exp set to 1 when apply_manual find this kind of exit, it check for the presence of a return exit in the destination map (could be usefull in map??) David Delbecq David.delbecq@usa.net ____________________________________________________________________ Get free email and a permanent address at http://www.netaddress.com/?N=1 -------------- next part -------------- A non-text attachment was scrubbed... Name: patch.townportal.crossfire.0.98.0 Type: application/octet-stream Size: 20430 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20010423/ede9e5e0/patch.townportal.crossfire.0.98.obj From Philipp.Currlin at t-online.de Mon Apr 23 12:34:15 2001 From: Philipp.Currlin at t-online.de (Philipp Currlin) Date: Thu Jan 13 18:00:36 2005 Subject: [CF-Devel] maps suddenly broken Message-ID: <3AE46797.3000307@epost.de> We got this bug a few days ago on damn with 0.98.8, this time with CVS from 2001-04-22. There are several tiles missing and the whole information stored in one rune of marking (see below). I also included a screenshot to show what is going on. It was there already when I joined damn so I have no idea what happened but it looks disgusting :-( Has anybody got an idea what could cause this? Last time it got worse after a few minutes and finally the server crashed. Afterwards everything was back to normal. Phil There is no messageendmsg Cha 16 x 14 y 14 level 25 direction 1 end arch cobblestones2 x 14 y 15 end arch dungeon_magic x 14 y 16 end arch cobblestones2 x 14 y 16 end arch rune_mark msg hiendmsg Cha 16 x 14 y 16 level 25 direction 5 end arch dungeon_magic x 14 y 17 end arch cobblestones2 x 14 y 17 end arch dungeon_magic x 14 y 18 end arch cobblestones2 x 14 y 18 end arch dungeon_magic x 14 y 19 end arch cobblestones2 x 14 y 19 end arch dungeon_magic x 14 y 20 end arch cobblestones2 x 14 y 20 end arch dungeon_magic x 14 y 21 end arch cobblestones2 x 14 y 21 end arch dungeon_magic x 14 y 22 end arch cobblestones2 x 14 y 22 end arch cobblestones2 x 14 y 23 end arch cobblestones2 x 14 y 24 end arch cobblestones2 x 14 y 25 end arch cobblestones2 x 14 y 26 end arch cobblestones2 x 14 y 27 end arch cobblestones2 x 14 y 28 end arch cobblestones2 x 14 y 29 end arch cobblestones2 x 14 y 30 end arch cobblestones2 x 14 y 31 end arch cwall_2_1_2 x 14 y 31 end arch sea face sea.114 x 15 speed_left -0.300000 state 3 end arch dungeon_magic x 15 end arch sea face sea.114 x 15 y 1 speed_left -0.300000 state 3 end arch dungeon_magic x 15 y 1 end arch sea face sea.114 x 15 y 2 speed_left -0.300000 state 3 end arch dungeon_magic x 15 y 2 end arch sea face sea.114 x 15 y 3 speed_left -0.300000 state 3 end arch dungeon_magic x 15 y 3 end arch sea1 face sea.114 x 15 y 4 speed_left -0.300000 state 3 end arch pier_1_4 x 15 y 4 end arch sea face sea.114 x 15 y 5 speed_left -0.300000 state 3 end arch dungeon_magic x 15 y 5 end arch cobblestones x 15 y 6 end arch gravestone2 x 15 y 6 no_pick 1 no_pass 1 end arch cobblestones2 x 15 y 7 end arch cobblestones2 x 15 y 8 end arch cobblestones2 x 15 y 9 end arch cobblestones2 x 15 y 10 end arch cobblestones2 x 15 y 11 end arch cobblestones2 x 15 y 12 end arch cwall_3_3 x 15 y 12 end arch cobblestones2 x 15 y 13 end arch dwall_2_2_4 x 15 y 13 end arch cobblestones2 x 15 y 14 end arch sign name To the Port msg Port Area of Scorn -------------- next part -------------- A non-text attachment was scrubbed... Name: test.jpg Type: image/jpeg Size: 53180 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20010423/bcb6ced5/test.jpg From peterm at alfven.EECS.Berkeley.EDU Mon Apr 23 13:25:59 2001 From: peterm at alfven.EECS.Berkeley.EDU (Peter Mardahl) Date: Thu Jan 13 18:00:37 2005 Subject: [CF-Devel] maps suddenly broken In-Reply-To: Your message of "Mon, 23 Apr 2001 19:34:15 +0200." <3AE46797.3000307@epost.de> Message-ID: <200104231826.f3NIPx021255@alfven.EECS.Berkeley.EDU> This could be a bug I introduced in an effort to make Marking Rune and Antimagic Rune durable. I will back out that change in CVS and see if it fixes things. PeterM > This is a multi-part message in MIME format. > --------------040908090108050006060704 > Content-Type: text/plain; charset=us-ascii; format=flowed > Content-Transfer-Encoding: 7bit > > We got this bug a few days ago on damn with 0.98.8, this time with CVS > from 2001-04-22. There are several tiles missing and the whole > information stored in one rune of marking (see below). > > I also included a screenshot to show what is going on. It was there > already when I joined damn so I have no idea what happened but it looks > disgusting :-( > > Has anybody got an idea what could cause this? Last time it got worse > after a few minutes and finally the server crashed. Afterwards > everything was back to normal. > > Phil > > > There is no messageendmsg > Cha 16 > x 14 > y 14 > level 25 > direction 1 > end > arch cobblestones2 > x 14 > y 15 > end > arch dungeon_magic > x 14 > y 16 > end > arch cobblestones2 > x 14 > y 16 > end > arch rune_mark > msg > hiendmsg > Cha 16 > x 14 > y 16 > level 25 > direction 5 > end > arch dungeon_magic > x 14 > y 17 > end > arch cobblestones2 > x 14 > y 17 > end > arch dungeon_magic > x 14 > y 18 > end > arch cobblestones2 > x 14 > y 18 > end > arch dungeon_magic > x 14 > y 19 > end > arch cobblestones2 > x 14 > y 19 > end > arch dungeon_magic > x 14 > y 20 > end > arch cobblestones2 > x 14 > y 20 > end > arch dungeon_magic > x 14 > y 21 > end > arch cobblestones2 > x 14 > y 21 > end > arch dungeon_magic > x 14 > y 22 > end > arch cobblestones2 > x 14 > y 22 > end > arch cobblestones2 > x 14 > y 23 > end > arch cobblestones2 > x 14 > y 24 > end > arch cobblestones2 > x 14 > y 25 > end > arch cobblestones2 > x 14 > y 26 > end > arch cobblestones2 > x 14 > y 27 > end > arch cobblestones2 > x 14 > y 28 > end > arch cobblestones2 > x 14 > y 29 > end > arch cobblestones2 > x 14 > y 30 > end > arch cobblestones2 > x 14 > y 31 > end > arch cwall_2_1_2 > x 14 > y 31 > end > arch sea > face sea.114 > x 15 > speed_left -0.300000 > state 3 > end > arch dungeon_magic > x 15 > end > arch sea > face sea.114 > x 15 > y 1 > speed_left -0.300000 > state 3 > end > arch dungeon_magic > x 15 > y 1 > end > arch sea > face sea.114 > x 15 > y 2 > speed_left -0.300000 > state 3 > end > arch dungeon_magic > x 15 > y 2 > end > arch sea > face sea.114 > x 15 > y 3 > speed_left -0.300000 > state 3 > end > arch dungeon_magic > x 15 > y 3 > end > arch sea1 > face sea.114 > x 15 > y 4 > speed_left -0.300000 > state 3 > end > arch pier_1_4 > x 15 > y 4 > end > arch sea > face sea.114 > x 15 > y 5 > speed_left -0.300000 > state 3 > end > arch dungeon_magic > x 15 > y 5 > end > arch cobblestones > x 15 > y 6 > end > arch gravestone2 > x 15 > y 6 > no_pick 1 > no_pass 1 > end > arch cobblestones2 > x 15 > y 7 > end > arch cobblestones2 > x 15 > y 8 > end > arch cobblestones2 > x 15 > y 9 > end > arch cobblestones2 > x 15 > y 10 > end > arch cobblestones2 > x 15 > y 11 > end > arch cobblestones2 > x 15 > y 12 > end > arch cwall_3_3 > x 15 > y 12 > end > arch cobblestones2 > x 15 > y 13 > end > arch dwall_2_2_4 > x 15 > y 13 > end > arch cobblestones2 > x 15 > y 14 > end > arch sign > name To the Port > msg > Port Area of Scorn > > --------------040908090108050006060704 > Content-Type: image/jpeg; > name="test.jpg" > Content-Transfer-Encoding: base64 > Content-Disposition: inline; > filename="test.jpg" > > /9j/4AAQSkZJRgABAQAAAQABAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRof > Hh0aHBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwh > MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAAR > CAFoAWgDASIAAhEBAxEB/8QAHAAAAQUBAQEAAAAAAAAAAAAAAgAEBQYHAQMI/8QATxAAAgEC > BQMDAgMDCgIGCAUFAQIDBBEABRIhMRMiQQYyURRhI2JxFUJSBxYkM0NygZGhwZKxJjVkddHw > NlRjgoOztOFEdJTD0tM0ovGy/8QAGwEAAgMBAQEAAAAAAAAAAAAAAAUBAwQCBgf/xAAzEQAC > AgIABAUDAgYCAwEAAAAAAQIDBBEFEiExExVBUWEUM3EigQYjJDJSkaGxQmLh8P/aAAwDAQAC > EQMRAD8A07NalKWevqJ5KgRQtGAkGi7M7uP3gfIA8Yi2zymj6nUjzdAgW+owbk6bDj5YC/HO > +2PT1lN9PlWdy/WRUeh6Y9ea+hfxX2NmXnj3DnGZn1Axv/0vybgBe1tuOP6Ryfk79x3FtgDR > 3z6kQuCmbak0BhqgFmYrZdxz3D7ffC/b1MWkURZuTGVDANT7E6duPGoX8c77Yzb9vWLker8m > 7reG2tbcXqNibc89x3Hjq58F1afVuS2NrDS21rDb+k7E2557juPABpUme0UbyrfNGEdrsDDY > k2sN1vc6l+2/OOPnlNHr6keboEC31GDcnTYDb5YC/HO+2M2/b3vt6uyfuKnbWONP/afNhc89 > x3+On1Axv/0vybcADtbbjj+kcn5O/cdxbYA0d8+pELgpm2pNAYaoBZmK2Xcc9w+33wv29TFp > FEWbkxlQwDU+xOnbjxqF/HO+2M2/b1i5Hq/Ju63htrW3F6jYm3PPcdx46ufBdWn1bktjaw0t > taw2/pOxNuee47jwAaVJntFG8q3zRhHa7Aw2JNrDdb3Opftvzjj55TR6+pHm6BAt9Rg3J02A > 2+WAvxzvtjNv2977ersn7ip21jjT/wBp82Fzz3Hf46fUDG//AEvybcADtbbjj+kcn5O/cdxb > YA0d8+pELgpm2pNAYaoBZmK2Xcc9w+33wv29TFpFEWbkxlQwDU+xOnbjxqF/HO+2M2/b1i5H > q/Ju63htrW3F6jYm3PPcdx46ufBdWn1bktjaw0ttaw2/pOxNuee47jwAaVJntFG8q3zRhHa7 > Aw2JNrDdb3Opftvzjj55TR6+pHm6BAt9Rg3J02A2+WAvxzvtjNv2977ersn7ip21jjT/ANp8 > 2Fzz3Hf46fUDG/8A0vybcADtbbjj+kcn5O/cdxbYA0d8+pELgpm2pNAYaoBZmK2Xcc9w+33w > v29TFpFEWbkxlQwDU+xOnbjxqF/HO+2M2/b1i5Hq/Ju63htrW3F6jYm3PPcdx46ufBdWn1bk > tjaw0ttaw2/pOxNuee47jwAaVJntFG8q3zRhHa7Aw2JNrDdb3Opftvzjj55TR6+pHm6BAt9R > g3J02A2+WAvxzvtjNv2977ersn7ip21jjT/2nzYXPPcd/jp9QM1/+l+TbgAdrbccf0jk/J37 > juLbAGgVPqihpp1p+jnctS1gsEKws5Pbse3YDUt2NlFxdhfEdT/yg5XVs4p6fOZyi63WlqKG > pcLcC+iJmci5A2BtffFAirZc2rq6Oor4ayid4KaaWldgiwuk911a2Ka3SDVZu46VIPBH1Iku > RQ0k2US1P1kk+iINM8zCTSxQoGLHUSNNhswcghrg4ANY/nFlzKzxS5lNEFVhLG0BVtWnTY6d > 76lN+N+cE+eU0evqR5ugQLfUYNydNgNvlgL8c77YzCDNRRPXUi+o8to0jrqiNKabUGhRZiFQ > ATqALKoFlFgbDi49z6gY3/6X5NwAO1tuOP6Ryfk79x3FtgDR3z6kQuCmbak0BhqgFmYrZdxz > 3D7ffC/b1MWkURZuTGVDANT7E6duPGoX8c77Yzb9vWLker8m7reG2tbcXqNibc89x3Hjq58F > 1afVuS2NrDS21rDb+k7E2557juPABqVLmFNWV7UkL5jqUXMhaEKNgbey/BB484k/pB/6zV/8 > cf8A/Txm/o/OPqPVFNCPUWWVnV13gh1amtHyLztv23J0k7n/AA1DC3MybKppRLIRTXUb/SD/ > ANZq/wDjj/8A6eF9IP8A1mr/AOOP/wDp4cYWMn19x34aI6vaLL6N6mWetZFIGlGiuSSAALp8 > kYjHzymj19SPN0CBb3MG5OmwG3ywF+Od9sOPWE30/perl+sio9BjPXlvpX8RdjZl549w5xl5 > 9QMb/wDS/JuAF7W244/pHJ+Tv3HcW2Z4lsrYc0iuaSfQ0d8+pELgpm2pNAYaoBZmK2Xcc9w+ > 33wv29TFpFEWbkxlQwDU+xOnbjxqF/HO+2M2/b1i5Hq/Ju63htrW3F6jYm3PPcdx46ufBdWn > 1bktjaw0ttaw2/pOxNuee47jxqODSpM9oo3lW+aMI7XYGGxJtYbre51L9t+ccfPKaPX1I83Q > IFvqMG5OmwG3ywF+Od9sZt+3vfb1dk/cVO2scaf+0+bC557jv8dPqBjf/pfk24AHa23HH9I5 > Pyd+47i2wBo759SIXBTNtSaAw1QCzMVsu457h9vvhft6mLSKIs3JjKhgGp9idO3HjUL+Od9s > Zt+3rFyPV+Td1vDbWtuL1GxNuee47jx1c+C6tPq3JbG1hpba1ht/Sdibc89x3HgA0qTPaKN5 > VvmjCO12BhsSbWG63udS/bfnHHzymj19SPN0CBb6jBuTpsBt8sBfjnfbGbft7329XZP3FTtr > HGn/ALT5sLnnuO/x0+oGN/8Apfk24AHa23HH9I5Pyd+47i2wBo759SIXBTNtSaAw1QCzMVsu > 457h9vvhft6mLSKIs3JjKhgGp9idO3HjUL+Od9sZt+3rFyPV+Td1vDbWtuL1GxNuee47jx1c > +C6tPq3JbG1hpba1ht/Sdibc89x3HgA0qTPaKN5VvmjCO12BhsSbWG63udS/bfnHHzymj19S > PN0CBb6jBuTpsBt8sBfjnfbGbft7329XZP3FTtrHGn/tPmwuee47/HT6gY3/AOl+TbgAdrbc > cf0jk/J37juLbAGkN6gpouqunNrgIrjVALFitl3XnuX7ffDWtr8tzBOlU0ubyimmimCiSAaZ > VZGXgeCVJvtsb4z/APb1i5Hq/Ju63htrW3F6jYm3PPcdx46ufBdWn1bktjaw0ttaw2/pOxNu > ee47jwAaYc2glaphp3zDqRRM+tzFoBC6gD23OxB/xwsUXIc4+ozUwj1FllZ1YZbwQ6tTWiPF > 5237bk6Sdz/gsAGo1jqlXmTMwVQ0NyXK7apfI3xFGfSDeaFioQsfqJBvxqH+DD/I4fZvXJlp > zSrkWoZY3huKeNpHN3kGyqCTz8cXxVf555aqmMHPWVWRbGgnuLgEf2XN9I+4OACe6waR4xUR > BjcI31Mt991/Xkf64H6kGPV1IgCA5H1EtirEg7fqRiFHrTLHfSwz0qFKuf2fPddXN/wvjSR+ > uA/ntlxjOps71KASfoJ+17EAf1XB1L/ngAn/AKhBKt6iPTub/Uyi66tt/kb/AOYwJqNIN5oW > KhSx+okG/Gof4MP8jiGHrOgE7aYs+Jje5Ay6fYtYlSOl84D+eeWqpjBz0qrItjQT3FwCP7Lm > +kfcHABPdYNI8YqIgxuEb6mW++6/ryP9cD9SDHq6kQBAcj6iWxViQdv1IxCj1pljvpYZ6VCl > XP7Pnuurm/4XxpI/XAfz2y4xnU2d6lAJP0E/a9iAP6rg6l/zwAT/ANQglW9RHp3N/qZRddW2 > /wAjf/MYE1GkG80LFQpY/USDfjUP8GH+RxDD1nQCdtMWfExvcgZdPsWsSpHS+cB/PPLVUxg5 > 6VVkWxoJ7i4BH9lzfSPuDgAnusGkeMVEQY3CN9TLffdf15H+uB+pBj1dSIAgOR9RLYqxIO36 > kYhR60yx30sM9KhSrn9nz3XVzf8AC+NJH64D+e2XGM6mzvUoBJ+gn7XsQB/VcHUv+eACf+oQ > Sreoj07m/wBTKLrq23+Rv/mMCajSDeaFioUsfqJBvxqH+DD/ACOIYes6ATtpiz4mN7kDLp9i > 1iVI6XzgP555aqmMHPSqsi2NBPcXAI/sub6R9wcAE91g0jxioiDG4RvqZb77r+vI/wBcD9SD > Hq6kQBAcj6iWxViQdv1IxCj1pljvpYZ6VClXP7PnJXVzf8L40kfrgP57ZcYzqbO9SgEn6Cft > exAH9VwdS/54AJ5qhQ4IqYuCQTUy7rc23Hkb/wCePOqzCGhhnqqmaNKeBZJZGE8t1VAC9rc8 > Ej5xE/zyoDK4WPPro2+nL57qWAJB/C+eMQWf+oYvUVRDktA87fiioqkroniuEt0RpZFbuazE > gj+rt+9gAg4xLMMw9RV0r080sby1LtTLUq0Z0r9IwJVT7Y05VmI2I1HERktRnL5tlUES0VNV > ZnB1KOeKSed4r6dTWnkZFIQuTtcgMgILXE56kmh6UOVUhglhijM9S8cpY3KuYozew7dJcgi4 > PTI848vTGZUuV5jkM9YKkwvkXSJp4HlYEtCAbKCf8fmw2NhgA0ygSloKOjpYGhip4YgiIKiQ > WQWUC/yAtt/thvnWdLkuTVeYSNFMaeNT0xUygySGyqARxqLKL+N78YZp6zota3jz5njsHAy6 > ftY22P4XGykfrih+ufVn7RrKKgoDVSxU8ij6epiZXZ3jIY6CquAkZbfcHqg+MABZXH6hraRq > if1HUvKZ5kZ2mqlLaZWW9kqFUDY2AAA/wJB5jDnlBldXVftuaQQQvKY/qa0arAkj/wDufNj4 > /wB7PfTthlJtcD6qp55/r3/8P9OdrqfqEf8ARnNRb/8ABzf/APB/8P8ATxbtALR/J5VVE/p+ > g+rrZamcPUo0lRUO8kirNIq3vsSAp/wti8Yzb+TTOoHoafK9NcZo6mrGpYH6IvI7WL6dP/8A > lz/ljScJeI/cRfX2FhYWFheWHjVuqUzMzBVBFyXK7XHkb4hjPpBvNCxUKWP1Eg341D/Aj/I4 > ks2rky3LZauRZ2WMrcU8bSObsBsqgk8/HGKj/PPLVUxg56VVkWxy+e4uAR/Zc30j7g4d8P8A > tsos7k91g0jxioiDG4RvqZb77r+vI/1wP1IMerqRAEByPqJbFWJB2/UjEKPWmWO+lhnpUKVc > /s+e66ub/hfGkj9cB/PbLjGdTZ3qUAk/QT9r2IA/quDqX/PG8rJ/6hBKt6iPTub/AFMouurb > f5G/+YwJqNIN5oWKhSx+okG/Gof4MP8AI4hh6zoBO2mLPiY3uQMun2LWJUjpfOA/nnlqqYwc > 9KqyLY0E9xcAj+y5vpH3BwAT3WDSPGKiIMbhG+plvvuv68j/AFwP1IMerqRAEByPqJbFWJB2 > /UjEKPWmWO+lhnpUKVc/s+e66ub/AIXxpI/XAfz2y4xnU2d6lAJP0E/a9iAP6rg6l/zwAT/1 > CCVb1Eenc3+plF11bb/I3/zGBNRpBvNCxUKWP1Eg341D/Bh/kcQw9Z0AnbTFnxMb3IGXT7Fr > EqR0vnAfzzy1VMYOelVZFsaCe4uAR/Zc30j7g4AJ7rBpHjFREGNwjfUy333X9eR/rgfqQY9X > UiAIDkfUS2KsSDt+pGIUetMsd9LDPSoUq5/Z8911c3/C+NJH64D+e2XGM6mzvUoBJ+gn7XsQ > B/VcHUv+eACf+oQSreoj07m/1Mouurbf5G/+YwJqNIN5oWKhSx+okG/Gof4MP8jiGHrOgE7a > Ys+Jje5Ay6fYtYlSOl84D+eeWqpjBz0qrItjQT3FwCP7Lm+kfcHABPdYNI8YqIgxuEb6mW++ > 6/ryP9cD9SDHq6kQBAcj6iWxViQdv1IxCj1pljvpYZ6VClXP7Pnuurm/4XxpI/XAfz2y4xnU > 2d6lAJP0E/a9iAP6rg6l/wA8AE5PMGhmAmja8MhFpnYstjbnYkWPOFiKi9S0eYy1FJCmbB9E > p/Ho5Y0W6aiGLRgDja5Hj5wsAE36mmWClzeR3dEV6csU91uo9wNxYni/jFEGdUUodQ9eNToV > JfdVBXg673azf8V97YuvrCV4ctzp430OGpwHt7byuL/a3N+RyMZRHBBGZ9M6kMrSqXOlwt7B > bG5ufgX5G9r4V5mVZVPliKM/Ltpny1ssEmdUahtX7RQu8ZUGQnt7TcDUDdgp+TZr3wYzujlD > sHzAIDGodSRp8lb6/cdLb8955titho3UNGIyUVozoJ3N7g/5G233+9+IDUsAqLEhujeRYABT > fe5On/T44yeYXGDzS/3LL+26N11h67S7BFbVsoXSWF9W7Hffkav0xwZ1RSh1D141PGQS+6KC > vB13ubN/xX3tiuUrfSNEsEulgNnK+0nTv9rX58ab7HAlaWkiqpWqUEYRp9T7Mqg2AtubkeBf > kb2vgWfe3pM6XEcmT1F9fwWOTOqNQ2r9ooXeMqDIT29puBqBuwU/Js174MZ3RzB3D5gqAxqH > UkafJW+v3HS2/PeebYzGX1JWioslPSR6Y7KulibNuCe7kE6dud9rkBgf1JXvcLFSKCoWwRjf > YD+I82U7fO2xUNtTy9d0MlDiGvQ1H9t0brrD12l2CK2rZQuksL6t2O+/I1fpjgzqilDqHrxq > eMgl91UFeDrvc2b/AIr72xl9L6lzKjVRB9OGUHS/TJIJ8+7n22t9iN9JYI/UFfGJNC05Mhvc > oxI+ADqO24+efN11T/We6B18Q9GjUZM6o1Dav2ihd4yoMhPb2m4GoG7BT8mzXvgxndHMHcPm > CoDGodSRp8lb6/cdLb8955tjLz6lriylYaQWQoLRtvc3B9x33A2+fNxqTepK57hYqVQVC2VG > N9gP4jzZTt87bFQx/We6Dk4h8GoftujddYeu0uwRW1bKF0lhfVux335Gr9McGdUUodQ9eNTx > kEvuigrwdd7mzf8AFfe2KplFWrU1NLSzBSykhyL6TcAm/wBjtf8ALceMOUggjM+mdSGVpFLH > S4F7Bbb7n4F+Rva+MUs6+MnFi6fEMmMnH1/BL1nqnKaJ9FTLmELylHUF2Nk7e42bt1WO9+Gv > fDl/UGXiGWeSauigQxqZi+kJ503121HS2537zzbFJyGngr86quuiSK0zL28EKbC1vsBhQ5ZP > WeoJqRE101LVSwwRWOlURyi3/iNlAufA/W+13Wa79u56KGJkTrhJS79y8wZ5Q1ao8E1Y6TsI > 4nV7gadJKg6iC5udzuNf+OCzLLmnl+pWWupaumIEMrEOFDCO6FS2+pgpJGk3/eFjeEpJaef1 > LC9EHaARJH/RRYyupILKQRtYouq4uE220nFoeUkzqBXDQ0aqNYbSG0bDv3Y6j3eNXO2NGPZK > afMyqpvmlFy3p9zPIayXMqP6+rcvV1kZnmZ99RKykWvvZRpUb7AAeMSnp0E1eRkdb/qNbmFr > PbqQA2Nx+l77A/a2IXK7/wA3aQWawpVOlrW3SXcXH+OH+V11DHR5RVweoctpamHLkpnjmIc7 > iMniRSpugHO1zxbt0lxfJmVJJx1KpgnTXUH9ouuwu1yzar6vGvnbGceohT0vqnM6upSYOssd > PErNchpKaMEk392wvudi3OJ39ve+3q7J+4qdtY40/wDafNhc89x3+IGuocvzDNmzCb1hlRdn > DmPpqyFhGEDENMbkAAgk7En72ALT6f2ytvH9Lqf/AJ8n/h/pztdS9Q/+jOai3/4Obx+Q/wDh > /p4t2w9FXU9BT9CH1XkZTqPILwi93cueJx5P/L427WV8FdQVFHJ6ryMRzxNExWEA2YW2vPb/ > AMj42ALT/JiweKMXmkKz1Qvqskf4r7Wvud73t+9bGnYyT+T2pipM8pqCD1Hl1dHI8z9GMEOd > QZzpAmI2O/tJtf721vCXiP3EX19hYWFhYXlhE+pZVgyCold3RFKainutrW4BuLE8X8YoAzqi > lDqHrxqdCCX3VQV4Ou92s3/Ffe2L16uleH0xVvG+hwYwHt7byKL/AGtzfkcjGQMtLSRVUrVK > iMI02pzZlQGwFtzcjwL8je18X1ZNtf6YCLiWTdXaoVepY5M6o1Dav2ihd4yoMhPb2m4GoG7B > T8mzXvgxndHMHcPmCoDGodSRp8lb6/cdLb8955tjMZfUlaKiyU9JHpjsq6WJs24J7uQTp253 > 2uQGB/Ule9wsVIoKhbBGN9gP4jzZTt87bFQzFPL13QKHENehqP7bo3XWHrtLsEVtWyhdJYX1 > bsd9+Rq/THBnVFKHUPXjU8ZBL7qoK8HXe5s3/Ffe2MvpfUuZUaqIPpwyg6X6ZJBPn3c+21vs > RvpLBH6gr4xJoWnJkN7lGJHwAdR23Hzz5uuqf6z3QOviHo0ajJnVGobV+0ULvGVBkJ7e03A1 > A3YKfk2a98GM7o5g7h8wVAY1DqSNPkrfX7jpbfnvPNsZefUtcWUrDSCyFBaNt7m4PuO+4G3z > 5uNSb1JXPcLFSqCoWyoxvsB/EebKdvnbYqGP6z3QcnEPg1D9t0brrD12l2CK2rZQuksL6t2O > +/I1fpjgzqilDqHrxqeMqS+6KCt7HXe5s3/Ffe2KplFWjU1NLSzBSykhyL6TcAm/2O1/y3Hj > DzpRfiMsqCMRlgT2tzYAjfcgbAX5ve18YZ598ZOLFs+I5MZOPqT0mc0ihyRmKFmjYAyE9vab > 21A3YKd9zZr3wQzqklVnD5gqXRQ6k9vBK31+46W357zzbFfWRo0vEEQ6GibRe5uf9wbbWvvf > k3GyO4DAohIjbQuqwsoHJtc2J8cfHEeY3nHmt76bLGc5pCofVXBZCFRi1goXSWF9W7Hffkav > 0wIzqilDrrrxqdCCX3RQV4Ou92s3/Ffe2ICKokR4+lOUIFxcXCE6Rcc2I2357QebWa5g4paS > aWnZXbR+ECNLXLWFwedhchSe253scTDPvlJR9zuviGTZJQj3ZaJM5o1DkjMULNGwBkJ7e0g2 > 1A3YKd99mvfBDO6OVWcPmCpqRA6kjT5K31+46W+/eebYyPNcvSkqbhWeNwdUjm51Akb8cgX/ > AOI7bFWJjTe6L99rfP6ff488W/DaRVrW+f8A4H7xshdHPr+Dd8uzWmqKkhBVt1opUiMh7V0x > km/cbtyfkasLGW+gUQetKQ6VDdKo8W/sZP0+/wDrttZFi6Cml1ezqNdkVqUts3X1vY5PnYIu > NVPcf/Ff/XGVhIwYpXl6ZDe47KLdu9tz5J/U/ONV9bf9UZ4LXJNOB+ple2MmRhUWUMwjFlXS > moEabMSfsANrb3O/yo4j91CDiu/GX4PSCNlpgIlcU+tbkLuzeB9uGO/HjHS/XpY41ULIQwGh > SDc7An58AAbdrbC9ykkVHipZHYIiX1LZrKe7kcmx4uN9ja2BF5+oKWMh+sEiNy7NY7LcCxvz > sPA4wuW9itJ7DlCOwKGVoYwkSFzdiOSLeNze3yeTziOrelLJErrI4S7uES4BAYR8EEm6M1wd > grE7E4kZfe6BV9+nSragG+AfIFx9vj5x4ZVW0iwZ4qVTRVcoWCDpsCdAiBe6mwN+mq6gCQWF > rXvjViJufNrehlwmpWZO5ehUc0y6pp0y53jVTVIZE6l1tFuCTqG3sJuLgi3NyMNPoqv98U4/ > ivONvm+x/wDafPtbnfXM5nD0q/LDLWB6j6RJ5Sdgp0KI14S4ERjJ54YXOF1NP9ppt/FJfTb5 > 7/Gnf+4/zhzCb5UezUFLqQ30VX++KcfxXnG3zfY/+0+fa3O+tfRVf74px/FecbfN9j/7T59r > c76pnqaf7TTb+KS+m3z3+NO/9x/nC6mn+002/ikvpt89/jTv/cf5xPOyfCRAzUda3TgEUTS1 > DiFAs1zrbYD/ABOsc8g3O7FrFR1S5LUT0U2QUk7xPG7/AF88baGOotuAxKmN7gElQVZrEkjH > izdysJnjaO5VhMQU2KncSeBcH+4/zhKwTURKQSzOxklLG5JJJvJvuDf+4/zjrxOhw6dy+Bx6 > fEvWqlkpYIU7CRDIzXJZr8k3II08/uC+oksZ60SdOeSYRBW3c7IoHbc23PBJ/U/OInJV1Grl > JJJlWEAuTbSuwO53Bex35H3OH8UX7UDSSyCHKYFGuQj+s2C225B2FgLsTYXBF098XZe9HlL8 > WWTnSjX0S7sbejBFJ6mkp4hIIOpcFxZjcA3+3P8AlbDuGskzLKVWOIQ/W65p9Ju0jSHURa1l > QszALdiwWzaRcN4Uk7UHqjMq2niVNFAauKJyG0lYjpDFTY30KSAdrkXNr4cU8Q6HQo42ukix > QMSXdgpsq3AAN+dhyBsMW5E+Vbj66GnEsyVONCFMu/TZJZfY5pAYnqOlGFiRgbuVsSR+Um/z > tfk2vizSAqJxIK5AHjIJk3Udmy999RJNzxdjvtir0eo5tCqCQETgFadtR2vcKQRtYjcHYcYt > EjiQzpeuQI0YX8S+m+ghRZ92JPP5udsaeG/bZk4U26237meemKJc3hyfLSyGN4EkqNQtaAax > ICRv3F1TY3GvUODja+sGkKCeHUWsNVRJ3KQSAf8AiH+Rxmf8n1fT5FkbHMYM4jzF4zDIiZfO > enGq/hqSEINyztfkawPAxbx63ysv3NntkYAuKCa66tOx/C+bf5j5wxGpOLVIWjZpo+m24JqZ > brstxjn1GkG80LFQpY/USDfjUP8ABh/kcQyes6ISagmfF1IEqDLp9mstv7Lz/wCeceMnrbL4 > qeURpn83T0gRLQTajsCACYwA2rSBcgG4wAHm3qCujr56DLIo3MSp1axp5HWPW3YgXUutrMCQ > WXSGU73tikQeuvUGV/ykn07NNNmVHNNFGRUnTJEHQFmvEALAuWNwdl5G5xZMvhlhgmerNbNX > zOs1Y0cwKiR9FwtyNgCFBPtQAau3EFlkWX5V/KDnOeV0OYrIkcMNE0NNJNpJhQMzMqMLkkLs > 192B5GADVaSYNXRgTRtcMRaZ2LLc22OxIsecS2KrlHqWjzHOUpIUzYPqY/j0csaLddRDFowB > xtcjx84tWEvEfuIvr7CwsLCwvLCA9agH0lW3FxeL/wCYv+uMXrejLJErrI4S7uES4BAYR8EE > m6M1wdgrE7E42n1p/wCiVaLXJ6YH6mRbYyDKq2kWDO1SqaKrlCQQdNgToEQL3UkA36arqAJB > YWte+NGKv5nNrehRZUrM9c3oio5pl1TTplzvGqmqQyJ1LraLcEnUNvYTcXBFubkYafRVf74p > x/FecbfN9j/7T59rc765nM4elX5YZawPUfSJPKTsFOhRGo2S4ERjJ54YXOF1NP8AaabfxSX0 > 2+e/xp3/ALj/ADhxCb5UO1BS6kN9FV/vinH8V5xt832P/tPn2tzvrX0VX++KcfxXnG3zfY/+ > 0+fa3O+qZ6mn+002/ikvpt89/jTv/cf5wupp/tNNv4pL6bfPf407/wBx/nE87J8JEDNR1rdO > ARRNLUOIUCzXOttgP8TrHPINzuxaxUdUuS1E9FNkFJO8Txu/188baGOotuAxKmN7gElQVZrE > kjHizdysJnjaO5VhMQU2KncSeBcH+4/zhKwTURKQSzOxklLG5JJJvJvuDf8AuP8AOOvE6HDp > 3L4HHp8S9aqWSlghXsJEMjNclmvyTci2nn9wX1EljZNADRLKoRth3KQBcAK225Njq2+3N8Qm > SrqNXIbkmVYQC5NtK7A7ncF7Hfkfc4mAVcBe4G406UvZbWY/qAB437sIc17uejxHE9fVS5fQ > JVJVH6OuJSF5OxNxcb7NcE7/AB8YIsJII0VVLgkWUEFvuTbe+wAHw2wvfAkE1Bed3Cyks8gO > s7gN87mx4uNyAeMGEtIoWnZuoymEHUxdQ1goItcGx3FrldrYymDTPOodXKKhkaJAqLq5088e > Lm5t4+TziOaP6+vgEs8dNSh2p+sy9iNps0hOykAEb3BHeD84c5hMaOjqZAFLRKxtq1DUAfI5 > HHG3xhVWXUeULlMtZTVDxSwmepZZO2SIrwpuveVBLHbubZiANOzEiknJ9/QfcCxue52v0ILO > FpqzodBJBTPUhoVLktb8UqCwLH4ubnyb+cMFyinGnSk5ta15JBf22v27cJ+l2/hFpHNjPUZ+ > TUwKakLKZ1tdUdpSLfvixIYcna5uceXT1f2eq/8AFHbVf57POrf++/xhtW2oI9dJKUm2PvRm > WrB60y+SJXEaU9SS0hkJv0CAB22Btvvt7hyAMLD/ANHJ/wBJ6dtF/wAKc6mSx/qX39g37r88 > u/xhY0Ql0MlsEpGu+tl15Rnq3tfob3t/avjLYzeFYowEuTf26bMbbAjY2/2ItpxqvrCV4ctz > p4n0PqpwHt7byuL/AGtzfkcjGURwQRmfTOpDK0ilzpYLewWxubn4F+Rva+E/EvunluLRfipo > MCNJNUyyKGUkKvNyCYxY+ODtyMA4applBZ2jisi39ouCVX7G4Y/+TjgaN1DRiMlFaM6Cdze4 > P+Rtt9/vfiA1LAKixIbo3kWAAU33uTp/0+OF6Qp6BkdRNYAVXLjWD72vqNzxq3H+n64bZTSU > 7wZ/LNFSuEkTowuCpMjRkhl5vpUM2nSeAe3TfHvSt9I0awS6WAuHK+0nTv8Aa1+fGm+xxC1N > StPU1qRPI5lqkSONjYMhjALaNxcAgBrkgsObm+3Bi5TaTHHBnq9v4Iak0rVSuGVNKKLlgApP > cdtQ+Ax+QrDD7qaf7TTb+KS+m3z3+NO/9x/nDWhkIieQuE1OSAWta3bc94uOy/HCuPOHXU0/ > 2mm38Ul9Nvnv8ad/7j/OGz76PYw7C6mn+002/ikvpt89/jTv/cf5wupp/tNNv4pL6bfPf407 > /wBx/nHvBSQAUT1uYVEDVUTVZjFQF6NOBdSBokMjFI3Y7gC1jYsNRQUMTUsEjPmbSSr2rT18 > M6KxbTCHcRaQHeN1uLhSBq95x34TKnkRQ26mn+002/ikvpt89/jTv/cf5wupp/tNNv4pL6bf > Pf407/3H+cenQp2iSSknr6gTVBipAmYI3VUabM9oSIyWaFdL2N5O6wuS9oaLJ6ysp4Y80zaN > J5+nFJUTxx61CKQQGjBJJMVl8rKDv3qDwmQ8iI4ymPVlMTCwSQyaZQ5JkF9Q1E37gpUfIAUE > DDuNGangg6jFIRpjQhAkat2iw03LBbgMxZtyQRuS3ykrRqq0dQ/QBP00kgBYR9qq1wBYn3cX > XbyL4dRwQRmfTOpDK0ilzpYLewWxubn4F+Rva+EF05Rskk+54m+2yNtnJLueMlNoqKiUhUNV > TNTvqjLMEZW06BqFiQebEWIIHz7MGqaVVLO0UVkW/tFxdV+zXDH/AMnHA0bqGjEZKK0Z0E7m > 9wf8jbb7/e/EBqXAVFiQ3Rt7iwACm+9ydP8Ap8cVucpJJ+hnndOcFCT6R7DzL3tmFNMC0aPI > 6l492kJNyL3sHNwL7W245xaJAVWcSCuQB47EybqOzZe++okm54ux32xU8nRYswpIYzM9tyIb > hz7dgQRbmx3HHjFnklq54s0eip6vpZcgepqamVkp6ZBGspuy6mdytz2I7AuL2Fjhzw37bHvC > ftv8hykKZhprQyvECOv7bmPb3CzG+5ufce7xgmLO8ygVwMZjU6JBqX2Er7+Tc3Y8am3Nt+T5 > fnSyPBHUZNBNPM1JBLPm1SYTULoBRWNOFd73Fg2okSAG6NpbZdlHqWGM081XllRPJNCia6yq > jdTIAyxFBT7SBFZm2DojansO4sRqPJmVJJwJKpgnTXUr7KLrsLtcs2q+o8a+dsDICqziQVyA > PHYmTdR2bL331Ekgni7HfbAFK+mzHMqCtpnMtK0Cu1DXSSqHYIxTvWM6tJRrgHZz3XBAOSUk > zgCuGho1UawdIbRsO/djqPd41c7YABlIUzDTWhleIEdf23Me3uFmN9zc+493jBMWd5lArh0z > GpKSDUvsJX38nUbseNTbm2Os8SNMQK/mMMOuOzVoAAu1tRuLn8x7scZo0RzF9XcNGrDq3CEl > BYd/JBG/jUe7bABKZMyR56d55RGttRftQaR4JuxOq97barXxavqo/hv8sVLKFK5m46NapAFz > LJdB2DxqNz/hzfc4d+qZpaf0jnU8EjxSx0E7pIjFWVhGxBBHBBxntxq7XuR0pNdixfVx/Df5 > YX1cfw3+WKP6cy7Mq30vlNVJ6nzcPPRQyMNNM25QE7tCWPPJJPyThrQtX0n8qzZdPnFdW0xy > PrhKhkCh+uFvpRVW9vNr782xV9BST4jLL6xmSb0pXRi4JCbkgfvrjJMppKd4M/mmipXCSJ0Y > XBUmRoyQy830qGbTpPAPbpvjVfU8rw+nql430PdAHt7buov9rc35HIxjFTUrT1NakUkjmWqR > I42NgyGMAto3FwCAGuSCw5ub0KhQucI9Foxwl/Wb+CFpNK1UrhlTSii5YAKT3HbUPgMfkKww > +6mn+002/ikvpt89/jTv/cf5w1oZCInkLhNTkgFrWt23PeLjsvxwrjzh11NP9ppt/FJfTb57 > /Gnf+4/zjU+47h22Lqaf7TTb+KS+m3z3+NO/9x/nC6mn+002/ikvpt89/jTv/cf5x7wUkAFE > 9bmFRA1VE1WYxUBejTgXUgaJDIxSN2O4AtY2LDUUFDE1LBIz5m0kq9q09fDOisW0wh3EWkB3 > jdbi4Ugavecd+Eyp5EUNupp/tNNv4pL6bfPf407/ANx/nC6mn+002/ikvpt89/jTv/cf5x6d > CnaJJKSevqBNUGKlCZgjdRRpsz2hIjJZoV0vY3k7rC5L2hosnrKynhjzTNo455+nFJUTxx61 > CKQQGjBJJMVl8rKDv3gHhMh5ERzlURGVQuVCpKZCkmokyAnUpYn97SVHzYKDbD9XMhDG5kYa > WZyCNJ7VAB3Fhx/gRbTfDbK5WgiRaWrkNMhIpWlsSsdlVX2AsSADe1xYeRfEXm2dR0laKOiW > SaQgEhI7NuwAXe9mK7ggONwN7myWOLblZLrrW2zxNtM78iSi+uydARGvOsgBQkKo3uQensfB > NjtyME0c70kcjpL0gOlG7A6TtcKD87k2+/64gMrOZSZrR0CUQkqupLHPNS1kxDqqjWAqSAAi > 73IupDbCwuZ6sqIKbM5MrqqooqRqohnLNOjO6gWAAUsQASSFG35ltvu4FbRBub6rqd2cOlGO > 09jTNiz5RVSMulXhmAe57zbVv41bjj4H649USvgqspqIKiOqrJSJaaCRAklwiqmsEr2nQFB4 > IS+s3NvDM52XJ6sK+pRTSdhXUBdQDYHj4vz2g82sNfm1RVNSo0rRy0sIEYjluY1EQCkOtrsS > rMdrqTa9rYyYkZOt6G/8P61L8kLUK0ma1oMy1ixymFZgSyzAXOskh+eoRfUe1id7XPOnq/s9 > V/4o7ar/AD2edW/99/jHFp5XeeUUk8olldw4p2YOpLae4Rm402ANzs5+BgjTzb/0Gpbn3Uj9 > 3PP4Xne/99vthjrS0ejROejk/wCk9O2i/wCFOdTJY/1L7+wb91+eXf4wsd9IQyr6ngZ6WcDp > T98lOy2/Ck3v0wAf8eXb7XWLYdjPb/ca363scnzsEXGqnuP/AIr/AOuMrCRgxSvL0yG9x2UW > 7d7bnyT+p+car62/6ozwWuSacD9TK9sZMjCosoZhGLKNMeoEabMSfsAPG9zv8quI/dR5Liu/ > GX4PSCNlpgIlcU+tbkLuzeB9uGO/HjHS/XpY41ULIQwGhSDc7An58AAbdrbC9ykkVHipZHYI > iX1LZrKe7kcmx4uN9ja2BF5+oKWMhzMEiNy7NY7LcCxvzx4HGFy3sVpPYcoR2BQytDGEiQub > sRyRbxub2Hk8nnFZqKd2z6reencpF0xoD6AztGBCCbi2prHVxYG+LNLu7oFX36dKtcBvgEcg > XH2+PnEdRTilzmumk+qiKx6qUxQNIryGIRljp8opk+LljuLY38Oa8R79hnwmfLfJy9iUX0/l > 9Blpd8pmqaamiZKrMIq2WOJZk1dR9GsFhcXIRTbuAuQQHc/prLJ+rBRZM+YSqh60EGZTfhgO > Qxcu6qFI2Fzc2JAIBtALUTTUUVFmWf5jWZUCryUoyjpmVg+ogvZtzs5JuWubm5vh5Pm2btmd > VUUHqDMacVvT6cYyRnaRLBQuo7m3fsO0tqIA1HDRznyvTW/T/wCnpPGr/wAiZjgo6mnjeBat > qmUtFHRrm1W0hnR7PH77Xt5vYWLX0gnBw0UL1U9JVQVlBVDSFiqM5qSyllbSbpIykF0cc323 > A2vXpq8UrUSZDm2YZfT0aqkUZysytqKANJuAA9xa4APe5v3EY4uYF8vrvpquszHMczkUVtRL > S9GOaIIdQI07WUFNmv3FgcdOxqW21y6/fZy7akurHMefZC2cU1Ky5gKad1iFV+1arpazfg69 > VjsLlbX3vbfHr6jpqany5KZap1kn1Ryv+1KlwmhrSXV20kNqRbH+O+4GKwIDF6no2raZ1ooL > VLCnLMdRHYFKhrFbhtz4sd9jNZlPUZ5LUVULzvOahIqORlu5RGOhSNIBBLM5BBI2HjHFmRFV > 733KMq+uEf0y7nr1qapb+jTNLDEscSkuGbTueBxvvb58ki+DCRgxSvL0yG9x2UW7d7bnyT+p > +ceUdN0HlUyNM7SaSWZTYgWsCoAIFxxtubcnHVYVFlDMIxZRpj1AjTZiT9gB43ud/lBPXM+V > 9DydmvEfK+h6QRstOBErin1rchd2bwL+OG548YIv16WONVCyHUBoUg3OwJ+fAAH8LbC9zxJF > R4qWR2CIl9S2aynu5HJseLjfY2tgRefqCljIczBIjcuzWOy3Asb88eBxjhb2cpPY+y8g5rA0 > T1HSjCxIwN3K2JIA/dJv87X5Nr4sM1Npnnn6ub0sn4Ss8FbJCWQabIdEgLG7vzsC7b83rlHq > ObRKgcETgFadtR25UEEbWI3B2HHziX9Q1lRT5JmUtI1XHNCsYSR5gFhBMfce7dhqLEkeSL4d > 8Nf8tnoeEbdb/JCyZlmNRntYlLnmfRUqyLRQxPms7Ez8O28oPadV11WPTNjYjFm6UxadRmHq > TsdL6c3nuvsuv9f9+TsNR37cRHpmjipaV0ijqGSlApwYGAs2peoQdfN7LuBp0sQd8TmqMCXp > /VrpaNTqluATo2Hf7jcC+1ix7tsbq9tbY6t0nyr0AipUovqIYRXlFcP1DKzE6mDsQWYszMzs > dR4LHfbByAqJxIK5AHjIJk3Ufh7L331Ekgni7HfbCIe9Uix5gWWSK4WQ7D8M2tr9x+drXO5t > hSOJDOl65AjRhfxL6b6CFFn3Yk8/m52xYVAyEKZhprQyvECOv7bmPb3CzG+5v+8e7xg9bGSc > AVt0KIdMguoOi49/PcbseNTb7Y6SmubQmYEgpqAmB0X0cXb3WNyfzHu2wOqMCXp/VrpaNTql > uATo2HfybgX2sWPdtgAkcrUjOHW1S4RbK7v2AaRwNV2JJJuRtcjxiH9a+pqSmkq8kzbKs3XJ > Z6dUqM1pUdVhZ2AsTYAqAQSQWvfSVO4xLZNcZrMuirutr9SS6rdFNiNRu3njydzh1V13qBM3 > emo8kpJqMRh1rJswMYJ4KFBGzA8nyLeb7YAK5mFHlHpzK/T8dLJmlZTVtXTZfFImd1CKEdTa > QaH0kWA2UAb7WGHghyDJvVQkoWrq/PvpHgakSrepk6WpH7zK5EYGxGplB1G2okYqfqjK86ye > DJ6elosrpKaX1BTTUcC1ksyQzkPdbdNdMRNm0rwS1rhgFs3pfIM69L5e8MOV5XUVk7dSsrZc > 0lMlRJ5Zj0Dtcmwvtc8kkkAlfUbVMno+oNbDDFOSmuOGUyqPxFtZiqkm1vA3xi9RTu2fVbz0 > 7lIumNAfQGdowIQTfbU1jq4sDfG0+oWqX9IVJrIYYqhtIaOGUyID1ABZiqk+DwP98ZVRTilz > munk+qiKx6qUxQNIryGIRljp8opk+LljuLYxNpZPX2MPOo5e2/QlV9P5fQZaXfKZqmmpomSq > zCKtljiWZNXUfR1AWFxchFNu4C5BAdz+mssmMsFFkz5hKqHrQQZlN+GA5DFy7qoVhsLm5sSA > QDaAWeaaiiosyz/MazKgVeSlGUdMysH1EF7Hc7OSblrm5ub4eT5tm7ZnVVFB6gzGnFb0+nGM > kZ2kSwULqO5t37DtLaiANRx25z5Xprfp/wDTf41f+RMxwUdTTxvAtW1TKWijo1zaraQzo9nj > 99r283sLFr6QTg4aKF6qekqYKygqhpCxVGc1BZSytpN0kZSC6OOb7bgbXrs1eKVqJMhzfMMv > p6NVSKM5WZW1FAGk3AUPcWuAD3ub9xGC+tc0FesFVW1+Z5lIv1s89L0EmhCEMCukcAFNmv3F > gcdOxqW21y6/fZy7akurPdM+yFs4pqVlzAU07rEKr9q1XS1m/B16rHYXK2vve2+Pb1BBS0tF > HT/UPqmJjmJzSpZVCNaS6s1iGBRbH+O44xWBSvF6kopa6kkWghP1B+n1N3EXQIyhu5dQaxPi > x32M/mxqc1kkqQalp5nVaJ2TvaNXZYwQALgszPuLggD93FdmTFV733M+VkVQj+mXc8q3MKf6 > SSWml68NLGNILi+m17G17XIO29j884pNFWTRFpYZpRPVL+MyAXCaiz7i5X2qbgA21Djm6PQA > RVNNJK8rTXjYllJGxWwKgCwvt45tycVCGJKSZ6ethCwSzBOta4hIILhVuBcgC1yu1txuQx/h > S7Hqvmn3fYVYPI+dQ6vZpHoCmgybK8x9WZpHTiOCJJIjHLqKkIQqKS9rkMO0+SBsQRih5jnV > XVHNKjMJoY6qTUJIBqdpi0oLdzatAVY1XYqbKlgbsS7rc+zjM6BqGTN+pRdVp4qWKnW0jXZg > CAi6hqHFtIt4sAYumjkzOppMpgB0ayJIzHeTUQNRO2+5YKPB8AsSfUXUwpptuyGtv/oYuaS+ > EWSsneo9La3JJFCo7mvylz4Hm5t4+53xEQfU1J68skaGrkMPUdyCoVO6xtwFKqGsd9IPnE7m > qpBlNZEAoVYnXSrAgHSRsRsQNuNttscyuvynIno5MxqWoIaxCC0ZPUanTT3poXUrSyhjqFgU > XazAHHz3Cadc2vcq4NNfra9wFnoaacCWkaop44rRw0tYUVm8AsXVlsFtsCO8n90AhBNTUrRr > WRS16xQAAU9YUE0nyzF1ZfbbYEd5P7oBlB6xyqLOCj5rV0/p2pYMrtNO80qp7mQsC66mKpe9 > rRS2Ia2DqPUvbVtk2YTw5bVSJHQS1M8kjalOqSYiQF9O2gWuutdx3HFsY7aTTXTf/wC+T0Du > 3vRz0mVjz+mhkdp2SjlUSxTllZ+k12YMwNwFOwBB1320jCxHekc0zCo9bU9Gc2qZIVpaiSeG > oq2cP+G1goYm7X323tc8XwsaYVLlKLptyNk9ZRGfKs8jU9zGBV3tv1Xt/rjO2yauhp2jMKxa > D3XK27yosotse61+L+Rpxp3qL+ozWyzMepT7Qmzn8R+Nx/zG2Ki8pJnAFcNDRqo1htIbRsO/ > djqPd41c7Y5uxa7nzSFt+HVdLmmV8ZLUJNL1o7aVsyo47XYAIpv92S/i36YCbJsxmjMLJrFP > ZNPUFhfSQLeCC9yeOfviyM8SNMQK/mMMOuOzVoAAu1tRuLn8x7scZo0RzF9XcNGrDq3CElBY > d/JBG/jUe7bFPl1JR5Xj/JXpsmq1knW0VkvqkRz3s7Ai9x7jqXfi1vvgnyjMF1vLFpkUBXMj > BgQdIVQLXFgwF+L+RpvixMrDrr0MzuDHe0p/JsO/k+T927sA8pJnAFcNDRqo1g6Q2jYd+7HU > e7xq52weXUk+V0b31K+uTVKSSdaP2KAyqwuHYDQpvtyyE+LfpgXyjMXR4+nqMCiK3UG19Nlt > 495JPHP3xY2eJGmIFfzGGHXHZq0AAXa2o3Fz+Y92OM0aI5i+ruGjVh1bhCSgsO/kgjfxqPdt > g8up+SPK6Na6/wCyv1GT1nUmU9IiPZpFc97MQVvce46l34tb7442S10NO0ZhWLQe65XT3lRZ > RbY91r8X8jTfFkZWHXXoZncGO9pT+TYd/J8n7t3YB5STOAK4aGjVRrB0htGw792Oo93jVzti > fLqfknyuj5K+MlqEml60dtK2ZUcdrsAEU3+7Jfxb9MBNk2YzxmFk1insmnqCwvpIFvBBe5PH > P3xZGeJGmIFfzGGHXHZq0AAXa2o3Fz+Y92OM0aI5i+ruGjVh1bhCSgsO/kgjfxqPdtiPLqfk > PK6Pkr02S1SyTraKyX1SK572dgRe49x1Lvxa33x1smroadozCsWg91ytu8qLKLbHutfi/kac > WNlYddehmdwY72lP5Nh38nyfu3dgHlJM4ArhoaNVGsHSG0bDv3Y6j3eNXO2Dy6kPK6N76lfG > S1CTS9aO2lbMqOO12ACKb/dkv4t+mAmybMZozCyaxT2TT1BYX0kC3ggvcnjn74sjPEjTECv5 > jDDrjs1aAALtbUbi5/Me7HGaNEcxfV3DRqw6twhJQWHfyQRv41Hu2weXUkeV4/yQ1PllTSZk > ZGZVjhb8WSFiWk1kEDe1mOpdxYDb4OJmQFVnEgrkAeOxMm6js2XvvqJJueLsd9sGysOuvQzO > 4Md7Sn8mw7+T5P3buwDykmcAVw0NGqjWDpDaNh37sdR7vGrnbGmmmNS1E10UQpWoAy2UzjTW > hleK46/tuY9vcLMb7m59x7vGCYs7zKBXDpmNSUkGpfYSvv5Oo3Y8am3NsdZ4kaYgV/MYYdcd > mrQABdrajcXP5j3Y4zRojmL6u4aNWHVuEJKCw7+SCN/Go922Li8d01I1bmElJDNPqGkdQyEK > igKxHNyxBJ1WuNXO2JJvS9SyuPrG7nQqes91Uab2PgmzXP5vtjwyBSudEdGtUgbmWS6DsHjU > bn/Dm+5xb8LcvJsqnqJbCKa6lVPpapPUtVMpLoR/SJCNI03NtrE2P335wTemKpi39NZQSoBW > VwQoIv53Js2/Peebb2jCxk+vuOvDRV2y18l15hUTPNGmlFRXYkXso2OxJYk3PGo74T57FH1O > pR1SaAt9QTcnTYDu+WA+Od9sSvqH/qWayzMdce0Js57143H/ADG2KbJKSZwBXDQ0aqNYOkNo > 2Hfux1Hu8audsMsS6VsNyK5pJ9CSrK3K6qoilrMoNRPRsrRvLFGzQuxSwUse07objbbnbDr9 > vRlpAKOqJjKhgNGxOnb3eNQueOd9sQjPEjTECv5jDDrjs1aAALtbUbi5/Me7HGaNEcxfV3DR > qw6twhJQWHfyQRv41Hu2xrOB76hr48wymtoYY5ddkGs2C6iykDm9zceLb8jFTfKMwTW8sWmR > QFcyMGBB0hVAtcWDAX4v5Gm+LEysOuvQzO4Md7Sn8mw7+T5P3buwDykmcAVw0NGqjWDpDaNh > 37sdR7vGrnbGa7ErtfNIyXYVV0uaZX1yapSSTrR+xQGVWFw7AaFN9uWQnxb9MC+UZi6PH09R > gURW6g2vpstvHvJJ45++LGzxI0xAr+Yww647NWgAC7W1G4ufzHuxxmjRHMX1dw0asOrcISUF > h38kEb+NR7tsU+XU/JR5XRrXX/ZX58nrOpMD0iI9mkVz3sxBW9x7jqXfi1vvjr5RmCa3li0y > KArmRgwIOkKoFriwYC/F/I03xYmVh116GZ3BjvaU/k2HfyfJ+7d2AeUkzgCuGho1UawdIbRs > O/djqPd41c7YPLqSfK6Pkr4yapSSTrR+xQGVWFw7AaFN9uWQnxb9MC+UZi6PH09RgUR26g2v > pstvHvJJ45++LGzxI0xAr+Yww647NWgAC7W1G4ufzHuxxmjRHMX1dw0asOrcISUFh38kEb+N > R7tsHltPyR5Vj611K/Pk9Z1JgekRHs0iue9mIK3uPcdS78Wt98eFb6crJtcsyvFOqCN5DIGV > lOkKmggg2DW3uNza1rm1MrDrr0MzuDHe0p/JsO/k+T927sA8pJnAFcNDRqo1g6Q2jYd+7HUe > 7xq52x3DCrrfNHaZ3Xw6quXNHaZR5vRDyNUJLS0UKsQZRTiVdEjbKADNpBGseCq3OxtYvoPT > dVTRzRwwC8Z0sA4ABbSbBRsu8jE2sou1rb4tbPEjTECv5jDDrjs1aAALtbUbi5/Me7HGaNEc > xfV3DRqw6twhJQWHfyQRv41Hu2xfdW7ly2SbX5LrcWNseWTeiuVmR1UoqYZBEyBSsjq5/ELk > WBuOTqXcbWt98Nv5qT08ajTUwtT6Qv8ATJAq3K6VUXuLarfFydxa5t7Kw669DM7gx3tKfybD > v5Pk/du7APKSZwBXDQ0aqNYOkNo2Hfux1Hu8audsUww4Q6RbX7ldeDXX/Y2v3KsvpiWORhM1 > WBEhQhK1wVZxZVN2+XUnxYnAD0vUDqDoNM8I6f4s+vTfQbDUTp3a5I22+2LazxI0xAr+Yww6 > 47NWgAC7W1G4ufzHuxxmjRHMX1dw0asOrcISUFh38kEb+NR7tsS8WLWnJ/7OniRa1zP/AGQ2 > SemfovUctWkMSGKGXqyRStZ7xtpupsL2ccC1reb4WLLRKVmqx0a1SIWuZZLoPwx41G5/w5vu > cLFsKlBaTLoVKK1tli9Q3EGbENIO+nv0x3EdSS4HwTxfxz4xUZAVWcSCuQB4yCZN1HZsvdfU > SSCeLsd9sW31GGMGa6RKT1abaH3H8V9huP8AmMVKRxIZ0JrkCNGF/EvpvoIUWfdiTz+bnbFp > aDIQpmGmtDK8QI6/tuY9vcLMb7m/7x7vGD1sZJwBW3Qoh0yC6g6Lj389xux41NvtjpKB5tCZ > gSCmoCYHRfRxdvdY3J/Me7bA6owJRH9Wulo1OqW4BOjYd/JuBfaxY922AA5AVlnUfWsE0AOG > 209vt7rkm57ja2o77YCQFROJBXIA8ZBMm6j8PZe++okkE8XY77YRD3qkWPMCyyRXCyHYfhm1 > tfuPzta53NsJ2EhnS9cmhowv4l9N9BCiz7sSefzc7YABkIUzDTWhleIEdf23Me3uFmN9zf8A > ePd4wetjJOAK26FEOmQXUHRce/nuN2PGpt9sdJQPNoTMCQU1ATA6L6PlvdY3J8aj3bYHVGBL > 0/q10tGp1S3AJ0bDv5NwL7WLHu2wAHICss6j61gmgBw22nt9vdck3PcbW1HfbASAqJxIK5AH > jIJk3Ufh7L331Ekgni7HfbCIe9Uix5gWWSK4WQ7D8M2tr9x+drXO5thSMJDOl65AjRhfxL6b > 6CFFn3Yk8/m52wADIQpmGmtDK8QI6/tuY9vcLMb7m/7x7vGD1sZJwBW3Qoh0yC6g6Lj389xu > x41NvtjpKB5tCZgSCmoCYHRfR8t7rG5PjUe7bA6owJen9Wulo1OqW4BOjYd/JuBfaxY922AA > 5AVlnUfWsE0AOG209vt7rkm57ja2o77YCQFROJBXIA8ZBMm6j8PZe++okkE8XY77YRD3qkWP > MCyyRXCyHYfhm1tfuPzta53NsKRhIZ0JrkCNGF/EvpvoIUWfdiTz+bnbAAMhCmYaa0MrxAjr > +25j29wsxvub/vHu8YPWxknAFbdCiHTILqDouPfz3G7HjU2+2Okprm0JmBIKagJgdF9Hy3us > bk+NR7tsCGjAl6f1a6WjU6pbgE6Nh3+43AvtYse7bAAcgKyzqPrWCaAHDbae3291yTc9xtbU > d9sBIConEgrkAeMgmTdR+HsvffUSSCeLsd9sIh71SLHmBZZIrhZDsPwza2v3H52tc7m2E7CQ > zpeuTQ0YX8S+m+ghRZ92JPP5udsAAyEKZhprQyvECOv7bmPb3CzG+5v+8e7xg9bGScAVt0KI > dMguoOi49/PcbseNTb7Y6SgebQmYEgpqAmB0X0cXb3WNyfzHu2wOqMCXp/VrpaNTqluATo2H > fybgX2sWPdtgAlsjUjP9Nqlwi2V3fsA0DcDVdiSSbkbXI8Yt+Kd6ev8AtyRdFXdbX6kl1W8a > mxGo3bzx5O5xccJeI/cRfX2FhYWFheWEZ6guMlnIaQdyX6fuI1rcD4J4v458YpsgKrOJBXIA > 8ZBMm6js2XuvqJJBPF2O+2Lj6iDHJJtIlJ1xbQ+4/iLsNx/zGKdI4kM6Xrk0NGF/EvpvoIUW > fdiTz+bnbDrh/wBtlFncGQhTMNNaGV4gR1/bcx7e4WY33N/3j3eMHrYyTgCtuhRDpkF1B0XH > v57jdjxqbfbHSUDzaEzAkFNQEwOi+ji7e6xuT+Y922B1RgS9P6tdLRqdUtwCdGw7+TcC+1ix > 7tsMCsOQFZZ1H1rBNADhttPb7e65Jue42tqO+2AkBUTiQVyAPGQTJuo/D2XvvqJJBPF2O+2E > Q96pVjzAsskVwsh2/qza2v3H52tc7m2E7CQzpeuTQ0YX8S+m+ghRZ92JPP5udsAAyEKZhprQ > yvECOv7bmPb3CzG+5v8AvHu8YPWxknAFbdCiHTILqDouPfz3G7HjU2+2OkoHm0JmBIKagJgd > F9HF291jcn8x7tsCGjAlEf1a6WjU6pbgE6Nh3+43AvtYse7bAAcgKyzqPrWCaAHDbae3291y > Tc9xtbUd9sBIConEgrkAeMgmTdR+HsvffUSSCeLsd9sIh71SrHmBZZIrhZDsPwza2v3H52tc > 7m2E7CQzpeuTQ0YX8S+m+ghRZ92JPP5udsAAyEKZhprQyvECOv7bmPb3CzG+5v8AvHu8YPWx > knAFbdCiHTILqDouPfz3G7HjU2+2OkoHm0JmBIKagJgdF9HF291jcn8x7tsCGjAlEf1a6WjU > 6pbgE6Nh3+43AvtYse7bAAcgKyzqPrWCaAHDbae3291yTc9xtbUd9sBIConEgrkAeMgmTdR+ > HsvffUSSCeLsd9sIh71SrHmBZZIrhZDsPwza2v3H52tc7m2E7CQzpeuTQ0YX8S+m+ghRZ92J > PP5udsAAyEKZhprQyvECOv7bmPb3CzG+5v8AvHu8YPWxknAFbdCiHTILqDouPfz3G7HjU2+2 > OkoHm0JmBIKagJgdF9HF291jcn8x7tsDqjAlEf1a6WjU6pbgE6Nh38m4F9rFj3bYADkBWWdR > 9awTQA4bbT2+3uuSbnuNrajvtgJAVE4kFcgDxkEybqPw9l776iSQTxdjvthEPeqVY8wLLJFc > LIdh+GbW1+4/O1rnc2wnYSGdL1yaGjC/iX030EKLPuxJ5/NztgAGQhTMNNaGV4gR1/bcx7e4 > WY33N/3j3eMHrYyTgCtuhRDpkF1B0XHv57jdjxqbfbHSUDzaEzAkFNQEwOi+ji7e6xuT+Y92 > 2B1RgSiP6tdLRqdUtwCdGw7+TcC+1ix7tsADymUisq1tUuEgYK7v2AdPkDVdiSSbkbXIwsDQ > XFRXLoq7rE1+pJdUvEDYjUbt548nc4WACw+pplgpc3kd3RFenLFPdbqPcDcWJ4v4xQJvUOXR > U80s01dHEGRy7P7EBW9u+92s3G51ebYvPrCV4ctzp43COGpwHt7SZXF/tbm/I5GMczSlp6jL > 692kXoQ0srxau0yS2OlCDfUQgLkAki6G/OMNltvjquPYwXW2+Oq4PoT/APPDJ316XzW7OhHZ > IbKCtza4sTY+b93PjDqP1HRVJYRpnRvpCmOnluALEjY7k2O/PedyBil0lBLJKtmAvx8Ef+f1 > /wCV9K9J+n5TCXDq0xTVo42/Xz45w2hit9XIV5PGLK/0wW5exGft+jMzxP8AtOKQhLLMjRlU > +RqO5az93IJO+2CGdUUgdddeAzxlSX3VQV4Ou92s3/Ffe2GfqR5Kf1bdGETrRxjURup6kgv9 > rc38EfNsVvNpukgpaIvJV1aladIoz1Pda9h503Ox+NzvhJkX3QyXTB7Jp4hk3OKXRvXT2HT/ > AMqOQBpF6OdA9RbdwIsNNz/WCxOk/ffnHW/lUyBi3ZnaglQpUKCqgi/9ruTZt+e8823olblP > 7CrBAjNUVJqKilksO1xGy76bE23Nx9tvu3Zz9NOCyyKxfUwnGod3AOna+5t5tcW4wx5tHp4V > 8yNDP8qmQEtaPOtyoGy9qgi/9pux7u7kascb+VP0+wcdPO+50INluqjTex6mxNmv/e+2KE71 > DVKLojLFHsocESAsLkjTc3AvtyOLcY8mdvppwWWRWLlmE41Du4B0+ebebXFuMRzHXgmgn+VL > 0+epaHO1JdLdwPaNNzbqCxNj5vvzgm/lUyBi3ZnaglQpUKCqgi4/rdybNvz3n43oTvOZ0Foy > xSSy6wQ41DcjTvcC+3Pi3B8WkP004LLIrF9TCcah3cA6fO5t5tcW4wcweCajln8oGS5vWPTw > HNI3IBUylVsqkXA/EN2Pcb8jUd9sPqr1RlNMh+oqK+NXdCrXJKICtzs1xexufzD7XzTKJ54v > U+WNrjjk/F0urBrXB7+Nj5uPi4scPc0zCFMw6nTdqcSaRNqIATtdSwVjYkKxHk6fNjjO52O5 > RXbQvs8VZHJF9NF7p/VeUV0xhppcwMskihF1NvYA2HcO9tDi1ySSbG4IxJV2Z09DTyVNTJWp > TqsTdWGUPoQ6Tyjnm4ux46y3Nit8sok6HppsuEM4nqWRpmLOOACq30G1iAbi1ioBuCcN5aFZ > 53qZmrJZHYys8kspZ7EbnsvdmAJ8iwI2xY5Pfc2LHm/U0U+uMhJY/WVwuVUXVhoUWv59xs/d > yLt/CccPrfIGDqayvXVIliQ3Yo03sdVwTpe5+5/hOM3GUQrZf6ULduoSPcWsWI7LXFgB4Nh5 > GEMqi20pUK3gdWSwLW0i+jgBQb+CADieZ+5P08/c0c+t8gIf+lV6kupF2fZRpubahYnS1978 > 77EAj64yFi162vQdliAwKqLEj3cmzXJ3GptzpOM2GVwLZglVpWzDvkBstgNtHJIFxyLAjbCG > UQrZbVQt26hI+1rEkdlriwA8Gw8jBzP3D6efubR6R9SZZmnqCGOlmqpXbUirISAgCE7gk3JI > bfm5I8Y0bHz/APyXUKQ/yg0bRiRQsMrOpkc21LZRYgXFl833FjuBj6AwnzW3Z3Cnacot70LC > wsLGMvIv1CwTJJiXdRqjBMfuN3XYfBPF/F74p0gKicSCuQB47EybqOzZe++okm54ux32xcvU > P/Us1lmY649oTZz3rxuP+Y2xTZJSTOAK4aGjVRrB0htGw792Oo93jVzth1w/7bKLO4MpCmYa > a0MrxAjr+25j29wsxvubn3Hu8YJizvMoFcOmY1JSQal9hK+/k6jdjxqbc2x1niRpiBX8xhh1 > x2atAAF2tqNxc/mPdjjNGiOYvq7ho1YdW4QkoLDv5II38aj3bYYFYqmWOA1LGWqZIggZw9gi > 3XYXbdjqvq8audsR4zqilDqHrxqdCCX3RQV4Ou9zZv8AivvbDvMHkgoaxo0rIpB0x1JZLoly > gva57vN7XBvvtiBy7IK7OA8uXPRinM60kb1EjxvJM2+gIqOSRHZyeArXJsr2X5Ft/i8lQtyr > chWclJJSZzRqHJGYoWaNgDIT29pvbUDdgp33NmvfBDOqSVWcPmCpdFDqT28ErfX7jpbfnvPN > sN29LZ1DKsEdd6eppJXkoY5Xqp1jkmBAMauYdJe7adKtclXG5WQDwj9F56lLUyy1mUmOBIzJ > qlqA6dQDpxFfpwTKe38O2vvQFbst+E83XoV7z+XfQkDnNIVD6q4LIQqMWsFC6Swvq3Y778jV > +mBGdUUodQ9eNTxkEvuqgrx33ubN/wAV97YYZrlea+mczgoa+alWdojKhp5jKqAsFvuAynYb > ld9OxJB0x/Sj/EZZUEYjLAntbmwBG/cQOBfm97XxkszcmuXLLuYrc/KrlyS7k9JnNGockZih > Zo2AMhPb2m9tQN2Cnfc2a98EM6pJVZw+YKl0UOpPbwSt9fuOlt+e882xX1kaNbxBEOhom0Xu > bn/cG21r735NxsjuAwKISI20LqsLKBybXNifHHxxz5jeV+a39kyxnOaQqH1VwWQhUYtYKF0l > hfVux335Gr9MMqz1Zk9JZKmozBOswZLamKomksRZiQTZiT+a+9sRcdRIjxmKcqQNr7hCdIuO > bEbb89oPNrVzNXBV5IbkzTxJGHQBiNbKBbYg2F+bgk9218aMXLutnqXYZ8Nuvy5vb6It7+t8 > iAkvNmiHWp3WQ2VbXPIsT03vvfnfYjBN64yIl9VTmaAadxFICqrcsOeex7nkXbc2xRRTUSWY > MuhbMGWoIGlbC4PW2BZVCnwVAPAOEKOmWy6lRlst+sbKwsWNutwgVQRyCARcDDHxPkd/SS/y > NEp/VGV1hcwz119QSz3QoqnfZm3JIfu5BJ32x51nqzJ6OyVNRmCGZgyW1MVRNJYizEgmzEn8 > 197YpeSolPnEclIzRFYWNxIXEYYoqX72AIUXB+ApG67Bmrgq8kNyZqiJIw6AMRrZQLbEGwvz > cEnu2vjP41njcu+hhjXdLJlXzfpRb39b5EBJebNEOtTushsq2ueRYnpvfe/O+xGCb1xkRL6q > nM0A07iKQFVW5Yc89j3PIu25tiiimokswZdC2YMtQQNK2FwetsCyqFPgqAeAcIUdMtl1KjLZ > b9Y2VhYsbdbhAqgjkEAi4GNHP8m76SX+RqGSeo8tzOsljppKx5GikRVmBXQFRr3BO5JV9/m4 > 8YWKZ6Jp4V9XQmAMqrR1LFRKWCgxgIGs7C+kXvwRaw22WI8Rr1MNkpVzcdmv+t7fsfOwRcaq > fb/4r/64x9hp9NVTTAShoq1YVQamVwxDyv8AACLHGrC/vK8MMbD62/6ozwWuSacD9TK9sZbk > woosuaqr5dVFTLUT1scsot0I5ywiUcB5pNKlWsHWNgLFcEfvv8FaW8h/ge5fShSHJXVe3PH/ > AJ+f9ub1lkzUc0cie6M3tfn5GKB6wrvT9PV08WVenIY3+jiqpqeCClhNPrBJWd5kks4stkCr > YEks21pb0s/pR6fJ0zDKKSaXNKd6w/W0kKNRRxhtTTNGqARMQvTbRvvc7gK0jmJLl0Jbv4el > KxWqzWnvsH/KHFEPWgliB6c2X08ht95JuB97A/riA9N0qT/yk06VUGowZcZogbjQ2tQH22N1 > PPBv/n4P9HNXVdVQ0MVFBVza4qaOMR9NbWQEDzbSW3tqLW2OPLJq40XrtnhgM9TLlhipoUtr > dy6gBAdi1gT4vY487VYrM1yRfiSjLOfL6IqfqAL/ADtz9pXRYZKuVWk12dAH48872Hm3gDDZ > mlEgbUjTGN9MIcOJVJuTawuTbxzz4sdi9VZDkmUCjyVMty7MM6aDqZhmNTEz6mAA7kDCzPrJ > DX/da32r3onLsgg9IZ9mOaenKLMaenqxFlMjgh6x21fhhv3iAFsB5uOcM3HZ6SNvKtaM7aSA > pIn1AaFi3Vm6ncrEgkKdO4Njt53+MGzSawxaPqmNtMWvUsqlrliAPI325+NrYvvp/J8mqv5T > qCjrqHLJ6WeCY5hTxwmOGABbxuF1HSxYheT7rAb4aeuKbIqiCvkyjKcty6igkCUMiIGerYG4 > ZWvYo44FifvYWxHKdeN8FL6sSoxNQeiSwknVjqV9QNlNt738bG17CxuTGUsu6Gdkbpwq4ImU > sDc7W3tfaxP2tjVs3yzI6PL8ooY/SmU02c1FKJq8S07SCmaynQU1AqWuSDf90j7Y8/5L/Tfp > ysyD1BWZ5klDPleX1DfSV0wI6i92q8l7ECyb8C5++DkDx/gzHJj9T6lg0SyVCwa3kdmBA1bd > uwv4H3+BgqlnMbQPFG8cjx6EjDapG0RX1WF7BddiBtrf5xO5PDRVE1VmtJQx0iVkzdGBWJES > HYL/AJgH/c74jo4aepcyVmhKekRXGpyoL6EJI0biwF/vq+2KK7FO2SXoLashW5M9ehwwG5DR > m9yGbpXN+Xb+q3Nth4YffCETEgrCA1wQOnsGOyi/S4UcHwdjgoaLLCa1KrLoaVaUdJ71kzjU > pDSJYb7XttcEi4JwdLQ0FTU1sU+XxQy0shDg1szXbQeqt/JBFieD4JG+LvDGnjr2PHoqF/qL > oBwYeVB2Ful5bcjxyMdMJuQ0Zvchm6QJud3b+q3Nth4YffHhNSxdV5aaihFIJGZJWac2SOwD > 6uoBYalA+zj5w4yuhyybKVq6+mpo42LEATTqeipvYrqO97MLXviOTfqS7td0cETXBEIDXBA6 > ewY7KL9LhRwfB2OOdFQv9RdAvtMPKg7C3S8tuR45GPSnpMveStSry+GF6LWJya2ZtT6byAfc > WINrg+CRue01FSSVM8TZQizQTCFY0rpmMkwsBGLfvKWC3432NhfA4a67OXkJLbRb/wCS+nEf > qqKY2LySOrOABe0bXvYC/dr3sOP0xuGMe9A0a5d6hyyiQraHWraTfU3Te5uCb7n9Pi/ONhx5 > +2fPY5IX8Pt8Xnn8iwsLCxWMiM9QXGSzkNIO5L9P3Ea1uB8E8X8c+MU2QFVnEgrkAeMgmTdR > 2bL3X1Ekgni7HfbFx9RajkkwUSk64tofcfxF2G4/5jFOkcSGdL1yaGjC/iX030EKLPuxJ5/N > zth1w/7bKLO4MhCmYaa0MrxAjr+25j29wsxvub/vHu8YPWxknAFbdCiHTILqDouPfz3G7HjU > 2+2OkoHm0JmBIKagJgdF9HF291jcn8x7tsDqjAl6f1a6WjU6pbgE6Nh38m4F9rFj3bYYFY1z > pbUNahWpdVEYVnbtC6k4BJLE3JuRySMV6mmraFI4IszzKkjN/wAJK2eOMFzcMAj/AJi2wtuN > jfFhzO/7OzFOnV3BjX8STtUnp2BGo3a+/Hk7nFPrZXXL5TACJrAR2AsotZmJ/KBfix7t8Js6 > U1elF62Is+Vn1KjB62HBnOcVFTVzDPs66CFaaFBmc/fLuC39YDtuSL8Ibc4kBmOaGOO2d5w0 > ntsM0qe7c2Ju/m4At/CdvOI+mhSm6VKrOlLTq0JZd7vYF/3t7bKAbbqd7HDsJpkULTs3UZTE > DqYuoawUEWuDY7i1yu1sZsjJsUuWMuxxxHKlCaqql0j/AMs86hllqHk6lROXZdcs8hklk2Au > zEkk9oAFzawFzgtADRLKoRth3KQBcAK3buTY6tvtzfASCzGPYnVpsGB33HI2I4+3xhKVcae4 > G406VvZbdx/UADxv3YxuTk9sTylKUnJvqEqkrG/R1xKQvJ2JuLjfZrgnf4+MEWEkMaKqlwSL > KCC33JtvfYAD4bYXvgSCagvO7hZSWeQHWdwG+dzY8XG5APGDCaZFC07N1GUxA6mLqGsFBFrg > 2O4tcrtbEEJMa5mySUkiKWaFI9C9S3ttexHi5ubePk84iM4kpVzOlgo7Rjpl3ncgamAcSFh2 > Ht6jAEEnTGpuRxLVpEdPOrW2BBAa+9iORsRuONvjEQDQy3nrBSywzTGNWKNI8MYLEuqhSLtv > Y7g3S4tfDHA6bbPV/wAP/an+QBU3IKSm91Kp1gTci0a/11iSO4+GH3xz6iMLvVXjC7sKjlAd > 2B637zbA+ODth0IcjpoKqeKnoaqnViYRVRaJmAABGlUUbsGK3ANmW9jsGNBSRnODBNSZdK5D > aoeiGQG9gIzGpZiTsvNwDybYYKcXtnoW2ltjimUSxZlK7B3NoZASSt7FiLFmtuxFgbAr99u5 > xLSrmdLBR2jHTLvO5A1MA4kLDsPb1GAIJOmNTcjiQeCOioJolhhi9xaOEgqGIPBA7gLgA/bz > ucRwNDLeesFLLDNMY1Yo0jwxgsS6qFIu29juDdLi18ZabFOyU/QU8Nu8aV017gCpuQUlN7qV > TrAm5Fo1/rrEkdx8MPvjn1EYXeqvGF3YVHKA7sD1v3m2B8cHbDoQ5HTQVU8VPQ1VOrEwiqi0 > TMAACNKoo3YMVuASGW9jsGNBSRnODBNSZdK5DaoeiGQG9gIzGpZiTsvNwDybY1KcXtjZtpbZ > Y/RI1+oamdnLS6JIpLMSARE7W3ZrbtawNgV++yw/9MUyUmapDHFDD2zlo4SCobpPcAgWIGwB > +3nc4WOKpqzcl7nmY2q6c5/Jo3rVdeUZ6t7X6G97f2r4yzKaqty2jzChjjyyppMwmWWaOto+ > qLa9Sr7wCoN2AtyzH741b1hI8OW508b6HDU4D29t5XF/tbm/I5GMr6UX4jLKgjEZYMe1ubAE > b7kDYC/N72ucUZt86rv0PujNxC+ym7db6tEZmdHmWatXyV+YkS17tNNIIWZyW9qi8nt0hVA8 > LbnzO1Oc5nmFCYZIsthiFOtEJqSjMUgg2ZYNes2Q6bFOCLjySGqyNGt4giHQ0TaL73P+4Ntr > X3vybjZHcBgUQkRtoXVbZQOTa5sT44+OMf1tzTWzFLieROPK5BOGkVXYaVfWA9/eb6tydr7j > j7frhhG2aUnqmmz3L1oJamGERx/XBmEZ1drKAeQLAfa+1sP4qiRHj6U5QgXFxcITpBI5sRtv > z2g82sulH+IyyoIwhYE9rc2AI33IGwF+b3tfFNN0qpc0e5mounTPnh3InNKj1hmNTXVlXV0Q > qq2xeVUZXRSOxV2uABfTz7ib3N8cjb1MMjy/LIDlcOX0JusaRuVklK7O97jqCxNxbcnkcS6y > NGt4giHQ0TaOTc/7g22tfe/JuNkdwGBRCRG2hdVtlA5NrmxPjj441+ZXfBt82ufsRFGnqehk > rqynny+KqzBemKsqxeJVYOUQm4A4uNzxhv8AR59NJQqf2SaakYOtK0bdGQ7qC6ediePBJGLD > FUSI8fSnKEC4uLhCdIJHNiNt+e0Hm1l0o/xGWVBGIywJ7W5sARvuQNgL83va+I8yu+A81yH2 > InM6n1fmFRWVVVVUQqKtQNaoytGhHYqW4UC5X+8Tyce8NX6mPpCH0yjZbT5KrIJxTI6vPtcq > 7fLWubWuR8Xw/WRo0vFoQ6GibRe5uf8AcG21r735NxsjuAwKISI20LqtsoHJtc2J8cfHB5jc > +hD4rc1oFIFjpIo44xFCFMaEE91rHcnyBb/AD9cQ9Lk1VHQ/QisiemY3aOaDUDqbndueCP8A > PxfE7FUSI8ZinKkC4vuEJ0gkc2I2357QebWgc2zuOkrRR0SyTSEAkJHZtyAF3vZiu4IDjcDe > 5sYEcm2zw6OrZXiTvcmqn1fc9/2XVJSmlkngSldLmAUd1uR2nTqHNgb/AHvv5MZTmkeWukNU > Kalk7EaKlMahrA9pDWDbX28/rhrlZzKTNaOgSiElV1JY55qWsmIdVUawFSQAEXe5F1IbYWFz > PVlRBS5nJldVVFFSNUEM5Zp0Z3UCwACliACSQo2/Mtnd+Fl0Vtzl1XUZWSyox2pb/YrUnpee > WBwaxI4phoVlhK7LY6R3WHPH3+LYfHL6yophSvVUxg7Pw2pu0Ado2LW4sbW8X8XxLRVEiPGY > pyhAuL7hCdIJHNiNt+e0Hm1l0o/xGWVBGIywJ7W5sARvuQNgL83va+EKzr16i98SyZf+REnL > KoUjUktRAlK41dAUd1BJLLZdQ2JAP6Hzj0pcvnRBqmQ0kbExxRQ9NFdgdtibGxcW+/8AlJLI > 0akxaEOhom0ebn/cG21r735NxtG7gMCiEiNtC6rbKBybXNifHHxxEs26ScWzifELpx5HInfS > cjL6py+dkIRjMNYuS50Em/i+448Abecal9XH8N/ljKPSkhb1JQqJCUCudO9gSm9t/sB/7oxN > fyh+pJsjymKlpNaVdcWVJlYARKunUb83swAt8k3BAvr4fiQujuQ24TZy0svv1cfw3+WF9XH8 > N/lj5xzL6qrgm/aVTURVlKyRU+WPC4Wnj0je7GyLpC25ZvI/exqXon1DRy+kqZq/OIHqoxI0 > 5qKkF1HVIBa5uBuoF/kYYy4XVFbGkcht6LVn1UhyaYapUu0YunuPeuwN9ieL+L3xU5AVE4kF > cgDx2Jk3Udmy919RJIJ4ux32xP5hUwVmStPSytURO6aWpHBLWcDYg/Ox3HnEBJKSZwBXDQ0a > qNYOkNo2Hfux1Hu8audsd1UxqXLE6ctgykKZhprQyvECOv7bmPb3CzG+5ufce7xgmLO8ygVw > 6ZjUlJBqX2Er7+TqN2PGptzbHWeJGmIFfzGGHXHZq0AAXa2o3Fz+Y92OM0aI5i+ruGjVh1bh > CSgsO/kgjfxqPdti0gbZwitQ18YaeTQiAM0llTdCOTuxve5H71r4p9XmlNRoJqqUozCzMw1g > Jso2sSABYX+62tYXumYPLBQ1jRpWRSDpjqSyXRL6Be1z3eb2uDffbGb11atPWmXpv9MHUNI1 > 1Kxka4203N9Qjc3HgC99rqsmnxb9PtoWW4aycpJvS0SFDmmX1dSIkaZmYOFRI2uXCtoXcWO6 > e0bm1gCcP8xSWgojNVk9CKJe+NhKqowuPZe3u3+Ool7axeqUcsEGQSUBjQ1FSY2mKypYn+zR > QJRY3CuLEAhbC17BvNFRzzvUzyiZnYyvM1SSXAI1PqM/7zgAE8Eb/OO/LKvdkPhFPuydf1Fl > zli05X3XPTe7bk3bbnY8fw/qcEfUuWk6nqH6hurs8TMoXcAAFdrBT58bW04rooKJbIRGriyE > mU2VhYsbdfhFCgjkEAi4whRUO2iNQf3E6+92t01/r+e0N8EAWsRifLKvdh5TT7ssMfqHKA5M > 08oXS+yxNsQG0g3HF13+wPxjj+osuaMK9U/4aFFDRvYLY7cbbh7/AOP3xXxR5ctm/CMa2bUs > 9gUWwJB6+wZgAp8EAH5whQUS2QiJXFkuZTZWFixt1+EUKCOQQCLjB5ZV7sjyijWtstCVlNm8 > MyRS21B0YglXNydzfg+Lj+G3zgZszTLYKeB8wqYCVOkLuoRfhVXYAC//AIW3i/T8UdPmwloy > YSkRNw5bQHKhL97C4UE3H5SADayzVwVeSG5M1REkYdAGI1soFtiDYX5uCT3bXxmWNyXeGn+k > 6w8SyF8q6ptR7sc1Wa0VbEYq3M8yES6mKpGfcobTquliAykn+6fK4b09TltJFMn1dSwdtUgl > hNm0g6QbJtpKufsQfucNRTUSWYMuhbMGWoIGlbC4PW2BZVCnwVAPAOEKOmWy6lRlst+sbKws > WNutwgVQRyCARcDGrwY65dsazwbJrUrGWAVUGaRSxpIV1B0Y7o5uTudXBuCLj+G3g4CbM0y2 > CnhfMKmAlTpC7qEX4VV2AAv/AOFt47JUSnziOSkZoisLG4kLiMMUVL97AEKLg/AUjddrLndJ > Fl3oyocECqrp4BGHUK5HUGlLGxDBQWte6ksdXnGaGLq1wi/09xVRi2Y+TKqqbSICqzWirYjF > W5nmQiXUxVIz7lDadV0sQGUk/wB0+Vw3p6nLaSKZPq6lg7apBLCbNpB0g2TbSVc/Yg/c4aim > okswZdC2YMtQQNK2FwetsCyqFPgqAeAcIUdMtl1KjLZb9Y2VhYsbdbhAqgjkEAi4GNPgx1y7 > Y1ng2TWpWMu3pivhrc6Vom3EdQragwZux9yD5uCLj+G3g4WIb0TTwr6uhMAZVWjqWKiUsFBj AQNZ2F9Ivfgi1htssFdUalyxYt+mjjt1pmv+t7HJ87BFxqprj/4z8ffGYaAGiWVQjbDuUgC4 > AVu3cmx1bfbm+NQ9bf8AVGeC1yTTgfqZXAxlilXUL3A3GnSt7LazH9QAPG/djDxP7qFfFt+M > vwEqkqj9HXEpC8nYm4uN9muCd/j4wRYSQxoFUsCRZQQW+5Nt77AAfDbC98CQTUF53YLKSzyA > 6zuA3zubHi43IBtbBhLSKFp2bqMphB1MXUNYKCLXBsdxa5Xa2FwqSZ5zsrsioZGiQKi6udPP > Hje5t4+TzgtADRLKoRth3KQBcAK3buTY6tvtzfHnILMY9idWmwYHfccjYjj7fGOqVcBbsDca > dKXstu4/qAB437sQHXYSqSqP0dcSkLydibi432a4J3+PjBFhJDGiqpcEiyggt9ybb32AAPht > he+BIJqC87sFlJZ5A2s7gN87mx4uNyAeMGEtIoWnZuoymEHUxdQ1goItcGx3FrldrYkEmec7 > K7IqGRokCournTzx43ubePk84LQA0SyqEbYdykAXACt27k2Orb7c3x5yCzGPYnVpsGB33HI2 > I4+3xjqlXAXuBuNOlL2W3cf1Fh437sQHXYSqSqP0dcSkLydibi432a4J3+B4wRYSQxoqqXBI > soILfcm299gAPhthe+BIJqC87uFlJZpAdZ3Ab53NjxcbkA2tgwlpFC07N1HUxA6mLqGsFBFr > g2O4tcrtbEgkxtmVSsNLJKmt4qeMaQ7AEqBe32uQdt7ffnFEoqyaItNDNKJ6pfxmQC4TUWbc > XK+1TcAG2oWI5vdXAs0M1K1rSXjIVgdyCNiNjyPt8YpMMSUkz09bCFglmCda1xCQQXCrcC5A > Frldrbjcj2P8IXU12zU+77DjhunGS9TSPQNNBk2V5j6szSOnEUESSRGOXUVIQhUUl7XIYdp8 > kDYgjFDzHOquqOaVGYTQx1UmoSQAM7TFpQW7m1aAqxquxU2VbA3Yl3W59nGZ0DUMmb9SiMzT > xUsVOtpGuzAEBF1DUOLaRbxYAxdNHJmdTR5TAG0ayJIzHeTUQNRO3yWCjwfALEn1d1MKabbs > hrb/AOho5pL4RcKadqnLqJ3Lt+BED3X5UE228m5t4+53w60ANEsqhG2HcpAFwArdu5Njq2+3 > N8eRjWP8FVUBToCqwIB3GxGxA24222wSlXAW7A3GnSl7LbuP6gAeN+7HyWbTk2jys3zTbQSq > SqP0dcSkLydibi432a4J3+PjBFhJDGiqpcEiyggt9ybb32AAPhthe+BIJqC87sFlJZ5A2s7g > N87mx4uNyAeMGEtIoWnZuoymEHUxdQ1goItcGx3FrldrY5OUmSnp8JUeoqWFWm6IjeJTrKsF > MbeVN1N7mwO3yTviG9YZRRelMzpRk2YV1LWyxvJVSRyhB0yxIsqqouTsApAAj9vnEx6YBX1R > SpcdrOCAwbfQ3kbEccbfGIX+VDKqyjz6TMQHejrQncBZVkVdOg782W/i9z8HHo+C65XsfcO+ > w/yRFJk1dnOVtnZkUZfHVaKqQBpJUBAZpWHLgarncnnxviyegfTGX+oZJ86q4P6PDMscFNr1 > AlVBPUuO7lTtYE6tgLDEF6a9WZpknp9spyyni+pqagukzXdhqUKFWMDdrgEXuPFji8/yZ+nc > xyOkrpq+AwCq6XSjc99lDG7Dx7hsd9jcDDi2UkmMa4xbRbMzjSDJ2ihVoo06aqsC2IUMBpW1 > rbbX2tz4xXZAVE4kFcgDxkEybqOzZe++okm54ux32xYs6DHK30iUnXHtF7j3rsNx/wAxiuyO > JDOl65NDRhfxL6b6CFFn3Yk8/m52xjNQMhCmYaa0MrxAjr+25j29wsxvub/vHu8YPWxknAFb > dCiHTILqDouPfz3G7HjU2+2OkoHm0JmBIKagJgdF9HF291jcn8x7tsDqjAl6f1a6WjU6pbgE > 6Nh38m4F9rFj3bYAGudLahrUK1MiqIwrO3aF1JwLksxuTcjkkYznP6uzTUM0XTperBLpcrHr > c08AZeFC2TqC+wOv5Axo2Z3/AGdmSdOr1Axr+JJ2oT07AjUbtffjydzikVFMcwz6GlSMOyJT > xxI05Vi7wx76o99KJck/wknwcZZySsbZzQt3yXwRBnYkhqkK5LBj1bBWIu5t1+EXYjwdxhCp > NwySm91ZUM4JuRaNf66xJHcfDj74ns4yilyPNVoJq9KljAZ2k61RCsYvYb9Rwb93xbSfnHpm > fp5cpySgzOrqQklY6IKAy1OuMt4d+p2kLdiCm2ki/kiy63r57Gr6d+5XPqECb1V4gvuFTygO > 7A9b95tg3I4O2OmdiSGqQrksGPVsFYi7m3X4RdiPB3GPetRoKZ60IY6MahHK09QwmK7NpJkX > hu23yPuMSeW5Z+1aqlpKZIhUzi5V8zqNMW1yXYXsL2W4vdmUecdu+KW2T9M/chRUkkMkpvdW > VDOCbkWjX+usSR3Hw4++OddAm9VeMLuwqbXQHdget+82wbkcHbEl06YRSGySSK7oqQ5jUOZS > GKjRv3arDT83GHNdlX7OzWbLZlglqY1QqtNmlRJ1Ge9kF7d3G35l+cR9TAiWO4rbZH0kLNRV > 88x1vKxU6r2CgbrYs1rNr2BtttsRjucS0q5nSwUdox0y7zuQCzAOJCw7D29RgCCTpjU3I4kZ > IUo8vkgsvaGDaXLAsb3N7m4uebn9TziNBoZbz1gpZYZpjGrFGkeGMFiXVQpF23sdwbpcWvhf > RZ4lkp+hh4TZ4viy+QBU7grKb3UqnWBNyLRr/XWJI7j4YffHPqIwu9VeMLuwqOUB3YHrfvNs > D44O2HQhyOmgqp4qehqqdWJhFVFomYAAEaVRRuwYrcAkMt7HYMaCkjOcGCaky6VyG1Q9EMgN > 7ARmNSzG+y83APJtjUpxexy20tsdUaJMMwlmZXJKwzB37eCxG77e4iwcAFeRfac9ZyJDLRQx > hozUyyTmokbTq6alCWT8O1hKwDAlisSG7C1mqRR5fTsixw09mLMsLgKrb8MCtwNrNqXj3cnE > 9W5tlYnNRmiZIfqEMtP+1abrrDTKzBXjiLLqaVuq2pGa6RRDTdlxXjTU3KfpsQYWR4ltk/kp > QqdwVlN7qVTrAm5Fo1/rrEkdx8MPvgfqIwu9UDGF9wqOUB3YHrfvNsD44O2L3DX5FPmNLSP6 > f9F008bxQ1tM9EjMrKAapw2sdNYwJvcGB6IIJEi3icvaHM/WELw5Bk65fK7TtQjKIXWKlC3J > bQjSdTRbYMR1WC8G2NOo+44V7ab12PL0SNfqGpnZy0uiSKSzEgERO1t2a27WsDYFfvssS2SC > P+cLmGlpqRX67dCmCBE/CftBQAMALDVbe3m5OFjPVNT217iCF3jSlP5L/wCtl15Rnq3tfob3 > t/avjLlcyEMbmRhpYuQV0ntUAHcWHH+BFtN8ap6wkeHLc6eN9D6qcB7e28ri/wBrc35HIxlf > Si/EZZUEYQsGPa3NgCN9yBsBfm97Xxi4l91GDiy/mrXsIBEa86yAFCQqje5B0bHwTY7cjHCX > lpwbuURREp8C4JC/Y+7b7n746sjRpeIIh0NE2i9zc/7g22tfe/JuNkdwGBRCRG2hdVtlA5Nr > mxPjj44XaFPRrSCfVIquRpV9YD395vq3J2vuOPt+uEshkIY3MjDSxcgrpPaoAO4sOP8AAi2m > +FFUSI8ZinKEC4uLhCdIuObEbb89oPNrLpR/iMsqCMRlgT2tzYAjfcgbAX5ve18Aa32EAiNe > dZAChIVRvcg9PY+L2O3Ixwl5acG7lEAiU+BcEhfsfdt9z98D9S0csVPSxq1VMrwpFGQGe12J > BY2A07bEXsR5N38Xp7MKogzvBRRFVHTS8rlbAEG9lVthv3C5+AAdNOJbb1iuhqowrL47gunu > M31Oquw0q+sB7+8+7cnbVuOPt+uG37RjlRJYknqS7rAZIYmmTuIRUFgbEXFhe+62tYXtMPpr > LkjVamN64qDb6tuou9t9HsBsALhQbD9cO8x4oP8AvOh/+piwwr4Wl/expVwiK6zkVGGWFnk6 > mu6FkeNRZ0kFwqsp3BDAXFh+mCJeWnBu5VFESn90XBIX7H3bfc/fGw5x6byzPO+qgKVQQolV > C2iZAQRbUOV7idLXU+QcZ7nvouvyZJatZEqsriS8rxgLNFGo3ZlY6XsqgkqQSTYIBxRfw2ce > sOqM+RwqcFuvqQLhpFDkaVfWA9/eb6tydr7jj7frhvPTLWkSFpEqGXQ0moFSh7VXSQQQBcWN > 9jta1y4iqJEaMxTlCBcXFxGTpBI5sRtvz2g82sulF+IyyoIwhYMe1ubAEb7kDgX5ve18YIWT > rluL0xbCc65bg+pDy5DTyCQTUtNAs3ewgSZSGIbQVXraRzt2kAHgjYv6ajigpmMKELfTcCy3 > ILBQBspuXOkWG5sBc4crIY1vFoQ6GibRe5uf9wbbWvvfk3G0buAwKISI20LqtsoHJtc2J8cf > HGi7NvvXLZJtFtuXZdHlkwnDSKrsNKvrAe/vN9W5O19xx8D9cJZDIQxuZGGli5BXSe1QAdxY > cf4EW03woqiRHjMU+ggXFxcITpFxzYjbfntB5tZdKP8AEZZUEYjLAntbmwBG+5A2Avze9r4y > GbW+wgERrzrIAUJCqN7kHRsfF9J+4xwl5acG7lEURKfAuCQv2Pu2+5++OrI0a3i0IdDRNovv > c/7g22tfe/JuNkd1DAohIjbQuq2ygcm1zYnxx8cGg6NaROelVkl9T0D6QokMwDm51nSWN/F9 > xx8DbzjSanK46yBoKqKCeF7ao5V1KbG4uCLc4zf0ZIW9V5eokJQLIdO9gTHvbf7Af+6MazjX > j5VlS1E9PwaKlS/yQlP6ZyyjnWemyyggmS+mSKBVYXFjYgX4OH/0knyv+eHmFjQ+IXP1HHhR > RBZ5C0OUSu0hUBowen7jd1FhxYni/i98VeQFROJBXIA8diZN1HZsvdfUSSCeLsd9sXL1D/1L > NZZmOuPaE2c968bj/mNsU2SUkzgCuGho1UawdIbRsO/djqPd41c7YY4l0rYbkVzik+gMpCmY > aa0MrxAjr+25j29wsxvubn3Hu8YJizvMoFcOmY1JSQal9hK+/k6jdjxqbc2x1niRpiBX8xhh > 1x2atAAF2tqNxc/mPdjjNGiOYvq7ho1YdW4QkoLDv5II38aj3bY1nB4ZrCJqStp0aeRgqIrN > IQqm6WG5JLEm9yNtVr4g6bJK6ky6Ghq6HL54KWVJCKinV9bNfUN77kyDfgG4BAGLMysOuvQz > O4Md7Sn8mw7+T5P3buwDykmcAVw0NGqjWDpDaNh37sdR7vGrnbFbrTeyt1rm5kyvwZRVUlPL > TfQ5bGOiYZ+lSRqXZ1VUDcAkFgb8dzc8Y8zktahqGo8tyqmqo41jWaGjiDRyagQQPBs+k32s > P1xZWeJGmIFfzGGHXHZq0AAXa2o3Fz+Y92OM0aI5i+ruGjVh1bhCSgsO/kgjfxqPdtg8Ne5P > K/dlDpvRWbUFXGXzKGpgoWRkQxWVmGnpg8E+5TvtxfzifrctzGqEwrsvyx1Rg0fWpUcxlnVt > IvzsQvxzvtfFgZWHXXoZncGO9pT+TYd/J8n7t3YB5STOAK4aGjVRrB0htGw792Oo93jVztg8 > NEtN95Mhmo67Q1NUUWXNTRSKxpzTIVW57YSDYW703/dsObYajJ8wWhNDFSUcSQPd/poliZ2K > ooDaT4Db3FvvtiyM8SNMQK/mMMOuOzVoAAu1tRuLn8x7scZo0RzF9XcNGrDq3CElBYd/JBG/ > jUe7bHMqIyWmczr548rbK5W5HVyiqhYx6QpV5Y3N2LkaeR7jqXe1uPvhDJc1pqYRCeeDohVt > 1FCgHSFVVA2tqA+L+RbezMrDrr0MzuDHe0p/JsO/k+T927sA8pJnAFcNDRqo1g6Q2jYd+7HU > e7xq52xTHBritLZVRjKjfhya2Ver9PV9YjwVtZVmOOxZElTaQgdNTqFj3MhPgeNxhvTek6ym > SpjQyS969VXdO42XQpsNtJa/wDf74uLPEjTECv5jDDrjs1aAALtbUbi5/Me7HGaNEcxfV3DR > qw6twhJQWHfyQRv41Hu2x39LHXLtlk65TWpSf+yvVOTVpadQ6qUFjNFIQxZiCu5Gzdy7jbj7 > 4mZMw9TxRU6JMtJHQ36MUccYjjLgogRdNwVWXSN9J0i/DFnbKw669DM7gx3tKfybDv5Pk/du > 7APKSZwBXDQ0aqNYOkNo2Hfux1Hu8audsRDEhWtRbRRXhQqTUG1siqhM+nyusyqprp0ppEji > kERjDqACI4dRX2HqLqHBF/l9UXS+nq+lp6+nCidpDGkrSiMsACrBAQO0amVmI5Ma79uLUzxI > 0xAr+Yww647NWgAC7W1G4ufzHuxxmjRHMX1dw0asOrcISUFh38kEb+NR7tsduhNabZa6Nx5e > Z6GGU5XVw51I7dIpBDN1JEYnVqQkXv57l42sB5vhYm6JSs1WOjWqRC1zLJdB+GPGo3P+HN9z > hYivGhWtROasSutcsSV9b2OT52CLjVTXH/xn4++Mw0ANEsqhG2HcpAFwArdu5Njq2+3N8ah6 > 2/6ozwWuSacD9TK4GMsUq6he4G406VvZbWY/qAB437sKeJ/dQk4tvxl+AlUlUfo64lIXk7E3 > Fxvs1wTv8fGCLCSGNAqlgSLKCC33JtvfYAD4bYXvgSCagvO7BZSWeQHWdwG+dzY8XG5ANrYM > JaRQtOzdRlMIOpi6hrBQRa4NjuLXK7WwuFSTPOoZXKKhkaJAqLq5088eLm5t4+TzgtADRLKo > Rth3qQBcAK3buTY6tvtzfASDSxj2J1abBgd9xyNiOPt8YbVk7CmEUNxUzOsUFl2uRYkn5AF+ > LHu3x1XBzkoo7qrlZYox7h5U5qPUWXTBVEEdW0ERtvcQS9Q/O7W2/Li/4qFPTCjzDIaaIEU8 > FU8Sj5YU8uo/PO3xtcc4t+PU1QVcFFeh7GmtVQUF6CwzzHig/wC86H/6mLDzDPMeKD/vOh/+ > pixYWml4hfWH/oTn3/d1R/8ALbE1iG9X/wDoVn3/AHdUf/LbEPsRLsZDOySaFjMrQoFRNZ7t > PPHi5ubePk84LQA0SyqEbYdykAXACt27k2Orb7c3x5uukmOyk6tNg4IvuORsRxxt8Y6pVwFu > wNxp0pey27j+oAHjfux5KXdniZ752wlUlUfo64lIXk7E3Fxvs1wTv8fGCLCSGNFVS4JFlBBb > 7k23vsAAfDbC98CQTUF53YLKSzyBtZ3Ab53NjxcbkA8YMJaRQtOzdRlMIOpi6hrBQRa4NjuL > XK7WxBykzznZXZFQyNEgVF1c6eePG9zbx8nnBaAGiWVQjbDuUgC4AVu3cmx1bfbm+POQWYx7 > E6tNgwO+45GxHH2+MdUq4C9wNxp0rey2sx/UWHjfuxAddhKpKo/R1xKQvJ2JuLjfZrgnf4+M > EWEkMaKqlwSLKCC33JtvfYAA+G2F74EgmoLzu4WUlnkB1ncBvnc2PFxuQDxgwmmRQtOzdRlM > QOpi6hrBQRa4NjuLXK7WxIJMm/STq/q6gEbSGONWRNZ3C9Nj/hvc28fJ5xq2Mm9HjT6vokuN > mkBAYNuI38jYjjjb4xrOO4HquCfZf5FhYWFjodEZ6guMlnIaQdyX6fuI1rcD4J4v458YpsgK > rOJBXIA8ZBMm6js2XuvqJJBPF2O+2Lj6iDHJJtIlJ1xbQ+4/iLsNx/zGKdI4kM6Xrk0NGF/E > vpvoIUWfdiTz+bnbDrh/22UWdwZCFMw01oZXiBHX9tzHt7hZjfc3/ePd4wetjJOAK26FEOmQ > XUHRce/nuN2PGpt9sdJQPNoTMCQU1ATA6L6OLt7rG5P5j3bYHVGBL0/q10tGp1S3AJ0bDv5N > wL7WLHu2wwKw5AVlnUfWsE0AOG209vt7rkm57ja2o77YCQFROJBXIA8ZBMm6j8PZe++okkE8 > XY77YRD3qkWPMCyyRXCyHYfhm1tfuPzta53NsKRxIZ0vXIEaML+JfTfQQos+7Enn83O2AAZC > FMw01oZXiBHX9tzHt7hZjfc3/ePd4wetjJOAK26FEOmQXUHRce/nuN2PGpt9sdJQPNoTMCQU > 1ATA6L6OLt7rG5P5j3bYHVGBL0/q10tGp1S3AJ0bDv5NwL7WLHu2wAHICss6j61gmgBw22nt > 9vdck3PcbW1HfbASAqJxIK5AHjIJk3Ufh7L331Ekgni7HfbCIe9Uix5gWWSK4WQ7D8M2tr9x > +drXO5thSOJDOl65AjRhfxL6b6CFFn3Yk8/m52wADIQpmGmtDK8QI6/tuY9vcLMb7m/7x7vG > D1sZJwBW3Qoh0yC6g6Lj389xux41NvtjpKB5tCZgSCmoCYHRfRxdvdY3J/Me7bA6owJen9Wu > lo1OqW4BOjYd/JuBfaxY922AA5AVlnUfWsE0AOG209vt7rkm57ja2o77YCQFROJBXIA8ZBMm > 6j8PZe++okkE8XY77YRD3qkWPMCyyRXCyHYfhm1tfuPzta53NsKRxIZ0vXIEaML+JfTfQQos > +7Enn83O2AAZCFMw01oZXiBHX9tzHt7hZjfc3/ePd4wetjJOAK26FEOmQXUHRce/nuN2PGpt > 9sdJQPNoTMCQU1ATA6L6OLt7rG5P5j3bYHVGBL0/q10tGp1S3AJ0bDv5NwL7WLHu2wAHICss > 6j61gmgBw22nt9vdck3PcbW1HfbASAqJxIK5AHjIJk3Ufh7L331Ekgni7HfbCIe9Uix5gWWS > K4WQ7D8M2tr9x+drXO5thSOJDOl65AjRhfxL6b6CFFn3Yk8/m52wADIQpmGmtDK8QI6/tuY9 > vcLMb7m/7x7vGD1sZJwBW3Qoh0yC6g6Lj389xux41NvtjpKB5tCZgSCmoCYHRfRxdvdY3J/M > e7bA6owJen9Wulo1OqW4BOjYd/JuBfaxY922AB5TKRWVa2qXCQMFd37AOnyBquxJJNyNrkYW > BoLiorl0Vd1ia/UkuqXiBsRqN288eTucLABMetl15Rnq3tfob3t/avjLlcyEMbmRhpYuQV0n > tUAHcWHH+BFtN8ap6wkeHLc6eN9D6qcB7e28ri/2tzfkcjGV9KL8RllQRhCwY9rc2AI33IGw > F+b3tfCHiX3Ued4sv5q17CARGvOsgBQkKo3uQdGx8E2O3Ixwl5acG7lEURKfAuCQv2Pu2+5+ > +OrI0aXiCIdDRNovc3P+4NtrX3vybjZHcBgUQkRtoXVbZQOTa5sT44+OF2hT0a0gnDSKHI0q > +oB7+831bk7atxx9v1x4IXlzzL5RFPJNpkVJA/bG5ACEg8AKHte4OwsOce8VRIjx9KcoQLi4 > uEJ0i45sRtvz2g82t5LGP2zAIZo+k0ExmDRnWIbi5t82Vdt9mNt8a8D76N3DtfUJj9RGM6yQ > psDUMI102tGIJgp48nUbHcXt8YtuKpc/t3J9SaZDVszm/BNPLZeN7Lp383+Ri0SyxwxPLK6x > xopZ3c2CgcknwMekPVB4Z5jxQf8AedD/APUxYUNe1curK6KrzFLX6tOgWEi9iVmcrG1jtZWJ > vfbY2ej0rn2ZGHrV+W0HSqIplVIJKpSY3WRTrJi2JW1gp2F9W+3MpRityegL9iG9X/8AoVn3 > /d1R/wDLbHGzesymy59RdKHxmNLeSnI+XHui4LG90QWvITgPVM8VT6CzqoglSWGTLJ3jkjYM > rqYmIII2II84l9iJdmZK+qRFdl0q+sB7+831bk7atxx9v1x1ZDIQxuZGGli5BXSe1QAdxYcf > 4EW03woaiRGjMU5QgXF9xGTpBI5sRtvz2g82sulH+IyyoIxGWBPa3NgCN9yBsBfm97Xx5KXd > nipLcnruIBEa86yAFCQqje5B0bHxfSfuMcJeWnBu5RFESnwLgkL9j7tvufvjqyNGt4tCHQ0T > aL73P+4NtrX3vybjZHdQwKISI20LqtsoHJtc2J8cfHEaOejWkE4aRQ5GlX1gPf3m+rcna+44 > +364aVmb0tEY2qpSksqkXYFxoAtsLEgBf9rWtfDuOokR4zFOVIFxcXEZOkXHNiNt+e0Hm1vP > OFpoPR1eqBvqKqpgWNnVR1V6oAQbg6l0tdC2pWDbgWY68PHV09S7G7BxFkTe+xHp6gygOTNP > IF0vssTbEBtINxxdd/sD8Y4/qLLmjCvVP+GhRQ0b2C2O3G24e/8Aj98V8UeXLZvwzGtm1LPY > FFsCQevsGYAKfBAB+cIUFEtkIjVxZCTKbKwsWNuvwihQRyCARcYZ+WVe7GvlFGtbZpHoXMYK > /wBW0bwOCQZlbYhmurG7A+drXH8NvnGw4wL+TKmgj/lAoGp1KKIZmIWQsFBQBA1pGF9Ivfgi > 1hcbb7hbk0xps5YjHBojQpQixYWFhYoN5F+oWCZJMS7qNUYJj9xu67D4J4v4vfFOkBVZxIK5 > AHjIJk3Udmy919RJIJ4ux32xcvUP/Us1lmY649oTZz3rxuP+Y2xQsznqZFNBQNVx19XNHS0h > eQERsyqxO7WLBdb3PPF72u64f9tlFi6jmUhTMNNaGV4gR1/bcx7e4WY33Nz7j3eMEWZ3mUCu > HTMakpKNS+wlffydRux41NubbuF9HU84aNP5Q8zaSSY0nSSKPq9TW8RsoXUDqhl7wOI3a9lJ > wOSfyfUU0Riyf19WFHLssMaQ+NOp0QrsCHjYMosRIrAkOCd3Mc6+TzmZUknAkqmCdNdSvsou > uwu1yzar6jxr52wMgKicSCuQB4yCZN1H4ey999RJIJ4ux32xG5StQZs1YV+bZlSJULBBKSqa > 9DgMwA0m5bt3H7jHVvt75nPUyKaCgarjr6uaOlpC8gIjZlVid2sWC63ueeL3ted9Nka66HMp > CmYaa0MrxAjr+25j29wsxvubn3Hu8YIszvMoFcOmY1JSUal9hK+/k6jdjxqbc23cL6Op5w0a > fyh5m0kkxpOkkUfV6mt4jZQuoHVDL3gcRu17KTgck/k+opojFk/r6sKOXZYY0h8adTohXYEP > GwZRYiRWBIcExzE6+TzmZUknAkqmCdNdSvsouuwu1yzar6jxr52wMgKicSCuQB4yCZN1H4ey > 999RJIJ4ux32xG5StQZs1YV+bZlSJULBBKSqa9DgMwA0m5bt3H7jHVvt75nPUyKaCgarjr6u > aOlpC8gIjZlVid2sWC63ueeL3ted9Nka66HMpCmYaa0MrxAjr+25j29wsxvubn3Hu8YIszvM > oFcOmY1JSUal9hK+/k6jdjxqbc23cL6Op5w0afyh5m0kkxpOkkUfV6mt4jZQuoHVDL3gcRu1 > 7KTgck/k+opojFk/r6sKOXZYY0h8adTohXYEPGwZRYiRWBIcExzE6+TzmZUknAkqmCdNdSvs > ouuwu1yzar6jxr52wMgKicSCuQB4yCZN1H4ey999RJIJ4ux32xG5StQZs1YV+bZlSJULBBKS > qa9DgMwA0m5bt3H7jHVvt75nPUyKaCgarjr6uaOlpC8gIjZlVid2sWC63ueeL3ted9Nka66H > MpCmYaa0MrxAjr+25j29wsxvubn3Hu8YIszvMoFcOmY1JSUal9hK+/k6jdjxqbc23cL6Op5w > 0afyh5m0kkxpOkkUfV6mt4jZQuoHVDL3gcRu17KTgck/k+opojFk/r6sKOXZYY0h8adTohXY > EPGwZRYiRWBIcExzE6+TzmZUknAkqmCdNdSvsouuwu1yzar6jxr52wMgKicSCuQB4yCZN1H4 > ey999RJIJ4ux32xG5StQZs1YV+bZlSJULBBKSqa9DgMwA0m5bt3H7jHVvt75nPUyKaCgarjr > 6uaOlpC8gIjZlVid2sWC63ueeL3ted9Nka66HMpCmYaa0MrxAjr+25j29wsxvubn3Hu8YIsz > vMoFcOmY1JSUal9hK+/k6jdjxqbc23cL6Op5w0afyh5m0kkxpOkkUfV6mt4jZQuoHVDL3gcR > u17KTgck/k+opojFk/r6sKOXZYY0h8adTohXYEPGwZRYiRWBIcExzE6+T2pQorKtFM8uiBhq > ZzpQdO/BN2Jve9v3rXwsRXppZzW5037QzDMKOPqQQTVGlVbQrB3sAu5btsV/cJub4WJT2Q1o > tXrexyfOwRcaqa4/+M/H3xmGgBollUI2w7lIAuAFbt3JsdW325vjUPW3/VGeC1yTTgfqZXAx > lilXUL3A3GnSl7LbuP6gAeN+7CLif3Uea4tvxl+AlUlUfo64lIXk7E3Fxvs1wTv8fGCLCSGN > AqlgSLKCC33JtvfYAD4bYXvgSCagvO7hZSWeQHWdwG+dzY8XG5ANrYMJaRQtOzdRlMIOpi6h > rBQRa4NjuLXK7WwuFSTPOdldkVDI0SBUXVzp548b3NvHyeceBSFM5oTUa45UidljvoWb2aUP > lr9rbcWDfJx7SDSxj7SdWmwYHfccjYjj7fGPOCWb9sUaRwM4YOsTqo/CksAGJPwA3ixO3nbX > g/fRt4dv6lFhp/TdTnkMksGcSZbJl0jT9daNJ9TaHErFSy29xHkbXHOJmi9KyUctHPJmGXVt > VK2uCorcoknYOtiXQNV6Yjcg9gUcWGwtN0eWimy+gyOBbPUaZZreIwe0c+WF9jcaPvjwzbPR > ldBV5/CiSvdKLK4nbSsjk2S58Aks/da17EjnHo29I9W3pEJmHrKDK8zno631Tl8dXTuY5F/Y > VSxUjkXFSR/kcFQetIsxqRT0fquhkmbfT+w6lb/4mpxQH/k/eR2kfMgXYlmISEAk7nbq7YtH > 8mvpqKmlmrag6Y4gXlfmyrck2B+L8f64hxUlqSJTZe4f5wrWR08ed0BmlQSKjZRIQykkAm9X > bkHnFO9TUFVHkU9bTZ3BSrmbtTPHQZQ0Yq3kViwZGqGQMQCTJp12WwbhTcWeWWlkmZdNXmzm > NVuDoiAAYX4Nl0p4PdfkYpHqqu+t9QJSRQl6bL/6NTDS15JA9prWsbF00W33gupGo4pybVVW > 2Zsu5U1ORBTsjlEQytDGFRNR7tPPHi5ubePk84LQA0SyqEbYdykAXACt27k2Orb7c3wEg0sY > 9idWmwYHfccjYjj7fGEpVwF7gbjTpW9lt3H9RYeN+7HmO549tuTYSqSqP0dcSkLydibi432a > 4J3+PjBFhJDGiqpcEiyggt9ybb32AAPhthe+BIJqC87uFlJZ5AdZ3Ab53NjxcbkA2tgwlpFC > 07N1GUwg6mLqGsFBFrg2O4tcrtbACTG+YGKWBoyS1OqCMdZgBoO5v3KBc3NtQA/i84762rqz > r0tFPLEvUneZXEm8KpHo0svU2/DkWS6sDuToBuSp3EAfUwXQdyJODvvqDKLDbfUo22I5xLVe > Z5VHM0+ZrkzipVpqc5xCakQ0yswV442ZSxkbqsCjEdOKEae5Rhvw3pFy9j0PBn/LmvkogqSS > GSUk3VlQzgm5Fo1/rrEkdx8OPvjn1CBN6q8QXdhU8oDuwPW/ebYNyODtjQYa7Ip8xpqRvT/o > umnjeKGupnoo2ZWUA1ThtY6axgTe4MD0QQSJFvDUkkeYeq0mpfTeVSUTlqj9mx5RTvpplXVv > pUuJNNhbXbqsqmwNsNVNN6HSi2m16Hv/ACaKX9ZJOzlpdTRyWYkA9N2tuzW3a1gbAr99tvxj > foBVT1VCEWiW9XVE/RC0JP4v9X8pa2n7AffGyY8/lS5rpFGDPnc38iwsLCxQMCM9QXGSz2aQ > dyX6fuI1rcD4J4v45xWfSlBX1lfm/qOjjaeSiVqLLYKiQmzjSJ2sXF21LbSxUMUHeobULL6i > DHJJtIlJ1xbQ+4/iLsNx/wAxjKc3oMtyjKar6Zcyikj6cdJE1fLpDFU0oFEoJ8k24XUR7cOM > H7RVLvo1oZZXxxQ0c3p7IpKWSVNaU0CtHDHpET3DldbdJukLADRG7b6lgxAZ/neY0nplIp8g > iyjOcxkekptAid4zM5knZdJZCoAVizMpkZWJVNr0LJcl6qP9XPnFR0FRHZK+RdUhZS2xYcAq > Ljbue+6jE1TZZQUlRJUQJXiZAsXUmq2l0BjGSi6pDYt277WJPdtjfFuS2cSiovQ8jpo6ONqW > nSrWCnSKOLQx0rGNFgt2uSbnuNrXO+2HvpSgzCszDN/UdHG08lEjUWWwVEhNnGkTtYuLtqW2 > lioYoO9Q2oMyHvUqseYFlkiuFkPb/Vm1tfuPzta53NsVrN6DLcoymq+mXMopI+nHSRNXy6Qx > VNKBRKCfJNuF1Ee3Ey7ER6mtDLK+OKGjm9PZFJSySprSmgVo4Y9Iie4crrbpN0hYAaI3bfUs > GIDP87zGk9MpFPkEWUZzmMj0lNoETvGZnMk7LpLIVACsWZlMjKxKptehZLkvVR/q584qOgqI > 7JXyLqkLKW2LDgFRcbdz33UYmqbLKCkqJKiBK8TIFi6k1W0ugMYyUXVIbFu3faxJ7tsRFuS2 > TKKi9DyOmjo42padKtYKdIo4tDHSsY0WC3a5Jue42tc77Ye+lKDMKzMM39R0cbTyUSNRZbBU > SE2caRO1i4u2pbaWKhig71DagzIe9Sqx5gWWSK4WQ9v9WbW1+4/O1rnc2xWs3oMtyjKar6Zc > yikj6cdJE1fLpDFU0oFEoJ8k24XUR7cTLsRHqa0Msr44oaOb09kUlLJKmtKaBWjhj0iJ7hyu > tuk3SFgBojdt9SwYgM/zvMaT0ykU+QRZRnOYyPSU2gRO8ZmcyTsukshUAKxZmUyMrEqm16Fk > uS9VH+rnzio6CojslfIuqQspbYsOAVFxt3PfdRiapssoKSokqIErxMgWLqTVbS6AxjJRdUhs > W7d9rEnu2xEW5LZMoqL0PI6aOjjalp0q1gp0iji0MdKxjRYLdrkm57ja1zvth76UoMwrMwzf > 1HRxtPJRI1FlsFRITZxpE7WLi7altpYqGKDvUNqDMh71KrHmBZZIrhZD2/1ZtbX7j87Wudzb > Fazegy3KMpqvplzKKSPpx0kTV8ukMVTSgUSgnyTbhdRHtxMuxEeprQyyvjiho5vT2RSUskqa > 0poFaOGPSInuHK626TdIWAGiN231LBiAz/O8xpPTKRT5BFlGc5jI9JTaBE7xmZzJOy6SyFQA > rFmZTIysSqbXoWS5L1Uf6ufOKjoKiOyV8i6pCyltiw4BUXG3c991GJqmyygpKiSogSvEyBYu > pNVtLoDGMlF1SGxbt32sSe7bERbktkyiovQ8jpo6ONqWnSrWCnSKOLQx0rGNFgt2uSbnuNrX > O+2HvpSgzCszDN/UdHG08lEjUWWwVEhNnGkTtYuLtqW2lioYoO9Q2oMyHvUqseYFlkiuFkPb > /Vm1tfuPzta53NsVrN6DLcoymq+mXMopI+nHSRNXy6QxVNKBRKCfJNuF1Ee3Ey7ER6mtDLK+ > OKGjm9PZFJSySprSmgVo4Y9Iie4crrbpN0hYAaI3bfUsGIDP87zGk9MpFPkEWUZzmMj0lNoE > TvGZnMk7LpLIVACsWZlMjKxKptehZLkvVR/q584qOgqI7JXyLqkLKW2LDgFRcbdz33UYmqbL > KCkqJKiBK8TIFi6k1W0ugMYyUXVIbFu3faxJ7tsRFuS2TKKi9Epl1NFRvNSQRTiCnpTHDqb8 > NEEYtYFiWO/JG1yL4WDoLiorl6dXdYmv1JLql4gbEajdvPHk7nCx2cE16yhM+VZ3Gp7mMCrv > a5Mr2/1xnj5RmCa3li0yKArmRgwIOkKoFriwYC/F/I03xpvqK/QzWyzMepT7Qmzn8R+Nx/zG > 18VF5STOAK4aGjVRrDaQ2jYd+7HUe7xq52xmuxK7nuRkvwqrpc0yvjJqlJJOtH7FAZVcXDsB > oU325ZCfFv0wL5RmLo8fT1GBRHbqDa+my28e8knjn74sbPEjTECv5jDDrjs1aAALtbUbi5/M > e7HGaNEcxfV3DRqw6twhJQWHfyQRv41Hu2xT5bSUeVY+vUr8+T1gkmB6REYs0iue9mIK3uPc > dS78Wt98etNQ5llmbRZm1ClRNAhjaOaqMakMY9IUhWIIsF4tvyNO88ysOuvQzO4Md7Sn8mw7 > +T5P3buwDykmcAVw0NGqjWDpDaNh37sdR7vGrnbFlWFVXLmiW04FNU+ePc8Gzv1Rprlno8u+ > om0rUTo7DUrAKIQh9hIZFL6nsLmxPDeTMfUU2d0lbJk9DNBlsbJDRLWvH0ZXCAuZVF2OlmFi > qqAfJF8SDPEjTECv5jDDrjs1aAALtbUbi5/Me7HGaNEcxfV3DRqw6twhJQWHfyQRv41Hu2xq > 0bNHpUep8+01ES5HlylVC9X9q1DqrNYL2lV1e5Ta4G/I8R0Nd6iocqFAMroUhiKGfVUNepPa > VUGx6XcVPD3O2oWJMgysOuvQzO4Md7Sn8mw7+T5P3buwDykmcAVw0NGqjWDpDaNh37sdR7vG > rnbBoNANn3qYVdTK1HRQziJYopY5CTR3I0JpYWkbvB1kgAtfSQuk14ZJXrB9OkV1pUWFV6g7 > RZbL9raySeOfviys8SNMQK/mMMOuOzVoAAu1tRuLn8x7scZo0RzF9XcNGrDq3CElBYd/JBG/ > jUe7bFF2NC7XOZ8jFhekp+hX58nrOpMD0iI9mkVz3sxBW9x7jqXfi1vvjr5RmCa3liCyKArm > RgwIOkKoFriwYC/F/I03xYmVh116GZ3BjvaU/k2HfyfJ+7d2AeUkzgCuGho1UawdIbRsO/dj > qPd41c7Yo8upM3lWP8lfGTVKSSdaP2KAyq4uHYDQpvtyyE+LfpgXyjMXR4+nqMCiO3UG19Nl > t495JPHP3xY2eJGmIFfzGGHXHZq0AAXa2o3Fz+Y92OM0aI5i+ruGjVh1bhCSgsO/kgjfxqPd > tg8tpDyrH16leqcmrS06h1UoLGaKQhizEFdyNm7l3G3H3xYFzr1XR0X00MsdHHANKLHHGEjB > uEVF07aRKoHj8NQeH1+jKw669DM7gx3tKfybDv5Pk/du7APKSZwBXDQ0aqNYOkNo2Hfux1Hu > 8audsW14kK1qDaL6sOFSag2htnGYepc5oKzLq+ukjppf61KbQrAsSViJI9p6qBvBVbX92quR > emq6KhzKjK9frhI5XkEZYKNLBBt29zqzH5jXftxbWeJGmIFfzGGHXHZq0AAXa2o3Fz+Y92OM > 0aI5i+ruGjVh1bhCSgsO/kgjfxqPdtizwf8A2ZY6dx5eZnh6TyeopPVVOFSEQ0yuGaMmxBW4 > FjbezLwLWAHzjTMVDIFK50R0a1SBuZZLoOweNRuf8Ob7nFvwmzKo12dPUvxKI0xaiLCwsLGQ > 1kX6hYJkkxLuo1RgmP3G7rsPgni/i98UeuooapSKyGrtDPFLH1GDaCNAsAWO7amBNrdx3ut8 > Xn1D/wBSzWWZjrj2hNnPevG4/wCY2xTZJSTOAK4aGjVRrB0htGw792Oo93jVzth1w9brZTN6 > ltHhFTx0cElOi1gMbxaj1QO4mMkkBlAdiSSRt3k38Y92LO8ygVw6ZjUlJBqX2Er7+TqN2PGp > tzbHWeJGmIFfzGGHXHZq0AAXa2o3Fz+Y92OM0aI5i+ruGjVh1bhCSgsO/kgjfxqPdthgVN7C > mZUknAkqmCdNdSvsouuwu1yzar6jxr52w2rqGGqUishq7QzxSx9Rg2gjQLAFju2pgTa3cd7r > fDplYddehmdwY72lP5Nh38nyfu3dgHlJM4ArhoaNVGsHSG0bDv3Y6j3eNXO2Ia33JT11R4RU > 8dHBJTotYDG8Wo9UDuJjJJAZQHYkkkbd5N/GPdizvMoFcOmY1JSQal9hK+/k6jdjxqbc2x1n > iRpiBX8xhh1x2atAAF2tqNxc/mPdjjNGiOYvq7ho1YdW4QkoLDv5II38aj3bYlEN7CmZUknA > kqmCdNdSvsouuwu1yzar6jxr52w2rqGGqUishq7QzxSx9Rg2gjQLAFju2pgTa3cd7rfDplYd > dehmdwY72lP5Nh38nyfu3dgHlJM4ArhoaNVGsHSG0bDv3Y6j3eNXO2Ia33JT11R4RU8dHBJT > otYDG8Wo9UDuJjJJAZQHYkkkbd5N/GPdizvMoFcOmY1JSQal9hK+/k6jdjxqbc2x1niRpiBX > 8xhh1x2atAAF2tqNxc/mPdjjNGiOYvq7ho1YdW4QkoLDv5II38aj3bYlEN7CmZUknAkqmCdN > dSvsouuwu1yzar6jxr52w2rqGGqUishq7QzxSx9Rg2gjQLAFju2pgTa3cd7rfDplYddehmdw > Y72lP5Nh38nyfu3dgHlJM4ArhoaNVGsHSG0bDv3Y6j3eNXO2Ia33JT11R4RU8dHBJTotYDG8 > Wo9UDuJjJJAZQHYkkkbd5N/GPdizvMoFcOmY1JSQal9hK+/k6jdjxqbc2x1niRpiBX8xhh1x > 2atAAF2tqNxc/mPdjjNGiOYvq7ho1YdW4QkoLDv5II38aj3bYlEN7CmZUknAkqmCdNdSvsou > uwu1yzar6jxr52w2rqGGqUishq7QzxSx9Rg2gjQLAFju2pgTa3cd7rfDplYddehmdwY72lP5 > Nh38nyfu3dgHlJM4ArhoaNVGsHSG0bDv3Y6j3eNXO2Ia33JT11R4RU8dHBJTotYDG8Wo9UDu > JjJJAZQHYkkkbd5N/GPdizvMoFcOmY1JSQal9hK+/k6jdjxqbc2x1niRpiBX8xhh1x2atAAF > 2tqNxc/mPdjjNGiOYvq7ho1YdW4QkoLDv5II38aj3bYlEN7HlKFFZVopnl0QMNTOdKDp34Ju > xN73t+9a+FhUSlZqsdGtUiFrmWS6D8MeNRuf8Ob7nCwAWL1DcQZsQ0g76e/THcR1JLgfBPF/ > HPjFRkBVZxIK5AHjIJk3Udmy919RJIJ4ux32xbfUYYwZrpEpPVptofcfxX2G4/5jFSkcSGdC > a5AjRhfxL6b6CFFn3Yk8/m52wADIQpmGmtDK8QI6/tuY9vcLMb7m/wC8e7xg9bGScAVt0KId > MguoOi49/PcbseNTb7Y6SgebQmYEgpqAmB0X0cXb3WNyfzHu2wOqMCXp/VrpaNTqluATo2Hf > ybgX2sWPdtgAOQFZZ1H1rBNADhttPb7e65Jue42tqO+2AkBUTiQVyAPGQTJuo/D2XvvqJJBP > F2O+2EQ/9KVY8wLLJFcLIdv6s2tr9x+drXO5thSMJDOl65AjRhfxL6b6CFFn3Yk8/m52wADI > QpmGmtDK8QI6/tuY9vcLMb7m/wC8e7xg9bGScAVt0KIdMguoOi49/PcbseNTb7Y6SgebQmYE > gpqAmB0X0cXb3WNyfzHu2wOqMCXp/VrpaNTqluATo2HfybgX2sWPdtgAOQFZZ1H1rBNADhtt > Pb7e65Jue42tqO+2AkBUTiQVyAPGQTJuo/D2XvvqJJBPF2O+2EQ96pVjzAsskVwsh2/qza2v > 3H52tc7m2E7CQzpeuTQ0YX8S+m+ghRZ92JPP5udsAAyEKZhprQyvECOv7bmPb3CzG+5v+8e7 > xg9bGScAVt0KIdMguoOi49/PcbseNTb7Y6SgebQmYEgpqAmB0X0cXb3WNyfzHu2wOqMCXp/V > rpaNTqluATo2HfybgX2sWPdtgAOQFZZ1H1rBNADhttPb7e65Jue42tqO+2AkBUTiQVyAPGQT > Juo/D2XvvqJJBPF2O+2EQ96pVjzAsskVwsh2H4ZtbX7j87WudzbCdhIZ0vXJoaML+JfTfQQo > s+7Enn83O2AAZCFMw01oZXiBHX9tzHt7hZjfc3/ePd4wetjJOAK26FEOmQXUHRce/nuN2PGp > t9sdJQPNoTMCQU1ATA6L6OLt7rG5P5j3bYHVGBL0/q10tGp1S3AJ0bDv5NwL7WLHu2wAHICs > s6j61gmgBw22nt9vdck3PcbW1HfbASAqJxIK5AHjIJk3Ufh7L331Ekgni7HfbCIe9Uqx5gWW > SK4WQ7D8M2tr9x+drXO5thOwkM6Xrk0NGF/EvpvoIUWfdiTz+bnbAAMhCmYaa0MrxAjr+25j > 29wsxvub/vHu8YPWxknAFbdCiHTILqDouPfz3G7HjU2+2OkoHm0JmBIKagJgdF9HF291jcn8 > x7tsDqjAl6f1a6WjU6pbgE6Nh38m4F9rFj3bYAJbI1Iz/TapcItld37ANA3A1XYkkm5G1yPG > Lfinenr/ALckXp1d1tfqSXVbxqbEajdvPHk7nFxwl4j9xF9fYWFhYWF5YRnqC4yWchpB3Jfp > +4jWtwPgni/jnximyAqs4kFcgDxkEybqOzZe6+okkE8XY77YuPqIMckm0iUnXFtD7j+Iuw3H > /MYp0jiQzpeuTQ0YX8S+m+ghRZ92JPP5udsOuH/bZRZ3BkIUzDTWhleIEdf23Me3uFmN9zf9 > 493jB62Mk4ArboUQ6ZBdQdFx7+e43Y8am32x0lA82hMwJBTUBMDovo4u3usbk/mPdtgdUYEv > T+rXS0anVLcAnRsO/k3AvtYse7bDArDkBWWdR9awTQA4bbT2+3uuSbnuNrajvtgJAVE4kFcg > DxkEybqPw9l776iSQTxdjvthEPeqVY8wLLJFcLIdv6s2tr9x+drXO5thOwkM6Xrk0NGF/Evp > voIUWfdiTz+bnbAAMhCmYaa0MrxAjr+25j29wsxvub/vHu8YPWxknAFbdCiHTILqDouPfz3G > 7HjU2+2OkoHm0JmBIKagJgdF9HF291jcn8x7tsDqjAl6f1a6WjU6pbgE6Nh38m4F9rFj3bYA > DkBWWdR9awTQA4bbT2+3uuSbnuNrajvtgJAVE4kFcgDxkEybqPw9l776iSQTxdjvthEPeqVY > 8wLLJFcLIdh+GbW1+4/O1rnc2wnYSGdL1yaGjC/iX030EKLPuxJ5/NztgAGQhTMNNaGV4gR1 > /bcx7e4WY33N/wB493jB62Mk4ArboUQ6ZBdQdFx7+e43Y8am32x0lA82hMwJBTUBMDovo4u3 > usbk/mPdtgQ0YEoj+rXS0anVLcAnRsO/3G4F9rFj3bYADkBWWdR9awTQA4bbT2+3uuSbnuNr > ajvtgJAVE4kFcgDxkEybqPw9l776iSQTxdjvthEPeqVY8wLLJFcLIdh+GbW1+4/O1rnc2wnY > SGdL1yaGjC/iX030EKLPuxJ5/NztgAGQhTMNNaGV4gR1/bcx7e4WY33N/wB493jB62Mk4Arb > oUQ6ZBdQdFx7+e43Y8am32x0lA82hMwJBTUBMDovo4u3usbk/mPdtgdUYEoj+rXS0anVLcAn > RsO/k3AvtYse7bAAcgKyzqPrWCaAHDbae3291yTc9xtbUd9sBIConEgrkAeMgmTdR+HsvffU > SSCeLsd9sIh71SrHmBZZIrhZDsPwza2v3H52tc7m2E7CQzpeuTQ0YX8S+m+ghRZ92JPP5uds > AAyEKZhprQyvECOv7bmPb3CzG+5v+8e7xg9bGScAVt0KIdMguoOi49/PcbseNTb7Y6SgebQm > YEgpqAmB0X0cXb3WNyfzHu2wIaMCUR/VrpaNTqluATo2Hf7jcC+1ix7tsADymUisq1tUuEgY > K7v2AdPkDVdiSSbkbXIwsDQXFRXLoq7rE1+pJdUvEDYjUbt548nc4WACw+pplgpc3kd3RFen > LFPdbqPcA3FieL+MUQZ1RSh11141PGVJfdVBXg673azf8V97Yt/rquTLckz2reYQrG1OOrpv > ovK4vwTcX5G45GMeo8yy6RZGSZlSXU8byLY6QLgEjUBcBhzyLE7NhflW3wl/LXQWZ12RW91d > i4SZ1RqG1ftFC7xlQZCe3tNwNQN2Cn5NmvfBjO6OYO4fMAgMah1JGnyVvr9x0tvz3nm2KhLm > tAgRlliYi8H4OpxqJuDtfkXA+bH74cQuK2xRBEhvG4YHawAF7/vEqdrePA4xvMyYrclr9jBL > Pyorclr9i0pnFJMy6HrvxnEcZvxp0krfVu5udzuNf+OHsgKicSCuQB47EybqOzZe++okkE8X > Y77YqeTqsWYUkUZme29obhz7dgQRbmx3HHjFsklJM4ArhoaNVGsNpDaNh37sdR7vGrnbDDDu > lbBuQzwMid8HKQMpCmYaa0MrxAjr+25j29wsxvubn3Hu8YJizvMoFcOmY1JSQal9hK+/k6jd > jxqbc2x1niRpiBX8xhh1x2atAAF2tqNxc/mPdjjNGiOYvq7ho1YdW4QkoLDv5II38aj3bY2G > 8VTLHAaljJVMkQQFw9gi3XYXbdjqvq8audsR4zqilDqHrxqeMqS+6qCvB13ubN/xX3th3mDy > QUNY0aVkUg6Y6ksl0S+gXtc93m9rg332xWaHKKmrpsyqqKMtRUivLU1s+qOOnRV12Y2ZmOgE > 2jD21JfnC7IuuVvJULMu7IjZyUkzJnVGobV+0ULvGVBkJ7e03A1A3YKfk2a98GM7o5g7B8wV > AY1DqSNPkrfX7jpbfnvPNsNJfSGbCaOH6z09BI0j0UUklVOsUk4YdiuYdLOC2nSpuSrjlHt5 > Q+is+LiFqzKGZ2iiEbSVAk1SIGSMj6cWcKutlI1KlmcAd2I3ma9Djefr0JD9t0brrD12l2CK > 2rZQuksL6t2O+/I1fpjgzqikDrrrxqeMgl91UFeDrvdrN/xX3tiBloa307nUuUVE1KKqlUa5 > ad3dUZtJAuyLYhWQ3AI3FjcG0BJVRVvqFqOPU1LFG5vuvUa6jexsRpIFt/N74rruyZ2uveiu > u7Lna6t60XSo9TZXAzo8mYiUtG3TVmdwnadWhWuNQB3+HBvvbCh9T01RHUTNTZzDBDIsTzbH > p2CuQdMhIuLnWRYazc7b12KKOGMRxRqiDhVFgP8ADE/6P/qc1/8Azv8A+zFhnGMktN9RtGMl > HTfUejPKKSJZlkrunNpEb6tgo0k2OqxY3JvyNf6Y4M6opQ6668anQgl90UFeDrvc2b/ivvbE > dnca0Od0T0lqczRzu+m4XWWiGu3Abu91r7D4FmPSj/EZZUEYjLAntbmwBG+5A2Avze9r4U5O > VfTZybE2Xl5FFnInv9iekzmjUOSMxQs0bAGQnt7Te2oG7BTvubNe+PGX1RlSSGOSprkZghUK > xLKgsWvZ/s12PGs77YrFZmppJBBStBHN09ErMDZYy4Gr5N9Wmy2vvfnujq1JIJXefMKKKOqH > QaRYSe1VQWW8lypBJJHBJtyCNGNPIsXNN6RpxbMm2PPJ6Rp/pn1DQVfqqGjjNY0rqwj6p7V0 > xhj+8bt3A3I/ftvY20XGL/yeqJfVmXThgdKzjVY3kLLu393tAW97KoudxbaMYMufNZ33oZ4l > nOmt70LCwsLGU2EX6hYJkkxLuo1RgmP3G7rsPgni/i98U6QFROJBXIA8diZN1HZsvffUSTc8 > XY77YuXqH/qWayzMdce0Js57143H/MbYpskpJnAFcNDRqo1g6Q2jYd+7HUe7xq52w64f9tlF > ncGUhTMNNaGV4gR1/bcx7e4WY33Nz7j3eMExZ3mUCuHTMakpINS+wlffydRux41NubY6zxI0 > xAr+Yww647NWgAC7W1G4ufzHuxxmjRHMX1dw0asOrcISUFh38kEb+NR7tsMCsVTLHAaljLVM > kQQM4ewRbrsLtux1X1eNXO2I8Z1RSh11141PGVJfdVBXg673azf8V97Yd5g8kFDWNGlZFIOm > OpLJdEvoF7XPd5va4N99sUqpjip6aqZKmNYyrStI7FHSMG2wsSWIvYC47gSbA4WZWRbC1QgK > szIuhaoVvuWafPaCCOR5Wr4QWRgXlOyAKb21CxYKxv8ADXvgovUFBVxNNDNXNDeNVlje4Hkr > cPYsdLffvPNsZzQUQrgMyqJpkVGSanSKVi0RF27XDm6kWJ4bWrDs0MS/rPVT1tfBleY1Ygpa > 59DzC2qHcFXLal7dVtXyuq1jbGhxyOVal1NkK7nDcp9fwXr9t0brrD12l2CK2rZQuksL6t2O > +/I1fpjgzqilDqHrxqeMqS+6KCt7HXe5s3/Ffe2KRkZeKr61PUuqKnTUmUyKHuNTA7jtJChl > uDouPGJjpR/iMsqCMIWBPa3NgCN9yBwL83va+F12bdXPl2J787IrnyJ7f4J6TOaNQ5IzFCzR > lQZCe3tN7agbsFO+5s174IZ1SSqzh8wVLoodSe3glb6/cdLb8955tivrI0aXi0IdDRNovc3P > +4NtrX3vybjZHcBgUQkRtoXVYWUDk2ubE+OPjivzG8p81v7JljOc0hUPqrgshCoxawULpLC+ > rdjvvyNX6YZVnqzJ6MrHU1GYIZ5E6VtTEKNN7WYkE2P66vNsRcdRIjxmKcqQLi4uIydIuObE > bb89oPNrDm0FCPR1dTyTrStXVMEX1M6KF0GUL5/eQK5ZCdSsHPFmOrDybrp6k+hvwcm/Ik9v > oh9/PfInmlhWbNBNqRtAWQlVGm5tcEE2O/5ufGF/Pz0/JFJMKzMRCCg6ixydoFiRfVa53357 > /NsUg5LRz5ZAHoaqlloXFsrkeQ1OZja7iIkdJT3XKarXfnTu4OWUMeZwZmKR6wzIEloUrJdO > VcXaacEutu66soA79+3dpp+415Ze5e6b1TlVcC0E9cQ2kLqupVBY3F23LWazeLnfbHuM6opQ > 6668anQgl90UFeDrvc2b/ivvbGfZLQQ5R6ieKirHq3WNpDmYBCS6yoGmzMDpIfu51X2ugOLF > 0o/xGWVBGELAntbmwBG+5A2Avze9r4U5eXbTZypifNzLqbOSD2T0mc0ahyRmKFmjYAyE9vab > 21A3YKd9zZr3wQzqklVnD5gqXRQ6k9vBK31+46W357zzbFfWRo0vFoQ6GibRfe5/3Btta+9+ > TcbRu4DAohIjbQuq2ygcm1zYnxx8cZ/MbzH5re+iZb8uzSmqKkhRVt1opUiMh7V0xkm/cbty > fkasLEH6fkLZxCokJQQTHTvYExb23+wH/ujCxvxsmyyG5DLFy7LK+aRa/wCVqGSo9Dep4ol1 > OxpbC/P47bD7/bzjKvRvoqealU1T6mm7kp2UWtYE+4i52ItxdRza67P67jWXIs+RxdSae4vz > +K/+mKl6fn+jihn0agt7i9rg3v8Abgebjbe4HY7x61LqzPxfMlVqqPTYxgytsrzWnrJg0hh0 > siMGTT+8LfFzY+L6fJBCwsNScwoVmEaJNVPJOViFiDIxbc239wUAbdrbC9zo3qmSEUkKmxnZ > u073C8ne/BOnY3vz+Y5dk7SVOTU3RjtMViRCASzEAWX/AB3PngcYVcZf6YpGJxksZOT3tk3Q > EHNYGieo6UYWJGBu5WxJA/hJv87X5Nr4s0gKicSCuQB4yCZN1HZsvffUSSCeLsd9sVej1fta > FUEgImAK07ajte6qQRtYgXB2HGLQ7iQzpeuTQ0YX8S+m+ghRZ92JPP5udsUcN+2xrwnfhPfu > DIQpmGmtDK8QI6/tuY9vcLMb7m/7x7vGD1sZJwBW3Qoh0yC6g6Lj389xux41NvtjpKa5tCZg > SCmoCYHRfRxdvdY3J/Me7bAhowJRH9Wulo1OqW4BOjYd/uNwL7WLHu2wyGo1zpbUNahWpkVR > GFZ27QupOBclibk3I5JGKzDLLSkSwZlV0JchZHp6h4VYL2jUYzdgO4/a5tu2LNmd/wBnZinT > q7gxr+JJ2qT07AjUbtffjydzik1s8j0MnQJuqhI7ICttNmYk7WUAE7b77jymzebx1yvQhz+d > 5MVB6PekznOaiaqmHqDPGgUrTQocynBeXgtbqA7bkj8h+cPRmebS0yBc7zoTMpUWzOpuNzYm > 7m5NwAB/CdvOGNKsNPNHl6u6wUqGNitzdv3z7rE7aQDbdTvY49hefqCljIfrBIjcuzWOy3As > b87DwOMU35FnNyxfYniGVKM1VXLpH192KRELs6PPKmoL1JpC8jlmLsTcncsxa2+55J3xVMhJ > bNI2JYlqZ2JPklkJJ+9/9LYt0p73UBR36dKtqAb4BHIFx9vj5xS8p+pFVG1KsRcUzAtO5VEv > pOprA/wn42tvjTwxuTk2d8Jk5Ocpdy24nPR/9Tmv/wCd/wD2YsZnmeb11HT071oDSVCl1ihq > GjCAEC5AUNY78sQSD8YWRVdS8U9bQ0kVHJCCwnhlaIne4U9pDC9hpOxIF74bDo0f1Tvm2WA3 > sYZwQPPdFiOn1IYIdMa1MzpDCsoKqZHssZuDc86rjx833ZR1+a5lUUwzNaYyU0TKHhJu3U02 > DCwAYaNRtYd62AGAljnrs4hihk6RplSeGTTfRLftax2JUpf79wPOE91auy1H2EV9SvzlH2Fm > 2V5TX11U1KwNBl9P1PrZC0pktsSN11GVjoSO4Q6WZfcQewNNUZhHNNQzQq0HSp7y3UsLGYC2 > 9wzohIHKkeDa6ZcmR5Zk0+Uz5FmVHHIweaAQz1Q1AKAyyIGK20DTfSw0g6V2xX2linqIYqXL > aimpKdmipYJ3aSRnMp6pLBiTqcEe4n8LYjUcbcyShS/Q350owx2uxOeknVvV2XrG0hijVkTW > dwvTY/4b3NvHyecatjJvSA0+r6JLjZpAQGDb9N/I2I442+Mazjz0SOCfZf5FhYWFjodEZ6gu > MlnIaQdyX6fuI1rcD4J4v458YpsgKrOJBXIA8ZBMm6js2XuvqJJBPF2O+2Lj6iDHJJtIlJ1x > bQ+4/iLsNx/zGKdI4kM6Xrk0NGF/EvpvoIUWfdiTz+bnbDrh/wBtlFncGQhTMNNaGV4gR1/b > cx7e4WY33N/3j3eMHrYyTgCtuhRDpkF1B0XHv57jdjxqbfbHSUDzaEzAkFNQEwOi+ji7e6xu > T+Y922B1RgS9P6tdLRqdUtwCdGw7+TcC+1ix7tsMCsa50tqGtQrUuqiIKzt2gak4FyWJuTcj > kkYzr1VTSz5MohO7yqr8BQL6R9ybjkfJ+caLmd/2dmSdOr1Dpr+JJ2qT07AjUbtc348nc4p7 > pHXR9F9RiFlGlL7Abm9+VAB2+5uNrqMufJkRm/QRZ1nh5UZvshpXJWNBLII55olCyVciqPwp > W1GUsqk9jOrSa9lGoqbFLCoU+U12bTnOJ6V1y3VphaZTpnezaIkAYM5Zl0nQTpuSbWxoMVZB > HUxwZnlv1nTUulTC6tMmoXVluBoax5VwQwUhRawCdv2nIr01ClLKrhLpI1RNUuHBAeZhrddh > pU3A0jnt07Z5lShzJjCzOpjDmTPOmh0UsIKBdCIjBCLajd3CqAAo1MSFAAF7eMPNADRLKoRt > h3KQBcAK225Njq2+3N8BL73QKvv06Va4DfAPkC4+3x84SlXAXuBuNOlL2W3cf1Fh437secnJ > zk5M8rOcpzcn3CVSVjfo64lIXk7E3Fxvs1wTv8fGCLCSGNFVS4JFlBBb7k23vsAB8NsL3wJB > NQXndgspLPIDrO4DfO5seLjcgG1sGEtIoWnZuoymEHUxdQ1goItcGx3FrldrY5OUmN68xSwN > GSWp1QRjrMANB3N+5QLm5tqFv4vOJD1HT5tm9bDl8EtItXHK1dTtK7WiaIKiKyhnAOmVJQdg > T7oxc3YTOINepgug7kSDY776gyiw23DKNtiOcS9XmeVRStPma5M/1KtPTnOITUrDTKzBXjjZ > lLGVuqwKMR04oRpuyjDfhvSLk/Q9DwZ/y5r5KlFXtLRH1RQVLRSU7LBm+ZugL1Q7BogSxUD2 > 2LIp9lz78H06Kh+kppKSVPTedaWpMpha880p0WeR2ayi+nZZB+7ce/Fwgr8iqMzpaNvT3oqm > njeKGupnoY2cMoBqnDax01jAmtqDA9EEEiRb12mzKnq/V3Xi9PZKcrLmb6AZTTtantstwpbq > sCqga7dV1Xg2w0dsUPq6JWRlJdl3PCmpaumqZaavdGnpVipdEBvGkYGtFS4DEAOB3XN1uSb7 > SOgBollUI2w7lIAuAFbbcmx1bfbm+G0UCwCRBT00LySs7xUoAiV2JJCW/dBIA+wAuecewKuo > W7A3GnSl7LbuP6iw8b92PN5NniWuSPE5dni3ykgJp4qWBaiZB9OhC3ueSG4sfd2sf8OLYiKn > O562NaaghSM7gTsu5uSL6eeNIF7AWPbuTiOrqls2zSWfUXTUVQltV99zfzc3382GJTLaJUtI > 25G4xsrx4Vrml1Z6XhnBK3FWW9d+hYPSnWiz56aaaWToxOIy7X7DA243NgXVzpGw/wARhY9M > vUwer6GZSQlTTzxPvfUwhdlO54A18fI58LG2mO48y9Sy/E8G2UYrps0T1y8ceSZ8800cMYNP > d5WCqPxX5JxnUHqPKoqeNf2nRBgg5qF5Fvzfb58Dg20aN63NOMkz41c/QgvT6pOsYrfivbuB > BG9vOMeqBks4jip/UJgLyKryDNHYqvyLyW+OQdr/AKhrXbKPRGbMwabn4lm+hYRmjZ9mVFTZ > fWUcsYKxOyMr9KMeLKVAJGo3JA2O2+0QkRamekEjS09DK9JG/wC6yqzBP0J0lvvfjfHtTZfl > dTn2Yzoy5lk2WMGheWQ1Akdoo+zWQ1wX/TngcDzX+kydkUcEbXRlRbIAAAtrbb6eALbbWHCf > itiaUX3F3EOWEFCL6ei9h1RTpDWQVUknQh1vrlU7v+81yTYNYgXuLbcc4sH7Rp3RtQzNA+iS > MujghQFJC3Nwxs1z8nnbet5VApr6OmiWKU6gwSZCVJup3sfmw/8AdvbGl1yR1FdQwSwI8chO > pwAQdIuFBG/OFcOJfSajy7T2MuC1c9Mnv1Ks+Y0pD6f2jdijCzObAab7XFmNmub+fd4x1s0p > 2L75kBZNJUMCFBW493J7tz/EdzYXtVZQU0oiiEMEfUfdhH3du9h/9/nBT0NCZ43kgj3DBIkj > A1Nb5H28HbBH+Japa/Q+o6eJL3KfmdTTVGX5ikc8snSjTUZJCgiFxYkMbkk3NyPJF9sQCxTr > TRxrTTRB9TbxWGluSAVuNvPzbjTiehiZqyanigRlutopyWHbKmkMAd7XO/gknFtrkjqa6hgl > gR43J1OACDpFwoI35x3xLJjGyDkt7WxbZwuOTNzk+xmsUJMhaSCYKVbZFvYgHSN/F7X+2Ali > qJ4ljdJisa2UEG1vA+xve/6/rjT6ygppRFEIaePqPuwj7u3ew/8Av84KehoTPG8kEe4YJEkY > GprfI+3g7YVR4njSa/S+pw/4eh/kZRJMhmngf8GRAxk1XUnV3BiTtf7j4H64haHIc3o6Iwml > UmexMrs6kx82A0Xtaw87XFsXaSnDZvTxR08RYTaUScFtgwIVrH58/Pzi71yR1NdQwSwI8chO > pwAQdIuFBG/OGk8z6GaUVtSWycLh/hynyy9jHWyyrnYvPk9LK/A1MG0qNgBqhNttzY2uSbC+ > PCkyjM6emSD6Gn0BxLKVcr1DyBYR2AB8Wte1uMbXWUFNKIohDTx9R92Efd272H/3+cFPQ0Jn > jeSCPcMEiSMDU1vkfbwdsVR/iSEtfpfUYvCs/wAjJow0MZjqjFFUaWaazEXJ3ub8AWsPyqo+ > +HJiq+vBWJDMlUFsGnjZkaM6bDTsbAKOD4A2AIMrJThs3p4o6eIsJtKJOC2wYEK1j8+d9/nF > 3rkjqa6hglgR45CdTgAg6RcKCN+cTkZCxrlLvvqKcfhfNdKzn6lRm9ZeoqyhajNMtKGUhp1Y > zvaxsACqAHjuJbzdTxivrBKKaOBYptEMQjjBBsEA2H23Jv8Ar9zjUKygppRFEIaePqPuwj7u > 3ew/+/zgp6GhM8byQR7hgkSRgamt8j7eDtjNZxum/lU0zZkcId6/XLsUr0jIf550SOAkg6uo > EnU10YgsDwT/AMgP1xrOM1yCNU9Z0QWPRpMygNuwUIdif8caVjXZWoPSOMHHWOpQT2LCwsLF > YwIv1CwTJJiXdRqjBMfuN3XYfBPF/F74p0gKicSCuQB47EybqOzZe++okm54ux32xcvUP/Us > 1lmY649oTZz3rxuP+Y2xTZJSTOAK4aGjVRrB0htGw792Oo93jVzth1w/7bKLO4MpCmYaa0Mr > xAjr+25j29wsxvubn3Hu8YJizvMoFcOmY1JSQal9hK+/k6jdjxqbc2x1niRpiBX8xhh1x2at > AAF2tqNxc/mPdjjNGiOYvq7ho1YdW4QkoLDv5II38aj3bYYFY2zoJ+z8wUyTMsaJ3vJZIxdT > 5O5N9VyP3rXxWhFMtKirTSxB7tvHYaWtfSCL3t/rbjTi11bwwQTtUwVPTWSG/wBSxeMEtHa6 > gm5vbex3vvtiazExtV00dRF1kdr9qA227UHnc774Q8UsULo7W9mazhkMqXPJmbo0X1MiSq+p > Y3dkTcrYHTf7X0n7jxtjlQJHo0MvU6UaDRcG1iLqB8G9+ObgecaVOlFPRmVYYolDEKNCjqP4 > UH7Nsf8Aww3hjoKXLxLPT9WSxjLdMd7E91gONJuL/bbCuGVU1vle96K3wCtdOYz17dZ4mCxy > dxYau5rm92+Cf9h+uDVzIQxuZGGli5BXSe1QAdxYcf4EW03w+rn6FUhieOOQMwVxuVFwLi+9 > he4Ntj97Yjo4IIzPpnUhlaRS50sFvYLY3Nz8C/I3tfGq+tQlpM8/l43g2uCewwEjcGdZAGUk > Ko3JIJTY+ODtyMcu00AN3KRgRAn2i4JC/Y+7b7/rgA0bqGjEZKK0Z0E7m9wf8jbb7/e/EBqG > AVFiQ3Rt7iwACm+9ydP+nxxToyaWtBTMZITJ1DCG1gTK+k6vdctwGFxxxYfriyxesfUdPQQw > U5ajiVSIlSlVUjQh9IRdOwUOthvfpoP4tdaoGpqSqpVkKNErAkSIWBOpbXt9yB/hjScxMbVd > NHURCZHa50oDbbtQedzvviyOVKhpR3pnoOE4jtrlJTaKfm/qzOM9oqzKq7MKiKCVHeZKVEV1 > UFyFJse06lBHlFHN2LVuny1aGhnuZnSUxuZJFFyoBKoNI4LEMRvdkj8gY1WdKKejMqwxRKGI > UaFHUfwoP2bY/wDhhvDHQUuXiWen6sljGW6Y72J7rAcaTcX+22BcU549U/b0G7wLeR1+K9Mz > 6RrzNE+lJRq1DV3Nc3Bb4P8A4D9cMM2rZxBHTUYaTM65hTQKWU31dq2v7bDg32up2tfE/XP0 > KpDE8ccgZgr8lRcC4vvYXuDbY/e2M/qKlsw9T9ajlZIqWQCCS5U3Bvr2JsduQeB/jjbTibv0 > uy6iKrh6jl8u9pdT3pKJMrqJKRqiOamErJT1IICzdxGxuRvs3JvewuAcWKJQqAjzj2o4qShy > aolqoopEVAg6z6A+oFVUsRZbllBLDT3XJGH2W5bktNTZpWTLl2cUtIkaxGB5ei87XHR0GR4y > LtD3Wsuo2HYdLG2lSfVnq6svwoPa7CyWpjzH1HSyQOslJTxTgSodSvN0WuAfyq3yR+J8jCwv > SkfQr6eBXGkQTuyqmhQzRksQo2XfwNthxsAsU0Wbi+XshG82WTKVnyaB/KBKkPpz1A8jKqBq > a5adoR/Wv++oJH+HPGMjyzL58w9UxwSyyQZbQwNU5g0WazSgoQdI5DA7X28G/wAX1n+UWm+r > 9N59BoV9UlIdDNpDWnY2Jsf+WMqy/qrTTRdeULUOHnWMFkckd3J9qAAAW4HPzoyMmNK+SzLy > 4UQ+R5TSN+ykp4KE0tKappnIlaZpGZiVBdgp27ubnzgS/XpY41ULIdQGhSGudgT8+AAP4W2F > 7lJIqPFSyOwREvqWzWU93I5Njxcb7G1sCLz9QUsZD9YJEbl2ax2W4FjfnYeBxhBZZK2fNI8z > bbO2bnMfZfpbNqYx9d4kKQx93eRYkgfwm5vYcE8nnGhyIhrqODpNDGhdUtsSxXfjjY883xnl > AZBnMAhWLWtQLIWulx4vfcbjf/K+NDqYunJGlKB9ajGW7NcC+xLn9NhhbmPrFHqOAb8GW/cf > Mxipz0gZNKgBQb3/AF/3xyaR46ct1RE+3cBqAPxhmk1eiyBaKljij3v1jY+SR/vgoZ690VhF > DpbcO76WA+bf+b4TrGlGW9roz0XNtFTQOc2n1RsW1NcRMbg9SO+k/wCNhi0yIhrqODpNDGhd > UtyWK78cbHnm+Kz0qmnzmZempmBvaSyqfxIyCfsf9MWapi6ckaUoH1qMZbs1wL7Euf02GPR8 > Wkn4WvYyUruPmYxU56QMmlQAoN7/AK/745NI8dOW6oifbuA1AH4wzSavRZAtFSxxR736xsfJ > I/3wUM9e6Kwih0tuHd9LAfNv/N8edWNKMt7XRmvm2ilT6/2/CGVtRqXDLETe+1wp/wCRxcpE > Q11HB0mhjQuqadiWK78cbHnm+KdVxVMHqKlUqvWWoJtIAA3B3+Af9MXGpi6ckaUoH1qMZbs1 > wL7Euf02GH/FJJyr17GDHX6pj5mMVOekDJpUAKDe/wCv++OTSPHTluqIn27gNQB+MM0mr0WQ > LRUscUe9+sbHySP98FDPXuisIodLbh3fSwHzb/zfCBY0oy3tdGb+ZNFKn1/t+EMrajUuGWIm > 99rhT/yOLlIiGuo4Ok0MaF1TTsSxXfjjY883xTquKpg9RUqlV6y1BNpAAG4O/wAA/wCmLjUx > dOSNKUD61GMt2a4F9iXP6bDD/ikk5V69jBjr9Ux8zGKnPSBk0qAFBvf9f98cmkeOnLdURPt3 > AagD8YZpNXosgWipY4o979Y2Pkkf74KGevdFYRQ6W3Du+lgPm3/m+ECxpRlva6M38yaK7kxf > +fFJqAVutOGCk2voN7fbGj4znK4ZYfXVEktw4kmJuoGoGM740bHrrmm4teyFdf8AfIWFhYWK > S4jPUFxks5DSDuS/T9xGtbgfBPF/HPjFNkBVZxIK5AHjIJk3Udmy919RJIJ4ux32xcfUQY5J > NpEpOuLaH3H8RdhuP+YxTncSGdL1yaGjC/iX030EKLPuxJ5/Nzth1w/7bKLO4MhCmYaa0Mrx > Ajr+25j29wsxvub/ALx7vGD1sZJwBW3Qoh0yC6g6Lj389xux41NvtjpKa5tCZgSCmoCYHRfR > xdvdY3J/Me7bA6owJen9Wulo1OqW4BOjYd/uNwL7WLHu2wwKwayp+gFTUFKiRYOmVZ3slrp9 > yWJJJuRfcjE0aYw1sBp5jF9ax65IDt7dVgx3H2xAVwc0OYosNS7r0+2aU6F2jNiNe7ef1J3O > JmL6oQ07SdNa+OMSNpW0Y23cnkjT2/N8ec43F80ZJmjHb6pj2qpurlojp4FWWNg8aSbG6n5+ > 9ufvjn4uX0Kt3APcurCyozG+5G4tewthslRWSVUU0UA6xGh0c2REtdRfkk84Az1FFVITLaSa > QKUdi0ar8qbfP+u2PPV1TWotr3NjaKNmzRNWaQLyE3YgEkrfbutvve3+OGYSMNFK8vTIb3HZ > Rbt3tufJP6n5xJZ/TSQ5mxl19VnZWBsA3lTbx7icRKsKiyhmEYso0x6gRpsxJ+wA8b3O/wAv > 8iXNJNeyPC8UUvqmekEbLTARK4p9a3IXdm8D7cMd+PGOl+vSxxqoWQhgNCkG52BPz4AA/hbY > XuUkio8VLI7BES+pbNZT3cjk2PFxvsbWwIvP1BTRkOZgkRuXZrHZbgWN+dh4HGM63sXpMdU9 > WtHXRVaGR4qbQidRtyACSCPG5vYfPJO+NCamMNbAaeYxfWseuSA7e0tYMdx8DGcEMahljSMl > XPZq1LcA3AIO/Itv+l8aDF9UIacydNa+NBI1ltGNt3J5I09vzfFGSnyqWz1PAW3XJP3HtVTC > XLQlPAqyxsHjSTY3U/P3tz98c/Fy+hVu4B7l1YWVGY33I3Fr2FsNkqKySqimigHWI0OjmyIl > rqL8knnAGeooqpCZbSTSBSjsWjVflTb5/wBdsL66prUW17noW0Zv6wqehR1LQW+pItr3JClg > AdX63I+4JxB+mcqOxCMGFt2YLba4NyLb8ffuGLf6jomFdIlQHLyFo3UmwYHg28e44r5zEZHl > DzmO9XGBHGzIenKDsSSgvYXJKmwO4BNse2xr4Pp66QiVsVkSrl0ZZzUSRZkmXBJppxT3FHS5 > nHSySS6NQD3lWWNQoJt3LaQ7ArY+Od1RqJcuyvrzVj5ZToktRKzFpZilgRfcdpvsSG6vJK3x > W8gzKmTMaauipJaqKkGpFKELNOB7nZwRtcuf3tTIVHNpeGOUEGdDPUVEnVMmlrzMXNyACNmY > sdvIsLYpzL1CDS7sz8Vyo11+FB7bJTJHVs7iWNpDHHBKiazuF6Tn/C5ubePk84WAyIFc8VLj > ZJgQGDb9J/I2I442+MLFeD9ox8P+1+5pPqfLp8zpc2o4I5S85iCOInZbq7k3Kqbcj/PFKHob > OFpxGiBd21WglK2Y72Bi2Nv9bcWwsLG67FrtluQxvw6rpc0zsfoTM+qzSoQpVtkgm5sdI3j4 > va/2wE3oXOpoUjYlljGlQYZ7WHH9ntvc/wD+8LCxR5fSUeWY/sz2p/RWdQ1kc6EQsjl+otLP > IWOrVdlKAEng2I2A/XFlipM1RFVqAWe5nBjnbqEjfcx/+RhYWCXDcea1JbN+LBY8WqztPSZr > Asp+hUyyG5YQzhRYWWw0eBgWos26AC0zCfYGYxTk2vcj2bA/H3wsLHHlOJv+01ePP3I+vyPP > KzMJK2ONIXVAsKCkmNzqRtbsU39pGm3G97naRipM1SNVagFnuagGOduoSN9zH/5GFhYtnw7H > mlGUeiOFZJNvZ2npM1gWU/QqZZDcsIZwosLLYaPAwLUWbdABaZhPsDMYpybXuR7Ngfj74WFi > rynE3/ad+PP3IjNMg9RV+dJXQRw06RD8NRSzsztcG7Ex/a1vjzvtMQ0marGqtQCz3NQDHOxk > JG+5j4/2wsLFkuG400lKPRFUJyjJyT7naekzWBZT9CplkNywhnCiwstho8DAtRZt0AFpmE+w > MxinJte5Hs2B+PvhYWK/KcTf9pb48/ciM0yD1FX50ldBHDTpEPw1FLOzO1wbsTH9rW+PO+0x > DSZqsaq1ALPc1AMc7GQkb7mPj/bCwsWS4bjTSUo9EVQnKMnJPudp6TNYFlP0KmWQ3LCGcKLC > y2GjwMC1Fm3QAWmYT7AzGKcm17kezYH4++FhYr8pxN/2lvjz9xvDlWcN6vp80ngWOjhV16cV > NM0jlltckoPPj7ffFp+oP/qtb/8ApZP/AOOFhYu+hpSSSKlJpt+4vqD/AOq1v/6WT/8AjhfU > H/1Wt/8A0sn/APHCwsH0NJ3zsaZmktdQPTxxVsbOy9wpZAbBgTY6djYEXxBN6eqmVxqru50K > npT3VRpvY22Js1/732wsLGmmqNS1E4k2+4J9PVR6lvrlJdLdlQRpGm5tpFibH7784JvT9Wxb > vrlBKhSsU4KqCL+NybNvz3nm26wsWkHnUZBmXSdqU1JnBQw9WCYomkg7jSdVyDc89xF/OO1G > X+omplWjRaaVmV5WME0hZr3O5j3Hi3xhYWM12LVdJOxbJUmt6Z7rSZ5oi/o6h1bVdqeZ9Nx3 > Adg88E48Muy/1HT0TR1KBpyWAdIJgoBN+Onz9/H35wsLFHluNrXKd+LP3I7OfTGeZtXGTpLF > TqmhF6E5d+N2bp87f6ffZkPQ2cLTiNEC7tqtBKVsx3sDFsbf624tusLEvAp9hdfh1XWOc+52 > P0JmfVZpUIUq2yQTc2Okbx8Xtf7YCb0LnU0KRsSyxjSoMM9rDj+z23uf/wDeFhY58vpKfLMf > 2Z6RejM9p6lKiBUSVGLhjTztrOrVdgY/87eAB98TlRl/qJqYLRotNKzK8jmCaQs17ncx7jxb > 4wsLHXl9D7rZsxqlRFqt9xwtJnmiL+jqHVtV2p5n03HcB2DzwThvl2X+o6eiaOpQNOSwDpBM > FAJvx0+fv4+/OFhYjy3G1rlNfiz9yOzj0xnua1xk6axU6poRehOXfjdm6fO3+n32Zn0RnLd5 > W8pBVi0MzDTwAAY9rD7/ABa1hhYWJeBT6IXX4dd1jsnvYdL/ACfZpLK3UMcahGN2WSMXtZBd > kAtfTcfHjbHlmHorM6KjWSqraLpqyU8emVnJLsERQqqTcu/j5/U4WFiPL6X7lPlmO16/7HmX > +k82o8wFVJCWVY5lPTgmLSFlIF7oBe5H+AGFhYWL6seFcdRNNWLXXHUT/9k= > --------------040908090108050006060704-- > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crow at bear.cs.dartmouth.edu Mon Apr 23 15:47:35 2001 From: crow at bear.cs.dartmouth.edu (Preston Crow) Date: Thu Jan 13 18:00:37 2005 Subject: [CF-Devel] ot: list archive/spam concern Message-ID: <200104232047.f3NKlZd26353@bear.cs.dartmouth.edu> I'm concerned that the archive of this list exposes email addresses to spammers. The issue is that spammers will run web robots to search for email addresses, and they will find all of ours in the archives. Is the archive something we control? Could we have a sed script to do something like: s/@[a-zA-Z1-9-_.]*[.]/@{domain}./g That would hide the addresses from the web, making posting to the list safe. I've seen one or two list archives do this. --PC From tanner at real-time.com Mon Apr 23 22:39:06 2001 From: tanner at real-time.com (Bob Tanner) Date: Thu Jan 13 18:00:37 2005 Subject: [CF-Devel] Command line utils? Message-ID: <20010423223906.B22171@real-time.com> What would be very helpful is a set of command line utils for broadcasting info to the users and shutting the server down. Many times I am behind a firewall and cannot get the xclient working. A command line util would be helpful so I could tell users I'm upgrading the server. -- Bob Tanner | Phone : (952)943-8700 http://www.mn-linux.org | Fax : (952)943-8500 Key fingerprint = 6C E9 51 4F D5 3E 4C 66 62 A9 10 E5 35 85 39 D9 From tanner at real-time.com Mon Apr 23 22:54:01 2001 From: tanner at real-time.com (Bob Tanner) Date: Thu Jan 13 18:00:37 2005 Subject: [CF-Devel] Can't open ? Message-ID: <20010423225401.F22171@real-time.com> Upgraded metalforge to the latest cvs snapshot and get this: Can't open /var/tmp/cftmp.1336.3407 Can't open /var/tmp/cftmp.1336.3407 Lots of them. Anything to worry about? -- Bob Tanner | Phone : (952)943-8700 http://www.mn-linux.org | Fax : (952)943-8500 Key fingerprint = 6C E9 51 4F D5 3E 4C 66 62 A9 10 E5 35 85 39 D9 From mwedel at scruz.net Mon Apr 23 23:38:44 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:00:38 2005 Subject: [CF-Devel] Wall of Thorns map bug References: <15120.988032816@www37.gmx.net> Message-ID: <3AE50354.7849E9B7@scruz.net> I'm not sure why thorns have 'is_floor 1' set. My initial thought is that it might have had something to do with the slow movement for it, but I looked at the code, and it doesn't have to be a floor for slow movement to work. My guess is then that the thorns object that wall of thorns is using is the general thorns object, which was meant as a floor object (just as the trees have is_floor set). So it works fine if the map maker is putting them down, as the map maker is obviously not intending them to go away. What should perhaps be done is a new thorns object get made up that is not a floor, and that get used for the spell. As an enhancement, it could also be given the right material type for wood, so it could also get burned down (although, not positive on that - I'm not sure if no_pick objects may be immune to that type of effect) From mwedel at scruz.net Mon Apr 23 23:42:38 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:00:38 2005 Subject: [Re: [CF-Devel] spell: town portal] References: <20010423091117.11809.qmail@nwcst284.netaddress.usa.net> Message-ID: <3AE5043E.2C3C43F3@scruz.net> One concern I have about portals leading to permanent apartments (ignoring possible issues of stealing, althought I could certainly see a player wanting to portal back to his apartment and not wanting others to follow). What I'm really concerned with from a programming perspective is if you get one player in another players portal, what happens if they try to use the pocket realities. I guess this is easy to test, but I'm not sure if it will create a proper name or not (and this might change depending on if the player who the apartment belongs to uses it first). The name mangling for that does not envision a player of a different name using one of those. From mwedel at scruz.net Mon Apr 23 23:56:41 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:00:38 2005 Subject: Fwd: Re: [CF-Devel] Crossfire Scripting language References: <01042307581001.01595@Terminus.magellan.fpms.ac.be> <20010423094317.A31728@crystal> <01042316125801.21498@Terminus.magellan.fpms.ac.be> Message-ID: <3AE50789.4E3E8B1B@scruz.net> > And true again. The problem with writing our own scripting language is > development time (as I said before). But if you are ready to write one, I'm > ready to help you. Development time is always hard to estimate, but my personal thought is that writing our own should not be very hard, because it does not need to be a very complicated language. What is basically needed in our script language: 1) If/else/endif constructs 2) Ability to set variables (probably a small subset) 3) Ability to check variables in the if statements. A simplification of the script could be that only variables can be checked in the if statements, and not function calls or the like. so in other words: item=@find_item(cloak) if ($item == 1 ) then @say("than you very much") endif While if (@find_item(cloak)) then ... is not valid. ie, the grammer can be kept very simple. If we write our own script langague, I would expect most of the work to be done in our callbacks (which are in native c) - in the case above, the @find_item and @say, with the script being very simple language. If we write our own, I'm really not that concerned with having to thread the scripting nearly to the extent I am if we use an external one, which may do more of the manipulation with its native functions. Or as said, my big worry is a broken script that just loops for ever. OTOH, I don't know the overhead of the script language to C interface - it could be pretty high, such that lots of callbacks to C do get costly. The real question is would such a simple script language be sufficient? I think for probably most all of what we do, it may be. It seems to me most script logic can be done via flowchart/if then else type things, and not be really complicated in what it is doing. IMO, most of the work for the above one is probably not the script interperter, but instead all the callbacks. From mwedel at scruz.net Mon Apr 23 23:59:50 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:00:38 2005 Subject: [CF-Devel] Can't open ? References: <20010423225401.F22171@real-time.com> Message-ID: <3AE50846.98C8D27D@scruz.net> Bob Tanner wrote: > > Upgraded metalforge to the latest cvs snapshot and get this: > > Can't open /var/tmp/cftmp.1336.3407 > Can't open /var/tmp/cftmp.1336.3407 > > Lots of them. Anything to worry about? Probably not. Most likely, youu are using the RECYCLE_TEMP_MAPS feature, and all the temp maps (or some of them) got cleared out of /var/tmp (or your using a different tmpdir). Crossfire will do the right thing and re-load the original from the maps directory if the temp one no longer exists. Note that this is a way you can reset maps without being wiz - look at the temp.maps file (or just figure out what map it is by looking in /var/tmp for example), and just rm that file. its effectively reset. If the map is active (ie, in memory), this trick won't work. From tanner at real-time.com Tue Apr 24 00:13:44 2001 From: tanner at real-time.com (Bob Tanner) Date: Thu Jan 13 18:00:38 2005 Subject: [CF-Devel] Can't open ? In-Reply-To: <3AE50846.98C8D27D@scruz.net>; from mwedel@scruz.net on Mon, Apr 23, 2001 at 09:59:50PM -0700 References: <20010423225401.F22171@real-time.com> <3AE50846.98C8D27D@scruz.net> Message-ID: <20010424001344.X22171@real-time.com> Quoting Mark Wedel (mwedel@scruz.net): > Bob Tanner wrote: > > > > Upgraded metalforge to the latest cvs snapshot and get this: > > > > Can't open /var/tmp/cftmp.1336.3407 > > Can't open /var/tmp/cftmp.1336.3407 > > > > Lots of them. Anything to worry about? > > Probably not. Most likely, youu are using the RECYCLE_TEMP_MAPS feature, and > all the temp maps (or some of them) got cleared out of /var/tmp (or your > using a different tmpdir). Crossfire will do the right thing and re-load the > original from the maps directory if the temp one no longer exists. Ahh, the tmpwatch script got them. I'll turn that off. -- Bob Tanner | Phone : (952)943-8700 http://www.mn-linux.org | Fax : (952)943-8500 Key fingerprint = 6C E9 51 4F D5 3E 4C 66 62 A9 10 E5 35 85 39 D9 From mwedel at scruz.net Tue Apr 24 00:20:37 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:00:38 2005 Subject: [CF-Devel] Can't open ? References: <20010423225401.F22171@real-time.com> <3AE50846.98C8D27D@scruz.net> <20010424001344.X22171@real-time.com> Message-ID: <3AE50D25.AD69BDAA@scruz.net> Bob Tanner wrote: > > Quoting Mark Wedel (mwedel@scruz.net): > > Bob Tanner wrote: > > > > > > Upgraded metalforge to the latest cvs snapshot and get this: > > > > > > Can't open /var/tmp/cftmp.1336.3407 > > > Can't open /var/tmp/cftmp.1336.3407 > > > > > > Lots of them. Anything to worry about? > > > > Probably not. Most likely, youu are using the RECYCLE_TEMP_MAPS feature, and > > all the temp maps (or some of them) got cleared out of /var/tmp (or your > > using a different tmpdir). Crossfire will do the right thing and re-load the > > original from the maps directory if the temp one no longer exists. > > Ahh, the tmpwatch script got them. I'll turn that off. In most cases, these temp files should only exist for a few hours. If the file has not been modified for more than 2 hours, then almost certainly the file can be removed, as the maps typically reset in 2 hours. If you have /var/tmp/cftmp file several days old, almost certainly they are safe to remove. I'm not exactly sure what tmpwatch does, but this is just some notes on what crossfire uses those files for. From jajcus at bnet.pl Tue Apr 24 09:09:47 2001 From: jajcus at bnet.pl (Jacek Konieczny) Date: Thu Jan 13 18:00:38 2005 Subject: [CF-Devel] BUG: crash Message-ID: <20010424160947.A4022@nic.nigdzie> Hi, My Crossfire server (games.bnet.pl) crashes recently quite often. Server info (crossfire -o): Welcome to CrossFire, v0.98.0 Copyright (C) 1994 Mark Wedel. Copyright (C) 1992 Frank Tore Johansen. Can't open /etc/crossfire/shutdown Non-standard include files: Secure: Datadir: /usr/X11R6/share/crossfire Localdir: /var/lib/crossfire Perm file: /etc/crossfire/forbid Shutdown file: /etc/crossfire/shutdown Save player: Save mode: 0660 Playerdir: /players Itemsdir: /unique-items Use checksum: Tmpdir: /var/lib/crossfire/tmp Map max timeout: 1000 Map reset: Max objects: 25000 Use_calloc: Use_swap_stats: Explore mode: Shop listings: Random encounter: Max_time: 120000 Linux serwus 2.2.18 #1 Mon Jan 8 22:28:26 /etc/localtime 2001 i686 pld Here are some logs of the last crash: Resetting map /navar_city/magara/houses/kaisas_place. CS: connection from client of type X11 C Client Initializing gods...done. enter_map: supplied coordinates are not within the map! (/HallOfSelection: -1, -1) get_nearest_player: Found free/non friendly object on friendly list Can't open /var/lib/crossfire/players/andrzej.pl We have not sent item andrzej (83777) We have not sent item andrzej (83777) We have not sent item andrzej (83777) We have not sent item andrzej (83777) We have not sent item andrzej (83777) make_path_tofile /var/lib/crossfire/players/andrzej... Resetting map /brittany/Brest/brest. Resetting map /brittany/Brest/brest.magic. make_path_tofile /var/lib/crossfire/players/andrzej/andrzej.pl... write_socket_buffer called when there is no data, fd=10 Resetting map /city/misc/gatehouse. Resetting map /world/world_a3. Resetting map /world/world_a4. Resetting map /random/0000000000000000. Resetting map /peterm/quests/ogre_chieffinal_map. Trying to load map /usr/X11R6/share/crossfire/maps/city/shops/bowshop. load_original_map: /city/shops/bowshop (0) CSSTAT: Tue Apr 24 12:43 tot 113279 1431555 1 9355 inc 2230 361902 2 600 Resetting map /HallOfSelection. Object squizez another object: arch human_player name andrzej race human face mage.131 animation warlock_class is_animated 0 Str 17 Dex 15 Con 14 Wis 9 Pow 12 Cha 10 Int 12 hp 10 maxhp 10 sp 4 maxsp 4 grace 1 maxgrace 2 food 967 dam 3 wc 18 ac 9 x 14 y 8 speed 1.100000 speed_left 0.300027 level 1 type 1 attacktype 1 weight 70000 last_heal 15 last_sp 43 last_grace 6 last_eat 11 randomitems human_player alive 1 can_use_armour 1 can_use_weapon 1 end Unfortunately I don't know what the player had done before server crashed. I hope this would help. Greets, Jacek From crossfire at suckfuell.net Tue Apr 24 15:59:33 2001 From: crossfire at suckfuell.net (Jochen Suckfuell) Date: Thu Jan 13 18:00:38 2005 Subject: [CF-Devel] Command line utils? In-Reply-To: <20010423223906.B22171@real-time.com> Message-ID: Hi! The feature you are looking for is already implemented. Try "telnet cfserver 13327". Then type "oldsocketmode". You can now issue the commands hiscore, logs, maps, motd, players, version, who. To be allowed to use tell and shout, you must first login by typing "name Playername Password" (where Playername is an existing player). You can close the telnet connection with "quit". All this can be accomplished by a script. On 24-Apr-2001 Bob Tanner wrote: > What would be very helpful is a set of command line utils for broadcasting > info to the users and shutting the server down. > > Many times I am behind a firewall and cannot get the xclient working. A > command > line util would be helpful so I could tell users I'm upgrading the server. > > -- > Bob Tanner | Phone : (952)943-8700 Bye Jochen -- HOST SYSTEM NOT RESPONDING, PROBABLY DOWN. DO YOU WANT TO WAIT? (Y/N) --- eMail jochen@suckfuell.net ----- http://www.suckfuell.net/jochen/ -------- From peterm at tonks.EECS.Berkeley.EDU Tue Apr 24 20:17:59 2001 From: peterm at tonks.EECS.Berkeley.EDU (Peter Mardahl) Date: Thu Jan 13 18:00:38 2005 Subject: [CF-Devel] 25% experience penalty is too high for high level chars Message-ID: <200104250117.f3P1Hxm04457@tonks.EECS.Berkeley.EDU> Hello, I've been playing a good deal, and I think that a 25% experience penalty is way too high about level 50 overall or so and up. Recovering all that exp can take many hours, and building up your exp by repeating certain maps over and over isn't all that fun. I propose that we lighten this penalty: 25% or 3 levels in each experience category, whichever is LESS. What say y'all? Regardless, I think I'll put this new rule into effect on crossfire.csua soon. PeterM From dnh at hawthorn.csse.monash.edu.au Tue Apr 24 22:21:08 2001 From: dnh at hawthorn.csse.monash.edu.au (dnh) Date: Thu Jan 13 18:00:38 2005 Subject: [CF-Devel] 25% experience penalty is too high for high level chars In-Reply-To: <200104250117.f3P1Hxm04457@tonks.EECS.Berkeley.EDU> Message-ID: I agree, it is very tiresome getting points back after you die. Perhaps we could make this a curve of loss? As level increases penalty decreases? dnh On Tue, 24 Apr 2001, Peter Mardahl wrote: > > Hello, > > I've been playing a good deal, and I think that a 25% experience > penalty is way too high about level 50 overall or so and up. > > Recovering all that exp can take many hours, and building up > your exp by repeating certain maps over and over isn't all that fun. > > I propose that we lighten this penalty: 25% or 3 levels in each > experience category, whichever is LESS. > > What say y'all? > > Regardless, I think I'll put this new rule into effect on > crossfire.csua soon. > > PeterM > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > From mwedel at scruz.net Tue Apr 24 22:32:30 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:00:38 2005 Subject: [CF-Devel] Command line utils? References: Message-ID: <3AE6454E.901C4428@scruz.net> Jochen Suckfuell wrote: > > Hi! > > The feature you are looking for is already implemented. > > Try "telnet cfserver 13327". Then type "oldsocketmode". You can now issue the > commands hiscore, logs, maps, motd, players, version, who. > > To be allowed to use tell and shout, you must first login by typing "name > Playername Password" (where Playername is an existing player). > > You can close the telnet connection with "quit". All this can be accomplished > by a script. Current, crossfire does try to cleanup when it gets a sighup signal (ie, save players). But I think it will still do less cleanup than a shutdown would. I think the main difference is that while sighup will save all the players, it won't save any maps the players are currently in. This is only of relevance if RECYCLE_TEMP_MAPS is being used - if you don't use that, there is no difference. Now it wouldn't be too hard to make it so that if it gets sigusr1, it calls shutdown (or does a shutdown like thing), and then flush the maps out. If people think this is desirable, let me know and I'll see about doing it. From mwedel at scruz.net Tue Apr 24 22:51:44 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:00:38 2005 Subject: [CF-Devel] BUG: crash References: <20010424160947.A4022@nic.nigdzie> Message-ID: <3AE649D0.E4D99BC@scruz.net> Unfortunately, that particular log does not help finding out the cause of those crashes. The squizez messages basically means that the map structure is somehow corrupt (the messages come from remove_ob). remove_ob does not call abort or otherwise kill execution, but my guess is that the fact the map is somehow corrupt, when this happens, the player and other pointers are put in a weird state. Please do confirm that you are at latest CVS - I haven't seen this problems on other servers. Please also make sure that you have done a make depend. doing cvs updates and compiles without ever having done a make depend is just asking for trouble. From gros at magellan.fpms.ac.be Wed Apr 25 15:15:49 2001 From: gros at magellan.fpms.ac.be (gros) Date: Thu Jan 13 18:00:38 2005 Subject: [CF-Devel] BUG - Cult and Pet Monsters Message-ID: <01042516154900.02182@Terminus.magellan.fpms.ac.be> The server crashes when you enter the Magical Shop of Scorn with too many followers (pet/cult monsters). Commander Gros Ad Dwarvam Aeternam ! From peterm at tonks.EECS.Berkeley.EDU Wed Apr 25 14:24:45 2001 From: peterm at tonks.EECS.Berkeley.EDU (Peter Mardahl) Date: Thu Jan 13 18:00:38 2005 Subject: [CF-Devel] Bug in summoned monsters via runes Message-ID: <200104251924.f3PJOjV06438@tonks.EECS.Berkeley.EDU> Hello, rune-summoned monsters don't have their randomitems, which means no spells as well. PeterM From highway at cstone.net Wed Apr 25 14:37:00 2001 From: highway at cstone.net (Sean Michael Whipkey) Date: Thu Jan 13 18:00:38 2005 Subject: [CF-Devel] bug report from one of my players Message-ID: <3AE7275C.83BA32E4@cstone.net> Just the facts...:) Since then he's replicated it a third time. It's nice to have players willing to suicide.:) In nurnberg. In /Dick/bomb1 (I think that's how it's listed, it's the "hard house") there is a spot to drop bombs on a teleporter and a lever to teleport the bombs through into a room. I dropped bombs onto the teleporter, took a step away, pulled the lever, took another step AWAY from the teleporter, and was instantly put into the room full of nasties. They of course killed me instantly. I was also immediately booted off the server rather than respawning like I should have. I tried to recreate, but the second time it worked fine. Just like it was supposed to. I proceeded to the next "stop" where a similar mechanism is in place. A similar thing happened, but I'm much less sure what happened this time because I was more relaxed and not paying as much attention as I had been before. Again, though, it appears as if I was teleported for no reason. Another payer witnessed the first incident and saw the spontaneous teleport, the second time - I was alone. From michael.toennies at nord-com.net Wed Apr 25 16:34:57 2001 From: michael.toennies at nord-com.net (Michael Toennies) Date: Thu Jan 13 18:00:39 2005 Subject: [CF-Devel] container Message-ID: This container bug come with the dxclient only. Because i don't change anything with the move cmd since month and it had worked well all the time, it must be some server issue. From peterm at tonks.EECS.Berkeley.EDU Wed Apr 25 17:12:11 2001 From: peterm at tonks.EECS.Berkeley.EDU (Peter Mardahl) Date: Thu Jan 13 18:00:39 2005 Subject: [CF-Devel] bug report from one of my players In-Reply-To: Your message of "Wed, 25 Apr 2001 15:37:00 EDT." <3AE7275C.83BA32E4@cstone.net> Message-ID: <200104252212.f3PMCBD08838@tonks.EECS.Berkeley.EDU> From mwedel at scruz.net Thu Apr 26 00:07:35 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:00:39 2005 Subject: [CF-Devel] destroy boulders References: Message-ID: <3AE7AD17.2123BF8B@scruz.net> The boulders got changed to be indestructible november of 2000 (between version 95.7 and 95.8) So it hasn't changed for a long time. If some specific maps need boulders to be destructible, it is easy enough to modify the boulders on those maps so it happens. Aestheticly, I'm not sure if boulders should get destroyed by fire. Fire tends not to destroy stone in most cases in real life. barrels can use the same purpose of boulders (ie, be rollable), and they are destroyable by fire (as it should be). It seems that that should generally be a fine replacement when such is needed. having the earth to dust destroy boulders could be done, but gets a little odd. earthwalls have levels of destructions (they basically have hp), and boulders/barrels currently don't have that. So it basically means you have the case of earthwalls either getting destroyed or not damaged at all (having barrels act as earthwalls could get done, but then gets odd, as instead of rolling the boulder, you would attack it and then destroy it). Michael Toennies wrote: > > Has the way you can destroy boulders (with medium fireballs) > changed? > > I run in the ruins of the sisters quests in the room where behind the > door the sister body part is. As a trap, you can put in a fight a boulder in > front of the door. In fact, you will do this in 90% of all approaches. > > Normally i can destroy this boulder with medium/large fireballs. But after i > cast now > about 40, i give up. > > Hm, because this "little traps" are part of the maop design, there are 2 > "kind of > boulders" out. > > Some, you should be able to destroy and some which you should not. > > A boulder which got destroyed in past i remember was the one you must use in > the quest > you find the warrior helmet. There sometimes, the red dragons destroy him. > > I prefer before 1.0 to include a new boulder type. With a new > flag/vulnerable type. > > And we have the spell earth to dust. It is must better when this will work > in this > destroyable boulders. > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel From mwedel at scruz.net Thu Apr 26 00:19:57 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:00:39 2005 Subject: [CF-Devel] Re: [Crossfire-cvs] CVS: crossfire/common treasure.c,1.10,1.11 References: Message-ID: <3AE7AFFD.23E155A8@scruz.net> The reason the code is ther is pretty simple. Basically, it was believe that if you are setting the stand_still flag, the object should not be animated. A poor assumption is made that the object being modified has no need for speed if it isn't getting animated. An example of this are the gems - if the artifact version is not animated, the gem object has no need for the speed. It probably won't break anything to remove the clearing of speed. The effect this will have is more object will be on the active list, which may have an effect on performance. crossfire-cvs-admin@lists.sourceforge.net wrote: > > Update of /cvsroot/crossfire/crossfire/common > In directory usw-pr-cvs1:/tmp/cvs-serv18952 > > Modified Files: > treasure.c > Log Message: > Small change to treasure.c: artifacts were getting their speed > set to zero for some reason. This had the effect of freezing > artifact-generated monsters. > > Commenting this out didn't seem to break the images for > other artifacts. > > PeterM > > Index: treasure.c > =================================================================== > RCS file: /cvsroot/crossfire/crossfire/common/treasure.c,v > retrieving revision 1.10 > retrieving revision 1.11 > diff -C2 -r1.10 -r1.11 > *** treasure.c 2001/04/21 01:22:43 1.10 > --- treasure.c 2001/04/25 07:46:57 1.11 > *************** > *** 1174,1178 **** > if (QUERY_FLAG(change,FLAG_STAND_STILL)) { > CLEAR_FLAG(op,FLAG_ANIMATE); > ! op->speed = 0.0; > update_ob_speed(op); > } > --- 1174,1178 ---- > if (QUERY_FLAG(change,FLAG_STAND_STILL)) { > CLEAR_FLAG(op,FLAG_ANIMATE); > ! /*op->speed = 0.0; */ /* why was this done? */ > update_ob_speed(op); > } > > _______________________________________________ > Crossfire-cvs mailing list > Crossfire-cvs@lists.sourceforge.net > http://lists.sourceforge.net/lists/listinfo/crossfire-cvs From mwedel at scruz.net Thu Apr 26 00:20:41 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:00:39 2005 Subject: [CF-Devel] BUG - Cult and Pet Monsters References: <01042516154900.02182@Terminus.magellan.fpms.ac.be> Message-ID: <3AE7B029.10E103C5@scruz.net> gros wrote: > > The server crashes when you enter the Magical Shop of Scorn with too many > followers (pet/cult monsters). What version, and how many pet monsters are we talking about (5? 10? 20?) too many is a broad definition. From mwedel at scruz.net Thu Apr 26 00:33:01 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:00:39 2005 Subject: [CF-Devel] container References: Message-ID: <3AE7B30D.12FEFA0F@scruz.net> Michael Toennies wrote: > > This container bug come with the dxclient only. > Because i don't change anything with the move cmd since > month and it had worked well all the time, it must be some > server issue. The fact this does work with the unix client suggests this is not a problem that may be easily characterized. Nothing has changed recently for the server side processing of containers in the server. There are two things I could think of that may be happening: 1) The container is not active, but the dxclient still has some method of trying to move stuff into such containers. The server does enforce the fact the container has to be active/open. 2) The dxclient is sending a bogus count (nrof) value to the server. I do see a bug in the code that it will use the nrof sent by the client to determine if the sack can hold it. Ie, lets say you have 10 food. But you set the count to 1000, and try to put that 10 food into the container. The server will use that 1000 number to determine of the container can hold it, and it probably won't be able to hold it. There should be some sanity checking done in the server such that if nrof requested is > nrof in actual object, reset appropriately. From gros at magellan.fpms.ac.be Thu Apr 26 07:53:31 2001 From: gros at magellan.fpms.ac.be (gros) Date: Thu Jan 13 18:00:39 2005 Subject: [CF-Devel] BUG - Cult and Pet Monsters In-Reply-To: <3AE7B029.10E103C5@scruz.net> References: <01042516154900.02182@Terminus.magellan.fpms.ac.be> <3AE7B029.10E103C5@scruz.net> Message-ID: <01042608533100.01943@Terminus.magellan.fpms.ac.be> Le Jeudi 26 Avril 2001 01:20, vous avez ?crit : > gros wrote: > > The server crashes when you enter the Magical Shop of Scorn with too many > > followers (pet/cult monsters). > > What version, and how many pet monsters are we talking about (5? 10? 20?) > too many is a broad definition. The version command returns version number 0.98.0. Further tests show that only two pet monsters is sufficient. I'm sorry if my definition was too broad, but I didn't had time to extensively test for the bug when it was first discovered - I was sure you would be able to proceed such a simple test by yourself. Commander Gros Ad Dwarvam Aeternam ! From mwedel at scruz.net Thu Apr 26 01:58:30 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:00:39 2005 Subject: [CF-Devel] Bug in summoned monsters via runes References: <200104251924.f3PJOjV06438@tonks.EECS.Berkeley.EDU> Message-ID: <3AE7C716.9DC74C11@scruz.net> Peter Mardahl wrote: > > Hello, > > rune-summoned monsters don't have their randomitems, > which means no spells as well. Fixed in CVS so that monsters will get their spells. From dnh at hawthorn.csse.monash.edu.au Thu Apr 26 06:28:22 2001 From: dnh at hawthorn.csse.monash.edu.au (dnh) Date: Thu Jan 13 18:00:39 2005 Subject: [CF-Devel] Change to treasures Message-ID: I think peterm's fix to treasures has affected some items, namely the major demonspawn shield. It seems to be stuck on Dshield.113, maybe this is a bug from before that or maybe peterm's recent second fix as repaired the damage? If it is sorry for the repeated message, dnh From hsteoh at quickfur.yi.org Thu Apr 26 09:08:02 2001 From: hsteoh at quickfur.yi.org (H. S. Teoh) Date: Thu Jan 13 18:00:39 2005 Subject: [CF-Devel] bug report from one of my players In-Reply-To: <200104252212.f3PMCBD08838@tonks.EECS.Berkeley.EDU>; from peterm@tonks.EECS.Berkeley.EDU on Wed, Apr 25, 2001 at 03:12:11PM -0700 References: <3AE7275C.83BA32E4@cstone.net> <200104252212.f3PMCBD08838@tonks.EECS.Berkeley.EDU> Message-ID: <20010426100802.A13945@crystal> On Wed, Apr 25, 2001 at 03:12:11PM -0700, Peter Mardahl wrote: > >From what someone told me, this is no bug. > > Instead, it's a diabolical plot on the part of the pupland > creators to kill players sometimes. > > Yes, that's right, sometimes. > > Sometimes the bombs get teleported, sometimes it's YOU. [snip] In fact, if you think *this* is diabolical, you ain't seen nuthin' yet... The next "stop" after this one (which, FYI, is only reachable if you *do* get teleported by "mistake" into the room with the blue dragons) has the same bomb-transporting mechanism, but with an even more diabolical trap: after pulling the switch a few times, you will activate a "bomb wall" which drop bombs all over the entire room and the previous room. Only those who are prepared and covered themselves with earthwalls (or 95% armour) will survive this "mistake". All I can say is, "Welcome to Pupland" :-) T -- If Java had true garbage collection, most programs would delete themselves upon execution. -- Robert Sewell From michael.toennies at nord-com.net Thu Apr 26 13:16:02 2001 From: michael.toennies at nord-com.net (Michael Toennies) Date: Thu Jan 13 18:00:39 2005 Subject: [CF-Devel] demonologic tower Message-ID: Notice that the balrog part of the demon tower is now broken for fighters. There is no serious item out, which grants enough res to fight the balrog hand to hand. Ill try it with a level 24 warrior (str 30, and much good items) AND venomteeth (i got in from snake pit first level). This grants poison res 80 but this is still not enough to kill the balrog. After he poisons me, my str drops to 23-25, leave me nearly dead. Because i get slowed too very much, i even can't cast / drink fast enough to help. Then blocked by fire elems, i die 4 times. There is no way to master this for a fighter with medium level. This poison stuff is instand dead for a fighter. Though lag and all i can't recover fast enough. And between level 15-35 i normally haven't so much items and/or wizard/priest level to kill major monsters with magic! And thats NOT the way the game should go. I don't want first pump up my warrior in a semi priest/wizard to master this key quests. All what we need is a massive plate mail, which grants 100% poison res. Make it heavy, so you can't cast in it. Notice, that even 90% or 95% res IS NOT ENOUGH. In a high speed fight against bigger monsters, you hit easily do 100 hits and more!! That means, you has a 1:1 chance to get poisoned and thats often the instand dead to the poor warrior. A mage is played different. He moves out instantly when he got hit, and he don't let his hp drop too much. As warrior, you need to play more risky, trying to calculate your hp lose with your damage you do. And move out close, heal and move in again. When you get poisoned with 50% hp, you are 100% dead. Lag and speed lose will kill you. There are other parts which get boosted up with strong poison monsters. Mainly, this is to avoid thats pumped mages slay the monsters to easy, but you forget the warriors about this. They must have a way to solve this without magic. From peterm at tonks.EECS.Berkeley.EDU Thu Apr 26 13:33:04 2001 From: peterm at tonks.EECS.Berkeley.EDU (Peter Mardahl) Date: Thu Jan 13 18:00:39 2005 Subject: [CF-Devel] Accidentally praying at the wrong altar Message-ID: <200104261833.f3QIX4D10744@tonks.EECS.Berkeley.EDU> This happens pretty frequently it seems, especially in random maps where a particular altar is part of the decor and may be hidden underneath monster detritus after combat. Losing 20 levels of experience (as has happened to me and to others) seems just a bit harsh for this sort of mistake. I propose, *for 1.0* that we throw players off altars if they pray on one belonging to another god. If someone wants to change religion, here is what will happen under that system: 1) They pray on the wrong alter 2) They lose 1 level of exp 3) They get tossed off the altar (3a) OR switch religions (3b) 4) If they get tossed off, they jump back on and pray again. This limits the damage for inadvertent prayer to 1 level. What say y'all? I think this is an important mod for 1.0, and it should be very minimal. PeterM From peterm at tonks.EECS.Berkeley.EDU Thu Apr 26 14:07:29 2001 From: peterm at tonks.EECS.Berkeley.EDU (Peter Mardahl) Date: Thu Jan 13 18:00:39 2005 Subject: [CF-Devel] demonologic tower In-Reply-To: Your message of "Thu, 26 Apr 2001 20:16:02 +0200." Message-ID: <200104261907.f3QJ7TM10802@tonks.EECS.Berkeley.EDU> > Notice that the balrog part of the demon tower is now broken for fighters. So what? It is the Tower of Demonology and Summoning. What makes you think that someone with no knowledge of magic or prayer is entitled to easy success here? > There is no serious item out, which grants enough res to fight the balrog > hand to hand. > > Ill try it with a level 24 warrior (str 30, and much good items) AND > venomteeth > (i got in from snake pit first level). This grants poison res 80 but this is > still > not enough to kill the balrog. Try it with a HIGHER level fighter. Poison's effect is level dependent. You can also try to obtain a better AC with the 'enchant armour' scrolls so you're less likely to get hit in the first place. > After he poisons me, my str drops to 23-25, leave me nearly dead. Because i > get slowed > too very much, i even can't cast / drink fast enough to help. Then blocked > by fire elems, > i die 4 times. There is no way to master this for a fighter with medium > level. I just can't get excited by the fact that a *medium* level fighter can't get through this map. Demonslayer is one of the top 3 weapons in the mapset, possibly THE best weapon in the mapset. Why should access to it be easy enough for a *level 24* fighter??? I changed Demonology because I was told that Demonslayer is too powerful to be given away so easily. I required passage up all 4 towers to make it harder. I took away the titans because what do Titans have to do with Demonology and Summoning? However, a Balrog is perfect. The bigger demons weren't available when I first did the map but they are now. > And thats NOT the way the game should go. I don't want first pump up my > warrior in a semi priest/wizard > to master this key quests. How is it a "key" quest? Because of the Demonslayer? If the Demonslayer is powerful enough to be "key" then it deserves strong guard. > Notice, that even 90% or 95% res IS NOT ENOUGH. In a high speed fight > against bigger monsters, you hit > easily do 100 hits and more!! That means, you has a 1:1 chance to get > poisoned and thats often the instand > dead to the poor warrior. If Poisoning is too powerful take it up with AV, who has meddled with it recently. The Balrog in Demonology stays. It is needed. It belongs. > There are other parts which get boosted up with strong poison monsters. > Mainly, this is to avoid thats pumped mages slay the monsters to easy, but > you forget the warriors about this. They must have a way to solve this > without > magic. Why? There are zillions of maps with "no magic", and all you REALLY need is to have more ac, more hp, higher level. Why not a map where LOW/MID LEVEL fighters have trouble? PeterM From Philipp.Currlin at t-online.de Thu Apr 26 14:24:09 2001 From: Philipp.Currlin at t-online.de (Philipp Currlin) Date: Thu Jan 13 18:00:39 2005 Subject: [CF-Devel] rewards for dropping body parts on altars Message-ID: <3AE875D9.1070503@epost.de> BehTong, Aprogas and I came up with an idea to give rewards for dropping body parts of your gods enemies on the altar of your god. This could be either random items or some experience. On the other hand the player should expect serious anger for dropping a dead dwarf on the altar of mostrai, for example. Phil From tanner at real-time.com Thu Apr 26 17:52:38 2001 From: tanner at real-time.com (Bob Tanner) Date: Thu Jan 13 18:00:40 2005 Subject: [CF-Devel] Metalforge IP address changing Message-ID: <20010426175238.B13662@real-time.com> On April 30th, 2001 between Midnight and 6am CST metalforge's IP address will change. We are dropping MrNet and thus need to return their IP addresses. The new IP address will be 208.20.202.42. We have already dropped the TTL on the zone files so thing should update quickly. As long as you access the server using it's hostname you should not have any problems. If you have any questions, please drop me an email. -- Bob Tanner | Phone : (952)943-8700 http://www.mn-linux.org | Fax : (952)943-8500 Key fingerprint = 6C E9 51 4F D5 3E 4C 66 62 A9 10 E5 35 85 39 D9 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 366 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20010426/36413229/attachment.pgp From leaf at real-time.com Thu Apr 26 21:09:23 2001 From: leaf at real-time.com (Rick Tanner) Date: Thu Jan 13 18:00:40 2005 Subject: [CF-Devel] ot: list archive/spam concern In-Reply-To: <200104232047.f3NKlZd26353@bear.cs.dartmouth.edu> Message-ID: On Mon, 23 Apr 2001, Preston Crow wrote: > I'm concerned that the archive of this list exposes email addresses to > spammers. The issue is that spammers will run web robots to search for > email addresses, and they will find all of ours in the archives. > > Is the archive something we control? Yes. There is an option in Mailman that hides the senders email address (replacing it with the list address) I still need to do a little more investigating to see how this works, exactly. For instance, does it just "hide" the email address in the archive, or in the actual message that gets sent to the list. Will turning this option on break anything, etc. > > Could we have a sed script to do something like: > s/@[a-zA-Z1-9-_.]*[.]/@{domain}./g > That would hide the addresses from the web, making posting to the list > safe. > > I've seen one or two list archives do this. > I'm not sure how something like that would work with the current setup for the Announce, Devel and Discussion list. It'something I would have to bug the admins here about.. ;) - Rick Tanner leaf@real-time.com From hsteoh at quickfur.yi.org Thu Apr 26 21:19:11 2001 From: hsteoh at quickfur.yi.org (H. S. Teoh) Date: Thu Jan 13 18:00:40 2005 Subject: [CF-Devel] rewards for dropping body parts on altars In-Reply-To: <3AE875D9.1070503@epost.de>; from Philipp.Currlin@t-online.de on Thu, Apr 26, 2001 at 09:24:09PM +0200 References: <3AE875D9.1070503@epost.de> Message-ID: <20010426221911.A16213@crystal> On Thu, Apr 26, 2001 at 09:24:09PM +0200, Philipp Currlin wrote: > BehTong, Aprogas and I came up with an idea to give rewards for dropping > body parts of your gods enemies on the altar of your god. > This could be either random items or some experience. On the other hand > the player should expect serious anger for dropping a dead dwarf on the > altar of mostrai, for example. [snip] Along the lines of dropping stuff on altars... we could make it so that dropping a weapon of the enemy god will make it cursed. Yes, this might limit the usefulness of some artifacts, but hey, we can always make more :-) I was also thinking of punishments like chaining the offending player to a heavy boulder (ala nethack), or, say, lythander punishing a really serious offence by transforming the player into a troll, etc.. This would vary from deity to deity. Another thing I'd like to see is to make killing monsters sacred to your deity have adverse effects. This, of course, is probably somewhere farther in the future, since it would require a lot of maps to be fixed to accomodate this. But nevertheless, I always thought it was weird that i can beat up on angels freely and Valriel couldn't seem to care less, although I keep "feeling a bond" with angels. Perhaps we should make it so that creatures sacred to a particular player's god will be friendly to him by default? (This could be a change we can make now, I think.) It seems weird that trolls would beat up a Gnarg priest for no reason, for example. (Of course, it'd probably be a different story if said priest provoked the trolls.) T -- MAS = Mana Ada Sistem? From mwedel at scruz.net Thu Apr 26 22:52:34 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:00:40 2005 Subject: [CF-Devel] ot: list archive/spam concern References: Message-ID: <3AE8ED02.6EF5B6E0@scruz.net> Rick Tanner wrote: > > On Mon, 23 Apr 2001, Preston Crow wrote: > > > I'm concerned that the archive of this list exposes email addresses to > > spammers. The issue is that spammers will run web robots to search for > > email addresses, and they will find all of ours in the archives. > > > > Is the archive something we control? > > Yes. > > There is an option in Mailman that hides the senders email address > (replacing it with the list address) > > I still need to do a little more investigating to see how this works, > exactly. For instance, does it just "hide" the email address in the > archive, or in the actual message that gets sent to the list. Will > turning this option on break anything, etc. I know that mhonarc (which is just a archive -> html converter) just re-writes the address when it creates the html archive. I would think that mailman would probably do something similar. The only disadvantage of this system is that if someone is viewing the archive on real-time, they can't directly respond to a user. But I don't know how often that happens, so that may not be a very big deal. Also, if possible, it should be done such that the crossfire-.... addresses don't get changed, so people who do do a followup on the website have it do the right thing. Also, I believe that the mailing list themselves are set up to prevent spamming, as you need to be on the list to send mail. To me right now, the biggest cause of spam is the defunct mailing lists at ifi.no, as those don't do spam filtering. From mwedel at scruz.net Fri Apr 27 00:27:26 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:00:40 2005 Subject: [CF-Devel] rewards for dropping body parts on altars References: <3AE875D9.1070503@epost.de> <20010426221911.A16213@crystal> Message-ID: <3AE9033E.881A5AD9@scruz.net> "H. S. Teoh" wrote: > > On Thu, Apr 26, 2001 at 09:24:09PM +0200, Philipp Currlin wrote: > > BehTong, Aprogas and I came up with an idea to give rewards for dropping > > body parts of your gods enemies on the altar of your god. > > This could be either random items or some experience. On the other hand > > the player should expect serious anger for dropping a dead dwarf on the > > altar of mostrai, for example. > [snip] > I think this has been discussed before. The tricky part of this is balance. Some races just generate a lot more parts than others. for example, the demon races generate a relatively low number of body parts. > I was also thinking of punishments like chaining the offending player to a > heavy boulder (ala nethack), or, say, lythander punishing a really serious > offence by transforming the player into a troll, etc.. This would vary > from deity to deity. Certainly divine intervention could be expanded to do more things. Repeated praying should be met with some scorn for example. > > Another thing I'd like to see is to make killing monsters sacred to your > deity have adverse effects. This, of course, is probably somewhere farther > in the future, since it would require a lot of maps to be fixed to > accomodate this. But nevertheless, I always thought it was weird that i > can beat up on angels freely and Valriel couldn't seem to care less, > although I keep "feeling a bond" with angels. The biggest problem with this (or making them friendly) is that it basically makes some maps useless (or even dangerous in a different regard). I don't really know if there are enough maps to basically say say 'you don't need to do these'. For example, followers of gnarg would have a much harder time if they can't kill the goblin type races - most of the low level maps use them to a great degree (and some of the random dungeons). While this realistically makes sense, there are certain playbalance issues with this. Making the monsters friendly is also only marginally useful if your part of a party - youu can't kill them but your friends can? That would seem to be pretty annoying to me. Also, the friendliness as currently supported is very generic - friendly basically means 'friendly to players', and 'not friendly to a specific player'. So that isn't a very good option right now. From mwedel at scruz.net Fri Apr 27 00:32:05 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:00:40 2005 Subject: [CF-Devel] Accidentally praying at the wrong altar References: <200104261833.f3QIX4D10744@tonks.EECS.Berkeley.EDU> Message-ID: <3AE90455.2EC34827@scruz.net> Perhaps a stupid suggestion, but why not just remove consecrated altars from most maps? They probably don't make a lot of sense (why would youu randomly find a altar to valrield buried deep within a dungeon?) I know the generic map loading code removed random consecration of altars. And I think there are altars to all the gods in the major cities or nearby, so its not like the random altars are really needed. Now I do know that the random map code does periodically insert special maps, and those may be dedicated to a specific god - I don't have a problem with that - those areas are usually well defined, so if someon accidentaly prays in one of those, they would get as much sympathy from me as if they played in a temple to another god. From mwedel at scruz.net Fri Apr 27 00:47:24 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:00:40 2005 Subject: [CF-Devel] demonologic tower References: <200104261907.f3QJ7TM10802@tonks.EECS.Berkeley.EDU> Message-ID: <3AE907EC.67EE43E0@scruz.net> I was thinking about this, and not addressing the specific difficulty of this map, but a general thought: There are already potions that give you 95% resistance to a few of the main attacktypes. Why not add some more potions in, like potion of poison resistance? paralyzation resistance, etc? IMO, I would rather have potions have 100% resistance than some of the general permanent items have this (ie, like the ring of Life). This would seem to be more balancing than having objects that give permanent immunity (ie, if you still want to keep being immune to that stuff, you need to keep spending money). Adding such potions may help balance out fighters and mages a little, as mages do typically do stuff from a distance so don't need those immunities quite as badly. From mwedel at scruz.net Fri Apr 27 01:18:30 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:00:40 2005 Subject: [CF-Devel] BUG - Cult and Pet Monsters References: <01042516154900.02182@Terminus.magellan.fpms.ac.be> <3AE7B029.10E103C5@scruz.net> <01042608533100.01943@Terminus.magellan.fpms.ac.be> Message-ID: <3AE90F36.4840E4E8@scruz.net> gros wrote: > The version command returns version number 0.98.0. > > Further tests show that only two pet monsters is sufficient. > I'm sorry if my definition was too broad, but I didn't had time to > extensively test for the bug when it was first discovered - I was sure you > would be able to proceed such a simple test by yourself. Thanks for letting me know. Often times, what happens is a bug gets reported in sort of a general fashion, I try to reproduce it, can't do so, and then find out the additional details later in (ie, number of pets, have to do something special first, etc). so instead I try to get all relevant details a head of time. In any case, I have fixed the problem in CVS. Thanks for the report. From dnh at hawthorn.csse.monash.edu.au Fri Apr 27 03:07:12 2001 From: dnh at hawthorn.csse.monash.edu.au (dnh) Date: Thu Jan 13 18:00:40 2005 Subject: [CF-Devel] Re: [CF-maps] (Beginner question) How to add new faces to crossfire.png? (fwd) Message-ID: ---------- Forwarded message ---------- Date: Fri, 27 Apr 2001 09:50:54 +0200 From: dluhosj@centrum.cz To: dnh@hawthorn.csse.monash.edu.au Subject: Re: [CF-maps] (Beginner question) How to add new faces to crossfire.png? > Please come onto #crossfire, this stream is getting way to long, and we > aren't getting very far are we =). Hello, Sorry that I was not there but it's quite difficult for me to use IRC... my connection is (quite heavily) paid, I mostly connect from work and I still don't have enough credit in the company to chat in work time... :o) > Are you sure you were su when you typed make install? > i really need to walk through it with you I think, irc is the best choice now. I agree... I'll try to visit #crossfire sometime, but I don't know when I manage... However, I've found a temporary solution, although it very probably is not how these things should be done. I have found a script named make_xpm_image.pl in the /crossfire/lib/adm directory. When invoked, it collects the .xpm images from the /crossfire/lib/arch directory and mangles them up to a crossfire.xpm file. So I have modified it to collect .png files instead, and it works. However, I had to do some additional changes because the .xpm file produced by the script is not compatible with the current crossfire server - maybe it is a relict from some old version of crossfire, because it uses slightly different format (uses ESRV_XPM keyword instead of IMAGE, does not put file lengths in the file). It is a bit strange to me that the file is in the distribution - I think it simply can't work without changes (and it seems it is never called from the Makefile). Well... I know it sounds paranoid, but I've scanned the crossfire distribution (crossfire-0.98.0 + crossfire-0.98.0.maps + crossfire-0.98.0.arch and got to a conclusion that the collect_images.pl file, which is called when 'make collect' is invoked from the /crossfire/lib directory, simply is not there. *shy smile* I would never dare to insinuate that there is a bug in the distribution files, but... :o) However, the truecolor PNGs seems to work quite well. I have not yet tried the Gtk client (I have my own little client), but the crossedit copes with them nicely, except for the semitransparent areas, as you mentioned, which get ignored sometimes but it's nothing serious. If you'd like to see the images, I'll send them when I have more of them (for the time being I have managed to truecolor-ize only some ground icons and lava, and now I'm trying to do the same with the sea). Have a nice day and lotsa sunshine, Jiri "BlueBear" Dluhos Hrajte on-line hry na http://www.XChat.cz Zalo¾te si svùj mail na http://mail.centrum.cz From andi.vogl at gmx.net Fri Apr 27 06:05:48 2001 From: andi.vogl at gmx.net (Andreas Vogl) Date: Thu Jan 13 18:00:40 2005 Subject: [CF-Devel] poisoning & demonologic tower In-Reply-To: <200104261907.f3QJ7TM10802@tonks.EECS.Berkeley.EDU> Message-ID: <000501c0cf0a$0771e060$f479fea9@kyle> > > Notice that the balrog part of the demon tower is now > > broken for fighters. > > So what? It is the Tower of Demonology and Summoning. What makes > you think that someone with no knowledge of magic or prayer > is entitled to easy success here? > [...] I agree with PeterM in several respects. There are so many maps where fighters have a definit advantage over wizzards/priests. It is just fair to have maps where the opposite is the case. And the demonslayer was a so-called "key item" because one could get it at WAY too low level, thus gaining a crazy amount of power. There are a big number of artifact weapons out there - many got less attention than they deserve, due to demonslayer. > If Poisoning is too powerful take it up with AV, who has meddled with > it recently. The Balrog in Demonology stays. It is needed. It belongs. Yes I have "meddled" with poisoning a few months ago, and I seem to be known for my tendency of beefing things up... hehe :] ...but not in this case! I did the opposite. I introduced limits to stats loss during poison-effect. Anyways, poisoning on high-level monsters is indeed not harmless. But I can't say I'm unhappy about that fact, as long as it is used in maps wisely. I also agree to Mark, maybe a "potion of poison resistance" with poison +90 might be useful. I would not go byond 90% though. There's a lot of poison-res. on equipment as well. "Venomtooth", "mudman's ring" and "orcish helmet" to name a few... And don't forget about Gnarg!! He is a warrior god and gives poison resistance (holy possession -> +95%!). Andreas V. From hsteoh at quickfur.yi.org Fri Apr 27 09:11:46 2001 From: hsteoh at quickfur.yi.org (H. S. Teoh) Date: Thu Jan 13 18:00:40 2005 Subject: [CF-Devel] poisoning & demonologic tower In-Reply-To: <000501c0cf0a$0771e060$f479fea9@kyle>; from andi.vogl@gmx.net on Fri, Apr 27, 2001 at 01:05:48PM +0200 References: <200104261907.f3QJ7TM10802@tonks.EECS.Berkeley.EDU> <000501c0cf0a$0771e060$f479fea9@kyle> Message-ID: <20010427101146.A18177@crystal> On Fri, Apr 27, 2001 at 01:05:48PM +0200, Andreas Vogl wrote: [snip] > There's a lot of poison-res. on equipment as well. "Venomtooth", > "mudman's ring" and "orcish helmet" to name a few... OK, I just conducted a little test. I collected the various poison resis eq that I have, and here is what I got: Orcish helmet, resis poison +30 Serpent cloak, resis poison +50 (!!!) Mudman's ring, resis poison +30 Venomtooth, resis poison +80 (!!!) TOTAL: 95% poison resistance. Alright, I admit this is quite a high-level set of eq, but even after removing serpent cloak, I still got 90% poison resis. The key ingredient here seems to be Venomtooth, though admittedly it's not that easy to get at lower levels. But even without venomtooth, I can still get 75% poison resis (with serpent cloak, that is). So anyway, the point is, I don't see poison protection as lacking at all. > And don't forget about Gnarg!! He is a warrior god and > gives poison resistance (holy possession -> +95%!). Now I wonder what happens if a Gnarg warrior is wearing all the above eq *and* casts holy poss.... :-P T -- Curiosity kills the cat. Moral: don't be the cat. From hsteoh at quickfur.yi.org Fri Apr 27 09:49:53 2001 From: hsteoh at quickfur.yi.org (H. S. Teoh) Date: Thu Jan 13 18:00:40 2005 Subject: [CF-Devel] rewards for dropping body parts on altars In-Reply-To: <3AE9033E.881A5AD9@scruz.net>; from mwedel@scruz.net on Thu, Apr 26, 2001 at 10:27:26PM -0700 References: <3AE875D9.1070503@epost.de> <20010426221911.A16213@crystal> <3AE9033E.881A5AD9@scruz.net> Message-ID: <20010427104953.A18255@crystal> On Thu, Apr 26, 2001 at 10:27:26PM -0700, Mark Wedel wrote: > "H. S. Teoh" wrote: > > > > On Thu, Apr 26, 2001 at 09:24:09PM +0200, Philipp Currlin wrote: > > > BehTong, Aprogas and I came up with an idea to give rewards for dropping > > > body parts of your gods enemies on the altar of your god. > > > This could be either random items or some experience. On the other hand > > > the player should expect serious anger for dropping a dead dwarf on the > > > altar of mostrai, for example. > > [snip] > > > > I think this has been discussed before. The tricky part of this is balance. > Some races just generate a lot more parts than others. for example, the demon > races generate a relatively low number of body parts. I don't see this as a problem: 1) The deity in question doesn't have to reward the player for *every* enemy body part offered. We can just have the reward only for very rare body parts. All-too-common body parts like orc livers would be completely ignored by, say, Lythander, while a gaelotroll's liver might generate some nice rewards. Another way is to make it level-dependent: a low-level gaea priest offering a zombie corpse might be rewarded, but a high-level gaea priest doing the same might be regarded with scorn ("What, is that all you can do?!"). On the flip side, a low-level priest offering a high-level body part might be very risky: perhaps he doesn't yet know the right procedures for preparing the sacrifice, and messing it up might get him a punishment instead of a reward. 2) We can also reduce the chances for reward for certain deities, whose enemy races generate a lot of body parts. > > I was also thinking of punishments like chaining the offending player to a > > heavy boulder (ala nethack), or, say, lythander punishing a really serious > > offence by transforming the player into a troll, etc.. This would vary > > from deity to deity. > > Certainly divine intervention could be expanded to do more things. Repeated > praying should be met with some scorn for example. I'd like to agree, though it would majorly change how the game is currently played. (No more altar-camping to get special prayers, e.g., tho I don't see that as a problem if said prayer is very powerful.) But as for punishments, there should be a lot more variety. For one thing, I think the flower cone spell should not happen that often... It's extremely annoying, and also silly in some cases: I find it totally bizzare, e.g., for Ruggili to send flowers to encourage his followers... > > Another thing I'd like to see is to make killing monsters sacred to your > > deity have adverse effects. This, of course, is probably somewhere farther > > in the future, since it would require a lot of maps to be fixed to > > accomodate this. But nevertheless, I always thought it was weird that i > > can beat up on angels freely and Valriel couldn't seem to care less, > > although I keep "feeling a bond" with angels. > > The biggest problem with this (or making them friendly) is that it basically > makes some maps useless (or even dangerous in a different regard). I don't > really know if there are enough maps to basically say say 'you don't need to do > these'. For example, followers of gnarg would have a much harder time if they > can't kill the goblin type races - most of the low level maps use them to a > great degree (and some of the random dungeons). > > While this realistically makes sense, there are certain playbalance issues with > this. > > Making the monsters friendly is also only marginally useful if your part of a > party - youu can't kill them but your friends can? That would seem to be pretty > annoying to me. Also, the friendliness as currently supported is very generic - > friendly basically means 'friendly to players', and 'not friendly to a specific > player'. So that isn't a very good option right now. Yeah, I don't expect this to be implemented anytime soon. But I'd like to see a move in this direction tho... there should be more variety of monsters in low-level maps (or all maps for that matter), and less hodge-podge mixing between monster races. (It still makes me cringe to see demons and angels in the same room... or red dragons and ice dragons in the same cave, etc..) I do think tho that friendliness/hostility should be towards a certain person -- just because some smartass player provoked the royal guard isn't good enough a reason for said guard to start bashing every player he sees coming his way. (Of course, this may not be easy to change, so I'm not expecting it anytime soon, but it'd be a nice thing to have). T -- Right now I'm having amnesia and deja vu at the same time. I think I've forgotten this before. From hsteoh at quickfur.yi.org Fri Apr 27 11:39:47 2001 From: hsteoh at quickfur.yi.org (H. S. Teoh) Date: Thu Jan 13 18:00:40 2005 Subject: [CF-Devel] destroy boulders In-Reply-To: <3AE7AD17.2123BF8B@scruz.net>; from mwedel@scruz.net on Wed, Apr 25, 2001 at 10:07:35PM -0700 References: <3AE7AD17.2123BF8B@scruz.net> Message-ID: <20010427123947.A18635@crystal> On Wed, Apr 25, 2001 at 10:07:35PM -0700, Mark Wedel wrote: > > The boulders got changed to be indestructible november of 2000 (between version > 95.7 and 95.8) So it hasn't changed for a long time. > > If some specific maps need boulders to be destructible, it is easy enough to > modify the boulders on those maps so it happens. I think the reception tower in nuernberg needs to be fixed so that the boulders/barrels are destructible (at least some of them). It is impossible to get the artifact keys otherwise. (Specifically, the tower of water and the tower of electricity.) > Aestheticly, I'm not sure if boulders should get destroyed by fire. Fire tends > not to destroy stone in most cases in real life. No, boulders should not be destroyed by fire, but by physical attacks (eg. bombs). [snip] > having the earth to dust destroy boulders could be done, but gets a little > odd. earthwalls have levels of destructions (they basically have hp), and > boulders/barrels currently don't have that. So it basically means you have the > case of earthwalls either getting destroyed or not damaged at all (having > barrels act as earthwalls could get done, but then gets odd, as instead of > rolling the boulder, you would attack it and then destroy it). [snip] I remember somebody saying something about bracing and then attacking the boulder/barrel? i.e., the default action is to roll them, you have to explicitly use ready_skill melee weapons to destroy them. T -- "I'm running Windows '98." "Yes." "My computer isn't working now." "Yes, you already said that." -- User-Friendly From mange at penguin.trew.se Fri Apr 27 03:11:50 2001 From: mange at penguin.trew.se (mange@penguin.trew.se) Date: Thu Jan 13 18:00:40 2005 Subject: [CF-Devel] Strange behaviour. Message-ID: <200104270811.f3R8Bod23268@trew.se> Two strange bugs: Both when playing on the server 130.89.221.177 First, I suddenly had lost all skills and all equipment, except that I suddenly had one sword, 400gold and one rod. I battled a red dragon and after the fight I opened my sack. It didn't work, so I tried somehting else, but that didn't work either (I guess now that's because my client showed me I had all this stuff, but the server didn't agree.) I ran back to my apartment and saved and reentered. That's when I realised that everything was missing. Second, I just stumbled upon another problem. I was hitting some beholders with "cause serious wounds" when suddenly my inventory got a lot shorter. I had a look and it seems all equipment not wielded/in use had disappeared. Now when I then unwear something, it disappears. I try to save and reenter into the game, but it still behaves the same. if I unwear/unwield something, it disappears. yours, Magnus. (crossfire://Mange@130.89.221.177) From tanner at real-time.com Fri Apr 27 12:51:15 2001 From: tanner at real-time.com (Bob Tanner) Date: Thu Jan 13 18:00:40 2005 Subject: [CF-Devel] ot: list archive/spam concern In-Reply-To: <3AE8ED02.6EF5B6E0@scruz.net>; from mwedel@scruz.net on Thu, Apr 26, 2001 at 08:52:34PM -0700 References: <3AE8ED02.6EF5B6E0@scruz.net> Message-ID: <20010427125115.G1388@real-time.com> Quoting Mark Wedel (mwedel@scruz.net): > > > I'm concerned that the archive of this list exposes email addresses to > > > spammers. The issue is that spammers will run web robots to search for > > > email addresses, and they will find all of ours in the archives. > > > > > > Is the archive something we control? One project on my TODO list is to install spamivore on the archives, that should keep all address harvesting bots off the list. Changing the mailman options just changes it in the web archives. -- Bob Tanner | Phone : (952)943-8700 http://www.mn-linux.org | Fax : (952)943-8500 Key fingerprint = 02E0 2734 A1A1 DBA1 0E15 623D 0036 7327 93D9 7DA3 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 232 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20010427/343d4d43/attachment.pgp From crow at bear.cs.dartmouth.edu Fri Apr 27 12:12:41 2001 From: crow at bear.cs.dartmouth.edu (Preston Crow) Date: Thu Jan 13 18:00:40 2005 Subject: [CF-Devel] destroy boulders Message-ID: <200104271712.f3RHCfa03356@bear.cs.dartmouth.edu> >I think the reception tower in nuernberg needs to be fixed so that the >boulders/barrels are destructible (at least some of them). It is >impossible to get the artifact keys otherwise. (Specifically, the tower of >water and the tower of electricity.) I just managed to get an impossible key. There are lots of doors opened by the tower keys, but you only get one at a time. If you save them up instead of using them, you can go down instead of up and get some of the keys. This may not be the way the key was supposed to be obtained, but it doesn't seem unreasonable. Now figuring out how to get that booze off the button so I could get up the stairs before the gate closed again was tough. (And without waiting for the base map to reset so another player could help!) As was safely getting the feather crown. --PC From peterm at tonks.EECS.Berkeley.EDU Fri Apr 27 12:29:37 2001 From: peterm at tonks.EECS.Berkeley.EDU (Peter Mardahl) Date: Thu Jan 13 18:00:41 2005 Subject: [CF-Devel] Strange behaviour. In-Reply-To: Your message of "Fri, 27 Apr 2001 10:11:50 +0200." <200104270811.f3R8Bod23268@trew.se> Message-ID: <200104271729.f3RHTbi15954@tonks.EECS.Berkeley.EDU> When exactly did this happen? There've been some bugfixes which might've addressed your problem. In the meantime, ask your server God to repair your character: there are probably many things wrong with it. PeterM > Two strange bugs: > Both when playing on the server 130.89.221.177 > > First, I suddenly had lost all skills and all equipment, except that > I suddenly had one sword, 400gold and one rod. I battled a red dragon > and after the fight I opened my sack. It didn't work, so I tried > somehting else, but that didn't work either (I guess now that's because > my client showed me I had all this stuff, but the server didn't agree.) > I ran back to my apartment and saved and reentered. That's when I > realised that everything was missing. > > Second, I just stumbled upon another problem. > I was hitting some beholders with "cause serious wounds" when suddenly > my inventory got a lot shorter. I had a look and it seems all equipment > not wielded/in use had disappeared. Now when I then unwear something, it > disappears. I try to save and reenter into the game, but it still behaves > the same. if I unwear/unwield something, it disappears. > > yours, > Magnus. (crossfire://Mange@130.89.221.177) > > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel From jajcus at bnet.pl Fri Apr 27 12:39:02 2001 From: jajcus at bnet.pl (Jacek Konieczny) Date: Thu Jan 13 18:00:41 2005 Subject: [CF-Devel] Broken changing of gods in 0.98.0 Message-ID: <20010427193902.B5029@nic.nigdzie> Hi, I have found another bug in the 0.98.0 release of Crossfire server. I had a player who worship Valriel. It has no wizdom experience although it has overal level of 8. It seems that it is imposible to gain any wizdom level with this god. So I tried to change it to Mostrai. When the player prayed over altar of Mostrai it was "bathed in Mostrai aura". It was even able to kill some monsters (goblins) with "holy word". But the second time I wanted to use this prayer I got "you need to worship some god" message. When I typed "'skills" to se what is happening the server died. After restarting server I tried it again, but just after praying over (and changing the god) altar I have left the game and entered the game. After entering the game again the player didn't worship any god (neither Valriel or Mostrai) so I made him pray over Mostrai altar again. Since then the player worship Mostrai as it should, but something strange happened to his experience: it got experience in all categories equal. Overal experience was as before, but the player had 6 level in all categories (including those he had no experience at all). I am not feeling quite fear after getting experience in wisdom and personality in a such easy way. And I wouldn't like someone else to kill my server. I am still not using CVS version, as I treat it as experimental and it may be harder to package (I don't want to change my working, carfuly packaged server, into not-FHS-copatible, not-sure-if-works one). And please not treat this report as request to leave everything else and fix this bug. I just would like to help. Greets, Jacek From peterm at tonks.EECS.Berkeley.EDU Fri Apr 27 14:01:47 2001 From: peterm at tonks.EECS.Berkeley.EDU (Peter Mardahl) Date: Thu Jan 13 18:00:41 2005 Subject: [CF-Devel] Broken changing of gods in 0.98.0 In-Reply-To: Your message of "Fri, 27 Apr 2001 19:39:02 +0200." <20010427193902.B5029@nic.nigdzie> Message-ID: <200104271901.f3RJ1lT16141@tonks.EECS.Berkeley.EDU> > Hi, > > I have found another bug in the 0.98.0 release of Crossfire server. > I had a player who worship Valriel. It has no wizdom experience although > it has overal level of 8. It seems that it is imposible to gain any > wizdom level with this god. So I tried to change it to Mostrai. You need to use holy word on undead or demons. Valriel's holy word ONLY works on undead and demons. Mostrai's holy word works on goblins and giants. Other Gods have different powers, and ways of advancement, though a good general rule is "use holy word on undead": this works for the majority of religions. > When the player prayed over altar of Mostrai it was "bathed in Mostrai > aura". It was even able to kill some monsters (goblins) with "holy > word". But the second time I wanted to use this prayer I got "you need > to worship some god" message. When I typed "'skills" to se what is There was some bug with changing religions that got fixed. Update past .98. The current CVS is way more stable than .98. (Or wait a little while for 1.0) Development is aiming at stability and bugfixes above all else right now. > I am still not using CVS version, as I treat it as experimental and it > may be harder to package (I don't want to change my working, carfuly > packaged server, into not-FHS-copatible, not-sure-if-works one). The current CVS has many fixes not present in .98, and little new stuff which might have bugs. However, Mark's mentioned that he wants to release 1.0 in a very short time. 1.0 should have significantly fewer bugs and should be much more stable. Perhaps you can simply wait. PeterM From mwedel at scruznet.com Fri Apr 27 20:11:49 2001 From: mwedel at scruznet.com (Mark Wedel) Date: Thu Jan 13 18:00:41 2005 Subject: [CF-Devel] Re: [CF-maps] (Beginner question) How to add new faces to crossfire.png? (fwd) In-Reply-To: Message-ID: > work without changes (and it seems it is never called from the Makefile). > > Well... I know it sounds paranoid, but I've scanned the crossfire distributi! > (crossfire-0.98.0 + crossfire-0.98.0.maps + crossfire-0.98.0.arch > and got to a conclusion that the collect_images.pl file, which is called when > 'make collect' is invoked from the /crossfire/lib directory, simply is not t! > *shy smile* I would never dare to insinuate that there is a bug in the distr! > files, but... :o) Yeah - it does appear to be missing. You can get a copy at http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/crossfire/crossfire/lib/adm/col! l I'll fix this up so it gets included in future distributions. The make_xpm_f! is not needed anymore, and should probably be removed. > However, the truecolor PNGs seems to work quite well. I have not yet tried > the Gtk client (I have my own little client), but the crossedit copes with t! > except for the semitransparent areas, as you mentioned, which get ignored > sometimes but it's nothing serious. Note that the editor and client use basically the same png loading code, so t! results should be the same between them. From tanner at real-time.com Fri Apr 27 21:32:11 2001 From: tanner at real-time.com (Bob Tanner) Date: Thu Jan 13 18:00:41 2005 Subject: [CF-Devel] CPU and memory? Message-ID: <20010427213211.E14271@real-time.com> After the latest cvs update, I am seeing crossfire consume much more resources. With 4 people playing. PID USER PRI NI SIZE RSS SHARE STAT LIB %CPU %MEM TIME COMMAND 25275 crossfir 16 5 21968 21M 1760 R N 0 60.5 11.4 250:33 crossfire -- Bob Tanner | Phone : (952)943-8700 http://www.mn-linux.org | Fax : (952)943-8500 Key fingerprint = 6C E9 51 4F D5 3E 4C 66 62 A9 10 E5 35 85 39 D9 From mwedel at scruz.net Fri Apr 27 22:07:55 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:00:41 2005 Subject: [CF-Devel] poisoning & demonologic tower References: <000501c0cf0a$0771e060$f479fea9@kyle> Message-ID: <3AEA340B.3CB01E7F@scruz.net> Andreas Vogl wrote: > Yes I have "meddled" with poisoning a few months ago, and I seem to be > known for my tendency of beefing things up... hehe :] > ...but not in this case! I did the opposite. I introduced limits to > stats loss during poison-effect. > Anyways, poisoning on high-level monsters is indeed not harmless. > But I can't say I'm unhappy about that fact, as long as it is used > in maps wisely. I guess I could look at the code, but how does resistance to poison affect it? Does it just reduce the likelihood of being poisoned? If so, thats not very useful if your fighting a monster with poison attacks, because you'll get hit by it so much, your going to fail one. Reduced duration may fall into a similar case. Sure, duration being really short is useful if your just hit by a poison cloud, but once again, if your fighting a monster, you'll probably get re-poisoned before it wears off. I really don't know how poison works, but it could very well be a case where getting 90% may not help out a lot in the above circumstance. > > I also agree to Mark, maybe a "potion of poison resistance" with > poison +90 might be useful. I would not go byond 90% though. > There's a lot of poison-res. on equipment as well. "Venomtooth", > "mudman's ring" and "orcish helmet" to name a few... > And don't forget about Gnarg!! He is a warrior god and > gives poison resistance (holy possession -> +95%!). As said, protectiion potions for most attacktypes could be added (confusion/slow/paralyze being another - maybe a potion of free action?) what about potion protection from drain, which is 100% protection, and reducing the current items to 90%? I think that would be 'more balancing' - right now, everyone gets 100% immunity to drain fairly early, and never care about draining monsters again - I would like to add that fear back in the gain. At least with 90% resistance, you have enough time to say 'oh $@!$', run away, and drink your potion before coming back. The math on this gets tricky, as the grimreaper tries to take 10% of your exp at that time, modified by your resistance. but if you have 90% resistance, even if youu get hit all 10%, your not losing too terribly much (although, the way the levels are, at higher levels this could be more a pain).. From mwedel at scruz.net Fri Apr 27 22:41:09 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:00:41 2005 Subject: [CF-Devel] rewards for dropping body parts on altars References: <3AE875D9.1070503@epost.de> <20010426221911.A16213@crystal> <3AE9033E.881A5AD9@scruz.net> <20010427104953.A18255@crystal> Message-ID: <3AEA3BD5.3321FB9@scruz.net> "H. S. Teoh" wrote: > 1) The deity in question doesn't have to reward the player for *every* > enemy body part offered. We can just have the reward only for very rare > body parts. All-too-common body parts like orc livers would be completely > ignored by, say, Lythander, while a gaelotroll's liver might generate some > nice rewards. This gets a bit more tricky, as now the sacrifice code has to look at treasure lists to try and figure out 1) how common that particular monster is, and 2) how common that part from that monster is. And idea I had was that you could record number of each bodypart so sacrificed. so the sacrifice could could quickly see that this is the 50'th orc liver, and not give much for it, but this is the first orc eye, and give a bit more. However, to do this would require potentially a bunch of invisible objects in the player inventory. Although, more cleverly, perhaps this could just be in the wisdom skill experience inventory - you would still have a bunch of invis objects, but at least they are not in the top level inventory, so we won't run accross them everything we traverse the player. This method has an advantage that a fairly common bodypart that is hard to transport (like demon's ichor) would get a just reward. The problem is still that some gods just have a lot more unique enemy monsters. For example, youu have kobold, goblin, orc, gnoll, ogre, hill giant as a quick list of enemies of mostrai/lythanderr (I think thats who they're enemies of). But there are a lot fewer of some other monster races, so to be fair, the only just thing is to allow repeat dontations of the same monster/body part. > > Another way is to make it level-dependent: a low-level gaea priest offering > a zombie corpse might be rewarded, but a high-level gaea priest doing the > same might be regarded with scorn ("What, is that all you can do?!"). On > the flip side, a low-level priest offering a high-level body part might be > very risky: perhaps he doesn't yet know the right procedures for > preparing the sacrifice, and messing it up might get him a punishment > instead of a reward. certainly level of sacrifice should be part of it. > > 2) We can also reduce the chances for reward for certain deities, whose > enemy races generate a lot of body parts. > > But as for punishments, there should be a lot more variety. For one thing, > I think the flower cone spell should not happen that often... It's > extremely annoying, and also silly in some cases: I find it totally > bizzare, e.g., for Ruggili to send flowers to encourage his followers... Presumely, a god_sacrifice type object would need to be added, which says what the relative appreciation of the god is towards sacrifices. I could see some not wanting them at all (ie, idea of bring in body parts to put on an altar could be rather distasteful). Others, like gods of death, may be happy with any bodypart, and more happy with those of their enemey. > Yeah, I don't expect this to be implemented anytime soon. But I'd like to > see a move in this direction tho... there should be more variety of > monsters in low-level maps (or all maps for that matter), and less > hodge-podge mixing between monster races. (It still makes me cringe to see > demons and angels in the same room... or red dragons and ice dragons in > the same cave, etc..) The mapguide does say not to do this. I think the maps are actually a lot better now. However, I think there are still some old maps sitting around which do have this problem. its just a matter of cleanup, and I don't think an intentional effect in current maps. > > I do think tho that friendliness/hostility should be towards a certain > person -- just because some smartass player provoked the royal guard isn't > good enough a reason for said guard to start bashing every player he sees > coming his way. (Of course, this may not be easy to change, so I'm not > expecting it anytime soon, but it'd be a nice thing to have). this is fairly difficult, in you now need a list in each monster who they like/dislike. Its even trickier in that when the player leaves the game, this needs to be cleaned up properly. And presumably, this information should be relevant accross map swaps (but not resets). ie, if you piss off a guard, leaving and coming back in 2 minutes should not result in that guard being neutral/friendly, but still pissed off. Right now, even things like runes and firewall disappears when the map is swapped out, because there is no good way to ensure ownership (its basically a pointer, and you can't save that in the map). So now you need to actually save it by name (which actually, could be done, and then if that player isn't around when the map is swapped back in, just set no owner) This could be open to abuses. Ie, player 'joe' goes to some map and sets up a bunch of spell casting walls (which he gets exp for on kills). He quits the game, waits for map to swap out, starts a new character called 'joe', goes to map to get it swapped in again, and starts getting a bunch of exp. This sort of goes back to the highscore discussion - player names are only unique at the time of creation - they can get recycled indefinately, and there is currently know way to know what instance of that particular name is being played. From mwedel at scruz.net Fri Apr 27 22:44:00 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:00:41 2005 Subject: [CF-Devel] Strange behaviour. References: <200104270811.f3R8Bod23268@trew.se> Message-ID: <3AEA3C80.7CCEE8CF@scruz.net> mange@penguin.trew.se wrote: > > Two strange bugs: > Both when playing on the server 130.89.221.177 > > First, I suddenly had lost all skills and all equipment, except that > I suddenly had one sword, 400gold and one rod. I battled a red dragon > and after the fight I opened my sack. It didn't work, so I tried > somehting else, but that didn't work either (I guess now that's because > my client showed me I had all this stuff, but the server didn't agree.) > I ran back to my apartment and saved and reentered. That's when I > realised that everything was missing. Try exiting/re-running the client. > > Second, I just stumbled upon another problem. > I was hitting some beholders with "cause serious wounds" when suddenly > my inventory got a lot shorter. I had a look and it seems all equipment > not wielded/in use had disappeared. Now when I then unwear something, it > disappears. I try to save and reenter into the game, but it still behaves > the same. if I unwear/unwield something, it disappears. Almost certainly you have set it so your client is only showing equipped items. You don't say what client you are using, if the x11 client, you cycle through what is shown in your inventory via the x command. In the gtk client, there are little tabs at the top of the inventory which determines what gets shown. These filters make it easy to find things like cursed items, equipped/unequipped items, etc, in your inventory. From mwedel at scruz.net Fri Apr 27 22:46:50 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:00:41 2005 Subject: [CF-Devel] Broken changing of gods in 0.98.0 References: <20010427193902.B5029@nic.nigdzie> Message-ID: <3AEA3D2A.50F2C258@scruz.net> Jacek Konieczny wrote: > After restarting server I tried it again, but just after praying over > (and changing the god) altar I have left the game and entered the game. > After entering the game again the player didn't worship any god (neither > Valriel or Mostrai) so I made him pray over Mostrai altar again. Since > then the player worship Mostrai as it should, but something strange > happened to his experience: it got experience in all categories equal. > Overal experience was as before, but the player had 6 level in all > categories (including those he had no experience at all). This is a bug that was fixed in CVS recently. The bug was that when youu changed religions, all invisible objects (including skill/experience categories) where removed from the player file. Now what happens is that when you log back in, the server does some sanity checking for skills, and if it doesn't find some, gives them and splits experience accordingly. This code is left over from before the skill code (so basically, if you had an old character, or let you keep playing under the new systems). From the_real_tomble at hotmail.com Sat Apr 28 00:14:56 2001 From: the_real_tomble at hotmail.com (Tom Barnes-Lawrence) Date: Thu Jan 13 18:00:41 2005 Subject: [CF-Devel] Some minor bugs Message-ID: From mwedel at scruz.net Sat Apr 28 01:06:15 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:00:41 2005 Subject: [CF-Devel] Some minor bugs References: Message-ID: <3AEA5DD7.A286D1D5@scruz.net> Tom Barnes-Lawrence wrote: > > >From 0.98.0 > I expect they've already been seen and corrected in CVS, but just > in case: > 1)The change in animation code means switches and doors under player > don't update in the floor display. Presumably seen weeks ago. Yours is the first report. I'm guessing most people don't look at that very closely. I've made a fix in CVS fo this. > 2)Entering maps and being blocked from entrance by monsters (because > they're standing where you're supposed to enter): One case in navar > where the little houses are all one map, so vikings had already moved > (and killed my low level character, I hadn't expected them), this > would be a map issue; BUT OTHER CASE, AFAIK, was a random map! Either > way, I hadn't been on that map before, and found myself surrounded > by creatures, incl. an ogre standing on the exit. That is surely a > big foobar. In long term, it would be nice if you could set "no > monster" flags on exits to stop this (actually, checkinv can just > about do this right now). There have been changes to the random map code so monsters should not appear on top of exits anymore. However, there is nothing preventing monsters from moving onto exits after the map is loaded. I'm not sure how desirable this really is. A common tactic for players is to retreat to the previous map since monsters won't follow. IT seems me a valid tactic to make this harder is for monsters to block exits. BTW, if this was done automatically (ie, monsters won't ever block exists) I think several maps could get broken, as monsters may now be restricted from where they can move to. > 3)Strange button setting: One of my maps has the spike+boulder > machinery, but with *two* buttons under some of the spikes, to > take boulders along a line. When put a character in the map, it > messed up. When I reloaded it in crossedit, it had set many buttons > to be pushed already. Looking at the map source, none of them were > so (it is decided by "value", isn't it?). I figure both the server > and crossedit are using the same methods to calculate this. Mucking > about with weight value of *some* of the buttons sorted it, I > suppose it was assuming *all* things with weight value applied that > weight to buttons below. Fairly sure this wasn't a problem in the > older crossedit (from 0.95). Actually, the editor does not really much with this. The editor does not do a lot of processing in order to try and not modify maps. when the server loads a map, it syncs all the buttons up so they have the same value (ie, everything with that connected value is either on or off, and not some and some off). Now it would be nice of the editor did have some sanity checking operations for things like this. From peterm at tonks.EECS.Berkeley.EDU Sat Apr 28 11:48:03 2001 From: peterm at tonks.EECS.Berkeley.EDU (Peter Mardahl) Date: Thu Jan 13 18:00:41 2005 Subject: [CF-Devel] Broken changing of gods in 0.98.0 In-Reply-To: Your message of "Sat, 28 Apr 2001 13:28:19 +0200." <20010428132819.B4345@nic.nigdzie> Message-ID: <200104281648.f3SGm3g18272@tonks.EECS.Berkeley.EDU> > According to spoiler Valriel's holy word works only on daemons and level > 1 in wisdom is not enough for killing daemons. > It was my mistake not to try it on other undeads (however I tried it on > many other creatures). The spoiler is wrong. It works on undead. It is as I told you. Demons and undead only. Level 1 is enough for killing demons, *if* you start with imps and not anything meaner than that. You can find some imps in the FireTemple map, or in any random map which includes demons. PeterM From david.delbecq at usa.net Sat Apr 28 13:10:10 2001 From: david.delbecq at usa.net (DAVID DELBECQ) Date: Thu Jan 13 18:00:41 2005 Subject: [[CF-Devel] CPU and memory?] Message-ID: <20010428181010.22661.qmail@nwcst287.netaddress.usa.net> Bob Tanner wrote: After the latest cvs update, I am seeing crossfire consume much more resources. With 4 people playing. PID USER PRI NI SIZE RSS SHARE STAT LIB %CPU %MEM TIME COMMAND 25275 crossfir 16 5 21968 21M 1760 R N 0 60.5 11.4 250:33 crossfire >-----------------------< Well, this doesn't seem to be a problem of the cvs version. I localy use the 0.98 version without cvs to develop maps. In a map with 10 demon lords, the server is laggy when they are casting while the same map didn't lead to problems with version 0.97 i used before. It seems the the latest changes did really slow down the server. When i speak of slowdowns, i mean a use of 90% cpu on a 600Mhz Athlon for 1 user. Could someone take a look at it? David Delbecq David.delbecq@usa.net ____________________________________________________________________ Get free email and a permanent address at http://www.netaddress.com/?N=1 From tanner at real-time.com Sat Apr 28 16:16:00 2001 From: tanner at real-time.com (Bob Tanner) Date: Thu Jan 13 18:00:42 2005 Subject: [CF-Devel] Most criticial computer component to crossfire? Message-ID: <20010428161600.J22088@real-time.com> What is the most critical computer component to crossfire RAM? CPU? Both? -- Bob Tanner | Phone : (952)943-8700 http://www.mn-linux.org | Fax : (952)943-8500 Key fingerprint = 6C E9 51 4F D5 3E 4C 66 62 A9 10 E5 35 85 39 D9 From peterm at tonks.EECS.Berkeley.EDU Sat Apr 28 16:57:37 2001 From: peterm at tonks.EECS.Berkeley.EDU (Peter Mardahl) Date: Thu Jan 13 18:00:42 2005 Subject: [CF-Devel] Most criticial computer component to crossfire? In-Reply-To: Your message of "Sat, 28 Apr 2001 16:16:00 CDT." <20010428161600.J22088@real-time.com> Message-ID: <200104282157.f3SLvbb18809@tonks.EECS.Berkeley.EDU> > What is the most critical computer component to crossfire RAM? CPU? Both? Crossfire typically consumes < 50M of RAM, so if you have more than that, RAM isn't your problem. However, if you don't have enough RAM, your CPU is irrelevant. I would: a) Make sure there's enough ram (probably 256 would be way more than needed.) b) Get a fast CPU. OR> c) Get the crossfire developers to waste less CPU power. I believe there are areas where we could get a factor of more than two. PeterM From the_real_tomble at hotmail.com Sat Apr 28 17:06:37 2001 From: the_real_tomble at hotmail.com (Tom Barnes-Lawrence) Date: Thu Jan 13 18:00:42 2005 Subject: [CF-Devel] Squishi Mapset Message-ID: Hi, As its almost worth looking at, and it illustrates the bug that I mentioned in a previous posting (that was hard to describe), I've packaged up my "Squishi" mapset and uploaded it to: --------- ftp://ftp.ifi.uio.no/pub/crossfire/incoming/Squishi_maps-v0.1.tar.bz2 --------- You'll prolly want to unpack it in (maps)/devel or (maps)/unfinished or wherever it was that has been designated for such maps in the CVS releases (I'm still using 0.98), but it you unpack it in the root of the maps directory it won't upset anything. Read the README for general instructions on linking it in. Hope it's clear. ...ENJOY! ... The bug referred to was bug (4) in the post I made last night, it can be seen in the map tomble/candy-apple/lament-keepGD, if you go to the "Entry Chamber" (it's marked), and drop a small item on the stone block before it activates, the machinery locks up. If you enter the chamber before it locks up, you get stuck (take a word of recall). That lock-up is AFAIK a fault in updating the buttons and pedestals. I don't *think* its fault of the map. Oh, and when you teleport onto a pedestal (that detects players), it doesn't notice you, unless you then drop something. Tomble (Tom Barnes-LawrencE) _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. From dnh at hawthorn.csse.monash.edu.au Sun Apr 29 03:40:51 2001 From: dnh at hawthorn.csse.monash.edu.au (dnh) Date: Thu Jan 13 18:00:42 2005 Subject: [CF-Devel] Client idea Message-ID: How about a command that can be typed at ANY time (including when player is not actually connected to a server) that asks the metaserver for an updated list of current status. It is annoying that I have to connect and disconnect to see if a server has updated, or to see how many people are playing.. etc. Another suggestion Mark ;) dnh From andi.vogl at gmx.net Sun Apr 29 11:37:50 2001 From: andi.vogl at gmx.net (Andreas Vogl) Date: Thu Jan 13 18:00:43 2005 Subject: [CF-Devel] poisoning & demonologic tower In-Reply-To: <3AEA340B.3CB01E7F@scruz.net> Message-ID: <000201c0d0ca$bd303c00$8b94fea9@kyle> Mark wrote: > I guess I could look at the code, but how does resistance to > poison affect it? > > Does it just reduce the likelihood of being poisoned? If so, thats not > very useful if your fighting a monster with poison attacks, because you'll > get hit by it so much, your going to fail one. Reduced duration may fall > into a similar case. Sure, duration being really short is useful if your > just hit by a poison cloud, but once again, if your fighting a monster, > you'll probably get re-poisoned before it wears off. > > I really don't know how poison works, but it could very well be a case where > getting 90% may not help out a lot in the above circumstance. Poison resistance affects both likelihood of getting sick and the poison damage. I think high level poison hurting that much has three reasons: First, most players don't wear any poison-resist usually. Second, once a player is sick, the poison strikes at rather high frequency. While other attacks (fire, cold, physical...) hit at lower rate due to the players' ac, poison is not affected by ac (once the player got sick). Third (and most important), the player looses stats while sick, and he receives both poison attacks and the "ordinary" attacks from monsters all whith reduced stats. There's plenty of ways where poisoning could be adjusted. But I find it quite difficult to see what mixture of duration, damage and contagiousness (relative to resistance) would be best. The current scheme doesn't seem extremely bad to me though. > As said, protection potions for most attacktypes could be added > (confusion/slow/paralyze being another - maybe a potion of free action?) > what about potion protection from drain, which is 100% protection, and > reducing the current items to 90%? I think that would be 'more balancing' > - right now, everyone gets 100% immunity to drain fairly early, and never > care about draining monsters again - I would like to add that fear back in > the gain. At least with 90% resistance, you have enough time to say > 'oh $@!$', run away, and drink your potion before coming back. The math on > this gets tricky, as the grimreaper tries to take 10% of your exp at that > time, modified by your resistance. but if you have 90% resistance, even if > you get hit all 10%, your not losing too terribly much (although, the way > the levels are, at higher levels this could be more a pain).. I definitly don't like the idea of draining resistance 90%. It's similar to the issue with acid corrosion. The main problem is that a player has no way to determine a monster's attacktypes. You would be surprised to know how many special monsters have draining attacks. I just can't imagine players being happy about loosing loads of their hardly gained levels, before realizing they found another draining monster. About resistance potions for paralyze, confusion and slow: The problem is that these resistance don't really work. Since these attacktypes inflict "effects" rather than damage, there's no true partial resistance. The effect can be ON and OFF, similar: A player can be immune or not, basically. That's the reason why 100% resist. on equipment exists for these attacktypes. And while these exist, potions don't make a lot of sense. If we want to change this, we should first try to tweak the attack-routines to give more visible results for resistances to paralyze/confusion/slow. Andreas V. From michael.toennies at nord-com.net Sun Apr 29 14:34:32 2001 From: michael.toennies at nord-com.net (Michael Toennies) Date: Thu Jan 13 18:00:43 2005 Subject: [CF-Devel] look/below item stack Message-ID: With the DxClient and the win32 client (java also), the connect will break if a player steps on a big pile. From highway at cstone.net Sun Apr 29 15:12:43 2001 From: highway at cstone.net (Sean Michael Whipkey) Date: Thu Jan 13 18:00:43 2005 Subject: [CF-Devel] poisoning & demonologic tower References: <000201c0d0ca$bd303c00$8b94fea9@kyle> Message-ID: <3AEC75BB.72DF1987@cstone.net> Andreas Vogl wrote: > I definitly don't like the idea of draining resistance 90%. It's similar to I concur. Even with something like the ring of Life, most people aren't going to leave that on all the time. Heck, the first time I fought a Grim Reaper I had a ring of Life, and didn't have on thanks to the drain on food, and got bushwhacked. It didn't help much sitting in my inventory... Then again, I think the ring of acid should give more of a bonus versus acid. Acid is the one thing that annoys my character (a half ork warrior) the most, with poison running a quick second. SeanMike From gros at magellan.fpms.ac.be Sun Apr 29 22:29:31 2001 From: gros at magellan.fpms.ac.be (gros) Date: Thu Jan 13 18:00:43 2005 Subject: [CF-Devel] Bug Report - Thrown objects lost Message-ID: <01042923293103.01965@Terminus.magellan.fpms.ac.be> Version: 0.98.0 Description: 1. Throw any object (throwing dagger, legendary object, etc.) with the 'throw' command; 2. Take it again; 3. Save your character with 'save' or with a bed to reality; logout, then log in again. The object is no more in your inventory. Commander Gros Ad Dwarvam Aeternam ! From mwedel at scruz.net Sun Apr 29 22:00:50 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:00:43 2005 Subject: [[CF-Devel] CPU and memory?] References: <20010428181010.22661.qmail@nwcst287.netaddress.usa.net> Message-ID: <3AECD562.64716956@scruz.net> DAVID DELBECQ wrote: > Well, this doesn't seem to be a problem of the cvs version. I localy use the > 0.98 version without cvs to develop maps. In a map with 10 demon lords, the > server is laggy when they are casting while the same map didn't lead to > problems with version 0.97 i used before. It seems the the latest changes did > really slow down the server. When i speak of slowdowns, i mean a use of 90% > cpu on a 600Mhz Athlon for 1 user. There is a known problem with lots of spellcasters on the same map/area. to fix this requires a fairly fundamental change in how map objects work, so is not likely to happen really soon. Basically, whenever a spell is added to a space, it needs to look at all the other objects on the space to see if it gets affected or is affected by any of them. When there are hundreds of objects on a space, this gets to be a very costly operation. The simple solution is to try to limit the number of reaally heavy spell casters in one area. The map guide basically says to do this for other reasons (if a player can kill 2, chances are it can kill 3, 4, or whatever number - at some point, the monsters block other monsters, the extras can't do anything anyways). From mwedel at scruz.net Sun Apr 29 23:06:27 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:00:43 2005 Subject: [CF-Devel] Most criticial computer component to crossfire? References: <200104282157.f3SLvbb18809@tonks.EECS.Berkeley.EDU> Message-ID: <3AECE4C3.ADB4432C@scruz.net> Peter Mardahl wrote: > > > What is the most critical computer component to crossfire RAM? CPU? Both? > > Crossfire typically consumes < 50M of RAM, so if you have more > than that, RAM isn't your problem. > > However, if you don't have enough RAM, your CPU is irrelevant. > > I would: a) Make sure there's enough ram (probably 256 would be way > more than needed.) > > b) Get a fast CPU. OR> > > c) Get the crossfire developers to waste less CPU power. I believe > there are areas where we could get a factor of more than two. I don't have a lot to add. Crossfire does not take a lot of ram, so as long as the system is not paging, not a big deal there. However, a few notes: crossfire does load and save stuff to/from disk now and again. For most any modern system, i/o performance is plenty fine, but if you had really slow i/o, that could be a problem. Once you get the memory so it doesn't page, cpu it what becomes useful. Note however it depends what else the machine may be doing. If the program is compiled on the same machine as it runs, then presumably you want to make sure there is enough ram so it doesn't swap during the compile process or other development work. there are lots of room for improvement in crossfire. AT some point, I hope to make it threaded - in this way, multiple cpu's will actually help performance, and it also means that one really large map to be loaded/saved won't freeze the entire server, as that will be in its own thread. From mwedel at scruz.net Mon Apr 30 00:44:02 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:00:43 2005 Subject: [CF-Devel] Client idea References: Message-ID: <3AECFBA1.3BBA2FD0@scruz.net> dnh wrote: > > How about a command that can be typed at ANY time (including when player > is not actually connected to a server) that asks the metaserver for an > updated list of current status. It is annoying that I have to connect and > disconnect to see if a server has updated, or to see how many people are > playing.. etc. > > Another suggestion Mark ;) I've added this to the post-1-0 client. Note that getting this metaserver information can be time consuming (if network connection between you and metaserver is bad for example). The client is not multithreaded, so it will wait until it gets the metaserver informatiion. You should not use the command ('metaserver) if your in a potentially dangerous area. From mwedel at scruz.net Mon Apr 30 00:45:21 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:00:43 2005 Subject: [CF-Devel] look/below item stack References: Message-ID: <3AECFBF1.2572D8D8@scruz.net> I think this may be fixed in latest CVS. otherwise, I need more information (server version, and if it occurs with unix clients would be helpful in knowing if I can reproduce it or not). Michael Toennies wrote: > > With the DxClient and the win32 client (java also), > the connect will break if a player steps on a big pile. > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel From mwedel at scruz.net Mon Apr 30 01:05:44 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:00:43 2005 Subject: [CF-Devel] poisoning & demonologic tower References: <000201c0d0ca$bd303c00$8b94fea9@kyle> Message-ID: <3AED00B8.92A221ED@scruz.net> Andreas Vogl wrote: > Poison resistance affects both likelihood of getting sick and the poison > damage. I think high level poison hurting that much has three reasons: > First, most players don't wear any poison-resist usually. If you put on poison resist items after your infected, does it help at all, or is it really needed when you are actually getting poisoned? > There's plenty of ways where poisoning could be adjusted. But I find it > quite difficult to see what mixture of duration, damage and contagiousness > (relative to resistance) would be best. > The current scheme doesn't seem extremely bad to me though. True - player can always cast cure poison also. Perhaps its just that I find the get the blue mushroom random quest very difficult because of the poisoning, and not really because of the monsters themselves (except for the fact they do poison). Individually, none of those monsters would be tough - what becomes tough is killing them and not getting to serioiusly poisoned. > > I definitly don't like the idea of draining resistance 90%. It's similar to > the issue with acid corrosion. The main problem is that a player has no way > to determine a monster's attacktypes. You would be surprised to know how > many special monsters have draining attacks. Note that draining resistance actually reduces effect. 90% resistance means you lose only 10% the amount of experience you would if you had no protection. This is a little different than acid, where either an item gets corroded or not - there is no 'its slightly corroded' - either it has gotten an additional minus or not. Just brainstorming here, but it seems to me that if draining is so nasty that any experienced character wants drain resistance 100, then draining seems to be a too powerful attacktype. It also means that drain attacks on monsters pretty much become meaningless (if all the characters its going to attack are immune to drain, then that attacktype has no effect. And this may be what leads to more monsters having drain - developer/tester sees it as not big deal because the player will be immune). But I think some of this is also good map design - the tactict of putting a drain monster/acid monster someplace where the character has no time to react seems at least somewhat common. This of course only works for the first time the player visits that map - after that, he knows that the monster is there and now prepares accordingly (or just avoids it). > About resistance potions for paralyze, confusion and slow: > The problem is that these resistance don't really work. Since these > attacktypes > inflict "effects" rather than damage, there's no true partial resistance. > The effect can be ON and OFF, similar: A player can be immune or not, > basically. > That's the reason why 100% resist. on equipment exists for these > attacktypes. > And while these exist, potions don't make a lot of sense. Incorrect. For the attacks above, duration is reduced accordingly. if you have 90% resistance, then you won't get stuck for very long. This is more useful for confusion/slow - for paralyze, even being paralyzed for a very short time can be deadly. But this goes with the above - if these attacktypes are so bad that youo need to be immune, it seems to dimish the usefulness of them (ie, any monster above level 20 might as well not have these attacks, as the player won't be affect anyways, and it will just chew up the monsters spell points). I don't really like that idea a lot. From peterm at tonks.EECS.Berkeley.EDU Mon Apr 30 02:52:40 2001 From: peterm at tonks.EECS.Berkeley.EDU (Peter Mardahl) Date: Thu Jan 13 18:00:43 2005 Subject: [CF-Devel] On the uselessness of lifesaving Message-ID: <200104300752.f3U7qeG27697@tonks.EECS.Berkeley.EDU> Hello You know those amulets of lifesaving which no one ever wears beccause the second you die, whatever killed you gets another chance and probably does it again right away? How about we make lifesaving bring you back.... Alive.... to your savebed? Regards, PeterM From david.delbecq at usa.net Mon Apr 30 05:41:56 2001 From: david.delbecq at usa.net (DAVID DELBECQ) Date: Thu Jan 13 18:00:43 2005 Subject: [Re: [[CF-Devel] CPU and memory?]] Message-ID: <20010430104156.23031.qmail@nwcst286.netaddress.usa.net> Mark Wedel wrote: DAVID DELBECQ wrote: > Well, this doesn't seem to be a problem of the cvs version. I localy use the > 0.98 version without cvs to develop maps. In a map with 10 demon lords, the > server is laggy when they are casting while the same map didn't lead to > problems with version 0.97 i used before. It seems the the latest changes did > really slow down the server. When i speak of slowdowns, i mean a use of 90% > cpu on a 600Mhz Athlon for 1 user. There is a known problem with lots of spellcasters on the same map/area. to fix this requires a fairly fundamental change in how map objects work, so is not likely to happen really soon. Basically, whenever a spell is added to a space, it needs to look at all the other objects on the space to see if it gets affected or is affected by any of them. When there are hundreds of objects on a space, this gets to be a very costly operation. The simple solution is to try to limit the number of reaally heavy spell casters in one area. The map guide basically says to do this for other reasons (if a player can kill 2, chances are it can kill 3, 4, or whatever number - at some point, the monsters block other monsters, the extras can't do anything anyways). -------------------------> Ok, you say it requires a lot of changes because it is a problem of lots of spells. If this is the case, this means you changed a lot of stuff from 0.97 version cause this version didn't lag and i don't think you made so heavily changes. Moreover, you speak about lots of spell on the same square. I have checked, there are no more than 5 objects on a square (6 if i include my self, 7 with the floor). The map, as i said, contain only 10 spellcaster, disposed so that 8 of them are hurting the player the same time, reducing number of spellcaster is simply stupid. 3rd point, even if map could be smaller, with lesser spellcaster, don't forget that level 80 players can cast more than 10 spells nearly at the same time, linked on the same key in the client (e.g. cast 5 icestorm, 5 burnig hands, 5 holy word, 1 counterwall in the same key to do lots damages in a short time in the arena.....). This cannot be prevented. At the end, i'll say this is not a problem for crossfire to be cpu consuming. The problem is that it becomes also VERY laggy (can hang-up up to 5 seconds when spellcasters become to cast). You say you are fixing bugs in crossfire for version 1.0 THIS clearly is a bug, i recommend you to check closely at the cast cone code, it contains a lot of useless assignements in a loop. (System does not seem laggy when casting things other than cone!!). If you make some checks, you could also see the the time consuming is done when spell casting, not when the spell spreads. David Delbecq David.delbecq@usa.net ____________________________________________________________________ Get free email and a permanent address at http://www.netaddress.com/?N=1 From dnh at hawthorn.csse.monash.edu.au Mon Apr 30 07:42:44 2001 From: dnh at hawthorn.csse.monash.edu.au (dnh) Date: Thu Jan 13 18:00:43 2005 Subject: [CF-Devel] This is the item.. Message-ID: Another cause of seg faults that has been around ALONG time is this one, Got update_item command for item we don't have (8198364) Segmentation fault That is what the client spews out. It has been around for along time I tends to turn up in the chests in the titan castle random maps by peterm. Should defn be fixed before V1, I am running on the LATEST cvs of the post 1.0 client, on csua which is about half a day old I think. dnh From dnh at hawthorn.csse.monash.edu.au Mon Apr 30 07:47:12 2001 From: dnh at hawthorn.csse.monash.edu.au (dnh) Date: Thu Jan 13 18:00:43 2005 Subject: [CF-Devel] .. further crash Message-ID: Okay, it has happened again on a different chest. After I opened the last one and walked back and tried again all the items inside looked pretty standard, but it didn't crash again. Got update_item command for item we don't have (8229210) Segmentation fault dnh From leaf at real-time.com Mon Apr 30 12:19:24 2001 From: leaf at real-time.com (Rick Tanner) Date: Thu Jan 13 18:00:43 2005 Subject: [CF-Devel] On the uselessness of lifesaving In-Reply-To: <200104300752.f3U7qeG27697@tonks.EECS.Berkeley.EDU> Message-ID: I think I used the Amulet of Lifesaving once, but I seem to recall that the amulet disappeared after it was used. Was that suppose to happen? If so, will the Lifesaving item continue to disappear after being used, for balance reasons? Something else I thought of, what kind of "condition" will your character be in after the Lifesaving kicks in? Does it act like a Word of Recall spell cast when you have 1 hit point? Lets say you are poisoned and that causes you to die but you're saved by the amulet of lifesaving and are brought back to your apartment, is your character still poisoned? Just a few questions on what I think is an overall good idea... - Rick Tanner leaf@real-time.com On Mon, 30 Apr 2001, Peter Mardahl wrote: > > Hello > > You know those amulets of lifesaving which no one ever wears > beccause the second you die, whatever killed you gets another > chance and probably does it again right away? > > How about we make lifesaving bring you back.... Alive.... > to your savebed? > > Regards, > > PeterM From peterm at tonks.EECS.Berkeley.EDU Mon Apr 30 12:50:25 2001 From: peterm at tonks.EECS.Berkeley.EDU (Peter Mardahl) Date: Thu Jan 13 18:00:43 2005 Subject: [CF-Devel] On the uselessness of lifesaving In-Reply-To: Your message of "Mon, 30 Apr 2001 12:19:24 CDT." Message-ID: <200104301750.f3UHoPV28272@tonks.EECS.Berkeley.EDU> > I think I used the Amulet of Lifesaving once, but I seem to recall that > the amulet disappeared after it was used. Yes, once they save your life, they're used up. I've gone ahead and checked in a change to have it bring you back home. Now maybe this will have a use. I think poisoning and disease still have more chances to kill your char even with an amulet of lifesaving: that was my read of it last night. PeterM > Was that suppose to happen? > > If so, will the Lifesaving item continue to disappear after being used, > for balance reasons? > > Something else I thought of, what kind of "condition" will your character > be in after the Lifesaving kicks in? Does it act like a Word of Recall > spell cast when you have 1 hit point? Lets say you are poisoned and that > causes you to die but you're saved by the amulet of lifesaving and are > brought back to your apartment, is your character still poisoned? > > Just a few questions on what I think is an overall good idea... > > - Rick Tanner > leaf@real-time.com > > On Mon, 30 Apr 2001, Peter Mardahl wrote: > > > > > Hello > > > > You know those amulets of lifesaving which no one ever wears > > beccause the second you die, whatever killed you gets another > > chance and probably does it again right away? > > > > How about we make lifesaving bring you back.... Alive.... > > to your savebed? > > > > Regards, > > > > PeterM > > > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel From andi.vogl at gmx.net Mon Apr 30 17:41:30 2001 From: andi.vogl at gmx.net (Andreas Vogl) Date: Thu Jan 13 18:00:43 2005 Subject: [CF-Devel] RE: [Crossfire-cvs] CVS: crossfire/lib artifacts,1.26,1.27 In-Reply-To: Message-ID: <000001c0d1c6$b4788160$4ca7fea9@kyle> Resistance to godpower must not exist! If we don't want to plunge the whole attacktype-concept into anarchy, there's certain rules we must keep. Mapmakers have to rely on certain attacktypes being dangerous. Godpower is the last resort against crazy equipment. Don't ruin it. Please take it out. Andreas V. > Update of /cvsroot/crossfire/crossfire/lib > In directory usw-pr-cvs1:/tmp/cvs-serv23480 > > Modified Files: > artifacts > Log Message: > New priest-oriented rings. > > [...] > + # > + # Ring of Benevolence > + # > + Allowed all > + chance 2 > + difficulty 6 > + Object Benevolence > + face ring.117 > + type 70 > + value 250 > + Cha 2 > + path_attuned 257 > + path_repelled 131072 > + Wis 2 > + Pow 2 > + grace 2 > + resist_godpower 30 <-- !!!!! > + msg > + This ring is blessed by the gods who do good, > + and protects a little against the power of those who > + do harm. > + endmsg > + end From andi.vogl at gmx.net Mon Apr 30 18:29:44 2001 From: andi.vogl at gmx.net (Andreas Vogl) Date: Thu Jan 13 18:00:43 2005 Subject: [CF-Devel] poisoning & demonologic tower In-Reply-To: <3AED00B8.92A221ED@scruz.net> Message-ID: <000101c0d1cd$713e8f00$4ca7fea9@kyle> Mark wrote: > > Poison resistance affects both likelihood of getting sick and > > the poison damage. I think high level poison hurting that much > > has three reasons: First, most players don't wear any poison-resist > > usually. > > If you put on poison resist items after your infected, does it help at > all, or is it really needed when you are actually getting poisoned? I suspect the resistance only takes effect if it is worn at the moment of "infection". Can't tell it for sure though. > > I definitly don't like the idea of draining resistance 90%. It's > > similar to the issue with acid corrosion. The main problem is that > > a player has no way to determine a monster's attacktypes. You would > > be surprised to know how many special monsters have draining attacks. > > Note that draining resistance actually reduces effect. 90% resistance > means you lose only 10% the amount of experience you would if you had > no protection. > > This is a little different than acid, where either an item gets corroded > or not - there is no 'its slightly corroded' - either it has gotten an > additional minus or not. This will be true when draining is adjusted to be fairly harmless with 90% resistance. As things are now, it definitly is not. > Just brainstorming here, but it seems to me that if draining is so nasty > that any experienced character wants drain resistance 100, then draining > seems to be a too powerful attacktype. It also means that drain attacks > on monsters pretty much become meaningless (if all the characters its > going to attack are immune to drain, then that attacktype has no effect. > And this may be what leads to more monsters having drain developer/ > tester sees it as not big deal because the player will be immune). > > But I think some of this is also good map design [...] *Good* map design? What you described above is what I call: "the revenge of the mapmakers". =) Sometimes developers create things that are real ugly/horrific in the players' eyes. Like the irreversible acid corrosion or the "worse-than-dying" draining attack. Since players don't like these but also don't like to war with us developers, people start to create artifacts with immunities to that stuff. Then *every* player gets these artifacts - And soon mapmakers design maps in the assurance that players are always immune. What is the outcome in the end? - Pretty much like the original hazard (acid/draining) would have been removed in the first place. I'm not trying to judge on anything here. But maybe we should listen more to the players' preferences in such cases. Either we remove the whole thing, we do nothing and stick with the immunities, or we tone down the hazard till players can accept it. > > About resistance potions for paralyze, confusion and slow: > > The problem is that these resistance don't really work. Since these > > attacktypes inflict "effects" rather than damage, there's no true > > partial resistance. The effect can be ON and OFF, similar: A player > > can be immune or not, basically. > > That's the reason why 100% resist. on equipment exists for these > > attacktypes. And while these exist, potions don't make a lot of sense. > > Incorrect. For the attacks above, duration is reduced accordingly. > if you have 90% resistance, then you won't get stuck for very long. No, it is correct. Unless either the offending monster gets killed or the player hides, the player will be "infected" again and again. Duration has no effect. As I said, if the player *can* be infected he will be -> the effect is ON. If the player is immune, he goes unharmed -> the effect is OFF. Partial resistance is an illusion here. I don't say it can't be done, but it isn't easy. I've played around with that a while ago - I know what I'm talking about. I got this to "almost work" for confusion (that was my changes to the confusion function a few months ago.) But it is a lot harder for paralyze and slow, I didn't manage to improve them yet. Andreas V. From peterm at tonks.EECS.Berkeley.EDU Mon Apr 30 18:38:29 2001 From: peterm at tonks.EECS.Berkeley.EDU (Peter Mardahl) Date: Thu Jan 13 18:00:44 2005 Subject: [CF-Devel] Resist godpower +30 In-Reply-To: Your message of "Tue, 01 May 2001 00:41:30 +0200." <000001c0d1c6$b4788160$4ca7fea9@kyle> Message-ID: <200104302338.f3UNcTL30906@tonks.EECS.Berkeley.EDU> I think you're being a bit alarmist here, AV. In fact, in general I think you've been swinging the pendulum too far in the "make the game hard" direction. The goal of crossfire mapmaking isn't to inflict sudden death on players at every opportunity. I agree a lot of your changes to maps are good, justifed and needed, but it's possible to go too far in the 'hard' direction. Not everyone who plays knows every trick/abuse like us experts. What happens when a player is hit with weaponmagic from comets? Pretty much instant death--DESPITE the carrillium apron which grants 30%. Instant death with no defense isn't that much fun for anyone. Same with cause wounds spells. The basic problem is that in order for crossfire to be fun, characters have to MOVE quickly and responsively. Monsters CANNOT move quickly and responsively or players get slaughtered because human reaction time isn't that quick, and the game will be unfun again. So players have a lot more damage/time potential than monsters. The result of this is that monsters have way more numbers and hitpoints than players, so they're not totally overmatched. The result of THAT is that spells have to do LOTS of damage. However, when this LOTS of damage is turned back onto players, it results all too often in unfun, instant death. Remember dancing sword and animate weapon? Denied now to monsters because they worked too well on players. Similarly ball lightning was 'safeguarded.' The fix for this is partial resistances. Death isn't so instant anymore when you can get 85+ resistance to a spell or effect. Well-prepared players have a chance. The carrillium apron isn't a problem because 30% doesn't help a lot. This ring also grants 30%, and two of them would grant, what, 51%? That's enough to help.... A bit. But it is not enough to say 'the sky is falling.' -- in my opinion. A little bit of godpower resistance is no big deal, and makes sense for this artifact, which is a holy ring for Priests of the Light. It protects against hostile actions from Priests causing harm. I agree godpower resistance is special and should be used sparingly, which is what we've done very effectively for weaponmagic, for years. One item, which used to get protection (50%, old system), but which now gets 30. If a majority of people respond negatively to this protection on this very rare ring, I'll take it off. PeterM > Resistance to godpower must not exist! > If we don't want to plunge the whole attacktype-concept > into anarchy, there's certain rules we must keep. > > Mapmakers have to rely on certain attacktypes being > dangerous. Godpower is the last resort against crazy > equipment. Don't ruin it. > > Please take it out. > > Andreas V. > > > Update of /cvsroot/crossfire/crossfire/lib > > In directory usw-pr-cvs1:/tmp/cvs-serv23480 > > > > Modified Files: > > artifacts > > Log Message: > > New priest-oriented rings. > > > > [...] > > + # > > + # Ring of Benevolence > > + # > > + Allowed all > > + chance 2 > > + difficulty 6 > > + Object Benevolence > > + face ring.117 > > + type 70 > > + value 250 > > + Cha 2 > > + path_attuned 257 > > + path_repelled 131072 > > + Wis 2 > > + Pow 2 > > + grace 2 > > + resist_godpower 30 <-- !!!!! > > + msg > > + This ring is blessed by the gods who do good, > > + and protects a little against the power of those who > > + do harm. > > + endmsg > > + end > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel From andi.vogl at gmx.net Mon Apr 30 19:42:59 2001 From: andi.vogl at gmx.net (Andreas Vogl) Date: Thu Jan 13 18:00:44 2005 Subject: [CF-Devel] Resist godpower +30 In-Reply-To: <200104302338.f3UNcTL30906@tonks.EECS.Berkeley.EDU> Message-ID: <000001c0d1d7$adac54e0$4ca7fea9@kyle> peterm wrote: > I think you're being a bit alarmist here, AV. I have spent huge effort at designing and balancing pupland maps to meet both my own liking and that of the original authors (and despite of what you might think: that of many players too). I think I have a right to air my opinions on this issue. (To make the connection to godpower: Several key-position monsters in pupland use godpower attacks.) > In fact, in general I think you've been swinging the pendulum too > far in the "make the game hard" direction. The goal of > crossfire mapmaking isn't to inflict sudden death on players at > every opportunity. I agree a lot of your changes to maps are good, > justifed and needed, but it's possible to go too far in the 'hard' > direction. > > Not everyone who plays knows every trick/abuse like us experts. Note that I never try to make the game harder from code side (the overall "rules"). However, pupland mapset is hard, and that's how it is designed to be. There are players who've solved everything else, and end up being very bored at level 110. Pupland is for those guys. There is nothing forcing people to play pupland, there's plenty of warnings, and the maps are hard - but not unfair! What really would make me sad is if pupland gets totally easy for experts, just because some newbie has problems at level 10. Is this justified? Can't there be one single attacktype without protections? Or do I have to use "internal" attacktype in future? > [...] The basic problem is that in order for crossfire to be fun, > characters have to MOVE quickly and responsively. [...] There are indeed players at level 110, or not? There are players who end up bored because they got everything they could. Maps should always be fair and not frustrating. But *not* all maps should be easy IMHO. > I agree godpower resistance is special and should be used sparingly, > which is what we've done very effectively for weaponmagic, for years. > One item, which used to get protection (50%, old system), but which now > gets 30. We need a limit. I can already see players sleepwalk through the game with weaponmagic +90 and godpower +95... The limit for weaponmagic should be at around 50% (Where it already is due to caryllium apron and barbal mal warhammer). Limit for godpower should stay zero. Andreas V. From peterm at tonks.EECS.Berkeley.EDU Mon Apr 30 20:11:07 2001 From: peterm at tonks.EECS.Berkeley.EDU (Peter Mardahl) Date: Thu Jan 13 18:00:44 2005 Subject: [CF-Devel] Prison for player killers? Message-ID: <200105010111.f411B7w31078@tonks.EECS.Berkeley.EDU> Hello, On IRC we kicked around this idea: 1) If someone kills another player, they get sent to prison IF: a) The "victim" was on a map of reasonable difficulty compared to his level (high leveller hunted down and killed a low-leveller in the low-leveller's natural habitat, easy maps.) Otherwise if, the victim is on a hard map (the high leveller's natural habitat) we deem the death 'accidental'. 2) If the victim shouts "forgive ", he's free. Otherwise, he's stuck for 3 days. 3) Other people have put forth the idea of only enforcing this upon repeat offenders, and having no penalty if people are on the same team. PeterM From peterm at tonks.EECS.Berkeley.EDU Mon Apr 30 20:50:12 2001 From: peterm at tonks.EECS.Berkeley.EDU (Peter Mardahl) Date: Thu Jan 13 18:00:44 2005 Subject: [CF-Devel] Resist godpower +30 In-Reply-To: Your message of "Tue, 01 May 2001 02:42:59 +0200." <000001c0d1d7$adac54e0$4ca7fea9@kyle> Message-ID: <200105010150.f411oCF31142@tonks.EECS.Berkeley.EDU> > peterm wrote: > > > I think you're being a bit alarmist here, AV. > > I have spent huge effort at designing and balancing pupland > maps to meet both my own liking and that of the original > authors (and despite of what you might think: that of many players too). > I think I have a right to air my opinions on this issue. It's good that you've overhauled pupland and fixed up the problems in it, but I think it's unfortunate that you've made monsters depend on godpower in order to make them hard. godpower belongs to gods and it makes sense to me to have relics of benevolent gods defend you from hostile godpower. Godpower attack belongs on afflictions from gods: disease, effects from gods: holy word, cause wounds, divine shock, and possibly god avatars (but I would prefer not in this case), not on monsters for the sole purpose of making them hard. I suggest that if you want to make monsters hard you use combinations of other attacktypes, so that a person will need lots of high resistances to defend vs. them: not practically possible. Alternately, use weaponmagic, and remove "prot weaponmagic" from the carrillium apron and from that hammer someone just told me about. Having a holy relic protect you from hostile godpower makes a lot more sense than prot. weaponmagic, the special attacktype. I can write a shellscript/short program to change the maps where you've used 'godpower' as attacktypes for non-holy/unholy monsters. In any case, I don't see "prot 51" god power as being a big threat. For that Prot 51 of godpower, the player has to give up TWO ring slots. Other artifacts grant far more protection per slot than 30. Same thing with weaponmagic. Other artifacts give far more protection per weapon slot (for that hammer) and per armour slot (for that apron) than 30, also. I think the real problem is that you put all your eggs into one attacktype basket. I realize this is more work than simply not allowing any defense vs. godpower at all, but I think it makes more sense to resist power from hostile gods than to resist weaponmagic, the special attacktype, and that granting weaponmagic to certain monsters makes much more sense than granting them Godpower attacks. PeterM > (To make the connection to godpower: Several key-position monsters > in pupland use godpower attacks.) > > > In fact, in general I think you've been swinging the pendulum too > > far in the "make the game hard" direction. The goal of > > crossfire mapmaking isn't to inflict sudden death on players at > > every opportunity. I agree a lot of your changes to maps are good, > > justifed and needed, but it's possible to go too far in the 'hard' > > direction. > > > > Not everyone who plays knows every trick/abuse like us experts. > > Note that I never try to make the game harder from code side > (the overall "rules"). However, pupland mapset is hard, and that's how > it is designed to be. > There are players who've solved everything else, and end up > being very bored at level 110. Pupland is for those guys. > There is nothing forcing people to play pupland, there's plenty > of warnings, and the maps are hard - but not unfair! > > What really would make me sad is if pupland gets totally > easy for experts, just because some newbie has problems at level 10. > Is this justified? > Can't there be one single attacktype without protections? > Or do I have to use "internal" attacktype in future? > > > [...] The basic problem is that in order for crossfire to be fun, > > characters have to MOVE quickly and responsively. [...] > > There are indeed players at level 110, or not? > There are players who end up bored because they got everything > they could. Maps should always be fair and not frustrating. > But *not* all maps should be easy IMHO. > > > I agree godpower resistance is special and should be used sparingly, > > which is what we've done very effectively for weaponmagic, for years. > > One item, which used to get protection (50%, old system), but which now > > gets 30. > > We need a limit. I can already see players sleepwalk through the game > with weaponmagic +90 and godpower +95... > The limit for weaponmagic should be at around 50% (Where it already is > due to caryllium apron and barbal mal warhammer). Limit for godpower > should stay zero. > > > Andreas V. > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel From highway at cstone.net Mon Apr 30 23:00:19 2001 From: highway at cstone.net (Sean Michael Whipkey) Date: Thu Jan 13 18:00:44 2005 Subject: [CF-Devel] luxory manor Message-ID: <3AEE34D3.9FFC9DB8@cstone.net> We got a key to the manor in Stoneville on our .98 server. However, the three beds on the right hand side of the manor show up as "damned". Can beds to reality be damned? If so, how, and what does that do? Is it something we did, perhaps? We do a good bit of alchemical and polymorphing in there... Thanks, SeanMike From mwedel at scruz.net Mon Apr 30 23:21:02 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:00:44 2005 Subject: [CF-Devel] poisoning & demonologic tower References: <000101c0d1cd$713e8f00$4ca7fea9@kyle> Message-ID: <3AEE39AE.37CA370C@scruz.net> Andreas Vogl wrote: > > Note that draining resistance actually reduces effect. 90% resistance > > means you lose only 10% the amount of experience you would if you had > > no protection. > > This will be true when draining is adjusted to be fairly harmless > with 90% resistance. As things are now, it definitly is not. I think a lot of the problem here is the same as with death - the experience totals needed for levels becomes fairly linear at some point, so losing 10% amounts for a lot more than it does at low levels. If you had 90% resistance, it would mean each hit you take with a drain attack would take 1% of your exp total. At low levels, this isn't that big a deal - even at half a million exp, that means a hit takes 5000 exp - thats just a few monsters to kill. I could see at higher levels where even 1% is 10 really tough monsters - monsters that just can't easily be found. > > > Just brainstorming here, but it seems to me that if draining is so nasty > > that any experienced character wants drain resistance 100, then draining > > seems to be a too powerful attacktype. It also means that drain attacks > > on monsters pretty much become meaningless (if all the characters its > > going to attack are immune to drain, then that attacktype has no effect. > > And this may be what leads to more monsters having drain developer/ > > tester sees it as not big deal because the player will be immune). > > > > But I think some of this is also good map design [...] I think I mistated what I really wanted to say. > > *Good* map design? > What you described above is what I call: > "the revenge of the mapmakers". =) agree here. > > Sometimes developers create things that are real ugly/horrific in the > players' eyes. Like the irreversible acid corrosion or the > "worse-than-dying" draining attack. > Since players don't like these but also don't like to war with us > developers, people start to create artifacts with immunities to that > stuff. Then *every* player gets these artifacts - And soon mapmakers > design maps in the assurance that players are always immune. > What is the outcome in the end? - Pretty much like the original hazard > (acid/draining) would have been removed in the first place. agree. > > I'm not trying to judge on anything here. But maybe we should listen > more to the players' preferences in such cases. > Either we remove the whole thing, we do nothing and stick with the > immunities, or we tone down the hazard till players can accept it. Note that some players preferance might be something like 'virtually impossible to be killed'. So we have to take some consesus and common sense. I personally think the third choice is the way to go - tune things down so they are acceptable. Depending on the attacktype may determine how easy/hard this is to do. For drain, it would not be really hard to reduce the amount that a drain hit takes (instead of 10% by default, maybe 3% or the like) as well a put some upper limit (100,000 or something) for high level characters. For acid, the first thing should be that the number of acid using monsters be severely limited. Rust monster, green slime, and black pudding are good. I think if acid had only remained with those monsters, acid immunity probably would not have been added - those monsters are infrequent enough and typically most uses have good warning (or they move slow enough) that youu can get away. Plus, you could kill them somewhat easily with range spells/missiles. But then some really tough monsters started getting acid attacks, and that really opened things up of needing real protection because fighters at least could not kill them via bow, but need to go hand in hand. The other factor is that most all artifacts are immune to acid. I've been playing a character recently and thinking 'hmm. wonder if acid attack is broken - it keeps hitting my helm'. Then I realized that was the only item I had which was made of metal. mithril chain, dragon shield, leather gloves and jackboots are all immune to the effects. So at some point, you don't even need to worry about acid protection for your equipment, as all the good stuff is already protected. It has been sugested that items should have quality ratings and thus get repaired. Being able to repair acid damage could be reasonable addition (not sure how to do this so that is balanced, however - if its too easy, then once again, then the acid attack only becomes slightly annoying). I don't know if I like the idea of general weapon quality, having it break, getting it repaired, etc as a standard feature - that seems more annoying than useful (in fact, the might & magic games have items get damaged, and the only effect is that it is annoying, as typically at least one character in the party can repair it, so it just becomes a matter of noticing the item is damaged, moving it to the repair character, moving it back, equipping it, etc. Worst part is that this takes no game time, so you can do it in the middle of combat with no bad effect). re confusion, slow, ... > No, it is correct. Unless either the offending monster gets killed > or the player hides, the player will be "infected" again and again. > Duration has no effect. As I said, if the player *can* be infected > he will be -> the effect is ON. If the player is immune, he goes > unharmed -> the effect is OFF. Partial resistance is an illusion here. It is still useful. A lot depends on the spell casting frequency of the monster. If you just have a couple of the spell casting monsters, this reduced duration may be useful enough that you can get out of danger and do something reasonable (like drink the potion that gives you full resistance). Paralyzation is really tough, as that is really an on/off effect. And if your paralyzed, chances are you'll get pegged by an incoming damage spell. One problem may just be the spellcasting of monsters - they can cast much faster than the player can recover, so you are correct - if you get hit once, your probably in trouble. Another problem is how fast damage can kill a player. a lightning bolt cast by most monsters can take out a 90 hp player in about a second, so if a bolt comes out, you need really fast reaction time to get out of the way or your toast. But what I'm really arguing against here is the items that give permanent immunity. As youu say above, once those are given out, the attacktype becomes meaningless. And that is the case for confusion, paralyze, and slow I believe - you get the amulet/ring of free actiion (or the speed +1, immune to paralyze/slow/confusion), and never worry about those attacks again. And those attacks are so deadly, that you really need a relatively high degree of protection. idea for fixing at least some of these: confusion: If you have a resistance, then perhaps give some chance based on resistance for the player to move the direction they want. Thus, if you are 50% resistant, you will still wonder around somewhat, but basically move in the direction youu want to, and hopefully get away from the creature. slow: amount of slowdown could be affected by resistance. So if you are 50% resistant, you are only slowed by 50% of what youu would have been otherwise. Once again, this should let you get out of danger. paralyze: No good solution. This is really either an on/off effect. Perhaps just do away with paralyzation as a monster attack, and leave it for players? Currently, players beyond a certain level are immune anyways because they get an immunity item for it. Note that my argument isn't that 100% immunity is bad. My argument is that items that give 100% immunity permanently are bad, and these should instead be replaced by potions (or blessings from god) that do so. So given that basis, the idea that if a player is mostly protected (say free action gives 90% instead of 100), the player, once seeing big nasty monster, still has a chance to get away and drink relevant potion. From mwedel at scruz.net Mon Apr 30 23:22:49 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:00:44 2005 Subject: [CF-Devel] luxory manor References: <3AEE34D3.9FFC9DB8@cstone.net> Message-ID: <3AEE3A19.4BA66422@scruz.net> Sean Michael Whipkey wrote: > > We got a key to the manor in Stoneville on our .98 server. > > However, the three beds on the right hand side of the manor show up as > "damned". > > Can beds to reality be damned? If so, how, and what does that do? Is > it something we did, perhaps? We do a good bit of alchemical and > polymorphing in there... The code doesn't care about cursed/damned status of savebeds, so it should make no difference. I would guess the polymorphing code may have something to do with this (if not the map itself). In any case, this is harmless. From mwedel at scruz.net Mon Apr 30 23:53:45 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:00:44 2005 Subject: [CF-Devel] This is the item.. References: Message-ID: <3AEE4159.43099965@scruz.net> anyone else seeing this crash? I haven't seen it myself, so I wonder if it may have something to do with the peculiarities of powerpc linux (the fact it is 64 bit, or the endianess, or the like). dnh wrote: > > Another cause of seg faults that has been around ALONG time is this one, > > Got update_item command for item we don't have (8198364) > Segmentation fault > > That is what the client spews out. It has been around for along time I > tends to turn up in the chests in the titan castle random maps by peterm. > Should defn be fixed before V1, I am running on the LATEST cvs of the post > 1.0 client, on csua which is about half a day old I think. > > dnh > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel From mwedel at scruz.net Mon Apr 30 23:54:04 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:00:44 2005 Subject: [CF-Devel] Bug Report - Thrown objects lost References: <01042923293103.01965@Terminus.magellan.fpms.ac.be> Message-ID: <3AEE416C.E494C26E@scruz.net> Just a note - this is now fixed in CVS. gros wrote: > > Version: 0.98.0 > Description: > 1. Throw any object (throwing dagger, legendary object, etc.) with the > 'throw' command; > 2. Take it again; > 3. Save your character with 'save' or with a bed to reality; logout, then log > in again. The object is no more in your inventory. > > Commander Gros > Ad Dwarvam Aeternam ! > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel From lembark at wrkhors.com Wed Apr 4 22:11:49 2001 From: lembark at wrkhors.com (Steven Lembark) Date: Thu Jan 13 18:03:54 2005 Subject: [CF List] question on worship in 0.97.0 Message-ID: <3ACBE275.43C5E22E@wrkhors.com> worshiping devourers used to give reduced food consumption in trade for reduced regeneration. when my character becomes a follower of the devourers the blurb says that i feel my digestion slowing down. catch: sustinence is -29 and the character sucks up food at an unsustainable rate even when just standing there. is this a bug or feature? -- Steven Lembark 2930 W. Palmer St. Chicago, IL 60647 lembark@wrkhors.com 800-762-1582 From mwedel at scruz.net Thu Apr 5 22:55:33 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:03:54 2005 Subject: [CF List] question on worship in 0.97.0 References: <3ACBE275.43C5E22E@wrkhors.com> Message-ID: <3ACD3E35.DC5E2B78@scruz.net> Steven Lembark wrote: > > worshiping devourers used to give reduced food consumption > in trade for reduced regeneration. when my character becomes > a follower of the devourers the blurb says that i feel my > digestion slowing down. catch: sustinence is -29 and the > character sucks up food at an unsustainable rate even when > just standing there. > > is this a bug or feature? Looking at the code and archetypes, it appear sustenance should really get set to -3. There may be a bug if it gets too negative, it doesn't work properly. But right now, I would be curious to know how sustenance got set to -29 - that seems to be the real bug. From mwedel at scruz.net Sun Apr 8 01:07:15 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:03:54 2005 Subject: [CF List] Crossfire 0.98.0 released. Message-ID: <3AD00013.520B3DCB@scruz.net> Crossfire 0.98.0 has been released. Once again, unless serious bugs are detected, this will be the last release before 1.0. It seems that that lots of bugs get reported off releases of official versions and not from CVS snapshots. Main changes: Mostly just a bunch of small bug fixes. List is at the end of the file. NOTE TO MIRROR SITES: The primary site (ftp.scruz.net) has limited download bandwidth per day. You can also get this release off of sourceforge.net. Files released for this version: sums (bsd) filename 13320 1549 crossfire-0.98.0.arch.tar.bz2 23828 1832 crossfire-0.98.0.arch.tar.gz 39314 2789 crossfire-0.98.0.maps.tar.bz2 46406 4017 crossfire-0.98.0.maps.tar.gz 17403 2683 crossfire-0.98.0.tar.bz2 62663 3012 crossfire-0.98.0.tar.gz 33843 239 crossfire-client-0.98.0.tar.gz Sums (md5) b633eba0e53234710c6d15ad4b04d8be crossfire-0.98.0.arch.tar.bz2 f004c95912e3ab0b71692f63a01db24c crossfire-0.98.0.arch.tar.gz 075ee95d823ea78f965867d6313ece42 crossfire-0.98.0.maps.tar.bz2 ae7cf5c6c6d554b647a1cf0a9e8014ce crossfire-0.98.0.maps.tar.gz 00000bab0b2e114e80d7f9c19fc87986 crossfire-0.98.0.tar.bz2 06b91c418538c06d8ec5a195bb105c0b crossfire-0.98.0.tar.gz 95c07464cfbc980ec8eccffeb4834259 crossfire-client-0.98.0.tar.gz crossfire-client-0.98.0 is the client (X11) distribution - standard X11 and gtk interfaces are provided. crossfire-0.98.0.tar.{gz/bz2} contains the server code with prebuilt archetype and image files. crossfire-0.98.0.arch.tar.{gz/bz2} contains the unpacked archetype changes. This is not needed if you only want to compile the server and play the game. crossfire-0.98.0-maps.tar.{gz/bz2} contains the maps. This is needed with the server distribution. FOR FIRST TIME USERS: You will only need the appropriate server, map and client file. You do not need the arch file. If you are a first time user, you may want the doc file unless you are using a web based player referance. If you just want to play the game at some remote server, you need the client and perhaps some version of the doc file. Crossfire is avaible on the following ftp sites Primary: ftp://ftp.scruz.net:/users/mwedel/public (165.227.192.254) ftp://ftp.sourceforge.net:/pub/sourceforge/crossfire (64.28.67.101) ftp://ftp.ifi.uio.no:/pub/crossfire (129.240.64.44) Secondary: ftp://ftp.real-time.com/pub/games/crossfire (206.10.252.12) ftp://ftp.cs.city.ac.uk:/pub/games/crossfire/ ftp://ftp.sunet.se:/pub/unix/games/crossfire (130.238.127.3) ftp://ftp.cs.titech.ac.jp:/pub/games/crossfire ftp://mirror.aarnet.edu.au/games/roguelike/crossfire/ ftp://crossfire.futt.org//pub/crossfire I uploaded this version to just ftp.scruz.net - it should be on the other ftp sites in a short time. Mark Wedel mwedel@scruz.net ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Changes: Client: Changes for 0.98.0: item_types,item_types.h: Change matching for sword - hopefully this should fix problems with dancing sword spellbooks. MSW 2001/04/06 gx11.c, item.c: move animations of the look window to the client. All the necessary was already being sent to the client - it was just needed for the client to use this information. Also remove some #if 0 code from gx11.c. MSW 2001/03/28 item.c: set_item_values - only resort items based on name if the name has changed. This fixes a problem with items moving around in the inventory if you lock/apply/unapply/unlock them. MSW 2001/03/23 ------------------------------------------------------------------------------ Server: Changes for 0.98.0: server/skills.c: Modify inscription so that when inscribing cleric spells, it reduces grace. Before, reduced mana no matter the type of spell. server/c_object.c: Fix bug in pick_up where it was not using the right count for picking up objects if the player did not specify one. This allowed players to put objects into containers that should not really fit. server/player.c: Don't let players shoot arrows at themself. Also, minor changes to use new_draw_info_format. server/swap.c: If recycle temp maps, don't save out random maps to get recycled. MSW 2001/04/07 PeterM 2001/04/06: include/libproto.h common/object.c server/apply.c server/spell_util.c Added a new function: instead of stacking many burnout or firetrail objects, only 1 per square is added. Real reduction in server overhead. No reduction in cosmetic effect. common/porting.c: Fix compile warnings/bugs introduced by Win32 changes. server/time.c: Modify move_player_mover so that it determines direction of the mover and then process accordingly, as well as formatting changes. server/c_object.c: modify examine so that it properly shows info about magic bullet spell books. MSW 2001-04-05 common/item.c: Modify identify function to clear the NO_SKILL_IDENT flag so objects will now merge. Also, once the object has been identified, the no_skill_ident doesn't have meaning anymore. MSW 2001-04-03 server/c_object: Modify examine command to only be able to examine valid objects, and not whatever is on top of the space, which may be insivisible. MSW 2001-04-01 include/sproto.h, server/c_wiz.c server/main.c server/player.c socket/loop.c: Modify leave function to take a second parameter that determines if it should print a message about the player leaving the game or not. Proper use of this prevents duplicate XXX left the game messages. MSW 2001-03-29 common/image.c, include/define.h, include/global.h: Add empty_face structure and appropriate code to initialize it. This is used for the server side look selection. include/newserver.h: Add NUM_LOOK_OBJECTS to control number of look objects to send at any one time. add look_position field to the newsocket structure. server/move.c: clear look position as player moves. server/player.c: initalize look_position element in structure. socket/item.c: modify esrv_draw_look to sne NUM_LOOK_OBJECTS at any one time, and to also send pseudo objects that lets the player scroll up and down . modify ApplyCmd so that if it detects the application of one pseudo objects to adjust the look_position. MSW 2001-03-29 common/readable.c: Name spellbooks based on level of spell, and not just randomly. Patch by Preston Crow, applied by Mark Wedel 2001-03-29 configure, configure.in, include/autoconf.h, includes.h: add check for time.h and include it if we find it. socket/item.c: esrv_move_object - have it check to see if the object is already on the ground before we try to re-drop it. Likewise, check to see if it is already in players inventory before we try to pick it up. common/object.c: Don't send face updates to the client or make the space as needing to be redrawn. Client now deals with animation of the look window on its own. utils/(metaserver.pl crossloop add_throw.perl crossloop.pl) lib/(Makefie.in, checkarch.pl collect.pl xpmtopix.pl) - - deleted from CVS - '.in' versions of these files now exist and the real versions are created as part of the configure process. Update Makefile.in to reflect this change. MSW 2001/03/28 common/object.c: have update_position just update the flag that the server needs to send the look window to the client and don't send the item at this point, as sending the look will do that. server/main.c: process_players1: Remove call to draw (which updates the client map) - the handle newclient in socket/loop.c already does this and there is no reason to send multiple instances of the same map. MSW 2001/03/23 server/c_object.c: drop_object function: send delete item to client as item is dropped. This fixes a problem of phantom objects in the inventory. Unrelated change to not call esrv_send_item for objects that are dropped - esrv_draw_look will get called later on and will update this at that time. MSW 2001/03/23 server/c_object.c: Update the return value for some matches - they function was returning immediately when it got a match, but did not give them a high match value, so searching for 'key ring' used to return a match value of 6 or so on the key ring, but a 14 on a key. common/object.c: Modify find_free_spot to call arch_out_of_map so that it properly deals with multipart objects. server/main.c: Fix enter_map so that we first use the golem (and not player) when calling find_free_spot. Also, modify code so that it properly updates coordinates of the multipart golem. MSW 2001/03/20 server/skills.c: Fix orate so that we check for a positive chance (and just not nonzero chance) for successful oration. Due to adjustments, at low levels, the oratory chance can be negative. MSW 2001/03/20 server/spell_effect.c: Change cast_change_attr to find an enemy (and not friend) when casting the curse spell. MSW 2001/03/20 server/apply.c: Increase size of buf to be a HUGE_BUF to very long item names don't cause a stack overflow. MSW 2001/03/20 common/object.c: Modify update_position so that we don't show invisible players to other players. MSW 2001/03/20 From jajcus at bnet.pl Sun Apr 15 11:08:21 2001 From: jajcus at bnet.pl (Jacek Konieczny) Date: Thu Jan 13 18:03:54 2005 Subject: [CF List] hiscores Message-ID: <20010415180821.A3487@nic.nigdzie> Hi, I don't like the way crossfire handles hiscores. Every time you start a game with the same player's name old score is reblaced, by the new one. It doesn't matter, that you were "Player the elf" before, and you ar "Player the human now". IMHO scores of players who quit should stay even if new player with the same name joins. Greets, Jacek From oxygen at ludd.luth.se Sun Apr 15 11:53:39 2001 From: oxygen at ludd.luth.se (Isak Styf) Date: Thu Jan 13 18:03:54 2005 Subject: [CF List] hiscores References: <20010415180821.A3487@nic.nigdzie> Message-ID: <01b701c0c5cc$9f273140$d9c3f082@DS28> > Hi, > > I don't like the way crossfire handles hiscores. Every time you start a > game with the same player's name old score is reblaced, by the new one. > It doesn't matter, that you were "Player the elf" before, and you ar > "Player the human now". > IMHO scores of players who quit should stay even if new player with the > same name joins. And how are you going to tell them apart? In my opinion (i havent discovered this before) it should be handled the mud way, where you cant have two characters with the same name until the first one is purged manually by a "wizard" (that would be the server admin in this case) or automatically by some function that (optionally) nukes characters that havent been playing for the last x months. Opinions? /// Isak Styf From mwedel at scruz.net Sun Apr 15 15:40:51 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:03:54 2005 Subject: [CF List] hiscores References: <20010415180821.A3487@nic.nigdzie> <01b701c0c5cc$9f273140$d9c3f082@DS28> Message-ID: <3ADA0753.8EB95453@scruz.net> Isak Styf wrote: > > > Hi, > > > > I don't like the way crossfire handles hiscores. Every time you start a > > game with the same player's name old score is reblaced, by the new one. > > It doesn't matter, that you were "Player the elf" before, and you ar > > "Player the human now". > > IMHO scores of players who quit should stay even if new player with the > > same name joins. > > And how are you going to tell them apart? > > In my opinion (i havent discovered this before) it should be handled the > mud way, where you cant have two characters with the same name until > the first one is purged manually by a "wizard" (that would be the server > admin in this case) or automatically by some function that (optionally) > nukes characters that havent been playing for the last x months. A lot of crossfire is keyed in on player names. For example, player improved weapons are keyed in on name. So in theory, a player of the same name could leave one for the next player (there are still level checks in place). Likewise, the save files are done by name. I can't see any change in the near future that will allow players of the same name It might be possible to better check the name/race/class for uniqueness. But preserving all the high scores would probably result in a very large high score file. From jajcus at bnet.pl Sat Apr 21 10:13:17 2001 From: jajcus at bnet.pl (Jacek Konieczny) Date: Thu Jan 13 18:03:54 2005 Subject: [CF List] Documentation Message-ID: <20010421171317.A4220@nic.nigdzie> I have just compiled HTML and PDF crossfire documentation. I had to heavily modify PostScript documentation build process to get hi-quality PDF docs (in oposition to PDF made from PostScript or PDF with raster fonts). I sill don't like the result, though. It seems docs sources are not quite up to date. In particular: - Initial equipment handbook section doesn't seem to work at all brobaly because of change in player selection procedure - In the handbook some mess is shown as books (several monsters and empty squares). These don't work for HTML doc neither. How can I fix this? Greets, Jacek From mwedel at scruz.net Sun Apr 22 22:42:43 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:03:54 2005 Subject: [CF List] Documentation References: <20010421171317.A4220@nic.nigdzie> Message-ID: <3AE3A4B3.72ED5BF9@scruz.net> Jacek Konieczny wrote: > > I have just compiled HTML and PDF crossfire documentation. I had to > heavily modify PostScript documentation build process to get hi-quality > PDF docs (in oposition to PDF made from PostScript or PDF with raster > fonts). I sill don't like the result, though. It seems docs sources are > not quite up to date. In particular: > > - Initial equipment handbook section doesn't seem to work at all > brobaly because of change in player selection procedure Almost certainly that is the case. probably most all documentation in the server dealing with race/class is wrong, because it was written before the race/class split. On the bright side, the in game documentation for races and classes is better than it ever has been, so its not quite as critical that this information is up to date. Almost certainly what would be needed is the addition of some text in the handbook, and some code to collect the class information (fortunately, the class have their own types, so extracting the right arch's wouldn't be hard). Other than specific filtering, I don't know of a way to prevent the bogus entries (no_class_face_change) from showing up in the lists. I will noote the extended documentation also is no longer really correct. With partial resistance code, many races have some minor bonus to some resistances, and the meaning of vulnerable, protected, and immune have different meanings. > > - In the handbook some mess is shown as books (several monsters > and empty squares). > > These don't work for HTML doc neither. > How can I fix this? This is in the poorly named makeps program. I've checked in this change: Remove the substitution of _ to - in the image names. This breaks image links, and I'm not really sure why it is ever needed. MSW 2001-04-22. From jajcus at bnet.pl Mon Apr 23 07:29:35 2001 From: jajcus at bnet.pl (Jacek Konieczny) Date: Thu Jan 13 18:03:54 2005 Subject: [CF List] Documentation In-Reply-To: <3AE3A4B3.72ED5BF9@scruz.net>; from mwedel@scruz.net on Sun, Apr 22, 2001 at 08:42:43PM -0700 References: <20010421171317.A4220@nic.nigdzie> <3AE3A4B3.72ED5BF9@scruz.net> Message-ID: <20010423142934.A4426@nic.nigdzie> On Sun, Apr 22, 2001 at 08:42:43PM -0700, Mark Wedel wrote: > > > > - In the handbook some mess is shown as books (several monsters > > and empty squares). > > > > These don't work for HTML doc neither. > > How can I fix this? > > This is in the poorly named makeps program. I've checked in this change: > Remove the substitution of _ to - in the image names. This breaks > image links, and I'm not really sure why it is ever needed. I don't think this is the reason. Wrong archetypes are already in "in_items" file. It seems, that some not-looking-like-book archetypes are marked as books, and than extracted as such. Greets, Jacek From mwedel at scruz.net Mon Apr 23 23:45:06 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:03:54 2005 Subject: [CF List] Documentation References: <20010421171317.A4220@nic.nigdzie> <3AE3A4B3.72ED5BF9@scruz.net> <20010423142934.A4426@nic.nigdzie> Message-ID: <3AE504D2.18AEEE@scruz.net> Jacek Konieczny wrote: > > This is in the poorly named makeps program. I've checked in this change: > > Remove the substitution of _ to - in the image names. This breaks > > image links, and I'm not really sure why it is ever needed. > I don't think this is the reason. Wrong archetypes are already in > "in_items" file. It seems, that some not-looking-like-book archetypes > are marked as books, and than extracted as such. The fix I put in was for incorrectly linked images (ie, youu get the netscape can't show image, so shows the image/question mark thing). In the case of extractions, I believe all of those just go by item type. So something listed as what the extraction program considers the right type gets included. Other than changing the scripts, there is probably no fix for this. From j.jongmans at aprogas.cx Thu Apr 26 08:50:34 2001 From: j.jongmans at aprogas.cx (Jasper Jongmans) Date: Thu Jan 13 18:03:54 2005 Subject: [CF List] Suggestion: improved communication in the client Message-ID: <20010426155034.A361@muisje.aprogas.cx> I have a few suggestions that I would like to make communication with other players nicer (in my opinion). * Local echo of things you 'tell Pros: this makes a conversation easier (i.e., you wont forget to what question a certain answer was) Cons: more lines in the logwindow * Seperate log_window/communication_window Pros: you can keep on talking even if someone/something causes alot of lines in the log window Cons: you will need to monitor two windows for possible interesting activity Note: I would like it if the communication window also contains a list of logged in users and existing parties that you can go into ``query'' with (similar to IRC) * Client side choosing of colours for certain events (without having to touch the source) Pros: you can easily seperate things that are said/told/shouted/other_stuff Cons: it will turn your log window into a christmas tree (some people will find this a pro) -- Jasper Jongmans aprogas@mail.com Website http://130.89.222.57/~aprogas/ PGP key ftp://130.89.222.57/keys/pgp_dss.asc From lembark at wrkhors.com Thu Apr 26 16:33:38 2001 From: lembark at wrkhors.com (Steven Lembark) Date: Thu Jan 13 18:03:54 2005 Subject: [CF List] Suggestion: improved communication in the client References: <20010426155034.A361@muisje.aprogas.cx> Message-ID: <3AE89432.2044C8A1@wrkhors.com> Jasper Jongmans wrote: > > I have a few suggestions that I would like to make communication with other > players nicer (in my opinion). > > * Local echo of things you 'tell > Pros: this makes a conversation easier (i.e., you wont forget to what > question a certain answer was) > Cons: more lines in the logwindow > > * Seperate log_window/communication_window > Pros: you can keep on talking even if someone/something causes alot of lines > in the log window > Cons: you will need to monitor two windows for possible interesting activity > Note: I would like it if the communication window also contains a list of > logged in users and existing parties that you can go into ``query'' with > (similar to IRC) > > * Client side choosing of colours for certain events (without having to > touch the source) > Pros: you can easily seperate things that are said/told/shouted/other_stuff > Cons: it will turn your log window into a christmas tree (some people will > find this a pro) how about supressing duplicate messages (e.g., "you pray...")? i don't know how many times i've lost useful info as it scrolls off the screen while i'm praying at hight speed. ditto for "you hit the blah with your blah". -- Steven Lembark 2930 W. Palmer St. Chicago, IL 60647 lembark@wrkhors.com 800-762-1582 From tanner at real-time.com Thu Apr 26 17:52:38 2001 From: tanner at real-time.com (Bob Tanner) Date: Thu Jan 13 18:03:55 2005 Subject: [CF List] Metalforge IP address changing Message-ID: <20010426175238.B13662@real-time.com> On April 30th, 2001 between Midnight and 6am CST metalforge's IP address will change. We are dropping MrNet and thus need to return their IP addresses. The new IP address will be 208.20.202.42. We have already dropped the TTL on the zone files so thing should update quickly. As long as you access the server using it's hostname you should not have any problems. If you have any questions, please drop me an email. -- Bob Tanner | Phone : (952)943-8700 http://www.mn-linux.org | Fax : (952)943-8500 Key fingerprint = 6C E9 51 4F D5 3E 4C 66 62 A9 10 E5 35 85 39 D9 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 366 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20010426/36413229/attachment-0001.pgp From mwedel at scruz.net Fri Apr 27 01:04:49 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:03:55 2005 Subject: [CF List] Suggestion: improved communication in the client References: <20010426155034.A361@muisje.aprogas.cx> Message-ID: <3AE90C01.9D29F544@scruz.net> Note there are some of these features in an unreleased client version. To get that client, use cvs and do 'cvs checkout -r post-1-0 client' Jasper Jongmans wrote: > > I have a few suggestions that I would like to make communication with other > players nicer (in my opinion). > > * Local echo of things you 'tell > Pros: this makes a conversation easier (i.e., you wont forget to what > question a certain answer was) > Cons: more lines in the logwindow It does echo things you 'say. > > * Seperate log_window/communication_window > Pros: you can keep on talking even if someone/something causes alot of lines > in the log window > Cons: you will need to monitor two windows for possible interesting activity > Note: I would like it if the communication window also contains a list of > logged in users and existing parties that you can go into ``query'' with > (similar to IRC) Sort of done. In the client described above, there is a -splitinfo window which creates two windows. Currently, the data is seperated by colored output going in one window, with black/white going in the other. This is pretty close. This functionality is only in the gcfclient. > > * Client side choosing of colours for certain events (without having to > touch the source) > Pros: you can easily seperate things that are said/told/shouted/other_stuff > Cons: it will turn your log window into a christmas tree (some people will > find this a pro) This is more or less on the TODO list. Currently, the server only sends color suggestions to the client, and no context, so the client can't really do such sorting. Whats on the TODO list is for the server to send actual descriptive id for what the text message is.