From mwedel at sonic.net Thu Sep 1 00:04:03 2005 From: mwedel at sonic.net (Mark Wedel) Date: Thu Sep 1 00:05:18 2005 Subject: [crossfire] Server map redo: movement types In-Reply-To: <20050831164654.WJFX2134.tomts48-srv.bellnexxia.net@[209.226.175.82]> References: <20050831164654.WJFX2134.tomts48-srv.bellnexxia.net@[209.226.175.82]> Message-ID: <43168BC3.8090104@sonic.net> temitchell@sympatico.ca wrote: >> From: Mark Wedel >> >> Unless a race has native flying, the player would have to do something to >> start flying (wear those boots, ready the skill, cast a spell). >> >> The question was really want to do once that has happened. Eg, player has >> applied the boots of levitation and now walks to a shop map, etc. >> >> > > > Well yes, naturally if you apply items of cast a spell you are choosing to > fly. What I was really getting at was jumping/flying as race move types. > Some races like dragons can fly - but I don't think they should just always > fly - it should have to be added as a command - fly and bound to a key or > whatever. Jumping should work the same way and all players should be able to > jump over a single tile if it allows flying over. The problem I see with > autoflying is the code choosing when to fly the player not choosing. Perhaps > you are fighting and want to bump into low walls (you might want to use it as > a barrier and fire missiles over it instead of flying over it by mistake). If > the fight is going bad however then you can fly or jump over the wall (if you > can - enter weight issues) suppose it isn't treating flying any differnet, > it is how you enter that movement state. I can also see cases where flying is > blocked (low roof) and you want the player to bump into the barrier and have > to continue on foot- not simply continue moving (not automatically change > movement to a walk.) Just a note, I wasn't saying that dragons would automatically fly - I'm not touching that code, so I expect it will remain that they will have to use the appropriate skill to actually start flying. And the issue isn't what movement types the player can potentially do (jump for example) - going back to the original question was 'what to do if the players movement type is MOVE_WALK | MOVE_FLY). How characters get multiple movement types is a different discussion and not what I'm addressing here. Likewise, the code is not going to auto apply new movement types. If you could in theory jump over that trap door but aren't currently flying, guess what, you walked onto it - you need to explicity use the jump command to hop over it. But you do have some points, which is what I was really getting to. Suppose the dragon has chosen to fly and is busy attacking. If he goes to the low wall, does he now fly over? I think the answer here is use. However, the issue is that characters will always be able to walk. So basically one could think of it of the character (if has flying object or is otherwise choosing to fly) basically uses that as movement, unless that doesn't work, in which case he'd automatically fall back to walking. Some of it is of course playability - I don't want to constantly have to be changing my movement types (switch to swim - now in water, switch back to walk, leaving water. Switch to fly (even though I have those levitation boots) as want to go over that wall, etc. > The 'fatigue' part was simply to prevent races with flying from moving across > oceans and large mountain ranges and the like at will. This gives them a > *huge* advantage over non flying races. If a dragon can fly a distance > equal to their Con before having to land then they get a massive benefit to > movement bit it's not like they're going to fly across the oceans (they'd > drown). Now if you use a magic item to fly instead of a racial skill then > it's not a balance issue - however that item should be worth a *lot* more if > it allows you to fly across the ocean now. Just a note, that right now, dragons can fly unlimited distances (and boots work forever) - you can't get over oceans, but can fly over terrain that doesn't actually block passage (which is only high mountain) and should be avoid all slow move penalties since it doesn't apply to flying. So the only real change is possilibility of flying over water. But that has to be looked at for other reasons, notably that it would open up the map a lot. From mwedel at sonic.net Thu Sep 1 00:15:01 2005 From: mwedel at sonic.net (Mark Wedel) Date: Thu Sep 1 00:15:32 2005 Subject: [crossfire] fatigue In-Reply-To: <200508312216.24469.tchize@myrealbox.com> References: <43155735.7000609@sonic.net> <200508312216.24469.tchize@myrealbox.com> Message-ID: <43168E55.6070809@sonic.net> tchize wrote: >> You get fatigue by doing strenous things (swimming, flying via skill, >>attacking, moving a lot). > > > Or just being awake ? or it will not be fatigue but stamina :) Idea was more physical fatigue not mental. I personally don't want to have to rest my character if I'm still wanting to play. > > >> You lose fatigue by resting - this can basically be measured by the >>character having an action and not actually doing anything. Certain magic >>potions could also reduce fatigue. > > > apply bed to reality? could be, but you'd have to record how long it was saved for (if I save and reload immediately, shouldn't be any advantage). That said, if the character is doing nothing - just standing there, I'd expect fatigue should drop pretty darn faster - it should drop faster than you get HP back for example. So basically, fatigue would really come in to play if your doing continuous work, eg, combat all the time, flying around the world as dragon, etc. But once you stop doing those things, you'd get back to 0 fatigue relatively quickly. >> If not carrying much, you wouldn't get much fatigue - thus, a lightly >>equipped person could run around all day and not have to rest much. > > > Race dependent? One could certainly add more variation - different races weighing different amount, different carrying capacities, etc. But one issue is that armor is one size fit all - a halfling should rightfully have smaller and lighter armor than a human. and at some level, different races/classes get the benefit - trolls for example are very strong and have high con - that alone will let them carry more and give them a higher maximum fatigue - I don't know if it is necessary to then give them even more bonuses. > > Perhaps, a level high enough in fatigue will improve your spell regeneration > (you are in a semi conscient state, bringing you closer to your god) > Also a level high enough in fatigue could also be converted to some berserk > state (a fighter not resting for 3 days begins to get crazy, he fight like > crazy (don't forget to include it's virtual los of dex for hitting chance), > well he becomes like a butcher :D ) Maybe. But you then have to some how enforce the player not being able to be clever. EG, a character in a beserk state shouldn't be thinking enough to drink that healing potion or apply that scroll of restoration. One could do something like at high level of fatigue, maybe you don't apply the item you want (x% of applying something random from your inventory) as a way to enforce that? Other thoughts: One could give chairs and non savebeds some meaning - sit in one of those, fatigue goes down faster. In some states, even when idle, you can't get back fatigue. EG, if you're swimming or flying, you can't be resting - if you just staying in one place, maybe you fatigue just doesn't go up quite as fast. From kirschbaum at myrealbox.com Thu Sep 1 02:22:27 2005 From: kirschbaum at myrealbox.com (Andreas Kirschbaum) Date: Thu Sep 1 02:23:34 2005 Subject: [crossfire] Re: [Crossfire-cvs] CVS commit: crossfire/lib In-Reply-To: References: Message-ID: <20050901072227.GA15102@kirschbaum.myrealbox.com> crossfire-cvs-admin@lists.sourceforge.net wrote: > Module Name: crossfire > Committed By: mwedel > Date: Wed Aug 31 06:28:23 UTC 2005 [...] > Log Message: > Recollect archetypes. [...] > Index: crossfire/lib/archetypes > diff -c crossfire/lib/archetypes:1.162 crossfire/lib/archetypes:1.163 > *** crossfire/lib/archetypes:1.162 Thu Aug 18 18:04:46 2005 > --- crossfire/lib/archetypes Tue Aug 30 23:28:11 2005 > *************** > *** 15872,15878 **** > type 82 > nrof 1 > glow_radius 0 > - is_lightable 1 > editable 128 > name_pl lanterns > client_type 1102 > --- 15872,15877 ---- This (and the following changes) seems not correct to me: the current archetypes directory does include this removed line. (And it is necessary to make lamps and torches work again.) From kirschbaum at myrealbox.com Thu Sep 1 02:36:23 2005 From: kirschbaum at myrealbox.com (Andreas Kirschbaum) Date: Thu Sep 1 02:37:34 2005 Subject: [crossfire] Re: [Crossfire-cvs] CVS commit: crossfire In-Reply-To: References: Message-ID: <20050901073623.GA15186@kirschbaum.myrealbox.com> crossfire-cvs-admin@lists.sourceforge.net wrote: > Module Name: crossfire > Committed By: tchize > Date: Wed Aug 31 20:07:22 UTC 2005 [...] > Log Message: > Accelerated map loading (a lot) and map saving (a bit) codes to improve map transition > experience. [...] > Index: crossfire/common/object.c > diff -c crossfire/common/object.c:1.100 crossfire/common/object.c:1.101 > *** crossfire/common/object.c:1.100 Sun Aug 28 20:52:49 2005 > --- crossfire/common/object.c Wed Aug 31 13:07:22 2005 [...] > --- 1602,1612 ---- > /* If we have a floor, we know the player, if any, will be above > * it, so save a few ticks and start from there. > */ > ! if (!(flag |INS_MAP_LOAD)) > ! for(tmp=floor?floor:GET_MAP_OB(op->map,op->x,op->y);tmp!=NULL;tmp=tmp->above) { > ! if (tmp->type == PLAYER) > ! tmp->contr->socket.update_look=1; > ! } > > /* If this object glows, it may affect lighting conditions that are > * visible to others on this map. But update_all_los is really > The condition "!(flag |INS_MAP_LOAD)" probably is not correct: FLAG_MAP_LOAD is the constant 0x20. Therefore "(flag|INS_MAP_LOAD)" is always non-zero which means "!(non-zero)" is always false. From alex_sch at telus.net Thu Sep 1 08:47:54 2005 From: alex_sch at telus.net (alex_sch@telus.net) Date: Thu Sep 1 08:49:37 2005 Subject: [crossfire] Re: [Crossfire-cvs] CVS commit: crossfire/lib In-Reply-To: <20050901072227.GA15102@kirschbaum.myrealbox.com> References: <20050901072227.GA15102@kirschbaum.myrealbox.com> Message-ID: <1125582474.4317068a96a65@webmail.telus.net> Quoting Andreas Kirschbaum : > crossfire-cvs-admin@lists.sourceforge.net wrote: > > Module Name: crossfire > > Committed By: mwedel > > Date: Wed Aug 31 06:28:23 UTC 2005 > [...] > > Log Message: > > Recollect archetypes. > [...] > > Index: crossfire/lib/archetypes > > diff -c crossfire/lib/archetypes:1.162 crossfire/lib/archetypes:1.163 > > *** crossfire/lib/archetypes:1.162 Thu Aug 18 18:04:46 2005 > > --- crossfire/lib/archetypes Tue Aug 30 23:28:11 2005 > > *************** > > *** 15872,15878 **** > > type 82 > > nrof 1 > > glow_radius 0 > > - is_lightable 1 > > editable 128 > > name_pl lanterns > > client_type 1102 > > --- 15872,15877 ---- > > This (and the following changes) seems not correct to me: the current > archetypes directory does include this removed line. (And it is > necessary to make lamps and torches work again.) Indeed (to me, this looks like mwedel forgot to update his arch tree before rebuilding) From antonoussik at gmail.com Thu Sep 1 13:43:15 2005 From: antonoussik at gmail.com (Anton Oussik) Date: Thu Sep 1 13:43:40 2005 Subject: [crossfire] fatigue In-Reply-To: <43168E55.6070809@sonic.net> References: <43155735.7000609@sonic.net> <200508312216.24469.tchize@myrealbox.com> <43168E55.6070809@sonic.net> Message-ID: On 9/1/05, Mark Wedel wrote: > > tchize wrote: > > >> You get fatigue by doing strenous things (swimming, flying via skill, > >>attacking, moving a lot). > > > > > > Or just being awake ? or it will not be fatigue but stamina :) > > Idea was more physical fatigue not mental. I personally don't want to have > to > rest my character if I'm still wanting to play. I like the idea of fatigue, but in CF days are so short that battles often last for weeks, and players can happily survive on 2-3 meals a week. If fatigue is introduced in the same way, that you only need to sleep (use_skill rest) once in a while it would be acceptable. > >> You lose fatigue by resting - this can basically be measured by the > >>character having an action and not actually doing anything. Certain > magic > >>potions could also reduce fatigue. But should be temporary improvement followed by getting very fatigued after that. Overdosing should eventually make you so fatigued you die. Also fatigue effects should be incremental with time. So when fully fresh you start at full stats. Then, after about 30 minutes of play you lose a stat, after another 15 minutes another stat, then after 8, 4, 2, and then 1 for every other minute of play. When all stats get to 1 you should start losing hp, until you die from fatigue or use_skill rest. Resting on a bed should speed up recovery (or perhaps change how much you can recover, so sleeping on the ground will not get you very good rest?) > apply bed to reality? > > could be, but you'd have to record how long it was saved for (if I save > and > reload immediately, shouldn't be any advantage). IMO bed of reality should not change in functionality. That said, if the character is doing nothing - just standing there, I'd > expect > fatigue should drop pretty darn faster - it should drop faster than you > get HP > back for example. Staying awake is an effort. If you don't believe me try doing it for a week. So basically, fatigue would really come in to play if your doing continuous > work, eg, combat all the time, flying around the world as dragon, etc. But > once > you stop doing those things, you'd get back to 0 fatigue relatively > quickly. Although it seems what is being discusses here is physical tirednes like from running or lifting weights and so on, which is a different tirednes than that from staying awake. Perhaps they could be combined together so total_fatigue = waking_fatigue + active_fatigue >> If not carrying much, you wouldn't get much fatigue - thus, a lightly > >>equipped person could run around all day and not have to rest much. > > > > > > Race dependent? > > One could certainly add more variation - different races weighing > different > amount, different carrying capacities, etc. But one issue is that armor is > one > size fit all - a halfling should rightfully have smaller and lighter armor > than > a human. Race and class items deserver their own thread, and IMO a very good idea if someone has the time to create new archetypes and add race/class restrictions to items. Other thoughts: > One could give chairs and non savebeds some meaning - sit in one of those, > fatigue goes down faster. This goes back to my use_skill rest idea In some states, even when idle, you can't get back fatigue. EG, if you're > swimming or flying, you can't be resting - if you just staying in one > place, > maybe you fatigue just doesn't go up quite as fast. A good observation. If anything flying and swimming should increase fatigue unless you are a firebourne and are flying (or a lizard person and swimming?) and you should only be able to use skill rest when on the ground. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://shadowknight.real-time.com/pipermail/crossfire/attachments/20050901/0b439f65/attachment.htm From lalo at exoweb.net Thu Sep 1 19:06:31 2005 From: lalo at exoweb.net (Lalo Martins) Date: Thu Sep 1 19:09:44 2005 Subject: [crossfire] Re: fatigue In-Reply-To: References: <43155735.7000609@sonic.net> <200508312216.24469.tchize@myrealbox.com> <43168E55.6070809@sonic.net> Message-ID: And so says Anton Oussik on 02/09/05 02:43... >>> Certain magic potions could also reduce fatigue. > > But should be temporary improvement followed by getting very fatigued > after that. Heh heh heh. We already have coffee, right? ;-) (My wife made a character who, by choice, lived off only alcoholic drinks. Yeah, a swashbuckler. I used to pile cups of coffee in front of her bed in the guild.) best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. -- http://www.exoweb.net/ mailto:lalo@exoweb.net GNU: never give up freedom http://www.gnu.org/ From temitchell at sympatico.ca Thu Sep 1 19:26:33 2005 From: temitchell at sympatico.ca (Todd Mitchell) Date: Thu Sep 1 19:25:43 2005 Subject: [crossfire] Server map redo: movement types In-Reply-To: <43168BC3.8090104@sonic.net> References: <20050831164654.WJFX2134.tomts48-srv.bellnexxia.net@[209.226.175.82]> <43168BC3.8090104@sonic.net> Message-ID: <43179C39.6060606@sympatico.ca> Mark Wedel wrote: > Just a note, I wasn't saying that dragons would automatically fly - > I'm not touching that code, so I expect it will remain that they will > have to use the appropriate skill to actually start flying. Ah, my mistake. I thought you were describing that if a player had the Flying move type they would automatically use it if they were otherwise blocked. This would actually be ok for cases like moving from land onto water or climbing over a high mountain but not so good for flying over the mountain or the water( or a low wall or over a hole). MOVE_WALK, MOVE_SWIM, MOVE_CLIMB are all mutually exclusive however MOVE_FLY could apply to all these. This is why I suggested they entering fly mode would be different from the rest. > > And the issue isn't what movement types the player can potentially do > (jump for example) - going back to the original question was 'what to > do if the players movement type is MOVE_WALK | MOVE_FLY). I would think they would only be able to have one movement type at a time. If they are flying they can't pick up things on the ground or trigger buttons and the like. If they are walking then they aren't flying... > How characters get multiple movement types is a different discussion > and not what I'm addressing here. > > Likewise, the code is not going to auto apply new movement types. If > you could in theory jump over that trap door but aren't currently > flying, guess what, you walked onto it - you need to explicity use the > jump command to hop over it. I would expect the code *would* actually apply movement types. Also that if you were climbing or swimming you could not reasonably do melee combat (and possibly not have 'hand' items applied unless you had were using a spell or item - this is interesting - boots of waterwalking is not swimming). As you say - I would hate to have to type 'climb', 'swim',' climb', 'walk'. Again 'fly' however is a special case. > Some of it is of course playability - I don't want to constantly have > to be changing my movement types (switch to swim - now in water, > switch back to walk, leaving water. Switch to fly (even though I have > those levitation boots) as want to go over that wall, etc. agreed - if you wade in to the water you should assume you would start swimming. If you couldn't swim however I think you should stop and not automatically start flying. > Just a note, that right now, dragons can fly unlimited distances (and > boots work forever) - you can't get over oceans, but can fly over > terrain that doesn't actually block passage (which is only high > mountain) and should be avoid all slow move penalties since it doesn't > apply to flying. > > So the only real change is possilibility of flying over water. But > that has to be looked at for other reasons, notably that it would open > up the map a lot. Yes, however if flying is limited what happens if you run out of juice while over a terrain you can't pass - I guess in most cases you would be stuck untill you can rest and fly again but over say water... do you take damage? Drown? From rbrockway at opentrend.net Thu Sep 1 19:49:06 2005 From: rbrockway at opentrend.net (Robert Brockway) Date: Thu Sep 1 19:43:43 2005 Subject: [crossfire] Re: fatigue In-Reply-To: References: <43155735.7000609@sonic.net> <200508312216.24469.tchize@myrealbox.com> <43168E55.6070809@sonic.net> Message-ID: On Fri, 2 Sep 2005, Lalo Martins wrote: > (My wife made a character who, by choice, lived off only alcoholic > drinks. Yeah, a swashbuckler. I used to pile cups of coffee in front > of her bed in the guild.) That's cool :) While we are on the subject of drinkings having effects (such as coffee reducing fatigure) I've always thought that anyone who over-indulges in booze should realy suffer a loss of Dex. Yes there is a bit of coding in there. On the topic of armour types, rather than having Halfling armour, Human armour, etc, we could assign a size attributed to all races and have the character required to use armour of the right size. So halflings and gnome would require small armor, trolls large armour and most other races medium armour. This would reduce the complexity and would mean less work when we add new races in the future. Rob -- Robert Brockway B.Sc. Phone: +1-416-669-3073 Senior Technical Consultant Email: support@opentrend.net OpenTrend Solutions Ltd. Web: www.opentrend.net We are open 24x7x365 for technical support. Call us in a crisis. From kirschbaum at myrealbox.com Fri Sep 2 19:16:08 2005 From: kirschbaum at myrealbox.com (Andreas Kirschbaum) Date: Fri Sep 2 19:17:58 2005 Subject: [crossfire] Re: [Crossfire-cvs] CVS commit: crossfire In-Reply-To: <20050901073623.GA15186@kirschbaum.myrealbox.com> References: <20050901073623.GA15186@kirschbaum.myrealbox.com> Message-ID: <20050903001608.GA2988@kirschbaum.myrealbox.com> Andreas Kirschbaum wrote: > The condition "!(flag |INS_MAP_LOAD)" probably is not correct: > FLAG_MAP_LOAD is the constant 0x20. Therefore "(flag|INS_MAP_LOAD)" is > always non-zero which means "!(non-zero)" is always false. Fixed in CVS: I did change "|" into "&" since it did prevent the client's ground view from being updated after the player applied an exit or whenever a spell effect should be displayed on the ground below the player. From mwedel at sonic.net Fri Sep 2 23:14:25 2005 From: mwedel at sonic.net (Mark Wedel) Date: Fri Sep 2 23:16:00 2005 Subject: [crossfire] map redo: more layers. In-Reply-To: <25410ce0508311036493e69f9@mail.gmail.com> References: <431559CC.1090704@sonic.net> <25410ce0508311036493e69f9@mail.gmail.com> Message-ID: <43192321.6060906@sonic.net> adam ashenfelter wrote: > How about 11: rooftops. When player is not under one, client displays > them. When the player walks under one, they disappear, and the player > can see the interior. I don't see how this really works much with the current system. All the houses that players enter take them to new maps - hence, no rooftop visible (ok, there might be a few exceptions, but still). There isn't even the graphics right now for rooftops - they are just part of building graphic. Also, doing so creates a new complication for drawing. The way a map actually looks is consistent for everyone - what changes is what spaces are visible. In such an above system, you'd now start making what the player sees on each space relative to where they are. So if you have a case of two players in the same area, but one indoors, the other outdoors, for the indoor player, he'd see everything inside. For the outdoor player, he'd just see the roof. Doing this would be a non trivial change, and also create a cpu hit. But mostly, since I don't see the maps or graphics set up to make use of this at all right now, doesn't see much point to add such support. From antonoussik at gmail.com Sat Sep 3 12:46:33 2005 From: antonoussik at gmail.com (Anton Oussik) Date: Sat Sep 3 12:48:08 2005 Subject: [crossfire] Re: fatigue In-Reply-To: References: <43155735.7000609@sonic.net> <200508312216.24469.tchize@myrealbox.com> <43168E55.6070809@sonic.net> Message-ID: This should be plain text. Sorry, gmail decided it wanted to send html emails for some strange reason and did not tell me. On 9/2/05, Robert Brockway wrote: > On Fri, 2 Sep 2005, Lalo Martins wrote: > > > (My wife made a character who, by choice, lived off only alcoholic > > drinks. Yeah, a swashbuckler. I used to pile cups of coffee in front > > of her bed in the guild.) > > That's cool :) While we are on the subject of drinkings having effects > (such as coffee reducing fatigure) I've always thought that anyone who > over-indulges in booze should realy suffer a loss of Dex. Yes there is a > bit of coding in there. Drinking booze should cast confusion on the drinker. I have been unable to make a booze like that though despite trying, as confusion always seems to get cast in some direction from or around the player. > On the topic of armour types, rather than having Halfling armour, Human > armour, etc, we could assign a size attributed to all races and have the > character required to use armour of the right size. So halflings and > gnome would require small armor, trolls large armour and most other races > medium armour. This would reduce the complexity and would mean less work > when we add new races in the future. That is true. Maybe make weapons have race bonuses then? If an armour is specifically made to fit around a halfling, a gnome would not find it as comfortable despite being able to wear it. This would make adding races more difficult though. Also when (if?) sexes are added, male/female armour are different, although wearable by the opposite sex. Perhaps add a penalty for wearing armour of the wrong sex (as it is not suited well for your build)? From tchize at myrealbox.com Sat Sep 3 17:30:50 2005 From: tchize at myrealbox.com (tchize) Date: Sat Sep 3 17:32:12 2005 Subject: [crossfire] sacrifice altar behaviour change Message-ID: <200509040030.56759.tchize@myrealbox.com> Just dropping a note to inform altar has changed a bit. A new check has been added. It know check if sacrificed item has the same fullname (not counting plural) as the slaying field of altar. This mean you can create an altar that asks you to sacrifice 5 bronze swords +2 by setting the following values in altar: nrof 5 slaying bronze sword +2 This make things easy for mapmakers as this is exactly the way names appear in client when described (all (str+2)(dex+1)(see invisible) aso put aside) This take into account material name, title, name, magical + -- -- Tchize (David Delbecq) tchize@myrealbox.com Public PGP KEY FINGERPRINT: ? ? F4BC EF69 54CC F2B5 4621 ?8DAF 1C71 8E6B 5436 C17C Public PGP KEY location: ? ? http://wwwkeys.pgp.net/pgpnet/wwwkeys.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20050904/ff4f266c/attachment.pgp From lalo at exoweb.net Sat Sep 3 21:40:06 2005 From: lalo at exoweb.net (Lalo Martins) Date: Sat Sep 3 21:42:15 2005 Subject: [crossfire] Re: fatigue In-Reply-To: References: <43155735.7000609@sonic.net> <200508312216.24469.tchize@myrealbox.com> <43168E55.6070809@sonic.net> Message-ID: And so says Anton Oussik on 04/09/05 01:46... > Drinking booze should cast confusion on the drinker. I have been > unable to make a booze like that though despite trying, as confusion > always seems to get cast in some direction from or around the player. Hopefully, the new and shiny python plugin will expose the confuse_player function from attack.c. ;-) (I used to have a patch for that, but I seem to have lost it, and anyway it's irrelevant now that the plugin is being rewritten) best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. -- http://www.exoweb.net/ mailto:lalo@exoweb.net GNU: never give up freedom http://www.gnu.org/ From nicolas.weeger at laposte.net Sun Sep 4 08:16:46 2005 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sun Sep 4 08:18:19 2005 Subject: [crossfire] Patch: Fix map display errors for big faces In-Reply-To: <20050824212734.GA17408@kirschbaum.myrealbox.com> References: <20050824212734.GA17408@kirschbaum.myrealbox.com> Message-ID: <431AF3BE.70302@laposte.net> Andreas Kirschbaum a ?crit : > I just added my patches to fix bug #1102991 (Duplicate grapical display > of the same monster): > > http://sourceforge.net/tracker/index.php?func=detail&aid=1269280&group_id=13833&atid=313833 This patch makes client unusable on my computer. Drawing routines suck 110% of the CPU power. Tried to trace the issue, apparently Map1aCmd is called really often, and time is spent in the draw_pixmap routine. Any help appreciated :) Ryo From nicolas.weeger at laposte.net Sun Sep 4 09:06:37 2005 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sun Sep 4 09:08:20 2005 Subject: [crossfire] Patch: Fix map display errors for big faces In-Reply-To: <431AF3BE.70302@laposte.net> References: <20050824212734.GA17408@kirschbaum.myrealbox.com> <431AF3BE.70302@laposte.net> Message-ID: <431AFF6D.2040003@laposte.net> > This patch makes client unusable on my computer. Drawing routines suck > 110% of the CPU power. Fixed & committed to CVS (flag not correctly cleared when drawing). Ryo From tchize at myrealbox.com Sun Sep 4 10:49:22 2005 From: tchize at myrealbox.com (tchize) Date: Sun Sep 4 10:50:21 2005 Subject: [crossfire] Maploading bug - update to latest cvs if you did checkout recently Message-ID: <200509041749.26997.tchize@myrealbox.com> If you run a server and did a recent checkout ofmap, please update sources files to latest. Some code displacements in map loading code left a var uninitialized, leading to some object disappearance at load time. This is serious for player appartments. Has been noticed as disappearing: - some doors (randomly) - fireplace I still don't know why such object while not flagged as OBJECT_ORIGINAL disappear, i suspect the overlay code has a bug inside which showed up when all objects of map where flagged as *not* original. Anyway, normal maps doesn't dissapear now, but unique doors and fireplace are still subject to change. Sorry for convenience, -- -- Tchize (David Delbecq) tchize@myrealbox.com Public PGP KEY FINGERPRINT: ? ? F4BC EF69 54CC F2B5 4621 ?8DAF 1C71 8E6B 5436 C17C Public PGP KEY location: ? ? http://wwwkeys.pgp.net/pgpnet/wwwkeys.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20050904/befe2943/attachment.pgp From nicolas.weeger at laposte.net Sun Sep 4 10:57:51 2005 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sun Sep 4 11:02:21 2005 Subject: [crossfire] create_and_rescale_image_from_data weirdness Message-ID: <431B197F.8020407@laposte.net> Hello. The logic of create_and_rescale_image_from_data (in gtk/image.c) is strange. In a first pass, it tests if (iscale != 100) { and calls in any case create_icon_image which creates the pixmap's image and mask through rgba_to_gdkpixmap. Then just after if (use_config[CONFIG_MAPSCALE] != 100) { which always create_map_image, which first line is erasing the mark and image just created and calls rgba_to_gdkpixmap! As I'm not too familiar with client display logic, I'm not sure of the best fix, but obviously there's an extra call :) Also, when if (use_config[CONFIG_DISPLAYMODE]==CFG_DM_SDL) { is true, a png_tmp is allocated and never freed. Ryo From tchize at myrealbox.com Sun Sep 4 10:58:56 2005 From: tchize at myrealbox.com (tchize) Date: Sun Sep 4 11:04:34 2005 Subject: [crossfire] Maploading bug - update to latest cvs if you did checkout recently In-Reply-To: <200509041749.26997.tchize@myrealbox.com> References: <200509041749.26997.tchize@myrealbox.com> Message-ID: <200509041759.02564.tchize@myrealbox.com> Le Dimanche 04 Septembre 2005 17:49, tchize a ?crit : >If you run a server and did a recent checkout ofmap, please update please read checkout of cvs, not checkout of map :D >sources files to latest. Some code displacements in map loading code >left a var uninitialized, leading to some object disappearance at load time. >This is serious for player appartments. Has been noticed as disappearing: >- some doors (randomly) >- fireplace > >I still don't know why such object while not flagged as OBJECT_ORIGINAL >disappear, i suspect the overlay code has a bug inside which showed up >when all objects of map where flagged as *not* original. > >Anyway, normal maps doesn't dissapear now, but unique doors and fireplace > are still subject to change. > >Sorry for convenience, -- -- Tchize (David Delbecq) tchize@myrealbox.com Public PGP KEY FINGERPRINT: ? ? F4BC EF69 54CC F2B5 4621 ?8DAF 1C71 8E6B 5436 C17C Public PGP KEY location: ? ? http://wwwkeys.pgp.net/pgpnet/wwwkeys.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20050904/fceb2a88/attachment-0001.pgp From fuchs.andy at gmail.com Sun Sep 4 23:06:17 2005 From: fuchs.andy at gmail.com (Andrew Fuchs) Date: Sun Sep 4 23:06:29 2005 Subject: [crossfire] License for wiki text Message-ID: Following up a discussion on irc, what is a good licence for the crossfire wiki's text? Public domain was quickly shot down. Other recomendations where the GNU FDL, and GPL, Creative Commons, and BSD. I do think that text will be copied from and to the game, from the wiki (once a better one is in place, which i am prepared to offer if needed) -- Andrew Fuchs From lalo at exoweb.net Mon Sep 5 00:00:44 2005 From: lalo at exoweb.net (Lalo Martins) Date: Mon Sep 5 00:04:30 2005 Subject: [crossfire] Re: License for wiki text In-Reply-To: References: Message-ID: And so says Andrew Fuchs on 05/09/05 12:06... > Following up a discussion on irc, what is a good licence for the > crossfire wiki's text? Public domain was quickly shot down. Other > recomendations where the GNU FDL, and GPL, Creative Commons, and BSD. For the content I've written, I'm happy with either one of these. (Although Creative Commons is a group of licenses, not one license. But I'm fine with any of them.) Personally I'd go with the FDL for documentation, and GPL for lore. best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. -- http://www.exoweb.net/ mailto:lalo@exoweb.net GNU: never give up freedom http://www.gnu.org/ From brenlally at gmail.com Mon Sep 5 09:16:20 2005 From: brenlally at gmail.com (Brendan Lally) Date: Mon Sep 5 09:16:34 2005 Subject: [crossfire] Re: License for wiki text In-Reply-To: References: Message-ID: <7903f03c05090507163d8884f1@mail.gmail.com> On 9/5/05, Lalo Martins wrote: > Personally I'd go with the FDL for documentation, and GPL for lore. What happens then if something written as documentation is latter used as lore within the game? I am not convinced the boundaries between these two catergories are always clear. From nicolas.weeger at laposte.net Mon Sep 5 15:18:26 2005 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Mon Sep 5 15:20:39 2005 Subject: [crossfire] create_and_rescale_image_from_data weirdness In-Reply-To: <431B197F.8020407@laposte.net> References: <431B197F.8020407@laposte.net> Message-ID: <431CA812.4080302@laposte.net> Nevermind, I was probably tired :) Tweaked code to just copy icon image/mask to map image/mask if same scale instead of doing twice the work. There's still a potential memory leak, though ^_- Ryo From lalo at exoweb.net Mon Sep 5 23:02:05 2005 From: lalo at exoweb.net (Lalo Martins) Date: Mon Sep 5 23:04:43 2005 Subject: [crossfire] Re: License for wiki text In-Reply-To: <7903f03c05090507163d8884f1@mail.gmail.com> References: <7903f03c05090507163d8884f1@mail.gmail.com> Message-ID: And so says Brendan Lally on 05/09/05 22:16... > On 9/5/05, Lalo Martins > wrote: >> Personally I'd go with the FDL for documentation, and GPL for lore. >> > > What happens then if something written as documentation is latter > used as lore within the game? Hmm. I was under the impression that the FDL is GPL-compatible (meaning, you can get something via FDL and redistribute via GPL). From a quick glance of gnu.org, that doesn't seem to be the case, sorry. But my point was the other way around - to make lore *more* restrictive (GPL), so that people can't run wild with it. So maybe dual-license documentation on FDL and GPL - which in practice means the documentation distributed on the release tarball turns up GPLed ;-) > I am not convinced the boundaries between these two catergories are > always clear. I don't agree here, though. (Or you misunderstand me.) By "documentation" I mean technical. Referring specifically to the wiki, you'll notice there is a "fact" section and a "lore" section. When I say "documentation" (or "fact"), I'm referring to about-game material, whereas "lore" is in-game material. The boundaries are pretty clear. (Ok, you can argue about stuff like formulae. Are these technical, or in-game? :-P Well, in this case, I'd consider them "lore", because they *can* make sense in-game.) best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. -- http://www.exoweb.net/ mailto:lalo@exoweb.net GNU: never give up freedom http://www.gnu.org/ From mwedel at sonic.net Mon Sep 5 23:27:51 2005 From: mwedel at sonic.net (Mark Wedel) Date: Mon Sep 5 23:28:43 2005 Subject: [crossfire] Server map redo: movement types In-Reply-To: <43179C39.6060606@sympatico.ca> References: <20050831164654.WJFX2134.tomts48-srv.bellnexxia.net@[209.226.175.82]> <43168BC3.8090104@sonic.net> <43179C39.6060606@sympatico.ca> Message-ID: <431D1AC7.9000202@sonic.net> Todd Mitchell wrote: >> And the issue isn't what movement types the player can potentially do >> (jump for example) - going back to the original question was 'what to >> do if the players movement type is MOVE_WALK | MOVE_FLY). > > > I would think they would only be able to have one movement type at a > time. If they are flying they can't pick up things on the ground or > trigger buttons and the like. If they are walking then they aren't > flying... But codewise, this gets trickier or we have to special case walking. as I think I described, move types would be similiar to attack types - all items that are equipped (which can include skills) with a movement type are OR'd together to determine what movement types the player is currently capable of. Thus, presuming no race has its actual movement type as fly (eg, its a skill you need to apply), everyone would just walk by default. But when you did enable fly, your movement type would be MOVE_WALK | MOVE_FLY (because move_walk is a native movemetn type for everyone). That said, walk/swim/fly could all be skills, or skill like things you have to select. However, that gets into A) auto apply the appropriate movement skill or B) having the player do it all the time. IMO, it is actually easier to let the movement types stack up. In the case of MOVE_SWIM | MOVE_WALK, it makes it very easy - the transition is automatic - you walk into the water, and start swimming, or swim out and start walking. But that is also a simpler case, in that the two are mutually exclusive (can't really walk where we swim, and vice versa). But one thought is to make these all skills. Thus, to use the skill swimming may require nothing on your arms (eg, the body_.. fields for swimming require both arms). Walking could also be done as a skill - in this way, you'd only have one movement type at a time. The problem is this might get into weird interactions with other skills, eg, if we go with attacking, your skill is no longer walking but melee weapons or something, and have to go back to walking. And unless the walking skill actually means something (would be weird to get exp in it, but one could see using it for different base movement speeds?) I'm not sure if it adds much. But as said, the weirdness here is the fly/walk combo, since you could use either over the same terrain. And unless/until there is a disadvantage in flying, it'd seem you'd want to fly almost all the time, so auto selection there would be odd. > agreed - if you wade in to the water you should assume you would start > swimming. If you couldn't swim however I think you should stop and not > automatically start flying. One could argue that given the choice, you'd almost always want to fly over water than swim anyways. One could also see some switch like 'auto_move selection' or something. But ideally, I want to keep it simple so that isn't needed. And in the case of swimming, switching automatically could possibly unequip items, making it pretty unpopular (think about cases where there may be small amounts of water in dungeons near nasty monsters). Maybe explicitly requiring the player to use the method of movement is what needs to be done. Thus may be needed just for sanity sake - player loaded down accidentally running into the lake and drowning would be pretty annoying. And putting in a special case where if movement type is something beyond walk, we strip that out wouldn't be that hard to do, unless we want to make walking a basic skill. > >> Just a note, that right now, dragons can fly unlimited distances (and >> boots work forever) - you can't get over oceans, but can fly over >> terrain that doesn't actually block passage (which is only high >> mountain) and should be avoid all slow move penalties since it doesn't >> apply to flying. >> >> So the only real change is possilibility of flying over water. But >> that has to be looked at for other reasons, notably that it would open >> up the map a lot. > > > Yes, however if flying is limited what happens if you run out of juice > while over a terrain you can't pass - I guess in most cases you would be > stuck untill you can rest and fly again but over say water... do you > take damage? Drown? Well, depends on terrain I'd think. In cases of impassable terrain (high mountains or something?), perhaps take damage on landing, but once you have landed, should be OK. If you land in the water, you should perhaps drown - if you're flying over dangerous areas, in a sense, your doing it at your own risk. If fatigue is added, that would be a similiar danger to swimming. From mwedel at sonic.net Mon Sep 5 23:37:32 2005 From: mwedel at sonic.net (Mark Wedel) Date: Mon Sep 5 23:38:43 2005 Subject: [crossfire] fatigue In-Reply-To: References: <43155735.7000609@sonic.net> <200508312216.24469.tchize@myrealbox.com> <43168E55.6070809@sonic.net> Message-ID: <431D1D0C.1050609@sonic.net> While mental fatigue makes realistic sense, as said, for a playable game, I'm not sure it adds anything. If I have to rest my character for 10 minutes every hour, that is just annoying and doesn't really add much. I just put my character in a safe place and go off and do something else. Or it means I sit my character around for a while before I save or whatever else. The idea of physical fatigue is being discussed as a balancing issue (eg, shouldn't be able to fly or swim all day). I think there is some need to balance that, and also apply same rule to other physical activities in the game. I don't recall there being any issue of balance with characters being able to stay awake all the time, and thus, I don't see mental fatigue as something that is really needing fixing right now. From lalo at exoweb.net Tue Sep 6 02:08:36 2005 From: lalo at exoweb.net (Lalo Martins) Date: Tue Sep 6 02:10:46 2005 Subject: [crossfire] Re: Server map redo: movement types In-Reply-To: <431D1AC7.9000202@sonic.net> References: <20050831164654.WJFX2134.tomts48-srv.bellnexxia.net@[209.226.175.82]> <43168BC3.8090104@sonic.net> <43179C39.6060606@sympatico.ca> <431D1AC7.9000202@sonic.net> Message-ID: And so says Mark Wedel on 06/09/05 12:27... > In cases of impassable terrain (high mountains or something?), perhaps > take damage on landing, but once you have landed, should be OK. If you're flying over impassable high mountains, and run out of juice, you crash-land (taking damage). Then, if you survive AND the eight squares around you are all impassable, sorry, you're stuck. Get some rest till you can fly again, or cast town portal, or word of recall, or dimension door. That sounds very reasonable to me, it's what I would expect; it's what happens on reality, except for the spell stuff, of course. (What happens to flying creatures. Duh.) On the other hand, it would probably be cool if one player was able to carry another. Then you could do a "rescue". (Not to mention quite a bit of other uses.) best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. -- http://www.exoweb.net/ mailto:lalo@exoweb.net GNU: never give up freedom http://www.gnu.org/ From mwedel at sonic.net Tue Sep 6 02:19:19 2005 From: mwedel at sonic.net (Mark Wedel) Date: Tue Sep 6 02:20:45 2005 Subject: [crossfire] LOS and lighting map redo In-Reply-To: <43140D09.9070700@sonic.net> References: <43140D09.9070700@sonic.net> Message-ID: <431D42F7.7070408@sonic.net> On thinking this over some more, there is also another complication/issue with lighting. As said in the original message, instead of the server communicating darkness of each space, it communicates the location of the lightsources and color of those sources. However, what do we do when the source of the light is not visible to the player? One could envision something like long hallway, with light pouring into the hallway form the rooms that branch off from it, but one can not see those sources. To me, there are really 3 options here: 1) Only send info on light sources that are on spaces player can see. This is safest and isn't hard to do, problem is that it is probably mostly useless (vast majority of lightsources will not be visible to player). 2) Send info for lightsources that illuminate any spaces player sees. While this gives information away, one could argue it is a pretty minor leak (EG, given how current client communicates light levels, once could potentially figure out where light sources are based on illumination of different spaces). It does complicate things some, because we need to record location of light sources that illuminate on the space - however, that probably isn't actually that hard, since we'd have to go by 1 by 1 for the light sources and see what they illuminate anyways - the issue here is that we now need to record that info (light source and 10,10 is illuminating this space). 3) Send all light sources for map area, regardless if visible or not. Easiest to do, but starts to give away a fair amount of informatin, especially for non static light sources (hmmm - a lot of light behind that wall - must be something there) - probably not a good option. -- Also, one other complication to this plan is the fact that light sources outside the viewable map would have to be sent. And the brighter the source of light, the more spaces outside the map to be sent. For example, imagine a wilderness area of grass at night (all dark). Another player carrying a super bright latern (glow radius 15) is approaching you. While he is 14 spaces from appearing on the map, his latern starts illuminating spaces youcan see. So it means we need to send info for a light sources that is 14 spaces from where you can see. This can be adjusted a bit based on how bright we want the maximum light sources. But it also adds some extra complication for the client beyond big image support - it now has to go out quite a ways looking for light sources. Likewise, this also means the protocol needs some support for negative coordinates (player could be approach from west after all). From mwedel at sonic.net Tue Sep 6 02:25:11 2005 From: mwedel at sonic.net (Mark Wedel) Date: Tue Sep 6 02:26:45 2005 Subject: [crossfire] Re: Server map redo: movement types In-Reply-To: References: <20050831164654.WJFX2134.tomts48-srv.bellnexxia.net@[209.226.175.82]> <43168BC3.8090104@sonic.net> <43179C39.6060606@sympatico.ca> <431D1AC7.9000202@sonic.net> Message-ID: <431D4457.8010503@sonic.net> Lalo Martins wrote: > And so says Mark Wedel on 06/09/05 12:27... > >> In cases of impassable terrain (high mountains or something?), perhaps >>take damage on landing, but once you have landed, should be OK. > > > If you're flying over impassable high mountains, and run out of juice, > you crash-land (taking damage). Then, if you survive AND the eight > squares around you are all impassable, sorry, you're stuck. Get some > rest till you can fly again, or cast town portal, or word of recall, or > dimension door. Yes - I agree. > On the other hand, it would probably be cool if one player was able to > carry another. Then you could do a "rescue". (Not to mention quite a > bit of other uses.) Arguably not really hard to do. The biggest issue right now is that players/monsters blocking spaces is only way to attack them (something there, you have to attack it). One could make a strong case that at least with flying, people on the ground shouldn't block you - you're flying over them after all. I imagine the best way to handle carrying others would be some special command (grab ... and release ...) or something - you could even use it on adjacant people and that moves them to your space. Perhaps as a way to make sure it is a willing thing, only allow it if of the same party. I'd think multiple people on the same space also becomes an issue if/when transportation objects are added (boats being the main one) - should certainly be reasonable that several people can get in one of the bigger boats (only one would be the captain - presumably the first one there). When that type of code is added, having players carry other playes would presuambly re-use it - the person carying the other is acting as the transportation objects - just in this case, the player being carried does have any choice of where he is going. From tchize at myrealbox.com Tue Sep 6 02:34:32 2005 From: tchize at myrealbox.com (tchize) Date: Tue Sep 6 02:33:54 2005 Subject: [crossfire] fatigue In-Reply-To: <431D1D0C.1050609@sonic.net> References: <43155735.7000609@sonic.net> <431D1D0C.1050609@sonic.net> Message-ID: <200509060934.33177.tchize@myrealbox.com> Le Mardi 6 Septembre 2005 06:37, Mark Wedel a ?crit : > > While mental fatigue makes realistic sense, as said, for a playable game, I'm > not sure it adds anything. > It adds, but this is already taken into account, in a smart disguised way. > If I have to rest my character for 10 minutes every hour, that is just > annoying and doesn't really add much. I just put my character in a safe place > and go off and do something else. > > Or it means I sit my character around for a while before I save or whatever else. > > The idea of physical fatigue is being discussed as a balancing issue (eg, > shouldn't be able to fly or swim all day). I think there is some need to > balance that, and also apply same rule to other physical activities in the game. Agree: physical activity, right now, is the only main component not needing recharging. I think we can consider mental fatigue is already taken into account in the fact you need to reload your mana or pray for your grace to increase (btw, i think grace increases too easily for now, it's too easy to cast then prayer spell than pray 3 seconds then recast. This is non sense :p, in role playing praying take at least 1/2 hour on games like add :D) > > I don't recall there being any issue of balance with characters being able to > stay awake all the time, and thus, I don't see mental fatigue as something that > is really needing fixing right now. Well, may i speak about a particular player asking Mids to restore a backup of his character because he felt aslept on keyboard and died of starvation the whole night, losing about 50 levels :p > > > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > > From mwedel at sonic.net Tue Sep 6 02:38:53 2005 From: mwedel at sonic.net (Mark Wedel) Date: Tue Sep 6 02:40:45 2005 Subject: [crossfire] map redo: more layers. In-Reply-To: <200508311650.01037.tchize@myrealbox.com> References: <431559CC.1090704@sonic.net> <200508311650.01037.tchize@myrealbox.com> Message-ID: <431D478D.30102@sonic.net> tchize wrote: >> The trickier part in all this is how to condense it down for the 3 objects for >>old protocol. May idea would be to basically set up a table which says order of >>objects you are looking at. The order would always be the same, but it may be >>something like: > > > why adapt old protocol, keep it's old behaviour (floor + 2 topmost objects) I'd have to look, but I think the old display logic has a more complicated logic than that (eg, things like monsters have pretty high importance in the display order). The old system basically had 3 layers: 1: Floor 2: Most important object, typically determined by visiblity value or other critier. 3: top object. The problem with just taking the floor + 2 top objects is a couple spells now obscure all monsters beneath it, which may not be a good thing. I suppose that can be used as a first pass to see how things look, and if it breaks a lot of stuff, work on refining i. > may i suggest static things like buildings/floor be sent once and for all to client Static things in general will only be sent once - the new system should make that more consistent - one problem with the old system is things can 'jump' layers depending on other objects. But if you mean send all static data for the map once, that creates a few problems: 1) Imposes even more lag when hopping maps, as a potentially very large burst of information needs to be sent. 2) potentially gives away map information (I'm ignoring the issue that most all maps are available for download - one could envision a server running private maps). 3) Gets trickier for the outdoor world maps IF you mean we only send that building once, then we need to track somehow we don't need to sent it again (I imagine the case you're talking about here is player steps to side so portion of map is no longer visible, then steps back that direction so it is again). I suppose we can track that player has seen that space before. However, in both cases, I think the bandwidth savings by doing this are relative trivial - granted, a player stepping back and forth constantly will cause a row to be redrawn, but if players want to abuse stuff, they can hop back and forth between maps. > Also, think about integrating ground animations in protocol (i mean, do not send > sea each time it change, better tell client there is an animated object on that layer) This is reasonable, but I think we need to establish 'constant' animations. What that means is that this is the animation sequence and this is the speed and will always be the speed (which for things like water is true). Then, we could send that animation info once, and then when we get such an animation, just send the fact is is constant animation XYZ. If we have to send animation speed/phase for such objects, this is less a gain. And if we try to do it for monsters, I think it adds a lot of complication for what once again may not be a lot of gain. From lalo at exoweb.net Tue Sep 6 03:30:34 2005 From: lalo at exoweb.net (Lalo Martins) Date: Tue Sep 6 03:32:46 2005 Subject: [crossfire] Re: LOS and lighting map redo In-Reply-To: <431D42F7.7070408@sonic.net> References: <43140D09.9070700@sonic.net> <431D42F7.7070408@sonic.net> Message-ID: And so says Mark Wedel on 06/09/05 15:19... > 3) Send all light sources for map area, regardless if visible or not. > Easiest to do, but starts to give away a fair amount of informatin, > especially for non static light sources (hmmm - a lot of light behind > that wall - must be something there) - probably not a good option. there are two simple fixes for that. with CURRENT CODE (lighting is calculated on server side): Right now, a square having an object that 'blocksview', is as lit as the lightest "side". IMHO, it should instead be as lit as the "darkest" side (eg, it blocks light *before* the square itself is drawn). With smoothing, it wouldn't even look bad. If you want to get really fancy, you can make special cases when the darker side is no_pass or void. with PROPOSED NEW CODE (lighting on client side): even better ;-) A cell with a 'blocksview' object should be lit according to the side(s) you're viewing it from exclusively. So even if there is a light source behind it, the client should ignore it, since it's "behind" the "wall", and therefore, by game logic, it's "view" is "blocked". (The "(s)" above means, if you're standing on a doorway, between two rooms with lights in their centers, then the wall just beside you will be lighted exactly as it would be now, because you can "see" both light sources.) A separate concern is that the server would need to send not only the light sources, but also objects that block your view. But sending the actual objects can give space for cheating. One way to get around that is to send fake objects of a new client type, let's call it the SOMETHING (meaning, it's something that 'blocksview', but it's none of your business what exactly it is). But then, in practice, you'd be sending the footprint to the whole map. An alternative is to do just that - send a completely separate map structure, the "lightmap" (term borrowed from 3d engines), which for each cell, says only how much light they give out, and how much light/view they block. Then leave actual lighting algos to the client. That obviously still allows cheating, though :-( but I don't think that's terribly important - seeing the footprint of your map is not the smartest cheating you can do, and if you really want to, you can just download the maps and open them in the editor. best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. -- http://www.exoweb.net/ mailto:lalo@exoweb.net GNU: never give up freedom http://www.gnu.org/ From alex_sch at telus.net Tue Sep 6 08:28:35 2005 From: alex_sch at telus.net (Alex Schultz) Date: Tue Sep 6 08:28:49 2005 Subject: [crossfire] LOS and lighting map redo In-Reply-To: <431D42F7.7070408@sonic.net> References: <43140D09.9070700@sonic.net> <431D42F7.7070408@sonic.net> Message-ID: <431D9983.9050101@telus.net> Mark Wedel wrote: > > On thinking this over some more, there is also another > complication/issue with lighting. > > As said in the original message, instead of the server communicating > darkness of each space, it communicates the location of the > lightsources and color of those sources. > > However, what do we do when the source of the light is not visible to > the player? One could envision something like long hallway, with > light pouring into the hallway form the rooms that branch off from it, > but one can not see those sources. > > To me, there are really 3 options here: > > 1) Only send info on light sources that are on spaces player can see. > This is safest and isn't hard to do, problem is that it is probably > mostly useless (vast majority of lightsources will not be visible to > player). > > 2) Send info for lightsources that illuminate any spaces player sees. > While this gives information away, one could argue it is a pretty > minor leak (EG, given how current client communicates light levels, > once could potentially figure out where light sources are based on > illumination of different spaces). It does complicate things some, > because we need to record location of light sources that illuminate on > the space - however, that probably isn't actually that hard, since > we'd have to go by 1 by 1 for the light sources and see what they > illuminate anyways - the issue here is that we now need to record that > info (light source and 10,10 is illuminating this space). > > 3) Send all light sources for map area, regardless if visible or not. > Easiest to do, but starts to give away a fair amount of informatin, > especially for non static light sources (hmmm - a lot of light behind > that wall - must be something there) - probably not a good option. Personally I think that option 2 is the best choice, though it's logic would be somewhat more difficult to code and arguably could give some information away. I think that the information given away in this way is rather minimal and unimportant. I think that option 3 would give away too much information, and option 1 would cause rather ugly display issues in many cases. > Likewise, this also means the protocol needs some support for negative > coordinates (player could be approach from west after all). I don't think this would be a major issue, just send a signed integer instead of unsigned. Also, though this is somewhat of a different topic, I think with these changes, would be a good time to try again at implimenting additive lighting: I am thinking the main advantage of additive lighting, is how it fixes display uglieness when a player who is lit up steps on a lamp, causing the overall brightness in the area to drasticly decrease. I think a good solution would be to do additive lighting with this restriction: add all no_pickup objects, and the brightest other object ontop of them. Alex Schultz From delbd at oma.be Tue Sep 6 05:04:24 2005 From: delbd at oma.be (David Delbecq) Date: Tue Sep 6 12:46:42 2005 Subject: [crossfire] map redo: more layers. In-Reply-To: <431D478D.30102@sonic.net> References: <431559CC.1090704@sonic.net> <200508311650.01037.tchize@myrealbox.com> <431D478D.30102@sonic.net> Message-ID: <200509061204.24482.delbd@oma.be> Le Mardi 6 Septembre 2005 09:38, Mark Wedel a ?crit : > tchize wrote: > > >> The trickier part in all this is how to condense it down for the 3 objects for > >>old protocol. May idea would be to basically set up a table which says order of > >>objects you are looking at. The order would always be the same, but it may be > >>something like: > > > > > > why adapt old protocol, keep it's old behaviour (floor + 2 topmost objects) > > I'd have to look, but I think the old display logic has a more complicated > logic than that (eg, things like monsters have pretty high importance in the > display order). > > The old system basically had 3 layers: > 1: Floor > 2: Most important object, typically determined by visiblity value or other critier. > 3: top object. > > The problem with just taking the floor + 2 top objects is a couple spells now > obscure all monsters beneath it, which may not be a good thing. I suppose that > can be used as a first pass to see how things look, and if it breaks a lot of > stuff, work on refining i. You don't get it, i meant, use the old code for that :) It's working so why change it. Your problem is to get old client to receive old style message. Aswar is easy, call old functions :) > > > > may i suggest static things like buildings/floor be sent once and for all to client > > Static things in general will only be sent once - the new system should make > that more consistent - one problem with the old system is things can 'jump' > layers depending on other objects. > > But if you mean send all static data for the map once, that creates a few > problems: > 1) Imposes even more lag when hopping maps, as a potentially very large burst of > information needs to be sent. Am not sure about it. A display of 25x25 client side currently means upon entering, at a rate of 1.5 object/square a send of 938 data informations. Go left 6 steps, go right 6 steps you send again 12 rows, that is 450 data object (containing face information mainly). Total 1388. Exit map (to heal for example) and renter it twice: +1876 total to enter a map, fight a bit, get out to heal, get in, get out to heal, get in: 3274 objects sent. Now if map is 50x50 (map are not usually bigger), and assuming only floor is send separately, you get: 2500 floor object send upon first enter. 313 dynamic object sent move left move right 6 steps: 150 exit enter twice: 616 additionnal information send total: 3579 the gap between the 2 ways will reduce as long as player use the map. Also as floor level is most of the time made of block of same arches, it will gain to get some basic compression :) > 2) potentially gives away map information (I'm ignoring the issue that most all > maps are available for download - one could envision a server running private maps). if a set of map need not to be downloaded a simple thing is to have a map flag 'this map is purely dynamic' then the computation of 'static parts of map' will end with a list of zero items. > 3) Gets trickier for the outdoor world maps > Not so much imho. Just let the client display 'several maps' at the same time. > IF you mean we only send that building once, then we need to track somehow we > don't need to sent it again (I imagine the case you're talking about here is > player steps to side so portion of map is no longer visible, then steps back > that direction so it is again). I suppose we can track that player has seen > that space before. Tracking is easy. For each map, extract 'static information', do some checksum on it. When a static information change (like is case from time to time using weather system) obviously checksum changes. 2 things happens: - players present in map simply recevie the new object like any dynamic object, but considering the layer they are in, the client can detect easily this was the place of a static object, then client replace static object with a new static object - for player outside, nothing special happen until they enter the map. When this happens, server compare checksums and decide client need to received again the static list for that map. What is interresting is, client can cache data even after disconnect! When client reconnect again it could tell to server "Hello, here is the list of mapkeys i support and associated checksums". Also, mapkeys could be quite small (24bits serial) if they have only a meaning during server runtime (which is supposed to be longer than client runtime, so caching could be used at least for a few days). If we limit cache to 1000 last seen maps and assume a 56bits checksum this brings only 10k to connecting protocol (last time i checked server badnwidth use it was about 3K/second while running and am still convinced static caching+client side animation can improve this a lot. Perhaps hacking a server to count what has been send as map data during game and what could have been send if static was send only once could be a good idea. But the problem is static animations which will get in the way of stats (static part will change while if we let animations handled client side, they don' t need to be resent). Deactivating animation code could be a good way to do check it (and would be partial as in both protocol, face don't need to beresend :). > > However, in both cases, I think the bandwidth savings by doing this are > relative trivial - granted, a player stepping back and forth constantly will > cause a row to be redrawn, but if players want to abuse stuff, they can hop back > and forth between maps. > > > > Also, think about integrating ground animations in protocol (i mean, do not send > > sea each time it change, better tell client there is an animated object on that layer) > > This is reasonable, but I think we need to establish 'constant' animations. > What that means is that this is the animation sequence and this is the speed and > will always be the speed (which for things like water is true). > > Then, we could send that animation info once, and then when we get such an > animation, just send the fact is is constant animation XYZ. > > If we have to send animation speed/phase for such objects, this is less a > gain. And if we try to do it for monsters, I think it adds a lot of > complication for what once again may not be a lot of gain. > > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > > -- David Delbecq Royal Meteorological Institute of Belgium - Is there life after /sbin/halt -p? From mikeeusaaa at yahoo.com Tue Sep 6 13:29:30 2005 From: mikeeusaaa at yahoo.com (Mitch Obrian) Date: Tue Sep 6 13:30:52 2005 Subject: [crossfire] map redo: more layers. In-Reply-To: <431D478D.30102@sonic.net> Message-ID: <20050906182930.31500.qmail@web61019.mail.yahoo.com> Yay more layers :D and maybe some optimization :D. Just keep it that the player can't cheat as we have it now :) --- Mark Wedel wrote: > tchize wrote: > > >> The trickier part in all this is how to condense > it down for the 3 objects for > >>old protocol. May idea would be to basically set > up a table which says order of > >>objects you are looking at. The order would > always be the same, but it may be > >>something like: > > > > > > why adapt old protocol, keep it's old behaviour > (floor + 2 topmost objects) > > I'd have to look, but I think the old display > logic has a more complicated > logic than that (eg, things like monsters have > pretty high importance in the > display order). > > The old system basically had 3 layers: > 1: Floor > 2: Most important object, typically determined by > visiblity value or other critier. > 3: top object. > > The problem with just taking the floor + 2 top > objects is a couple spells now > obscure all monsters beneath it, which may not be a > good thing. I suppose that > can be used as a first pass to see how things look, > and if it breaks a lot of > stuff, work on refining i. > > > > may i suggest static things like buildings/floor > be sent once and for all to client > > Static things in general will only be sent once - > the new system should make > that more consistent - one problem with the old > system is things can 'jump' > layers depending on other objects. > > But if you mean send all static data for the map > once, that creates a few > problems: > 1) Imposes even more lag when hopping maps, as a > potentially very large burst of > information needs to be sent. > 2) potentially gives away map information (I'm > ignoring the issue that most all > maps are available for download - one could envision > a server running private maps). > 3) Gets trickier for the outdoor world maps > > IF you mean we only send that building once, then > we need to track somehow we > don't need to sent it again (I imagine the case > you're talking about here is > player steps to side so portion of map is no longer > visible, then steps back > that direction so it is again). I suppose we can > track that player has seen > that space before. > > However, in both cases, I think the bandwidth > savings by doing this are > relative trivial - granted, a player stepping back > and forth constantly will > cause a row to be redrawn, but if players want to > abuse stuff, they can hop back > and forth between maps. > > > > Also, think about integrating ground animations in > protocol (i mean, do not send > > sea each time it change, better tell client there > is an animated object on that layer) > > This is reasonable, but I think we need to > establish 'constant' animations. > What that means is that this is the animation > sequence and this is the speed and > will always be the speed (which for things like > water is true). > > Then, we could send that animation info once, and > then when we get such an > animation, just send the fact is is constant > animation XYZ. > > If we have to send animation speed/phase for such > objects, this is less a > gain. And if we try to do it for monsters, I think > it adds a lot of > complication for what once again may not be a lot of > gain. > > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From alex_sch at telus.net Tue Sep 6 14:17:25 2005 From: alex_sch at telus.net (Alex Schultz) Date: Tue Sep 6 14:20:53 2005 Subject: [crossfire] Re: LOS and lighting map redo References: <43140D09.9070700@sonic.net> <431D42F7.7070408@sonic.net> <431D9983.9050101@telus.net> Message-ID: Alex Schultz writes: > I think a good solution would be to do additive lighting with this > restriction: add all no_pickup objects, and the brightest other object > ontop of them. I'll revise what I said: all no_pickup objects, the brightest pickupable non- living object, and the brightest living object (though usually, there should only be one living oject on a tile) From alex_sch at telus.net Tue Sep 6 14:30:23 2005 From: alex_sch at telus.net (Alex Schultz) Date: Tue Sep 6 14:34:53 2005 Subject: [crossfire] Re: LOS and lighting map redo References: <43140D09.9070700@sonic.net> <431D42F7.7070408@sonic.net> <431D9983.9050101@telus.net> Message-ID: Alex Schultz writes: > (snip) One other thing to add to what I was saying: On the technical side, I think that a reletively easy way to accomplish #2, would be, when the server is calculating LOS for squares, it should store all light sources that affect each square as a sort of list in the square. This way, all that the server has to do to check which light sources to send, it just needs to look at the squares that players have *some* vision of, of and concat (while ignoring duplicates) the light sources in the lists for those squares. This method may take more memory, but IMHO it is a easy to code and gives what is in my opinion the 'proper' results, and so far as I see should run fast in runtime. Alex Schultz From temitchell at sympatico.ca Tue Sep 6 19:04:58 2005 From: temitchell at sympatico.ca (Todd Mitchell) Date: Tue Sep 6 19:03:37 2005 Subject: [crossfire] Server map redo: movement types In-Reply-To: <431D1AC7.9000202@sonic.net> References: <20050831164654.WJFX2134.tomts48-srv.bellnexxia.net@[209.226.175.82]> <43168BC3.8090104@sonic.net> <43179C39.6060606@sympatico.ca> <431D1AC7.9000202@sonic.net> Message-ID: <431E2EAA.2070105@sympatico.ca> Mark Wedel wrote: > One could argue that given the choice, you'd almost always want to > fly over water than swim anyways. I see that as an issue in itself - flying then becomes the preferred movement type. Now maybe if you were easier to hit with missiles when flying and/or also easier to push around (knockback code has modifier for friction I believe) it might be more attractive to swim sometimes. If you can't pick up things, are easier to hit and can get blow about then flying is a bit more balanced. If you got some cover when swimming it might make it even better. > One could also see some switch like 'auto_move selection' or > something. But ideally, I want to keep it simple so that isn't > needed. And in the case of swimming, switching automatically could > possibly unequip items, making it pretty unpopular (think about cases > where there may be small amounts of water in dungeons near nasty > monsters). > > Maybe explicitly requiring the player to use the method of movement > is what needs to be done. Thus may be needed just for sanity sake - > player loaded down accidentally running into the lake and drowning > would be pretty annoying. And putting in a special case where if > movement type is something beyond walk, we strip that out wouldn't be > that hard to do, unless we want to make walking a basic skill. Well this was my point for flying. Mistakenly flying out to sea and drowning would be pretty crappy. So either you walk into water and unequip items in hand automatically or you are blocked from entering water until you unequip your items and switch to swimming skill... Having players have to choose their movement type is certainly an option. It avoids a lot of problems and allows for some interesting map puzzles where players could choose to swim in a sand lake or climb a invisible wall. It would also allow them to try (and fail) to swim in grass or climb a lake. > In cases of impassable terrain (high mountains or something?), > perhaps take damage on landing, but once you have landed, should be OK. > > If you land in the water, you should perhaps drown - if you're flying > over dangerous areas, in a sense, your doing it at your own risk. If > fatigue is added, that would be a similiar danger to swimming. Yes in most cases (like mountains) you would simply be stuck until you could fly again. If over shallow water you might be able to swim. If flying over deep water you would be in trouble - this is a good thing however I think - it means you better be careful flying over deep water. Flying over hostile terrain you would take the appropriate damage each turn until you could get off the terrain. From alex_sch at telus.net Tue Sep 6 19:15:29 2005 From: alex_sch at telus.net (Alex Schultz) Date: Tue Sep 6 19:15:39 2005 Subject: [crossfire] Server map redo: movement types In-Reply-To: <431E2EAA.2070105@sympatico.ca> References: <20050831164654.WJFX2134.tomts48-srv.bellnexxia.net@[209.226.175.82]> <43168BC3.8090104@sonic.net> <43179C39.6060606@sympatico.ca> <431D1AC7.9000202@sonic.net> <431E2EAA.2070105@sympatico.ca> Message-ID: <431E3121.7070503@telus.net> Todd Mitchell wrote: > Mark Wedel wrote: > >> One could argue that given the choice, you'd almost always want to >> fly over water than swim anyways. > > I see that as an issue in itself - flying then becomes the preferred > movement type. Now maybe if you were easier to hit with missiles when > flying and/or also easier to push around (knockback code has modifier > for friction I believe) it might be more attractive to swim > sometimes. If you can't pick up things, are easier to hit and can get > blow about then flying is a bit more balanced. If you got some cover > when swimming it might make it even better. Actually, I remember checking at that friction code once, it already does account for flying if I remember correctly. > Yes in most cases (like mountains) you would simply be stuck until you > could fly again. If over shallow water you might be able to swim. If > flying over deep water you would be in trouble - this is a good thing > however I think - it means you better be careful flying over deep > water. Flying over hostile terrain you would take the appropriate > damage each turn until you could get off the terrain. What do you mean by hostile? Do you mean like flying over a goblin or something? Alex Schultz From temitchell at sympatico.ca Tue Sep 6 21:14:09 2005 From: temitchell at sympatico.ca (Todd Mitchell) Date: Tue Sep 6 21:13:38 2005 Subject: [crossfire] Server map redo: movement types In-Reply-To: <431E3121.7070503@telus.net> References: <20050831164654.WJFX2134.tomts48-srv.bellnexxia.net@[209.226.175.82]> <43168BC3.8090104@sonic.net> <43179C39.6060606@sympatico.ca> <431D1AC7.9000202@sonic.net> <431E2EAA.2070105@sympatico.ca> <431E3121.7070503@telus.net> Message-ID: <431E4CF1.4030102@sympatico.ca> Alex Schultz wrote: > > What do you mean by hostile? Do you mean like flying over a goblin or > something? I meant landing on terrain that causes damage like cold or fire damage - also for things like wasteland which or very high mountains which might do damage too. I don't think you should be able to land on a goblin, you would bounce to the nearest free space no? - it does raise the question what happens if you run out of energy and drop into a crowded room where there is no free space... From mwedel at sonic.net Wed Sep 7 00:49:58 2005 From: mwedel at sonic.net (Mark Wedel) Date: Wed Sep 7 00:51:42 2005 Subject: [crossfire] map redo: more layers. In-Reply-To: <200509061204.24482.delbd@oma.be> References: <431559CC.1090704@sonic.net> <200508311650.01037.tchize@myrealbox.com> <431D478D.30102@sonic.net> <200509061204.24482.delbd@oma.be> Message-ID: <431E7F86.2030200@sonic.net> David Delbecq wrote: > Le Mardi 6 Septembre 2005 09:38, Mark Wedel a ?crit : > > You don't get it, i meant, use the old code for that :) It's working so why change it. > Your problem is to get old client to receive old style message. Aswar is easy, call > old functions :) Yes, but right now if you look at MapSpace function, it has definitions for what is on the different layers, and is coded for those 3 layers. If we go to 10 layers, I don't want to have to have something like: struct MapSpace { object *old_faces[OLD_MAP_LAYERS] object *faces[MAP_LAYERS] } As that is just begging to get cleaned up at a later point. I'd much rather just have the new data, and have the send code pull out the appropriate information instead of having those double arrays (the new code also in a sense simplifies the update_position() function). So what probably really happens is that to some degree, the logic in update_position that determines the faces gets moved to the client logic. At some point in the future, support for this old protocl method goes away. From mwedel at sonic.net Wed Sep 7 01:06:43 2005 From: mwedel at sonic.net (Mark Wedel) Date: Wed Sep 7 01:07:42 2005 Subject: [crossfire] Re: LOS and lighting map redo In-Reply-To: References: <43140D09.9070700@sonic.net> <431D42F7.7070408@sonic.net> Message-ID: <431E8373.806@sonic.net> Lalo Martins wrote: > And so says Mark Wedel on 06/09/05 15:19... > >>3) Send all light sources for map area, regardless if visible or not. >>Easiest to do, but starts to give away a fair amount of informatin, >>especially for non static light sources (hmmm - a lot of light behind >>that wall - must be something there) - probably not a good option. > > > there are two simple fixes for that. > > with CURRENT CODE (lighting is calculated on server side): > > Right now, a square having an object that 'blocksview', is as lit as > the lightest "side". IMHO, it should instead be as lit as the > "darkest" side (eg, it blocks light *before* the square itself is > drawn). > > With smoothing, it wouldn't even look bad. > > If you want to get really fancy, you can make special cases when the > darker side is no_pass or void. The problem with that logic is now walls are dark (they aren't illuminated). So that doesn't work very well. While sending which spaces block view actually isn't hard to do (Easy enough to put it in the new protocol - a list of flags for the space for example) , there are still complications. I'd have to look at all the walls, but I think there are some number that only lighting have of would not look correct (due to perspective, or just how things line up). IMO, the best fix for this is to use double width walls in maps - then, each side could see the entire wall, without the light leaking to the other side. Trying to figure out which side the light is coming from now means that the light has to be individually figured for each player - this would add a non trivial amount of cpu (although may be possible with simple coordinate checking - I'd have to thinkg about that more) From mwedel at sonic.net Wed Sep 7 01:11:01 2005 From: mwedel at sonic.net (Mark Wedel) Date: Wed Sep 7 01:11:43 2005 Subject: [crossfire] Server map redo: movement types In-Reply-To: <431E4CF1.4030102@sympatico.ca> References: <20050831164654.WJFX2134.tomts48-srv.bellnexxia.net@[209.226.175.82]> <43168BC3.8090104@sonic.net> <43179C39.6060606@sympatico.ca> <431D1AC7.9000202@sonic.net> <431E2EAA.2070105@sympatico.ca> <431E3121.7070503@telus.net> <431E4CF1.4030102@sympatico.ca> Message-ID: <431E8475.7050206@sonic.net> Todd Mitchell wrote: > Alex Schultz wrote: > >> >> What do you mean by hostile? Do you mean like flying over a goblin or >> something? > > > I meant landing on terrain that causes damage like cold or fire damage - > also for things like wasteland which or very high mountains which might > do damage too. I don't think you should be able to land on a goblin, > you would bounce to the nearest free space no? - it does raise the > question what happens if you run out of energy and drop into a crowded > room where there is no free space... How often does that really happen? One could argue the need for a ceiling height parameter, or to disallow flying indoors (ceiling not high enough). But that would require updating a lot of maps. Just a note, case you describe right now actually isn't that different when you enter a map saturated with monsters - you will often just be put on top of the monster. From mwedel at sonic.net Wed Sep 7 01:14:26 2005 From: mwedel at sonic.net (Mark Wedel) Date: Wed Sep 7 01:15:42 2005 Subject: [crossfire] fatigue In-Reply-To: <200509060934.33177.tchize@myrealbox.com> References: <43155735.7000609@sonic.net> <431D1D0C.1050609@sonic.net> <200509060934.33177.tchize@myrealbox.com> Message-ID: <431E8542.9050403@sonic.net> tchize wrote: > Le Mardi 6 Septembre 2005 06:37, Mark Wedel a ?crit : > Agree: physical activity, right now, is the only main component not needing recharging. > I think we can consider mental fatigue is already taken into account in the fact you need > to reload your mana or pray for your grace to increase (btw, i think grace increases too easily for > now, it's too easy to cast then prayer spell than pray 3 seconds then recast. This is non sense :p, > in role playing praying take at least 1/2 hour on games like add :D) SP regen is pretty quick also, if you have a few magic+ items (and of course, there are magic poewr potions). One fix for this would be to just increase how long it takes to prayer. However, there is the consideration that you don't want to force players to sit around too much. From tchize at myrealbox.com Wed Sep 7 05:24:07 2005 From: tchize at myrealbox.com (tchize) Date: Wed Sep 7 05:23:45 2005 Subject: [crossfire] map redo: more layers. In-Reply-To: <431E7F86.2030200@sonic.net> References: <431559CC.1090704@sonic.net> <200509061204.24482.delbd@oma.be> <431E7F86.2030200@sonic.net> Message-ID: <200509071224.08159.tchize@myrealbox.com> Le Mercredi 7 Septembre 2005 07:49, Mark Wedel a ?crit : > David Delbecq wrote: > > Le Mardi 6 Septembre 2005 09:38, Mark Wedel a ?crit : > > > > > You don't get it, i meant, use the old code for that :) It's working so why change it. > > Your problem is to get old client to receive old style message. Aswar is easy, call > > old functions :) > > Yes, but right now if you look at MapSpace function, it has definitions for > what is on the different layers, and is coded for those 3 layers. > > If we go to 10 layers, I don't want to have to have something like: > > struct MapSpace { > object *old_faces[OLD_MAP_LAYERS] > object *faces[MAP_LAYERS] > } Yes, you are right, i forgot layers were stored in maps and not in player socket (is it really efficient to store it in map btw?) > > As that is just begging to get cleaned up at a later point. I'd much rather > just have the new data, and have the send code pull out the appropriate > information instead of having those double arrays (the new code also in a sense > simplifies the update_position() function). > > So what probably really happens is that to some degree, the logic in > update_position that determines the faces gets moved to the client logic. > > At some point in the future, support for this old protocl method goes away. > > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > > From leaf at real-time.com Wed Sep 7 22:59:34 2005 From: leaf at real-time.com (Rick Tanner) Date: Wed Sep 7 23:00:03 2005 Subject: [crossfire] Crossfire web fourm and crossfire.metalforge.net server offline - hardware failure Message-ID: <431FB726.4040005@real-time.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Until further notice, the Crossfire Web Forum (http://www.metalforge.net/cfmb) and crossfire.metalforge.net server are offline due to hardware failure(s). Updates will be made available, when they are available. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDH7cmhHyvgBp+vH4RAjveAJ4jUc3Tn1PPKnltg9sUok2/UW52hwCggWNz kO86WtGaiHTtKWP9KeOQEZc= =k2zp -----END PGP SIGNATURE----- From mwedel at sonic.net Wed Sep 7 23:53:41 2005 From: mwedel at sonic.net (Mark Wedel) Date: Wed Sep 7 23:54:04 2005 Subject: [crossfire] map redo: more layers. In-Reply-To: <200509071224.08159.tchize@myrealbox.com> References: <431559CC.1090704@sonic.net> <200509061204.24482.delbd@oma.be> <431E7F86.2030200@sonic.net> <200509071224.08159.tchize@myrealbox.com> Message-ID: <431FC3D5.1030503@sonic.net> tchize wrote: > Le Mercredi 7 Septembre 2005 07:49, Mark Wedel a ?crit : > >>David Delbecq wrote: >> >>>Le Mardi 6 Septembre 2005 09:38, Mark Wedel a ?crit : >> >>>You don't get it, i meant, use the old code for that :) It's working so why change it. >>>Your problem is to get old client to receive old style message. Aswar is easy, call >>>old functions :) >> >> Yes, but right now if you look at MapSpace function, it has definitions for >>what is on the different layers, and is coded for those 3 layers. >> >> If we go to 10 layers, I don't want to have to have something like: >> >>struct MapSpace { >> object *old_faces[OLD_MAP_LAYERS] >> object *faces[MAP_LAYERS] >>} > > > Yes, you are right, i forgot layers were stored in maps and not in player socket (is > it really efficient to store it in map btw?) It is probably more efficient (cpu wise) to only calculate what the spaces look like in one place. With the new layer system, I think the cpu cost of storing what the layers look like will be relatively trivial - we already need to traverse the spaces on the object to determine if the block site, block passage, etc. While doing that, storing some of them away is easy. But really, whether it is more efficient to do it on the map or per player would perhaps depend on map usage. Certainly for maps where only 1 player on the map, could be some gain in storing in purely on the player side. However, maps where there is more than 1 player, figuring it out in one place is certainly more efficient. That said, the other reason to have some fallback method is that I could forsee players on more bandwidth (or cpu) limited situations saying 'I really don't want all 10 layers - I only want 5'. So if we have a fallback method for sending them 5, then having a method for sending just 3 isn't that much harder to do. From leaf at real-time.com Thu Sep 8 15:14:01 2005 From: leaf at real-time.com (Rick Tanner) Date: Thu Sep 8 15:14:17 2005 Subject: [crossfire] Crossfire web forum and crossfire.metalforge.net server offline - hardware failure In-Reply-To: <431FB726.4040005@real-time.com> References: <431FB726.4040005@real-time.com> Message-ID: <43209B89.2060306@real-time.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 All tests indicate motherboard failure. A new MB has been ordered; no ETA at this time on when it will be here or when the server will be back on line. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDIJuIhHyvgBp+vH4RAqADAJ91Hkztz77+OYrQVYfekPbCri/cIwCfTCUQ kfJXFadsOUK/t3kx2/EnwmY= =OLgW -----END PGP SIGNATURE----- From nicolas.weeger at laposte.net Thu Sep 8 16:20:02 2005 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Thu Sep 8 16:22:18 2005 Subject: [crossfire] Crossfire web forum and crossfire.metalforge.net server offline - hardware failure In-Reply-To: <43209B89.2060306@real-time.com> References: <431FB726.4040005@real-time.com> <43209B89.2060306@real-time.com> Message-ID: <4320AB02.4040009@laposte.net> > All tests indicate motherboard failure. > > A new MB has been ordered; no ETA at this time on when it will be here > or when the server will be back on line. Many thanks for all the work you put in the website & MB. Ryo From leaf at real-time.com Fri Sep 9 19:47:31 2005 From: leaf at real-time.com (Rick Tanner) Date: Fri Sep 9 19:48:45 2005 Subject: [crossfire] Crossfire web forum and crossfire.metalforge.net server offline - hardware failure In-Reply-To: <43209B89.2060306@real-time.com> References: <431FB726.4040005@real-time.com> <43209B89.2060306@real-time.com> Message-ID: <43222D23.2060301@real-time.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 New motherboard arrived; however, the CPU appears to be dead as well. A new one has been ordered and should be here early next week. No ETA on when the server or forum will be back online. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDIi0jhHyvgBp+vH4RAvMoAKDsA10vHcRdRbwptpk2WS6LjJn2fACg3jUN iB+QELn90q0N+KgIeo5Lv+E= =NXzd -----END PGP SIGNATURE----- From mikeeusaaa at yahoo.com Fri Sep 9 22:00:35 2005 From: mikeeusaaa at yahoo.com (Mitch Obrian) Date: Fri Sep 9 22:00:46 2005 Subject: [crossfire] Crossfire web forum and crossfire.metalforge.net server offline - hardware failure In-Reply-To: <43222D23.2060301@real-time.com> Message-ID: <20050910030035.70171.qmail@web61019.mail.yahoo.com> Comon :/ there's no spare cpu's around? /me want to use. Also, can anyone get to my crossfire server. It doesn't seem to be on the list for some reason. --- Rick Tanner wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > New motherboard arrived; however, the CPU appears to > be dead as well. A > new one has been ordered and should be here early > next week. > > No ETA on when the server or forum will be back > online. > > > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.1 (GNU/Linux) > Comment: Using GnuPG with Thunderbird - > http://enigmail.mozdev.org > > iD8DBQFDIi0jhHyvgBp+vH4RAvMoAKDsA10vHcRdRbwptpk2WS6LjJn2fACg3jUN > iB+QELn90q0N+KgIeo5Lv+E= > =NXzd > -----END PGP SIGNATURE----- > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > ______________________________________________________ Click here to donate to the Hurricane Katrina relief effort. http://store.yahoo.com/redcross-donate3/ From alex_sch at telus.net Sat Sep 10 00:48:23 2005 From: alex_sch at telus.net (Alex Schultz) Date: Sat Sep 10 00:48:48 2005 Subject: [crossfire] [OT] Crossfire web forum and crossfire.metalforge.net server offline - hardware failure In-Reply-To: <20050910030035.70171.qmail@web61019.mail.yahoo.com> References: <20050910030035.70171.qmail@web61019.mail.yahoo.com> Message-ID: <432273A7.8040101@telus.net> Mitch Obrian wrote: >Also, can anyone get to my crossfire server. It >doesn't seem to be on the list for some reason. I manually entered your server name (cat2.dynu.ca), but it doesn't work (just hangs as if the machine was turned off). Alex Schultz From mikeeusaaa at yahoo.com Sat Sep 10 01:07:59 2005 From: mikeeusaaa at yahoo.com (Mitch Obrian) Date: Sat Sep 10 01:08:49 2005 Subject: [crossfire] [OT] Crossfire web forum and crossfire.metalforge.net server offline - hardware failure In-Reply-To: <432273A7.8040101@telus.net> Message-ID: <20050910060759.4850.qmail@web61019.mail.yahoo.com> Hmm, I'll have to check the log file then. Thanks :). --- Alex Schultz wrote: > Mitch Obrian wrote: > > >Also, can anyone get to my crossfire server. It > >doesn't seem to be on the list for some reason. > > I manually entered your server name (cat2.dynu.ca), > but it doesn't work > (just hangs as if the machine was turned off). > > Alex Schultz > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > ______________________________________________________ Click here to donate to the Hurricane Katrina relief effort. http://store.yahoo.com/redcross-donate3/ From nicolas.weeger at laposte.net Sat Sep 10 15:59:01 2005 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sat Sep 10 16:01:02 2005 Subject: [crossfire] create_and_rescale_image_from_data weirdness In-Reply-To: <431CA812.4080302@laposte.net> References: <431B197F.8020407@laposte.net> <431CA812.4080302@laposte.net> Message-ID: <43234915.8050807@laposte.net> > There's still a potential memory leak, though ^_- Scratch that, SDL_CreateRGBSurfaceFrom requires the allocated memory to be kept. So no memory leak. Ryo From blatnc at yahoo.com Sat Sep 10 19:51:21 2005 From: blatnc at yahoo.com (Blake Delaney) Date: Sat Sep 10 19:53:04 2005 Subject: [crossfire] map and player persistence question Message-ID: <20050911005121.94738.qmail@web34515.mail.mud.yahoo.com> Hello, I'm trying to figure out how the persistence system works in crossfire, for maps and for players. Note that anywhere I ask about the location of source code, I'm talking about file and function names. Maps: I noticed that a map will keep its state for a period of time after I leave it. I also noticed that it will lose all that state if enough time passes. From the source code I noticed some sort of reset system. That's about all I have figured out at the moment. How is it decided when to load a map into memory? Where is the source code that makes this decision? How is it decided when to reset a map? Where is the source code that does this? Is this done by simply deleting the changed map in memory? Can a map ever reset with a player on it? Are there any maps that don't reset? Is there any mechanism for state changes to a map that will not be cleared after a short amount of time? If so where is the source code that deals with that? Are changed maps ever saved to disk for any reason in crossfire? By changed, I mean maps with items dropped on them, or generated monsters, or whatever. Players: When is a character saved to disk? Is it only when they go to bed? Where is the source code that deals with this? It seems that there is only one character allowed per player. Is that accurate? Thank you in advance for any answers, explanations or resources. Sincerely, Blake ______________________________________________________ Click here to donate to the Hurricane Katrina relief effort. http://store.yahoo.com/redcross-donate3/ From alex_sch at telus.net Sat Sep 10 20:28:31 2005 From: alex_sch at telus.net (Alex Schultz) Date: Sat Sep 10 20:29:05 2005 Subject: [crossfire] map and player persistence question In-Reply-To: <20050911005121.94738.qmail@web34515.mail.mud.yahoo.com> References: <20050911005121.94738.qmail@web34515.mail.mud.yahoo.com> Message-ID: <4323883F.9090503@telus.net> Blake Delaney wrote: >Hello, > >I'm trying to figure out how the persistence system >works in crossfire, for maps and for players. > >Note that anywhere I ask about the location of source >code, I'm talking about file and function names. > >Maps: >I noticed that a map will keep its state for a period >of time after I leave it. I also noticed that it will >lose all that state if enough time passes. From the >source code I noticed some sort of reset system. >That's about all I have figured out at the moment. > >How is it decided when to load a map into memory? >Where is the source code that makes this decision? > > Maps are loaded into memory whenever: 1) a player enters a map that is currently not loaded 2) the weather code simulates weather on that map (however in that case it's unloaded right away after, unless a player is on it) 3) when a DM uses the "reset" command The loading process is very fast (the cvs version had some changes a week ago or so that improved it further), such that the player probably won't notice the load time. Most of this map related code should be in common/map.c I don't have time atm to search for specific functions. >How is it decided when to reset a map? > After a certain timeout of inactivity on the map (I can't remember what the default time is, and individual maps can set it separately too), it is reset. Players entering the map when it tries to reset, or just periodically when the player is in it, will cause this timeout to reset. >Is this done by simply >deleting the changed map in memory? > > It's done by unloading the map from memory, and unless it is an apartment or guild type map, it is not saved to disk when unloaded. >Can a map ever reset with a player on it? > > No. >Are there any maps that don't reset? > > Sort of, apartments and such do 'reset' in that they are unloaded from memory like the rest, however their contents is saved to disk and loaded again when the map is entered. >Is there any mechanism for state changes to a map that >will not be cleared after a short amount of time? If >so where is the source code that deals with that? > > Well, if you're referring to the apartment style maps, you would want to look at the saving code in common/maps.c >Are changed maps ever saved to disk for any reason in >crossfire? By changed, I mean maps with items dropped >on them, or generated monsters, or whatever. > > Again, apartment/guild maps. >Players: >When is a character saved to disk? Is it only when >they go to bed? Where is the source code that deals >with this? > > Players are saved to disk by one of four ways: 1) the save bed 2) periodic automatic save of character 3) the 'save' command 4) emergency save upon server shutdown It shouldn't be too hard to find the code for that, but I don't have time to do that at the second. >It seems that there is only one character allowed per >player. Is that accurate? > > For a given username, yes. However there's nothing preventing you from getting multiple usernames, and this is a very common practice, and no public server I know of disallows it. There is no need for having an 'account' style system where a single user has multiple characters grouped together because there simply isn't need to keep track of stuff like that, unlike commercial MMORPGs. I don't have time for searching for specific functions at the moment, but somebody else can probably help you, and later I might have time to gather a list of which functions control the things you're rerfering to. Alex Schultz From mwedel at sonic.net Sun Sep 11 00:36:47 2005 From: mwedel at sonic.net (Mark Wedel) Date: Sun Sep 11 00:37:09 2005 Subject: [crossfire] map and player persistence question In-Reply-To: <4323883F.9090503@telus.net> References: <20050911005121.94738.qmail@web34515.mail.mud.yahoo.com> <4323883F.9090503@telus.net> Message-ID: <4323C26F.7030801@sonic.net> A few other notes/corrections. I don't have time either to hunt through for function names. But generally, the server/swap.c determines when maps are swapped out and reset. Loading of maps is done as demanded. > Maps are loaded into memory whenever: > 1) a player enters a map that is currently not loaded > 2) the weather code simulates weather on that map (however in that case > it's unloaded right away after, unless a player is on it) > 3) when a DM uses the "reset" command > The loading process is very fast (the cvs version had some changes a > week ago or so that improved it further), such that the player probably > won't notice the load time. A side case to #1 is the outdoor (tiled) maps. A player may not be on the actual neighboring map, but if a player can see some portion of it, it needs to be in memory. Loading is typically handled in enter_exit(), which I think is in server/main.c. However, the tile maps I think are handled in common/object.c, when code is called the references the neighboring map. > > After a certain timeout of inactivity on the map (I can't remember what > the default time is, and individual maps can set it separately too), it > is reset. Players entering the map when it tries to reset, or just > periodically when the player is in it, will cause this timeout to reset. > There are two things here - There is the case when a map is swapped out from memory to disk. If a player revisits that map before it resets, it is swapped back in. There is the actual reset case, where this swapped map is deleted and next time a player visits it, it is loaded back in memory. there are default timeout values for both of these, of which the map can overried to some extent (variosu config options can enforce min/maxes on these). Reset is handled in two different cases. Most maps reset time is cleared if a player visits it. But some maps, most notably shops, have 'fixed' reset times - that is, when first loaded into memory, its reset time is set, no matter how many players visit it in the interim. Thus, you can get cases where a player exits the shop and re-enters just a minute later to find it is all different. >> Is this done by simply >> deleting the changed map in memory? >> >> > It's done by unloading the map from memory, and unless it is an > apartment or guild type map, it is not saved to disk when unloaded. Typically, when a map resets, it is not in memory (because a player being on the map would cause the reset time to be a while away) If for some reason a map expires while in memory, when it is time to swap it out, that won't happen - it will just be deleted from memory. >> Are there any maps that don't reset? >> >> > Sort of, apartments and such do 'reset' in that they are unloaded from > memory like the rest, however their contents is saved to disk and loaded > again when the map is entered. In theory, highly used maps could also never reset just by the fact that there is always players visiting them. This is the reason that fixed reset was added to shops (visited so often they'd never get reset). Right now, some of the towns may be pretty close to that category - players always hanging around, thus not likely to reset. > >> Is there any mechanism for state changes to a map that >> will not be cleared after a short amount of time? If >> so where is the source code that deals with that? >> >> > Well, if you're referring to the apartment style maps, you would want to > look at the saving code in common/maps.c I'm not exactly sure when you say 'state changes'. Unique objects, determined by the unique flag, will persist across map resets. And if the floor is marked as unique, then all objects above it are preserved. An example of this is the old apartment map in scorn (maps/scorn/taverns/apartments). Here, unique floors are used throughout to preserve the contents of the apartment across resets. However, the common areas (except for the altars) are not unique, so stuff in the lobby area would disappear > >> Are changed maps ever saved to disk for any reason in >> crossfire? By changed, I mean maps with items dropped >> on them, or generated monsters, or whatever. >> >> > Again, apartment/guild maps. Depends on definition of changed maps. If I go to a dungeon, and leave the dungeon, after a few minutes, it is swapped out. Swapped out in the case means written to disk (typically /tmp, which may not really be disk, but that is just a configuration issue). The format here is exactly same as original file. If I revisit that map in 2 hours (Default reset time), it is loaded back in. If I don't go back, then it will reset. > >> Players: >> When is a character saved to disk? Is it only when >> they go to bed? Where is the source code that deals >> with this? >> >> > Players are saved to disk by one of four ways: > 1) the save bed > 2) periodic automatic save of character > 3) the 'save' command > 4) emergency save upon server shutdown 5) Whenever a player dies The code for this is in various areas - some in server/player.c, some in apply.c, depends on mechanism. Look for save_player() > > It shouldn't be too hard to find the code for that, but I don't have > time to do that at the second. > >> It seems that there is only one character allowed per >> player. Is that accurate? >> >> > For a given username, yes. However there's nothing preventing you from > getting multiple usernames, and this is a very common practice, and no > public server I know of disallows it. There is no need for having an > 'account' style system where a single user has multiple characters > grouped together because there simply isn't need to keep track of stuff > like that, unlike commercial MMORPGs. And in fact, there is nothing preventing the same person (computer) having multiple active players on the same server at the same time. This would typically not be that useful, but I have done it a few times when I've needed to test player/player interactions From lalo at exoweb.net Sun Sep 11 05:43:42 2005 From: lalo at exoweb.net (Lalo Martins) Date: Sun Sep 11 05:47:14 2005 Subject: [crossfire] Re: map and player persistence question In-Reply-To: <4323883F.9090503@telus.net> References: <20050911005121.94738.qmail@web34515.mail.mud.yahoo.com> <4323883F.9090503@telus.net> Message-ID: Can I ask that, when you collect answers to your satisfaction, you put them together in a single document, and stick it on the wiki? These are very useful questions for new hackers trying to understand the system. I'll tell you what I know, but it may be slightly inaccurate in the details. And so says Alex Schultz on 11/09/05 09:28... >> Is there any mechanism for state changes to a map that >> will not be cleared after a short amount of time? If >> so where is the source code that deals with that? >> > Well, if you're referring to the apartment style maps, you would want to > look at the saving code in common/maps.c > >> Are changed maps ever saved to disk for any reason in >> crossfire? By changed, I mean maps with items dropped >> on them, or generated monsters, or whatever. >> > Again, apartment/guild maps. There are two relevant mechanisms, both referred to commonly as "uniqueness". First, a map can be "unique" (by setting the unique flag to true on the exit object that leads to it). Hmm, that's not precise; an _exit_ can be unique. Yes, that's better. (Although we refer to this feature as an "unique map".) If an exit is unique, a player that goes trough it will be taken to a special version of the target map; this version is different for each player, and is persistent - when it resets, its whole contents will be saved to disk. However, they are saved to the player's directory. The other thing in unique items. When a map reset, any cell that has any items marked "unique" (except for exits... I think) will be saved to an "overlay" map file, which is in turn saved to a special directory. The way this is usually put to use, is by marking a few _floor_ objects as "unique", so that those cells will always be saved. You may hear people referring to this practice as "unique floor" or "unique squares". Guild houses (iirc) have a room or two with unique floor, so that you can keep your loot there. best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. -- http://www.exoweb.net/ mailto:lalo@exoweb.net GNU: never give up freedom http://www.gnu.org/ From fuchs.andy at gmail.com Sun Sep 11 11:43:19 2005 From: fuchs.andy at gmail.com (Andrew Fuchs) Date: Sun Sep 11 11:43:20 2005 Subject: [crossfire] Re: map and player persistence question In-Reply-To: References: <20050911005121.94738.qmail@web34515.mail.mud.yahoo.com> <4323883F.9090503@telus.net> Message-ID: On 9/11/05, Lalo Martins wrote: > Can I ask that, when you collect answers to your satisfaction, you put > them together in a single document, and stick it on the wiki? These are > very useful questions for new hackers trying to understand the system. AFAIK, we are getting a new (better imo, using dokuwiki) wiki soon, probaly after leaf solves the current problems with the metalforge server. > The way this is usually put to use, is by marking > Guild houses (iirc) have a room or two with unique floor, so that you ... That would be the entire interior, plus the storage building. -- Andrew Fuchs From blatnc at yahoo.com Sun Sep 11 17:16:50 2005 From: blatnc at yahoo.com (Blake Delaney) Date: Sun Sep 11 17:17:26 2005 Subject: [crossfire] map/player persistence wiki version 1 In-Reply-To: Message-ID: <20050911221650.83532.qmail@web34505.mail.mud.yahoo.com> Thank you everyone for your detailed answers to my questions. > On 9/11/05, Lalo Martins wrote: > > Can I ask that, when you collect answers to your > satisfaction, you put > > them together in a single document, and stick it > on the wiki? These are > > very useful questions for new hackers trying to > understand the system. I don't know how to use a wiki, but here is an alpha version of the answers I have received so far. I compiled them into one document and made a first attempt at merging the answers from various people into one answer for each question. I am still no expert on the material discussed. I suggest that anyone interested here tweak this document and increment the version number in the subject line until everyone is satisfied, and then someone post it to the wiki. If you do this, make sure to copy, edit, and paste instead of hitting "reply" to avoid introducing right angle brackets (>). Blake map and player persistence: >How is it decided when to load a map into memory? Maps are loaded into memory whenever: 1) a player enters a map that is currently not loaded 2) A player comes near the edge of an unloaded outdoor titled tiled map. A player may not be on the actual neighboring map, but if a player can see some portion of it, it needs to be in memory. 2) the weather code simulates weather on that map (however in that case it's unloaded right away after, unless a player is on it) 3) when a DM uses the "reset" command The loading process is very fast, such that the player probably won't notice the load time. > Where is the source code that loads and unloads maps? Most of this map related code should be in common/map.c Loading is typically handled in enter_exit(), which I think is in server/main.c. However, the tile maps I think are handled in common/object.c, when code is called the references the neighboring map. >How is it decided when to reset a map? (And what is a reset anyway?) After a certain timeout of inactivity on the map (I can't remember what the default time is, and individual maps can set it separately too), it is reset. Players entering the map when it tries to reset, or just periodically when the player is in it, will cause this timeout to be extended. It's done by unloading the map from memory, and unless it is an apartment or guild type map, it is not saved to disk when unloaded. There are two things here - There is the case when a map is swapped out from memory to disk. If a player revisits that map before it resets, it is swapped back in. There is the actual reset case, where this swapped map is deleted and next time a player visits it, it is loaded back in memory. there are default timeout values for both of these, of which the map can overried to some extent (various config options can enforce min/maxes on these). Reset is handled in two different cases. Most maps reset time is cleared if a player visits it. But some maps, most notably shops, have 'fixed' reset times - that is, when first loaded into memory, its reset time is set, no matter how many players visit it in the interim. Thus, you can get cases where a player exits the shop and re-enters just a minute later to find it is all different. Typically, when a map resets, it is not in memory (because a player being on the map would cause the reset time to be a while away) If for some reason a map expires while in memory, when it is time to swap it out, that won't happen - it will just be deleted from memory. >Can a map ever reset with a player on it? No. >Are there any maps that don't reset? Sort of, apartments and such do 'reset' in that they are unloaded from memory like the rest, however their contents is saved to disk and loaded again when the map is entered. generally, the server/swap.c determines when maps are swapped out and reset. Loading of maps is done as demanded. In theory, highly used maps could also never reset just by the fact that there is always players visiting them. This is the reason that fixed reset was added to shops (visited so often they'd never get reset). Right now, some of the towns may be pretty close to that category - players always hanging around, thus not likely to reset. >Are there maps that never lose their changes? What is uniqueness? If I go to a dungeon, and leave the dungeon, after a few minutes, it is swapped out. Swapped out in the case means written to disk (typically /tmp, which may not really be disk, but that is just a configuration issue). The format here is exactly same as original file. If I revisit that map in 2 hours (Default reset time), it is loaded back in. If I don't go back, then it will reset. Apartment and guild maps don't lose changes. There are two relevant mechanisms for saving map changes permanently, both referred to commonly as "uniqueness". Unique objects, determined by the unique flag, will persist across map resets. And if the floor is marked as unique, then all objects above it are preserved. An example of this is the old apartment map in scorn (maps/scorn/taverns/apartments). Here, unique floors are used throughout to preserve the contents of the apartment across resets. However, the common areas (except for the altars) are not unique, so stuff in the lobby area would disappear First, a map can be "unique" (by setting the unique flag to true on the exit object that leads to it). Hmm, that's not precise; an _exit_ can be unique. Yes, that's better. (Although we refer to this feature as an "unique map".) If an exit is unique, a player that goes trough it will be taken to a special version of the target map; this version is different for each player, and is persistent - when it resets, its whole contents will be saved to disk. However, they are saved to the player's directory. The other thing in unique items. When a map reset, any cell that has any items marked "unique" (except for exits... I think) will be saved to an "overlay" map file, which is in turn saved to a special directory. The way this is usually put to use, is by marking a few _floor_ objects as "unique", so that those cells will always be saved. You may hear people referring to this practice as "unique floor" or "unique squares". Guild houses (iirc) have a room or two with unique floor, so that you can keep your loot there. That would be the entire interior, plus the storage building. >When is a character saved to disk? Players are saved to disk by one of four ways: 1) the save bed 2) periodic automatic save of character 3) the 'save' command 4) emergency save upon server shutdown 5) Whenever a player dies The code for this is in various areas - some in server/player.c, some in apply.c, depends on mechanism. Look for save_player() >It seems that there is only one character allowed per >player. Is that accurate? For a given username, yes. However there's nothing preventing you from getting multiple usernames, and this is a very common practice, and no public server I know of disallows it. There is no need for having an 'account' style system where a single user has multiple characters grouped together because there simply isn't need to keep track of stuff like that, unlike commercial MMORPGs. And in fact, there is nothing preventing the same person (computer) having multiple active players on the same server at the same time. This would typically not be that useful, but I have done it a few times when I've needed to test player/player interactions ______________________________________________________ Yahoo! for Good Watch the Hurricane Katrina Shelter From The Storm concert http://advision.webevents.yahoo.com/shelter From mikeeusaaa at yahoo.com Sun Sep 11 21:51:35 2005 From: mikeeusaaa at yahoo.com (Mitch Obrian) Date: Sun Sep 11 21:53:30 2005 Subject: [crossfire] Whaleing village pack needs to be updated in CVS In-Reply-To: <20050911221650.83532.qmail@web34505.mail.mud.yahoo.com> Message-ID: <20050912025135.54391.qmail@web61014.mail.yahoo.com> I think the cvs version is too old. https://cat2.dynu.ca/cat2/worldpatch.tar.gz ______________________________________________________ Yahoo! for Good Watch the Hurricane Katrina Shelter From The Storm concert http://advision.webevents.yahoo.com/shelter From leaf at real-time.com Mon Sep 12 13:45:05 2005 From: leaf at real-time.com (Rick Tanner) Date: Mon Sep 12 13:45:44 2005 Subject: [crossfire] Whaleing village pack needs to be updated in CVS (re-post) Message-ID: When posting a new topic - please start (or compose) a new message to help ensure the message/topic threading in the list archive stays together. Thanks. ---- Date: Sun, 11 Sep 2005 19:51:35 -0700 (PDT) From: Mitch Obrian Subject: [crossfire] Whaleing village pack needs to be updated in CVS I think the cvs version is too old. https://cat2.dynu.ca/cat2/worldpatch.tar.gz -- From mikeeusaaa at yahoo.com Mon Sep 12 15:26:46 2005 From: mikeeusaaa at yahoo.com (Mitch Obrian) Date: Mon Sep 12 15:27:47 2005 Subject: [crossfire] Whaleing village pack needs to be updated in CVS (re-post) In-Reply-To: Message-ID: <20050912202646.2152.qmail@web61021.mail.yahoo.com> Ok, will do. Btw when will the board be back up? --- Rick Tanner wrote: > > When posting a new topic - please start (or compose) > a new message to > help ensure the message/topic threading in the list > archive stays > together. > > Thanks. > > ---- > > Date: Sun, 11 Sep 2005 19:51:35 -0700 (PDT) > From: Mitch Obrian > Subject: [crossfire] Whaleing village pack needs to > be updated in CVS > > I think the cvs version is too old. > https://cat2.dynu.ca/cat2/worldpatch.tar.gz > > > -- > > > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > ______________________________________________________ Yahoo! for Good Donate to the Hurricane Katrina relief effort. http://store.yahoo.com/redcross-donate3/ From mikeeusaaa at yahoo.com Mon Sep 12 15:35:16 2005 From: mikeeusaaa at yahoo.com (Mitch Obrian) Date: Mon Sep 12 15:35:40 2005 Subject: [crossfire] Crossfire site suggestions and request. Message-ID: <20050912203516.12961.qmail@web61017.mail.yahoo.com> http://crossfire.real-time.com/irc/index.html Perhapse add a web irc client so users can log on to the channel from school, work, computers who's users don't know how to work irc, locked down comps, etc? http://crossfire.real-time.com/download/index.html could maybe a link to the development mlab package be included somewhere on there (maybe under cvs part?) https://cat2.dynu.ca/cat2/mlab-devel.tar.gz so localhost users who want to play in mlab don't have to wait for cvs (the tarball has instructions on how to install mlabdev properly) I was also thinking maybe we should have a /backup branch of cvs where we can upload tarballs of in-progress projects we are working on? __________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com From edler at heydernet.de Mon Sep 12 16:59:07 2005 From: edler at heydernet.de (Bernd Edler) Date: Mon Sep 12 16:59:47 2005 Subject: [crossfire] Re: LOS and lighting map redo In-Reply-To: <431E8373.806@sonic.net> References: <43140D09.9070700@sonic.net> <431D42F7.7070408@sonic.net> <431E8373.806@sonic.net> Message-ID: On Tue, 6 Sep 2005, Mark Wedel wrote: > Trying to figure out which side the light is coming from now means that the > light has to be individually figured for each player - this would add a non > trivial amount of cpu (although may be possible with simple coordinate > checking - I'd have to thinkg about that more) > I think, coordinate checking might work nicely: 123 8W4 P 765 W = Wall 1-8 relevant adjacent squares depending on player position we make the light as bright as the relevant neighbor. The relevant one is just the one that if it had blocksview=1, then W would be blocked from view. Thus the "reference" square is not a wall itself. Alas, if P is a player, both 8 and 7 are relevant. If only one of them has blocksview=0, then the choice is obviously easy. Else we can make an average or take the brighter one. Their lighting level probably does not differ much anyway. That ought not to be more complex then LOS calculation itself. From mwedel at sonic.net Tue Sep 13 01:18:15 2005 From: mwedel at sonic.net (Mark Wedel) Date: Tue Sep 13 01:19:55 2005 Subject: [crossfire] Crossfire site suggestions and request. In-Reply-To: <20050912203516.12961.qmail@web61017.mail.yahoo.com> References: <20050912203516.12961.qmail@web61017.mail.yahoo.com> Message-ID: <43266F27.9040003@sonic.net> Mitch Obrian wrote: > I was also thinking maybe we should have a /backup > branch of cvs where we can upload tarballs of > in-progress projects we are working on? CVS isn't designed, nor a good place, to use as an upload/storage site. And ftp server for that matter would be better. I'd have to look, but using CVS for that purpose may also be a violation of the sourceforge usage policy (I vaguely recall guidelines for what CVS can and can not be used for). Sourceforge does have a mechanism to attach files to patch and change requests - might be a maximum size. but if there is a max size there, must likely they'd be unhappy if people put very large files files into the CVS repository. I personally want hte patch/RFE to be used for this - I don't want yet another place patches or files may be located. From tchize at myrealbox.com Tue Sep 13 06:18:43 2005 From: tchize at myrealbox.com (tchize) Date: Tue Sep 13 06:18:03 2005 Subject: [crossfire] Crossfire site suggestions and request. In-Reply-To: <20050912203516.12961.qmail@web61017.mail.yahoo.com> References: <20050912203516.12961.qmail@web61017.mail.yahoo.com> Message-ID: <200509131318.43377.tchize@myrealbox.com> Le Lundi 12 Septembre 2005 22:35, Mitch Obrian a ?crit : > http://crossfire.real-time.com/irc/index.html > > Perhapse add a web irc client so users can log on to > the channel from school, work, computers who's users > don't know how to work irc, locked down comps, etc? Depend on hosting server scalability. - Using something like CGI::IRC is quite transparent to visitor but mean lots of headache on server side (each client is using 1 apache thread) - Using a java-applet based irc client mean we need either an irc server on crossfire.real-time.com which acts as a proxy for freenode or we need to sign the java applet to allow it to connect to freenode directly. From mikeeusaaa at yahoo.com Tue Sep 13 07:58:56 2005 From: mikeeusaaa at yahoo.com (Mitch Obrian) Date: Tue Sep 13 08:00:02 2005 Subject: [crossfire] Crossfire site suggestions and request. In-Reply-To: <43266F27.9040003@sonic.net> Message-ID: <20050913125856.54701.qmail@web61023.mail.yahoo.com> There are some phpirc scripts here and there like this one: https://cat2.dynu.ca/ircphp/index.php . I don't think the overhead for those are much. Also could there perhapse be a link to the devel tarball of mlab on the downloads page of crossfire.real-time.com (perhapse below the cvs stuff as that's devel too) https://cat2.dynu.ca/cat2/mlab-devel.tar.gz ? --- Mark Wedel wrote: > Mitch Obrian wrote: > > > I was also thinking maybe we should have a /backup > > branch of cvs where we can upload tarballs of > > in-progress projects we are working on? > > CVS isn't designed, nor a good place, to use as an > upload/storage site. And > ftp server for that matter would be better. I'd > have to look, but using CVS for > that purpose may also be a violation of the > sourceforge usage policy (I vaguely > recall guidelines for what CVS can and can not be > used for). > > Sourceforge does have a mechanism to attach files > to patch and change requests > - might be a maximum size. but if there is a max > size there, must likely they'd > be unhappy if people put very large files files into > the CVS repository. > > I personally want hte patch/RFE to be used for > this - I don't want yet another > place patches or files may be located. > > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > __________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com From mikeeusaaa at yahoo.com Tue Sep 13 08:00:55 2005 From: mikeeusaaa at yahoo.com (Mitch Obrian) Date: Tue Sep 13 08:02:13 2005 Subject: [crossfire] Crossfire site suggestions and request. In-Reply-To: <43266F27.9040003@sonic.net> Message-ID: <20050913130055.62793.qmail@web61020.mail.yahoo.com> There are some phpirc scripts here and there like this one: https://cat2.dynu.ca/ircphp/index.php . I don't think the overhead for those are much. Also could there perhapse be a link to the devel tarball of mlab on the downloads page of crossfire.real-time.com (perhapse below the cvs stuff as that's devel too) https://cat2.dynu.ca/cat2/mlab-devel.tar.gz ? --- Mark Wedel wrote: > Mitch Obrian wrote: > > > I was also thinking maybe we should have a /backup > > branch of cvs where we can upload tarballs of > > in-progress projects we are working on? > > CVS isn't designed, nor a good place, to use as an > upload/storage site. And > ftp server for that matter would be better. I'd > have to look, but using CVS for > that purpose may also be a violation of the > sourceforge usage policy (I vaguely > recall guidelines for what CVS can and can not be > used for). > > Sourceforge does have a mechanism to attach files > to patch and change requests > - might be a maximum size. but if there is a max > size there, must likely they'd > be unhappy if people put very large files files into > the CVS repository. > > I personally want hte patch/RFE to be used for > this - I don't want yet another > place patches or files may be located. > > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > __________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com From mikeeusaaa at yahoo.com Tue Sep 13 08:00:58 2005 From: mikeeusaaa at yahoo.com (Mitch Obrian) Date: Tue Sep 13 08:02:17 2005 Subject: [crossfire] Crossfire site suggestions and request. In-Reply-To: <43266F27.9040003@sonic.net> Message-ID: <20050913130058.70272.qmail@web61019.mail.yahoo.com> There are some phpirc scripts here and there like this one: https://cat2.dynu.ca/ircphp/index.php . I don't think the overhead for those are much. Also could there perhapse be a link to the devel tarball of mlab on the downloads page of crossfire.real-time.com (perhapse below the cvs stuff as that's devel too) https://cat2.dynu.ca/cat2/mlab-devel.tar.gz ? --- Mark Wedel wrote: > Mitch Obrian wrote: > > > I was also thinking maybe we should have a /backup > > branch of cvs where we can upload tarballs of > > in-progress projects we are working on? > > CVS isn't designed, nor a good place, to use as an > upload/storage site. And > ftp server for that matter would be better. I'd > have to look, but using CVS for > that purpose may also be a violation of the > sourceforge usage policy (I vaguely > recall guidelines for what CVS can and can not be > used for). > > Sourceforge does have a mechanism to attach files > to patch and change requests > - might be a maximum size. but if there is a max > size there, must likely they'd > be unhappy if people put very large files files into > the CVS repository. > > I personally want hte patch/RFE to be used for > this - I don't want yet another > place patches or files may be located. > > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From mikeeusaaa at yahoo.com Tue Sep 13 10:17:16 2005 From: mikeeusaaa at yahoo.com (Mitch Obrian) Date: Tue Sep 13 10:18:04 2005 Subject: [crossfire] Crossfire site suggestions and request. In-Reply-To: <20050913130058.70272.qmail@web61019.mail.yahoo.com> Message-ID: <20050913151716.4990.qmail@web61018.mail.yahoo.com> Sorry for the multi-post, webmail was acting up. --- Mitch Obrian wrote: > There are some phpirc scripts here and there like > this > one: https://cat2.dynu.ca/ircphp/index.php . I don't > think the overhead for those are much. > > Also could there perhapse be a link to the devel > tarball of mlab on the downloads page of > crossfire.real-time.com (perhapse below the cvs > stuff > as that's devel too) > https://cat2.dynu.ca/cat2/mlab-devel.tar.gz ? > > --- Mark Wedel wrote: > > > Mitch Obrian wrote: > > > > > I was also thinking maybe we should have a > /backup > > > branch of cvs where we can upload tarballs of > > > in-progress projects we are working on? > > > > CVS isn't designed, nor a good place, to use as > an > > upload/storage site. And > > ftp server for that matter would be better. I'd > > have to look, but using CVS for > > that purpose may also be a violation of the > > sourceforge usage policy (I vaguely > > recall guidelines for what CVS can and can not be > > used for). > > > > Sourceforge does have a mechanism to attach > files > > to patch and change requests > > - might be a maximum size. but if there is a max > > size there, must likely they'd > > be unhappy if people put very large files files > into > > the CVS repository. > > > > I personally want hte patch/RFE to be used for > > this - I don't want yet another > > place patches or files may be located. > > > > > > _______________________________________________ > > crossfire mailing list > > crossfire@metalforge.org > > > http://mailman.metalforge.org/mailman/listinfo/crossfire > > > > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam > protection around > http://mail.yahoo.com > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > __________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com From temitchell at sympatico.ca Tue Sep 13 14:31:04 2005 From: temitchell at sympatico.ca (temitchell@sympatico.ca) Date: Tue Sep 13 14:32:08 2005 Subject: [crossfire] Crossfire site suggestions and request. Message-ID: <20050913193935.XBBW2134.tomts48-srv.bellnexxia.net@[209.226.175.82]> > > From: Mark Wedel > I personally want hte patch/RFE to be used for this - I don't want yet another > place patches or files may be located. > I also think the patch facility on sourceforge is proper for this, anything too big to attach to the patch tracker is likely too big to test easily and should probably be broken into smaller pieces anyway. The real issue is *tracking* and testing these things, not moving them or storing them which is why I also think the actual patches should be actually uploaded to the patcher and not just linked to file from an external server location. From leaf at real-time.com Wed Sep 14 17:47:22 2005 From: leaf at real-time.com (Rick Tanner) Date: Wed Sep 14 17:48:38 2005 Subject: [crossfire] Crossfire web fourm and crossfire.metalforge.net server offline - hardware failure In-Reply-To: <431FB726.4040005@real-time.com> References: <431FB726.4040005@real-time.com> Message-ID: <4328A87A.4020807@real-time.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Status update.. The crossfire server, crossfire.metalforge.net, is back online. The issues with the server: Initial testing showed the mother board had failed. New mother board was ordered and installed. Still had problems. Further testing showed the CPU had died as well. Weekend. New CPU arrived, testing. Found drive and/or data errors. More testing with the hard drives. Found all hardware to be in good working order (RAID controller and the two drives.) Had to rebuild the array - came back with out any problems. The web forum is going to remain off line for a little while longer. No ETA as to when the forum will be available. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDKKh6hHyvgBp+vH4RAvYpAJ4zBrpSKf6ggDpINY6BRxyaESZbhwCbBSZq oCQzf2Icoy4athDZavnZpJk= =RHRf -----END PGP SIGNATURE----- From alex_sch at telus.net Wed Sep 14 21:24:53 2005 From: alex_sch at telus.net (Alex Schultz) Date: Wed Sep 14 21:26:41 2005 Subject: [crossfire] mapguide/director question Message-ID: <4328DB75.8090502@telus.net> Hi, I have a question about this exert from the mapguide: /12) Do not put directors with bullet, lightning, fireball, etc. that are a loop or continuous. Example: Do not have two directors, each facing each other, with a bullet wall firing into them at the side. / Why is this a problem? I saw what was written below it, but don't bullets and fireballs and such explode after traveling for a bit? The reason I am asking this, is because I am thinking of adding a new type of spell, that makes some bullets/fireballs/orsomethinglikethat, fly around you in a circle, making use of new director functionality I'm working on (allows directors to only affect a specific arch). Anybody see any issues with this? And would rule 12 of the mapguide interfere or would it be fine because the directors would only exist for a short finite time? Thanks, Alex Schultz From leaf at real-time.com Wed Sep 14 23:33:32 2005 From: leaf at real-time.com (Rick Tanner) Date: Wed Sep 14 23:34:43 2005 Subject: [crossfire] mapguide/director question In-Reply-To: <4328DB75.8090502@telus.net> References: <4328DB75.8090502@telus.net> Message-ID: <4328F99C.7030308@real-time.com> Alex Schultz wrote: > > /12) Do not put directors with bullet, lightning, fireball, etc. that > are a loop or continuous. Example: Do not have two directors, each > facing each other, with a bullet wall firing into them at the side. > / > > Why is this a problem? I saw what was written below it, but don't > bullets and fireballs and such explode after traveling for a bit? Nope, they travel between the directors until they hit something substantial such as another player, monster, summoned pet, etc. Numerous (quantities vary...) ball or bullets can wreak havoc on the server load. Plus, they can also results in a nasty surprise - image 10 (or several dozen for that matter) magic bullets all stacked on top of each other so they appear "as one" in the animation sequence; instead of taking 10pts of damage it could be several hundred. From alex_sch at telus.net Thu Sep 15 01:01:12 2005 From: alex_sch at telus.net (Alex Schultz) Date: Thu Sep 15 01:02:45 2005 Subject: [crossfire] mapguide/director question In-Reply-To: <4328F99C.7030308@real-time.com> References: <4328DB75.8090502@telus.net> <4328F99C.7030308@real-time.com> Message-ID: <43290E28.3030008@telus.net> Rick Tanner wrote: > Alex Schultz wrote: > >> >> /12) Do not put directors with bullet, lightning, fireball, etc. that >> are a loop or continuous. Example: Do not have two directors, each >> facing each other, with a bullet wall firing into them at the side. >> / >> >> Why is this a problem? I saw what was written below it, but don't >> bullets and fireballs and such explode after traveling for a bit? > > > Nope, they travel between the directors until they hit something > substantial such as another player, monster, summoned pet, etc. Actually, I'm afraid you're mistaken... I just tested on my private test server. They do disappear/explode after moving a bit without hitting anything (i.e. when director bouncing). A small fireball exploded about ~5 seconds of bouncing, and small bullet disappeared after about the same amount of time. I don't see how it could be that bad either: I'm testing firing missile swarm (about the most projectile intensive spell there is), into a tight 3 director loop, and my server barely gets up to 2% cpu usage. Large fireball fired as rapidly as can be by a signal player's natural casting can't push it over 1.3% cpu, and even with all this, the idle cpu usage is 1%. Really, unless lots of monsters are casting, or if it's meteor swarm with it's massive amount of fire, I don't see how this could be a problem. Alex Schultz From alex_sch at telus.net Thu Sep 15 01:13:56 2005 From: alex_sch at telus.net (Alex Schultz) Date: Thu Sep 15 01:14:45 2005 Subject: [crossfire] mapguide/director question In-Reply-To: <43290E28.3030008@telus.net> References: <4328DB75.8090502@telus.net> <4328F99C.7030308@real-time.com> <43290E28.3030008@telus.net> Message-ID: <43291124.6030602@telus.net> Alex Schultz wrote: > I don't see how it could be that bad either: I'm testing firing > missile swarm (about the most projectile intensive spell there is), > into a tight 3 director loop, and my server barely gets up to 2% cpu > usage. Large fireball fired as rapidly as can be by a signal player's > natural casting can't push it over 1.3% cpu, and even with all this, > the idle cpu usage is 1%. Really, unless lots of monsters are casting, > or if it's meteor swarm with it's massive amount of fire, I don't see > how this could be a problem. And one other curious statistic to add: I tested level 12 MS with that too, and no matter how much I tried I couldn't get cpu usage over 13%, However then I tried with level 112 and that brought it up to 100% cpu, due to the increase in number of meteors with level. Overall from what I can tell, directors have little effect on all this other than that they prevent if from hitting a exploding/disappearing for longer, which could be simulated anyways by casting out into the open in bigworld. Alex Schultz From mwedel at sonic.net Thu Sep 15 01:50:37 2005 From: mwedel at sonic.net (Mark Wedel) Date: Thu Sep 15 01:52:46 2005 Subject: [crossfire] mapguide/director question In-Reply-To: <43291124.6030602@telus.net> References: <4328DB75.8090502@telus.net> <4328F99C.7030308@real-time.com> <43290E28.3030008@telus.net> <43291124.6030602@telus.net> Message-ID: <432919BD.2070907@sonic.net> Alex Schultz wrote: > Alex Schultz wrote: > >> I don't see how it could be that bad either: I'm testing firing >> missile swarm (about the most projectile intensive spell there is), >> into a tight 3 director loop, and my server barely gets up to 2% cpu >> usage. Large fireball fired as rapidly as can be by a signal player's >> natural casting can't push it over 1.3% cpu, and even with all this, >> the idle cpu usage is 1%. Really, unless lots of monsters are casting, >> or if it's meteor swarm with it's massive amount of fire, I don't see >> how this could be a problem. > > > And one other curious statistic to add: > I tested level 12 MS with that too, and no matter how much I tried I > couldn't get cpu usage over 13%, However then I tried with level 112 and > that brought it up to 100% cpu, due to the increase in number of meteors > with level. > Overall from what I can tell, directors have little effect on all this > other than that they prevent if from hitting a exploding/disappearing > for longer, which could be simulated anyways by casting out into the > open in bigworld. This was changed in the spell redo - spells now have a range before they run out. So loops aren't quite as bad. However, have two directors pointing to each other will still be much worse than a player firing those same missiles on the bigworld. That is because whenever one of these objects move onto a space, it has to check all the other objects on the space to see if anything happens. So if you fire across the world maps, there will only be a few objects on each space the meteor has to check against. In comparison, in the director loop, it has to check on all the objects on the space, which is considerable (all the other meteors). And you have a whoel bunch, so this is happening a whole lot. So at some level, it isn't any worse if there is only one meteor going back and forth . But if you have 100 going back and forth, that hundreds of times worse than if those were being fired across an open map. From alex_sch at telus.net Thu Sep 15 02:32:22 2005 From: alex_sch at telus.net (Alex Schultz) Date: Thu Sep 15 02:32:46 2005 Subject: [crossfire] mapguide/director question In-Reply-To: <432919BD.2070907@sonic.net> References: <4328DB75.8090502@telus.net> <4328F99C.7030308@real-time.com> <43290E28.3030008@telus.net> <43291124.6030602@telus.net> <432919BD.2070907@sonic.net> Message-ID: <43292386.1050408@telus.net> Mark Wedel wrote: > So if you fire across the world maps, there will only be a few objects > on each space the meteor has to check against. > > In comparison, in the director loop, it has to check on all the > objects on the space, which is considerable (all the other meteors). > And you have a whoel bunch, so this is happening a whole lot. You seem to be implying that the meteors checking for other objects is the issue, however from what I've found in profiling it's all the flames checking all the other flames to see if they are a counterspell seems to be about 2/3 or so of the time. From what I've saw, most proposed solutions to this involved merging the flame objects so there's only one layer per square, however this would greatly complicate how they disappear and how the damage of each changes. However believe I have thought of a solution that would take much less effort and would shave off the time it takes for the counterspell checking: Have a "countermap" which lists the number of counterspell objects on each square of a map, when one counterspell object is added, it adds one to the correct spot in the array (or whatever data structure it is), and when removed counterspells subtract one from that spot on the array. Then the big loop that currently goes through every object on the square for counterspells only has to quickly check the "countermap". This does not completely get rid of the issue, though I feel this solution is the most efficient in gain vs. complexity. > So at some level, it isn't any worse if there is only one meteor > going back and forth . But if you have 100 going back and forth, that > hundreds of times worse than if those were being fired across an open > map. However, assuming it's the flames that are the big part of the problem and not the meteors themself, when they explode, they will explode in the same place and all the flames would have to check eachother being counterspells just as much as when the directors were affecting the meteors. Anyways, based on these results though, I would say that the circular spells thing should be fine so long as the changes to directors I'm making make it so meteors and other more potent ones wouldn't be affected by the directors. Alex Schultz From brenlally at gmail.com Thu Sep 15 21:01:46 2005 From: brenlally at gmail.com (Brendan Lally) Date: Thu Sep 15 21:03:05 2005 Subject: [crossfire] International talk like a Pirate day. Message-ID: <7903f03c05091519014bcc2094@mail.gmail.com> in preparation for international talk like a pirate day on monday, I have created a pirate_hat arch. Additionally I have a modified wolfsburg inn map, that is available to any server admins that want to use it here https://sourceforge.net/tracker/index.php?func=detail&aid=1292493&group_id=13833&atid=313833 The question I have is, where in the arch tree should the pirate hat go? Whilst it is a helmet, which would suggest armour/helmet as the correct location, it isn't designed to be generally available. Therefore there is some doubt as to whether it really belongs there. It has been suggested on IRC that I create a new directory for it called festive or holiday or something of that sort, but I am reluctant to do that without wider approval. From mwedel at sonic.net Thu Sep 15 23:00:34 2005 From: mwedel at sonic.net (Mark Wedel) Date: Thu Sep 15 23:01:07 2005 Subject: [crossfire] mapguide/director question In-Reply-To: <43292386.1050408@telus.net> References: <4328DB75.8090502@telus.net> <4328F99C.7030308@real-time.com> <43290E28.3030008@telus.net> <43291124.6030602@telus.net> <432919BD.2070907@sonic.net> <43292386.1050408@telus.net> Message-ID: <432A4362.9070006@sonic.net> Alex Schultz wrote: > Mark Wedel wrote: > >> So if you fire across the world maps, there will only be a few objects >> on each space the meteor has to check against. >> >> In comparison, in the director loop, it has to check on all the >> objects on the space, which is considerable (all the other meteors). >> And you have a whoel bunch, so this is happening a whole lot. > > > You seem to be implying that the meteors checking for other objects is > the issue, however from what I've found in profiling it's all the flames > checking all the other flames to see if they are a counterspell seems to > be about 2/3 or so of the time. From what I've saw, most proposed > solutions to this involved merging the flame objects so there's only one > layer per square, however this would greatly complicate how they > disappear and how the damage of each changes. However believe I have > thought of a solution that would take much less effort and would shave > off the time it takes for the counterspell checking: > Have a "countermap" which lists the number of counterspell objects on > each square of a map, when one counterspell object is added, it adds one > to the correct spot in the array (or whatever data structure it is), and > when removed counterspells subtract one from that spot on the array. > Then the big loop that currently goes through every object on the square > for counterspells only has to quickly check the "countermap". This does > not completely get rid of the issue, though I feel this solution is the > most efficient in gain vs. complexity. Its not really that simple however. It isn't only that the space in question has to be examined for counterspells - it is more generic - when an object is inserted, the objects on the space have to be examined to see if any of the objects on that space may somehow affect the inserted objects. For spells, counterspell is the most likely scenario, but directors and spinners are other possible cases. Likewise, the object being inserted has to check against objects currently on the space to see how it may effect them (burn them up, etc). Although that may actually be done in the spell code when it is actually inserting the object. The point being here is you just can't set up a counterspell map and say the check_walk_on code only needs to check that - doing that is sure to break some thing. A more likely fix might not be counterspells, but basically record the type/subtype of the object(s) on the space that have check_walk_on set (right only need to know there are two different types). The assumption being an object of the same type/subtype doesn't effect itself. Thus, if you get a square and the only objects with walk_on set are the same type of the object as we are inserting, we don't need to do any checking. When types are different, then we go through and see if there are directors, exits, counterspells, whatever. This would only take a few bytes - if there are 4 different types of objects on the space, we don't need to record the properties of all 4 - we just need to know that there are 4 different ones so have to go to old fallback. If there is only 1 type, we need to know that to check against what the new object is. From alex_sch at telus.net Thu Sep 15 23:42:51 2005 From: alex_sch at telus.net (Alex Schultz) Date: Thu Sep 15 23:43:07 2005 Subject: [crossfire] mapguide/director question In-Reply-To: <432A4362.9070006@sonic.net> References: <4328DB75.8090502@telus.net> <4328F99C.7030308@real-time.com> <43290E28.3030008@telus.net> <43291124.6030602@telus.net> <432919BD.2070907@sonic.net> <43292386.1050408@telus.net> <432A4362.9070006@sonic.net> Message-ID: <432A4D4B.3050604@telus.net> Mark Wedel wrote: > Alex Schultz wrote: > >> However believe I have thought of a solution that would take >> much less effort and would shave off the time it takes for the >> counterspell checking: >> Have a "countermap" which lists the number of counterspell objects on >> each square of a map, when one counterspell object is added, it adds >> one to the correct spot in the array (or whatever data structure it >> is), and when removed counterspells subtract one from that spot on >> the array. Then the big loop that currently goes through every object >> on the square for counterspells only has to quickly check the >> "countermap". This does not completely get rid of the issue, though I >> feel this solution is the most efficient in gain vs. complexity. > > > Its not really that simple however. True, what I suggested isn't simple, but it is simpler than any method I've thought of to merge all the fire objects created by a meteor swarm. > > It isn't only that the space in question has to be examined for > counterspells - it is more generic - when an object is inserted, the > objects on the space have to be examined to see if any of the objects > on that space may somehow affect the inserted objects. Indeed, though according to my profiling, the counterspell checking is by far the largest portion of this. > A more likely fix might not be counterspells, but basically record > the type/subtype of the object(s) on the space that have check_walk_on > set (right only need to know there are two different types). The > assumption being an object of the same type/subtype doesn't effect > itself. > > Thus, if you get a square and the only objects with walk_on set are > the same type of the object as we are inserting, we don't need to do > any checking. When types are different, then we go through and see if > there are directors, exits, counterspells, whatever. This would only > take a few bytes - if there are 4 different types of objects on the > space, we don't need to record the properties of all 4 - we just need > to know that there are 4 different ones so have to go to old > fallback. If there is only 1 type, we need to know that to check > against what the new object is. Hmmm... this sounds like it might be a good solution. However it should be noted that this wouldn't completely fix MS slowness of course, just fix one of the several reasons why it's so bad, which would be a good fix to do even if the other aspects of MS slowness (i.e. the raw amount of flame objects) were fixed. Alex Schultz From delbd at oma.be Fri Sep 16 03:07:59 2005 From: delbd at oma.be (David Delbecq) Date: Fri Sep 16 03:07:10 2005 Subject: [crossfire] International talk like a Pirate day. In-Reply-To: <7903f03c05091519014bcc2094@mail.gmail.com> References: <7903f03c05091519014bcc2094@mail.gmail.com> Message-ID: <200509161007.59467.delbd@oma.be> Le Vendredi 16 Septembre 2005 04:01, Brendan Lally a ?crit : > in preparation for international talk like a pirate day on monday, I > have created a pirate_hat arch. wtf is international talk like a pirate day? From antonoussik at gmail.com Fri Sep 16 05:07:29 2005 From: antonoussik at gmail.com (Anton Oussik) Date: Fri Sep 16 05:09:13 2005 Subject: [crossfire] International talk like a Pirate day. In-Reply-To: <200509161007.59467.delbd@oma.be> References: <7903f03c05091519014bcc2094@mail.gmail.com> <200509161007.59467.delbd@oma.be> Message-ID: > wtf is international talk like a pirate day? A day in the year when you talk like a pirate. Yarr! http://www.yarr.org.uk/ http://www.talklikeapirateday.com/ I think putting social clothing into its own section is a good idea. From brenlally at gmail.com Fri Sep 16 05:11:38 2005 From: brenlally at gmail.com (Brendan Lally) Date: Fri Sep 16 05:13:13 2005 Subject: [crossfire] International talk like a Pirate day. In-Reply-To: <200509161007.59467.delbd@oma.be> References: <7903f03c05091519014bcc2094@mail.gmail.com> <200509161007.59467.delbd@oma.be> Message-ID: <7903f03c05091603116eb601ce@mail.gmail.com> On 9/16/05, David Delbecq wrote: > wtf is international talk like a pirate day? September 19th. it is one day a year where everyone talks like a caricatured pirate. Primarily simply because it is funny to do so, You'll notice it next monday, message boards, newgroups, mailing lists etc, will be full of random Yarr!'s thrown into the middle of sentences. To be honest, I'm surprised you didn't notice it last year. ITLAPD homepage: http://www.talklikeapirate.com/piratehome.html wikipedia article: http://en.wikipedia.org/wiki/International_Talk_Like_A_Pirate_Day From temitchell at sympatico.ca Fri Sep 16 09:08:10 2005 From: temitchell at sympatico.ca (Todd Mitchell) Date: Fri Sep 16 09:07:19 2005 Subject: [crossfire] International talk like a Pirate day. In-Reply-To: <7903f03c05091603116eb601ce@mail.gmail.com> References: <7903f03c05091519014bcc2094@mail.gmail.com> <200509161007.59467.delbd@oma.be> <7903f03c05091603116eb601ce@mail.gmail.com> Message-ID: <432AD1CA.5060309@sympatico.ca> ITLPD is especially revered by us Pastafarians. > > From brenlally at gmail.com Fri Sep 16 18:58:25 2005 From: brenlally at gmail.com (Brendan Lally) Date: Fri Sep 16 18:59:26 2005 Subject: [crossfire] International talk like a Pirate day. In-Reply-To: References: <7903f03c05091519014bcc2094@mail.gmail.com> <200509161007.59467.delbd@oma.be> Message-ID: <7903f03c05091616584e61efac@mail.gmail.com> On 9/16/05, Anton Oussik wrote: > I think putting social clothing into its own section is a good idea. A seperate directory under /arch/ or a subsection of an existing one (/arch/misc maybe)? From kirschbaum at myrealbox.com Sat Sep 17 04:27:26 2005 From: kirschbaum at myrealbox.com (Andreas Kirschbaum) Date: Sat Sep 17 04:27:36 2005 Subject: [crossfire] Re: [Crossfire-cvs] CVS commit: client In-Reply-To: References: Message-ID: <20050917092725.GA30626@kirschbaum.myrealbox.com> crossfire-cvs-admin@lists.sourceforge.net wrote: > Module Name: client > Committed By: ryo_saeba > Date: Mon Sep 5 20:16:53 UTC 2005 [...] > Index: client/ChangeLog [...] > + common/mapdata.c: remove parasite #define NDEBUG [...] > Index: client/common/mapdata.c > diff -c client/common/mapdata.c:1.1 client/common/mapdata.c:1.2 > *** client/common/mapdata.c:1.1 Wed Aug 31 14:57:23 2005 > --- client/common/mapdata.c Mon Sep 5 13:16:53 2005 > *************** > *** 21,27 **** > The author can be reached via e-mail to crossfire-devel@real-time.com > */ > > - #define NDEBUG > #include > > #include "client.h" > --- 21,26 ---- It was very intentional that I left in this #define NDEBUG: The module mapdata contains quite a few assert() statements. Some functions (notably mapdata_face() and mapdata_bigface()) may be called very often in certain situations. (These two functions probably will be called more than 1000 times each second if the player is running and uses a large view area.) I'm fairly sure that none of these assert() statements will ever trigger, but I did not remove them just because they could be useful for debugging at a later time. To not waste (cpu) resources, I just disabled them. This is why I left in the "parasite #define NDEBUG" just before "#include ": Ansi C specifies that if the preprocessor symbol NDEBUG is defined at the time is included, the macro assert() does nothing at all. That is, after the removal now all the assert() statements are enabled (thus probably wasting lots of cpu time). OTOH, I didn't feel to just disable all assert() statements in the whole client by adding -DNDEBUG to the build system since I think assert() statements should always be enabled if possible. From nicolas.weeger at laposte.net Sat Sep 17 12:18:09 2005 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sat Sep 17 12:21:43 2005 Subject: [crossfire] Re: [Crossfire-cvs] CVS commit: client In-Reply-To: <20050917092725.GA30626@kirschbaum.myrealbox.com> References: <20050917092725.GA30626@kirschbaum.myrealbox.com> Message-ID: <432C4FD1.2070001@laposte.net> > It was very intentional that I left in this #define NDEBUG: Well, time to do some magic to have make --debug and make --nodebug? :) More seriously, assert are good to have. If you want to put the define back, then please put it between #ifndef WIN32 / #endif :) (NDEBUG is defined in Windows during Release build, so redefinition warning) Ryo From brenlally at gmail.com Sat Sep 17 21:23:09 2005 From: brenlally at gmail.com (Brendan Lally) Date: Sat Sep 17 21:23:50 2005 Subject: [crossfire] autopackage Message-ID: <7903f03c05091719232110f21f@mail.gmail.com> Inspired by a comment that Leaf made on IRC concerning klik, I had a look at autopackage as a way to distribute crossfire client. The hope is that it could provide an alternitive to building from source or comically outdated distro packages, and a way to provide snapshot releases as Ryo currently does on windows. After a bit of hair playing with the autopackage spec I have something that seems to run ok. Since it is too large for the tracker, and not suitable for widespread public release, I have placed the package, and the file from which it is generated http://cavetroll.uwcs.co.uk/crossfire-client-1.8-snapshot1.x86.package and http://cavetroll.uwcs.co.uk/default.apspec.in respectively. I would be interested to know if they actually work properly/at all on other systems. (expect these files to hang around for only a few weeks until I get bored, or run low on disk space) http://autopackage.org/docs/howto-install/ explains what this .package file is and what to do with it. regardless there appear to be two issues. 1) the .desktop file doesn't do anything. (this may be an issue with my system) 2) crossfire-client doesn't appear to be relocatable, whilst this isn't a problem for running gcfclient, it is for getting it to use the sound server (or bundling images with the client, which I haven't yet attempted) Notwithstanding these two points, does this seem like something worth pursuing? From brenlally at gmail.com Sun Sep 18 22:34:46 2005 From: brenlally at gmail.com (Brendan Lally) Date: Sun Sep 18 22:36:15 2005 Subject: [crossfire] Re: autopackage In-Reply-To: <7903f03c05091719232110f21f@mail.gmail.com> References: <7903f03c05091719232110f21f@mail.gmail.com> Message-ID: <7903f03c050918203445ac7798@mail.gmail.com> On 9/18/05, Brendan Lally wrote: > regardless there appear to be two issues. > 1) the .desktop file doesn't do anything. (this may be an issue with my system) I fixed this problem, or at least worked around it. An updated package is here, http://cavetroll.uwcs.co.uk/crossfire-client-1.8snapshot-1.x86.package md5sum 999aa3211771b83b7cf65cb35595b0f6 > 2) crossfire-client doesn't appear to be relocatable, whilst this > isn't a problem for running gcfclient, it is for getting it to use the > sound server (or bundling images with the client, which I haven't yet > attempted) This is a much more difficult problem to solve, I tried playing with binreloc, but couldn't make it work properly. So I took the easy option and compiled with --disable-sound From alex_sch at telus.net Wed Sep 21 02:24:47 2005 From: alex_sch at telus.net (Alex Schultz) Date: Wed Sep 21 02:25:18 2005 Subject: [crossfire] Buildable Land Plots Message-ID: <43310ABF.2010908@telus.net> Hi, For a while I've been hearing on and off about people thinking about making buildable land plots in bigworld. I'm not sure who to credit for the origional idea, but I've taken some time to plan out one possible way of doing it. Here's the steps to buildable land plots according what I've been thinking would work well. In this plan, I try to keep every feature that could potentially be useful outside of the bigworld land plots in the server code as opposed to python just to make it flexable for map makers to use such features in the future for other things. So here's what I've been thinking would be a good way to impliment buildable land plots adding feature by feature. -Add 'global unique' maps: -permenantly stored like unique, only it's stored in a different location and is shared between all players -existing permenant maps (i.e. guild) like maps shouldn't be used because these need are generated while running like unique or random maps, so near the unique maps in their own place makes sence. -Random map changes: -Allow random map generator to make unique maps (is this already possible?) -Allow random map generator to make 'gobal unique' maps -Create 'open space' map style, which generates no walls except for the outer border. -Building changes: -Allow maps to specify in their header that building is restricted -'Building passes' allow building in these areas (can be made as an invisible force, or as a card type object, to be flexible) -Fix overlays: -Fix conflicts with weather -Fix other misc bugs -Write python glue code for details of land plots that can't be used as features elsewhere: -Python for making the map entrance, and the building passes -Make random map styles ISSUES: -Where should land plots be buildable? -When a map maker builds over a land plot entrance, what happens to the land plot? -What (if anything) should be done about the potential issue of players trapping eachother in buildable areas. Supporting (not needed or important, but would enhance the experience of buildable land plots) details: -Buildable savebeds -Buildable lock/key pairs -Buildable shops -Buildable teleporters -Buildable crafting stations (?) -New buildable things (i.e. new walls, grass, etc.) Comments? Suggestions? Any help working on any parts of this would be great. Thanks, Alex Schultz From mikeeusaaa at yahoo.com Wed Sep 21 02:49:03 2005 From: mikeeusaaa at yahoo.com (Mitch Obrian) Date: Wed Sep 21 02:49:17 2005 Subject: [crossfire] Buildable Land Plots In-Reply-To: <43310ABF.2010908@telus.net> Message-ID: <20050921074903.64671.qmail@web61020.mail.yahoo.com> # -When a map maker builds over a land plot entrance, #what happens to #the land plot? Land plot is deleted? (It's a tough world out there :) ) --- Alex Schultz wrote: > Hi, > > For a while I've been hearing on and off about > people thinking about > making buildable land plots in bigworld. I'm not > sure who to credit for > the origional idea, but I've taken some time to plan > out one possible > way of doing it. Here's the steps to buildable land > plots according what > I've been thinking would work well. In this plan, I > try to keep every > feature that could potentially be useful outside of > the bigworld land > plots in the server code as opposed to python just > to make it flexable > for map makers to use such features in the future > for other things. So > here's what I've been thinking would be a good way > to impliment > buildable land plots adding feature by feature. > > -Add 'global unique' maps: > -permenantly stored like unique, only it's > stored in a different > location and is shared between all players > -existing permenant maps (i.e. guild) like maps > shouldn't be used > because these need are generated while running like > unique or random > maps, so near the unique maps in their own place > makes sence. > > -Random map changes: > -Allow random map generator to make unique maps > (is this already > possible?) > -Allow random map generator to make 'gobal > unique' maps > -Create 'open space' map style, which generates > no walls except for > the outer border. > > -Building changes: > -Allow maps to specify in their header that > building is restricted > -'Building passes' allow building in these > areas (can be made as > an invisible force, or as a card type object, to be > flexible) > > -Fix overlays: > -Fix conflicts with weather > -Fix other misc bugs > > -Write python glue code for details of land plots > that can't be used as > features elsewhere: > -Python for making the map entrance, and the > building passes > > -Make random map styles > > ISSUES: > -Where should land plots be buildable? > -When a map maker builds over a land plot > entrance, what happens to > the land plot? > -What (if anything) should be done about the > potential issue of > players trapping eachother in buildable areas. > > Supporting (not needed or important, but would > enhance the experience of > buildable land plots) details: > -Buildable savebeds > -Buildable lock/key pairs > -Buildable shops > -Buildable teleporters > -Buildable crafting stations (?) > -New buildable things (i.e. new walls, grass, > etc.) > > Comments? Suggestions? Any help working on any parts > of this would be great. > > Thanks, > Alex Schultz > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From antonoussik at gmail.com Wed Sep 21 03:51:29 2005 From: antonoussik at gmail.com (Anton Oussik) Date: Wed Sep 21 03:53:17 2005 Subject: [crossfire] Buildable Land Plots In-Reply-To: <43310ABF.2010908@telus.net> References: <43310ABF.2010908@telus.net> Message-ID: On 9/21/05, Alex Schultz wrote: > ISSUES: > -Where should land plots be buildable? I would say allow anywhere, on world map, but not in a city. I would also introduce some sort of land tax for every plot you have built up. Also when you first build on the plot, you "buy" it, so you pay the money, and get get a permit to build there. This raises some new issues: - Where/how to pay to buy a plot - How to determine who owns a given plot, and who the tax should be charged to - How to accomplish the previous two and keep the maps sellable between players If you do not pay up the land tax your most expensive plot wil be demolished, and the money salvaged used to pay tax for remaining properties. This carries on until there are no more plots to sell. I can see several ways of calculating the tax for a given plot. Either per region (so in scorn charges 800gold/plot/day, brest may charge 300, and navar 450. This approach would work but be inflexible. Another approach I can think of is to have a base price of plot, and then raise price for every nearby developed plot within surrounding 5-9 squares or so. Additionally extra tax could be imposed for every object stored in a plot as a way of cutting down on clutter on maps. If it was really wanted the object tax (or land use tax) could be made exponential after some time. > -When a map maker builds over a land plot entrance, what happens to > the land plot? Do not allow building over the entrance. That is a silly thing to do and would only be attempted by accident. > -What (if anything) should be done about the potential issue of > players trapping eachother in buildable areas. I can see this could become a major DM pain, but can not see much that can be done - there is already word of recall. Perhaps someone else can come up with a better idea for this. Additionally I have a few more ideas/issues to add to this. - Buildable altars - Buildable map entrances/exits? - When a plot is developed change the face on world map to reflect that. - (this one is harder) If a player buys a 2x2 set of plots, should they be able to build a house 4 times as big, and should the world map introduce a large building into itself whaen that happens? From brenlally at gmail.com Wed Sep 21 06:41:18 2005 From: brenlally at gmail.com (Brendan Lally) Date: Wed Sep 21 06:45:19 2005 Subject: [crossfire] Buildable Land Plots In-Reply-To: References: <43310ABF.2010908@telus.net> Message-ID: <7903f03c05092104417e12d951@mail.gmail.com> On 9/21/05, Anton Oussik wrote: > On 9/21/05, Alex Schultz wrote: > > ISSUES: > > -Where should land plots be buildable? > I would say allow anywhere, on world map, but not in a city. This ties into the building over an entrance problem. Basically you restrict map-makers too much (you also allow potentially for maps on inaccessible islands off the coast, or surrounded by impassible mountains) > This raises some new > issues: > - Where/how to pay to buy a plot python script that checks the list of available squares, and either picks one of an appropriate price, or picks one at random (maybe with a little history stored, so that the more plots are purchased in each area the higher the prices go) > - How to determine who owns a given plot, and who the tax should > be charged to if the map header that limits control is set, then simply call that 'owner' then the only people who can build is a player who has a name that matches 'owner' or someone with a building permit, which has a race field that is 'owner' (these would be given to the player who brought the plot, probably at a fee. > - How to accomplish the previous two and keep the maps sellable > between players there would need to be a trade array, of outstanding trades that would take effect on next map load (either that or load on the fly, but that is unneccessary). Probably a python script could be used to populate such a table. > If you do not pay up the land tax your most expensive plot wil be > demolished, and the money salvaged used to pay tax for remaining > properties. This carries on until there are no more plots to sell. surely, least expensive that is over the value of the debt owed? Although I'm inclined to go with random, whilst the above might be how baliffs are /supposed/ to work, I don't think they really do in practise. > I can see several ways of calculating the tax for a given plot. Either > per region (so in scorn charges 800gold/plot/day, brest may charge > 300, and navar 450. This approach would work but be inflexible. > > Another approach I can think of is to have a base price of plot, and > then raise price for every nearby developed plot within surrounding > 5-9 squares or so. Don't know that I like this, it seems a fairer metric would be something like number of standard entrances within 20/50/100 squares (and therefore proximity to town) > Additionally extra tax could be imposed for every object stored in a > plot as a way of cutting down on clutter on maps. If it was really > wanted the object tax (or land use tax) could be made exponential > after some time. this requires yet more big arrays, with the entry for each owned map updated either periodically or when it is being saved out. As it is, I think probably an asset tax would be more fair, I can't really see how having a thousand arrows would lead to a greater tax burden than 900 artifacts. > > -When a map maker builds over a land plot entrance, what happens to > > the land plot? > Do not allow building over the entrance. That is a silly thing to do > and would only be attempted by accident. How do you intend to know, from the map editor, where entrances have been sited? If you allow building anywhere that isn't a city, then there is no obvious place new maps can be added, ever. (also you could have buildings appearing in the middle of roads, this would not be very clever). the way I see it there are three approaches, either use a list of coordinates or maps, or a map header, or a map square (can develop) the map square could probably be set in the archetypes on grass, that wouldn't be so bad, but then anytime a valid plot coordinate wanted to be assigned, there would be a need to search through the map files directly, which is a lot of wasted I/O. another approach is map headers, this has the advantage of only needing to search the first 20-odd lines of the map file, but they still all need to be opened. The first approach listed would be the quickest, having an external list, but then there are other issues involved in keeping such a list up to date. > - When a plot is developed change the face on world map to reflect that. > - (this one is harder) If a player buys a 2x2 set of plots, should > they be able to build a house 4 times as big, and should the world map > introduce a large building into itself whaen that happens? assuming the names are systematic, simply set the tile paths north, south, east and west to what the map names of the new maps would be, if they exist, the maps will tile, if not they won't. From alex_sch at telus.net Wed Sep 21 08:22:44 2005 From: alex_sch at telus.net (Alex Schultz) Date: Wed Sep 21 08:23:18 2005 Subject: [crossfire] Buildable Land Plots In-Reply-To: References: <43310ABF.2010908@telus.net> Message-ID: <43315EA4.5000808@telus.net> Anton Oussik wrote: >> -When a map maker builds over a land plot entrance, what happens to >>the land plot? >> >> >Do not allow building over the entrance. That is a silly thing to do >and would only be attempted by accident. > > No, I mean, if one builds a land plot somewhere, but then outside of the game a map maker changes that place in bigworld, and does something add a city there or something else the interferes with with the land plot of a player. >> -What (if anything) should be done about the potential issue of >>players trapping eachother in buildable areas. >> >> >I can see this could become a major DM pain, but can not see much that >can be done - there is already word of recall. Perhaps someone else >can come up with a better idea for this. > > Yes, there's already word of recall, however players can indirectly create no_magic/no_prayer areas by use of open gates. Hopefully someone can come up with a better idea for dealing with this. > - When a plot is developed change the face on world map to reflect that. > > Yes, that would be difficult, but the best way to do that would probably be with the python scripts. > - (this one is harder) If a player buys a 2x2 set of plots, should >they be able to build a house 4 times as big, and should the world map >introduce a large building into itself whaen that happens? > I think it would be neat if they could, though it would take a bit of effort to accomplish, probably through use of python to set the tiling of the maps would be best. Alex Schultz From nicolas.weeger at laposte.net Wed Sep 21 08:50:24 2005 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Wed Sep 21 08:51:20 2005 Subject: [crossfire] Buildable Land Plots Message-ID: Hello. Your ideas about building on land sound fun, let's hope we can do something on that effect :) Just a note: if you intend to have land building be part of game, imo do it totally part of the server code, or do it totally through Python (or a separate plugin, for that matter). Remember Python is *optional*, we wouldn't want someone to have part of building (since in server core) but not some important part (in plugin) ^_- Ryo Acc?dez au courrier ?lectronique de La Poste : www.laposte.net ; 3615 LAPOSTENET (0,34?/mn) ; t?l : 08 92 68 13 50 (0,34?/mn) From alex_sch at telus.net Wed Sep 21 19:31:59 2005 From: alex_sch at telus.net (Alex Schultz) Date: Wed Sep 21 19:33:28 2005 Subject: [crossfire] Buildable Land Plots In-Reply-To: References: Message-ID: <4331FB7F.2010107@telus.net> Nicolas Weeger wrote: >Hello. > >Your ideas about building on land sound fun, let's hope we can >do something on that effect :) > >Just a note: if you intend to have land building be part of >game, imo do it totally part of the server code, or do it >totally through Python (or a separate plugin, for that >matter). Remember Python is *optional*, we wouldn't want >someone to have part of building (since in server core) but >not some important part (in plugin) ^_- > >Ryo > True, but in any case though, I'll be starting on the changes that that are useful for things other than the plots first, and those will be written in C, and whether the plot-specific parts are written in python on not, they will depend on the nice general changes (i.e. 'global unique' maps). So in other words, it will probably a be a while till I get to that stage anyways. Anyways, Now that I think about it, making the parts that are specific to the land plots as a separate plugin might be a good idea. Hmm.. really a even simpler way to think about 'global unique' maps then my original explanation is as (optionally permanent) maps created from templates. And when applying unique or 'global unique' maps to the random map generator, it just makes the random map generator the template for the unique/'global unique' map. Alex Schultz From temitchell at sympatico.ca Wed Sep 21 22:40:46 2005 From: temitchell at sympatico.ca (Todd Mitchell) Date: Wed Sep 21 22:39:32 2005 Subject: [crossfire] Buildable Land Plots In-Reply-To: <4331FB7F.2010107@telus.net> References: <4331FB7F.2010107@telus.net> Message-ID: <1127360446.3506.27.camel@oberon.kameria> A long time ago I started working on something for buildings. The synopsys is: You would add a few new arches: a ZONE arch, a special EXIT arch and BLUEPRINT arch. Map makers would add zone arches (a subtype of altars) to the maps to designate where homes could be built, players would go to a store and buy a blueprint for a house (different house types naturally), and when they stood on the zone and applied the bluprint, two things would happen - first a special unique exit would be created which was not a traditional unique exit, but a unique object that was an exit* This would mean that as a unique object, it would be saved on the map it was placed on. This exit would point to a newly created map in /var/crossfire/maps The second thing of course was that a map of the proper type would be created in /var/crossfire/maps. These maps would be like guild maps in that they would have unique areas but would be sharable (you could invite other player in). The player would have a deed to the property which activated most of the gateways and inventory checkers giving them access to all the rooms of the house, while guests would only be allowed into the main rooms. Variations on this theme would allow new guilds to be built and even churches for the religious folk. That's the basic gist of things - there was some idea of having different zones allowing different buildings or having four joined zones allowing bigger building to be created. Here are examples of the arches: #define ALTAR_BUILDING 1 /*subtype of ALTAR*/ zone.arc: Object zone name lotforsale type 18 subtype 1 face goldmat.111 color_fg brown no_pick 1 editable 2 visibility 100 end #define BUILDING_BLUEPRINT 129 bprint_house.arc: Object bprint_house name house blueprint face bprint.111 race scrolls nrof 1 type 129 material 0 value 34 weight 350 editable 128 magicmap white name_pl blueprints client_type 1041 end #define EXIT_BUILDING 1 /*subtype of EXIT*/ b_house.arc: Object b_house type 66 subtype 1 face house_3.111 color_fg brown no_pick 1 editable 2 unique 1 visibility 100 end * I changed enter_exit in main.c so exit subtype 1 (EXIT_BUILDING) did not automatically make an exit to a unique map, but was a unique object which happened to be an exit. else if (exit_ob->subtype != EXIT_BUILDING && QUERY_FLAG(exit_ob, FLAG_UNIQUE)) { enter_unique_map(op, exit_ob); I didn't get very far with it but I have a few house templates and there are probably a lot of over optimistic postings in the archives about it. On Wed, 2005-21-09 at 18:31 -0600, Alex Schultz wrote: > Nicolas Weeger wrote: > > >Hello. > > > >Your ideas about building on land sound fun, let's hope we can > >do something on that effect :) > > > >Just a note: if you intend to have land building be part of > >game, imo do it totally part of the server code, or do it > >totally through Python (or a separate plugin, for that > >matter). Remember Python is *optional*, we wouldn't want > >someone to have part of building (since in server core) but > >not some important part (in plugin) ^_- > > > >Ryo > > > True, but in any case though, I'll be starting on the changes that that > are useful for things other than the plots first, and those will be > written in C, and whether the plot-specific parts are written in python > on not, they will depend on the nice general changes (i.e. 'global > unique' maps). So in other words, it will probably a be a while till I > get to that stage anyways. Anyways, Now that I think about it, making > the parts that are specific to the land plots as a separate plugin might > be a good idea. > > Hmm.. really a even simpler way to think about 'global unique' maps then > my original explanation is as (optionally permanent) maps created from > templates. And when applying unique or 'global unique' maps to the > random map generator, it just makes the random map generator the > template for the unique/'global unique' map. > > Alex Schultz > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire -- Todd Mitchell From kirschbaum at myrealbox.com Fri Sep 23 17:07:11 2005 From: kirschbaum at myrealbox.com (Andreas Kirschbaum) Date: Fri Sep 23 17:08:14 2005 Subject: [crossfire] Re: [Crossfire-cvs] CVS commit: client In-Reply-To: <432C4FD1.2070001@laposte.net> References: <20050917092725.GA30626@kirschbaum.myrealbox.com> <432C4FD1.2070001@laposte.net> Message-ID: <20050923220711.GA32382@kirschbaum.myrealbox.com> Nicolas Weeger wrote: > > It was very intentional that I left in this #define NDEBUG: > > Well, time to do some magic to have make --debug and make --nodebug? :) > More seriously, assert are good to have. Generally speaking, I think assert statements should normally not be disabled at all, particularly not for release builds: if an assert statement actually should fail, the program contains a very serious logic error. Therefore it is not sensible to continue (and probably crash shortly afterwards without printing a sensible error message). OTOH, if continuation is possible or even sensible, it should not be an assert statement but an if statement which then calls LOG(LOG_ERROR,...) or LOG(LOG_WARNING,...). > If you want to put the define back, then please put it between #ifndef > WIN32 / #endif :) I don't think this is a "WIN32" feature. Therefore I'm very reluctant to add yet another #ifdef WIN32 block. > (NDEBUG is defined in Windows during Release build, so redefinition > warning) I fail to see why the compiler should emit a warning at all: the Ansi C standard explicitly allows macro redefinition if (and only if) the two definitions are identical (ignoring white space differences). Therefore I suspect that the WIN32 build system does not define the macro NDEBUG as the empty string. From leaf at real-time.com Fri Sep 23 19:13:40 2005 From: leaf at real-time.com (Rick Tanner) Date: Fri Sep 23 19:14:27 2005 Subject: [crossfire] Crossfire web fourm and crossfire.metalforge.net server offline - hardware failure In-Reply-To: <431FB726.4040005@real-time.com> References: <431FB726.4040005@real-time.com> Message-ID: <43349A34.5090605@real-time.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Crossfire Web Forum (Messageboard) is back online and at a new location. http://forum.metalforge.net Hardware failure took the forum down originally, then there were numerous PHP and MySQL issues with moving the forum to a different server, which were resolved a few moments ago. Thanks for your patience and understanding during this hectic transition. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDNJo0hHyvgBp+vH4RAj6RAKCCCp2SnluR0ejmXFYTmDGpIzMuYgCfQHML LWWIOd1VAnX5AdfrWV5CrpQ= =3VaP -----END PGP SIGNATURE----- From nicolas.weeger at laposte.net Sat Sep 24 02:43:00 2005 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sat Sep 24 02:46:25 2005 Subject: [crossfire] Crossfire web fourm and crossfire.metalforge.net server offline - hardware failure In-Reply-To: <43349A34.5090605@real-time.com> References: <431FB726.4040005@real-time.com> <43349A34.5090605@real-time.com> Message-ID: <43350384.9050908@laposte.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > The Crossfire Web Forum (Messageboard) is back online and at a new location. > > http://forum.metalforge.net Yes! Many thanks for all the work :) Ryo -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDNQOBk4bbdCBVlpERAmYPAKCDVOXnJU87bo2witiA67uYBN4DwwCgnbtL V+qykTHocOAaRR0U3qYHSlU= =exDz -----END PGP SIGNATURE----- From nicolas.weeger at laposte.net Sat Sep 24 02:49:02 2005 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sat Sep 24 02:52:25 2005 Subject: [crossfire] Re: [Crossfire-cvs] CVS commit: client In-Reply-To: <20050923220711.GA32382@kirschbaum.myrealbox.com> References: <20050917092725.GA30626@kirschbaum.myrealbox.com> <432C4FD1.2070001@laposte.net> <20050923220711.GA32382@kirschbaum.myrealbox.com> Message-ID: <433504EE.3030507@laposte.net> > Generally speaking, I think assert statements should normally not be > disabled at all, particularly not for release builds: if an assert > statement actually should fail, the program contains a very serious > logic error. Therefore it is not sensible to continue (and probably > crash shortly afterwards without printing a sensible error message). > OTOH, if continuation is possible or even sensible, it should not be an > assert statement but an if statement which then calls LOG(LOG_ERROR,...) > or LOG(LOG_WARNING,...). Well, we disagree here, i guess :) For me assert() are there to debug the code, so should be turned off when doing releases. Which is incidentally what I do for Windows ^_- assert() are there to make sure your function is called correctly, to enforce arguments and such are ok - in release, you're expected to not have that behaviour. > I don't think this is a "WIN32" feature. Therefore I'm very reluctant to > add yet another #ifdef WIN32 block. Then don't readd it? > I fail to see why the compiler should emit a warning at all: the Ansi C > standard explicitly allows macro redefinition if (and only if) the two > definitions are identical (ignoring white space differences). Therefore > I suspect that the WIN32 build system does not define the macro NDEBUG > as the empty string. It is defined as empty string. Ryo From kirschbaum at myrealbox.com Sun Sep 25 04:24:56 2005 From: kirschbaum at myrealbox.com (Andreas Kirschbaum) Date: Sun Sep 25 04:26:50 2005 Subject: [crossfire] Unbalanced spell types Message-ID: <20050925092456.GA27655@kirschbaum.myrealbox.com> Currently, for two similar monsters that differ only in size (number of tiles they occupy), some spells hit the larger monster (much) harder. This is due to the fact that (for example) cone spells hit all monster parts individually. Each hit does the same (i.e. full) damage. Hence, a 2x1 sized monster can be hit twice by only one spell. The biggest monster I'm aware of is a Greater Demon. Its size is 42 tiles, therefore a fully hitting spell deals 42 times the damage compared to a 1x1 sized monster. To me, this is not the right behavior because it weakens big monsters against some spells. And it's not obvious to a map maker that monster size does matter. Besides that, you cannot really fix such a monster: if you just add more hp, it also becomes harder to kill with (say) melee or bullet spells. As a solution, I propose to scale down the damage done by the following spells: destruction explosion effects cone spells aura spells earth to dust I think the damage should be scaled down by the monster size (measured in tiles it occupies). This would mean a spell deals full damage only if it hits the whole monster (i.e. the spell covers all monster tiles). All other spells should not be affected by monster size, including: ball lightning bolt spells bullet spells Note that bolt spells currently do have the same problem and deal different damage depending on how you hit the monster: hitting a hill giant vertically will do double damage compared to hitting it horizontally. For this spell type I cannot think of a simple solution that works correctly: just scaling down by either MIN(monster width, monster height) or MAX(monster width, monster height) either does not fix the problem, or weakens bolt spells for no apparent reason (to the player). Therefore, I think bolt spells should be ignored for now. From kirschbaum at myrealbox.com Sun Sep 25 06:57:06 2005 From: kirschbaum at myrealbox.com (Andreas Kirschbaum) Date: Sun Sep 25 06:58:53 2005 Subject: [crossfire] Re: [Crossfire-cvs] CVS commit: maps-bigworld/scorn/temples In-Reply-To: References: Message-ID: <20050925115706.GA1488@kirschbaum.myrealbox.com> crossfire-cvs-admin@lists.sourceforge.net wrote: > Module Name: maps-bigworld > Committed By: eracc > Date: Wed May 25 23:15:01 UTC 2005 [...] > Log Message: > Updated Scorn temples to level 120 so high level players cannot reconsecrate them and cause DM headaches. [...] > Index: maps-bigworld/scorn/temples/gnarg > diff -c maps-bigworld/scorn/temples/gnarg:1.3 maps-bigworld/scorn/temples/gnarg:1.4 > *** maps-bigworld/scorn/temples/gnarg:1.3 Tue Mar 15 13:44:15 2005 > --- maps-bigworld/scorn/temples/gnarg Wed May 25 16:15:01 2005 > *************** > *** 384,389 **** > --- 384,390 ---- > y 4 > end > arch altar_gnarg > + level 120 > x 5 > y 4 > end Is this really the correct fix for this problem? Wouldn't it be better to update the holy altar archetypes and let the individual altars inherit level 120? After all, it's just too easy for a map maker to forget to set the level to 120. (In fact, despite this patch the world still contains about 80 level 100 altars, a few of them actually are located Scorn, Navar City, and other easily reachable maps.) From alex_sch at telus.net Sun Sep 25 09:27:27 2005 From: alex_sch at telus.net (Alex Schultz) Date: Sun Sep 25 09:28:55 2005 Subject: [crossfire] Re: [Crossfire-cvs] CVS commit: maps-bigworld/scorn/temples In-Reply-To: <20050925115706.GA1488@kirschbaum.myrealbox.com> References: <20050925115706.GA1488@kirschbaum.myrealbox.com> Message-ID: <4336B3CF.1080006@telus.net> Andreas Kirschbaum wrote: >crossfire-cvs-admin@lists.sourceforge.net wrote: > > >>Log Message: >>Updated Scorn temples to level 120 so high level players cannot reconsecrate them and cause DM headaches. >> >> >Is this really the correct fix for this problem? Wouldn't it be better >to update the holy altar archetypes and let the individual altars >inherit level 120? After all, it's just too easy for a map maker to >forget to set the level to 120. (In fact, despite this patch the world >still contains about 80 level 100 altars, a few of them actually are >located Scorn, Navar City, and other easily reachable maps.) > > I believe the logic of why it was done that way was because reconsecrating altars in dungeons would not be a significant DM headache or issue. Really, I have never seen or heard of ones in dungeons being an issue, and also reconsecrating altars in dungeons is potentially useful. I do believe though that it would be beneficial if the faces of reconsecrated altars was changed to match how the altar changed. Alex Schultz From eracclists at bellsouth.net Sun Sep 25 18:50:20 2005 From: eracclists at bellsouth.net (ERACC) Date: Sun Sep 25 18:51:04 2005 Subject: [crossfire] Re: [Crossfire-cvs] CVS =?iso-8859-1?q?commit=3A=09maps-bigworld/scorn/temples?= In-Reply-To: <4336B3CF.1080006@telus.net> References: <20050925115706.GA1488@kirschbaum.myrealbox.com> <4336B3CF.1080006@telus.net> Message-ID: <200509251850.20866.eracclists@bellsouth.net> On Sunday 25 September 2005 09:27 am Alex Schultz wrote: > Andreas Kirschbaum wrote: > > >crossfire-cvs-admin@lists.sourceforge.net wrote: > > > >>Log Message: > >>Updated Scorn temples to level 120 so high level players cannot reconsecrate them and cause DM headaches. > >> > >Is this really the correct fix for this problem? Wouldn't it be better > >to update the holy altar archetypes and let the individual altars > >inherit level 120? After all, it's just too easy for a map maker to [...] > > > I believe the logic of why it was done that way was because > reconsecrating altars in dungeons would not be a significant DM headache [...] Alex is correct. The only altars that were truly a problem were the ones in Scorn where a noob may have no idea to watch out for an altar in a temple being reconsecrated. Just modifying those maps is enough to solve the problem. Once a noob is exploring outside Scorn, well, the noob is on his/her own then. No more coddling. ;-) Gene Alexander -- Linux era4.eracc.UUCP 2.6.8.1-12mdk i686 18:45:20 up 130 days, 19:26, 8 users, load average: 0.07, 0.07, 0.08 ERA Computer Consulting - http://www.eracc.com/ eCS, Linux, FreeBSD, OpenServer & UnixWare resellers From mwedel at sonic.net Sun Sep 25 22:43:43 2005 From: mwedel at sonic.net (Mark Wedel) Date: Sun Sep 25 22:45:08 2005 Subject: [crossfire] Unbalanced spell types In-Reply-To: <20050925092456.GA27655@kirschbaum.myrealbox.com> References: <20050925092456.GA27655@kirschbaum.myrealbox.com> Message-ID: <43376E6F.8070901@sonic.net> Andreas Kirschbaum wrote: > I think the damage should be scaled down by the monster size (measured > in tiles it occupies). This would mean a spell deals full damage only if > it hits the whole monster (i.e. the spell covers all monster tiles). Do note you need to cover rounding issues. In the case of the greater demon (42 spaces), that could be a considerable amount of damage. And ideally, this should be handled after damage (or maybe as part of) damage reduction from protections is taken into account, since that also has rounding errors (but I think those might have been fixed by randomly determing if the remainder does damage). > Note that bolt spells currently do have the same problem and deal > different damage depending on how you hit the monster: hitting a hill > giant vertically will do double damage compared to hitting it > horizontally. > > For this spell type I cannot think of a simple solution that works correctly: > just scaling down by either MIN(monster width, monster height) or > MAX(monster width, monster height) either does not fix the problem, or weakens > bolt spells for no apparent reason (to the player). Well, the direction of the bolt could be determined and adjusted accordingly. The gotcha is that perhaps how much of the monster you hit should be of relevance. If we take the area spells above, it is certainly likely that any spell will only hit a portion of the monster. So cone/explosion spells are generally going to be weaker from that change. Having the same logic for bolt spells doesn't seem unreasonable - if a bolt only hits 50% of the creature, it only does 50% of the damage. That said, one thing I said long ago and hasn't been done is the idea that a monster (or other object) no longer needs an archetype to cover the extent of its image. With the big image support, a hill giant can be changed so that it is only 1 square, but still appears 2 spaces tall. Likewise, demon lords could be greatly reduced in size - their full height doesn't have to be set. So that can be done to also reduce the footprint of many monsters, also fixing the problem to some extent. That said, some monsters, like dragons, can't really be fixed in that way. From mwedel at sonic.net Sun Sep 25 23:05:16 2005 From: mwedel at sonic.net (Mark Wedel) Date: Sun Sep 25 23:07:08 2005 Subject: [crossfire] holy altars & sacrificing. Message-ID: <4337737C.1040606@sonic.net> There have been past discussions about allow players to sacrifice enemy monster parts on their gods altar to get to some benefit, etc. I was thinking about this, and maybe it just makes sense to let the player sacrifice whatever. Now the reward for doing this is improved chance at divine intervention. After all, we let players buy most everything else, let them buy some godly influence and have them use up there money. From the most basic, take the value of the objects on the altar. Apply some formula (square or cube root?) and that is the bonus odds of improved results. Whether or not the god gives you anything, the sacrifices are of course taken. After all, the gods or priests are not guarantee success, just saying it would be more likely. There should of course be some cap on how much a bonus you can get, so a player can drop down 50,000 pp and get the best stuff easily. Certain objects may have increased value - body parts of enemy monsters are maybe credited and 3 or 5x normal value. Unidentified equipment has zero, or perhaps negative value. The priests don't want you throwing their junk at you. Likewise, cursed objects (known or otherwise) have negative value. Gold, gems, identified stuff, etc, has normal value. One could perhaps customize this some based on gods (some gods worship some items more than others). It would seem to me this might be a good way to burn up some extra money. Even at modest levels, it can take a long time praying over the altar to get some gift. So all I do is press control-p for few minutes. If I could drop down some of my extra platinum and save some time, I'd do so. The code already has a special check for player praying over a gods altar, so all that is involved is a little code there - no changes to archetype should be needed. That said, if my idea of some gods liking some objects more then others is added, then some archetype or something describe that may be necessary (_sacrifice_want or something). Some gods may not really want stuff (would gaea really want people sacrificing weapons? Although that case could be made either way - she may want them just so that no one can use them, or it could be said that if the priests are really taking the sacrificing and giving them to people in need, would only want stuff they could use). The other thought, which is somewhat related, is add some stat (or use some field in the praying skill) that denotes piety. Eg, each time you sacrifice stuff, your piety goes up. Each time you pray without sacrificing, your piety goes down. Some minimum piety is needed to get some gifts (eg, you're not going to get the gods weapon if you never do anything). Perhaps the kill code can also be modified to check to see if you killed a monster of the god - if so, piety also goes up. In some sense, piety is sort of like exp, but less direct in that you can buy it (looking at the catholic church, many people are depicted in artwork not because they were really religous, but rather because they gave lots of money). Either way, it would seem this might be a way to use up some player wealth. As an aside, there should also be some cap on how much is actually taken. Eg, if a player accidentally drops his stash of gems of flawless beauty, god may realize it is a mistake and only 'take' one of them, and not the entire stash). This could also make it a little more convient - drop that pile of platinum, and just pray with 100 pp (or whatever) being taken each time, instead of drop, pray, drop, pray, etc). From mwedel at sonic.net Sun Sep 25 23:20:33 2005 From: mwedel at sonic.net (Mark Wedel) Date: Sun Sep 25 23:21:08 2005 Subject: [crossfire] Buildable Land Plots In-Reply-To: <43315EA4.5000808@telus.net> References: <43310ABF.2010908@telus.net> <43315EA4.5000808@telus.net> Message-ID: <43377711.60004@sonic.net> It seems to me that areas have to be set up that allow building. After all, the king (or someone) owns all the land, They probably don't want someone plopping a house down in the middle of their favorite hunting forest. If this zoning is added, it then fixes the problem of map makers trying to use those spaces - if they see that space is set for building, they should avoid it and put their entrance someplace else. That said, wide areas should probably be set up for building - we don't want the case of the old apartements were 20 rooms (or whatever) seemed like enough, but clearly isn't. hundreds, or perhaps thousands, of buildable spaces should be set up. (mmmm, we can have the navar city suburbs). If I recall correctly, one idea on this was to actually set up house archs (and other buildings) that were closed with a message like: "For Sale - 50,000 pp. Go to ... to buy deed" and then when player has deed and uses it on that space, it now becomes a map. This goes with Todds idea of different building layouts you could buy, eg, that tower may be 100,000 pp, but is 3 small levels. That hut is only 25,000 but is only one small room, etc. Rather than tieing specific deeds to plot, probably make it simpler - you buy the deed for a tower, and when you find the one you like, and that hasn't been used by someone else, you try try to enter and 'buy' it, and your deed is updated somehow. Now what would be even cooler, and maybe is a job for the plugin or just DM's, is some form of shop/other building creation. Eg, suppose an area is set up that isn't close to any city. After enough plots (or maybe value of those plots) in that area is sold, a general store pops up or something (after all, lots of people in the area). As said, maybe let the DM handle that, but maybe put in some hooks to make it easier (eg, dm just issues a single command and a shop is copied from the templates and exits are updated, etc). From mikeeusaaa at yahoo.com Sun Sep 25 23:29:31 2005 From: mikeeusaaa at yahoo.com (Mitch Obrian) Date: Sun Sep 25 23:31:07 2005 Subject: [crossfire] Shop treasure lists (wish to add shop only lists) Message-ID: <20050926042931.43591.qmail@web61024.mail.yahoo.com> Currently things such as the archery and weapon shop tiles read from the mele and archery weapons lists. I would like to add a shop_archery_only list and a shop_archery list and have the archery tile read from the shop_archery list. The shop_archery list would do as follows (note, I'm using incorrect syntax, but it conveys the message): treasureone shop_archery list archer_weapons chance 99 more list shop_archery_only chance 1 end treasureone shop_archery_only a weapon etc. these would be in shoparcherylists.trs so no need to touch the gigantic treasurelist This way one can add weapons/items that they wish for shops to carry but don't want to be found randomly in duengons. When I talked to Ryo about such a thing a few months ago he though it was a pretty good idea. If there are no objections I can do this tomorrow or so. Also could the giant treasurelist be made into a .trs in the arch dir (treasures.trs ?). Would me more convient to be in the same spot. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From mikeeusaaa at yahoo.com Mon Sep 26 02:05:01 2005 From: mikeeusaaa at yahoo.com (Mitch Obrian) Date: Mon Sep 26 02:05:11 2005 Subject: [crossfire] Buildable Land Plots In-Reply-To: <43377711.60004@sonic.net> Message-ID: <20050926070501.71376.qmail@web61018.mail.yahoo.com> On my server I'd like all worldmaps to be buildable. It would be good to have a setting atleast to allow the server admin to allow building everywhere. Look at the text muds. They allow building everywhere. Also we don't have kings, perhapse players themselves will become the rulers as in text muds. Less restrictions (or rather, the ability to place less restrictions) is a good thing for enjoyment of the game. --- Mark Wedel wrote: > > > It seems to me that areas have to be set up that > allow building. > > After all, the king (or someone) owns all the > land, They probably don't want > someone plopping a house down in the middle of their > favorite hunting forest. > > If this zoning is added, it then fixes the problem > of map makers trying to use > those spaces - if they see that space is set for > building, they should avoid it > and put their entrance someplace else. > > That said, wide areas should probably be set up > for building - we don't want > the case of the old apartements were 20 rooms (or > whatever) seemed like enough, > but clearly isn't. hundreds, or perhaps thousands, > of buildable spaces should > be set up. (mmmm, we can have the navar city > suburbs). > > If I recall correctly, one idea on this was to > actually set up house archs > (and other buildings) that were closed with a > message like: > > "For Sale - 50,000 pp. Go to ... to buy deed" and > then when player has deed and > uses it on that space, it now becomes a map. > > This goes with Todds idea of different building > layouts you could buy, eg, > that tower may be 100,000 pp, but is 3 small levels. > That hut is only 25,000 > but is only one small room, etc. > > Rather than tieing specific deeds to plot, > probably make it simpler - you buy > the deed for a tower, and when you find the one you > like, and that hasn't been > used by someone else, you try try to enter and 'buy' > it, and your deed is > updated somehow. > > Now what would be even cooler, and maybe is a job > for the plugin or just DM's, > is some form of shop/other building creation. Eg, > suppose an area is set up > that isn't close to any city. After enough plots > (or maybe value of those > plots) in that area is sold, a general store pops up > or something (after all, > lots of people in the area). As said, maybe let the > DM handle that, but maybe > put in some hooks to make it easier (eg, dm just > issues a single command and a > shop is copied from the templates and exits are > updated, etc). > > > > > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From antonoussik at gmail.com Mon Sep 26 03:11:11 2005 From: antonoussik at gmail.com (Anton Oussik) Date: Mon Sep 26 03:13:13 2005 Subject: [crossfire] Unbalanced spell types In-Reply-To: <43376E6F.8070901@sonic.net> References: <20050925092456.GA27655@kirschbaum.myrealbox.com> <43376E6F.8070901@sonic.net> Message-ID: On 9/26/05, Mark Wedel wrote: > That said, one thing I said long ago and hasn't been done is the idea that a > monster (or other object) no longer needs an archetype to cover the extent of > its image. With the big image support, a hill giant can be changed so that it > is only 1 square, but still appears 2 spaces tall. > > Likewise, demon lords could be greatly reduced in size - their full height > doesn't have to be set. So that can be done to also reduce the footprint of > many monsters, also fixing the problem to some extent. > > That said, some monsters, like dragons, can't really be fixed in that way. I can't really see how this would work in practice without confusing the player. When they are "behind" the monster in melee combat they would a) not be dealing damage unless running down, b) not be able to tell where they are as they would be obscured by the monster, c) be confused which part of the monster they can run into to deal damage, and why some monsters you can run into the whole of it, whist with others only into certain parts of them. Over time they would develop a habit of only hitting the bottom row of tiles for the fear of "missing" the monster and running into a room full of them. From antonoussik at gmail.com Mon Sep 26 03:23:07 2005 From: antonoussik at gmail.com (Anton Oussik) Date: Mon Sep 26 03:25:12 2005 Subject: [crossfire] Buildable Land Plots In-Reply-To: <20050926070501.71376.qmail@web61018.mail.yahoo.com> References: <43377711.60004@sonic.net> <20050926070501.71376.qmail@web61018.mail.yahoo.com> Message-ID: Not tying down a deed to a space certainly makes it easier. Also combining building plans with deeds seems sensible, since a player would know what sort of thing they would want to buy. If I understand correctly, those deeds (like a tower deed) would only provide a base building which can then be expanded/improved using things from building shop. Another small idea - ability to name the map entrance as it will appear on the world map, like "Casper's home". This would allow players to easily find the right plot. From nicolas.weeger at laposte.net Mon Sep 26 03:28:01 2005 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Mon Sep 26 03:28:47 2005 Subject: [crossfire] holy altars & sacrificing. Message-ID: Some people had an idea for a "sacrifice pit" or something close, too. Short summary: drop items in a pit, depending on their value and how much of the same kind has already been dropped (with a decay factor), give a reward (xp or whatever). Then players have an invenctive to drop items/money, and be smart in what they drop (don't drop a zillionth orc part, but a turban of heavens for instance). I think this could be done using Python plugin, maybe not even too hard. Nicolas Acc?dez au courrier ?lectronique de La Poste : www.laposte.net ; 3615 LAPOSTENET (0,34?/mn) ; t?l : 08 92 68 13 50 (0,34?/mn) From nicolas.weeger at laposte.net Mon Sep 26 03:30:20 2005 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Mon Sep 26 03:31:50 2005 Subject: [crossfire] Buildable Land Plots Message-ID: The idea of popping up shops is great, and i'd add things like roads, post office, and such, too! :) That said, the issue i can see is about permission in directories: if game modifies/adds itself the maps, then comes the issue of physically writing the file, thus requiring write access to maps subdirectory. Maybe that's not a real issue, but still, need to think about that. Or find a way to specify those maps are stored in var subdirectory or something like that. As for building itself, i'd say players buy blueprints of what they want, and it gets build. Then we could have rare blueprints you can only find by doing quests, and such. Ryo Acc?dez au courrier ?lectronique de La Poste : www.laposte.net ; 3615 LAPOSTENET (0,34?/mn) ; t?l : 08 92 68 13 50 (0,34?/mn) From alex_sch at telus.net Mon Sep 26 08:04:19 2005 From: alex_sch at telus.net (Alex Schultz) Date: Mon Sep 26 08:05:18 2005 Subject: [crossfire] Buildable Land Plots In-Reply-To: References: Message-ID: <4337F1D3.3030001@telus.net> Nicolas Weeger wrote: >The idea of popping up shops is great, and i'd add things like >roads, post office, and such, too! :) > >That said, the issue i can see is about permission in >directories: if game modifies/adds itself the maps, then comes >the issue of physically writing the file, thus requiring write >access to maps subdirectory. Maybe that's not a real issue, >but still, need to think about that. >Or find a way to specify those maps are stored in var >subdirectory or something like that. > > Hence my plan for "global unique" maps in my original post, which would be better named "template maps". They would be stored in a var subdirectory, and the template maps could either be based off a map in the normal map tree, or based upon the one time output of the random map generator. Also I have been thinking of a way to possible extend tiling so it can refer to such maps outside of the normal map tree. and then via this, have adjunct land plots tiled together. >As for building itself, i'd say players buy blueprints of what >they want, and it gets build. Then we could have rare >blueprints you can only find by doing quests, and such. > >Ryo > IMO, It might be nicer if it's just the raw land and the player makes the building manually. At the time of my original post making use of the random map generator as well to make landscape details, and choosing from several styles depending on what tile one tried to build the plot on. That said, blueprints might be nice too because they would save players who don't want to create the building from scratch some time. Personally I think it would be good if there was both the option to use a blueprint, or to just build the building from scratch. Also, because some sort of building permissions system would need to be implemented, players could make a 'magic ear' type password system with the talking books I recently implemented into building. Also, due to the inverted gate that I added, it's also possible for creative players to make a "boulder based" lock for their buildings. Encouraging these sorts of creative things is partially why I would like to at least have the option of open-ended blank plots. I indeed to start working on the "template maps" some time soon, however due to schoolwork and such it could be a while before I get that done. Alex Schultz From nicolas.weeger at laposte.net Mon Sep 26 08:26:35 2005 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Mon Sep 26 08:27:17 2005 Subject: [crossfire] Buildable Land Plots Message-ID: > The idea of popping up shops is great, and i'd add things like > roads, post office, and such, too! :) To extend that idea: for "common" services (bank, shop, post office, roads, maybe teleporters to other towns?), it would require a fee to be paid regularly to sustain the service. Then either a player is very rich, or players group to get a post office (6 players having houses nearby group to get a post office). After all you're asking some company to put a shop near you, you need to pay for that privilege :) Also could be based on local traffic in shops (ie if magic shop gets much commerce, you don't have to pay much to sustain it, but if no one comes, then you get to pay a lot, they don't want to have too much losses!). Ryo Acc?dez au courrier ?lectronique de La Poste : www.laposte.net ; 3615 LAPOSTENET (0,34?/mn) ; t?l : 08 92 68 13 50 (0,34?/mn) From josh at woosworld.net Mon Sep 26 09:05:40 2005 From: josh at woosworld.net (Joshua Wilson) Date: Mon Sep 26 09:07:18 2005 Subject: [crossfire] Re: [Crossfire-cvs] CVS commit: maps-bigworld/scorn/temples In-Reply-To: <200509251850.20866.eracclists@bellsouth.net> References: <20050925115706.GA1488@kirschbaum.myrealbox.com> <4336B3CF.1080006@telus.net> <200509251850.20866.eracclists@bellsouth.net> Message-ID: <43380034.5040708@woosworld.net> ERACC wrote: > On Sunday 25 September 2005 09:27 am > Alex Schultz wrote: > > >>Andreas Kirschbaum wrote: >> >> >>>crossfire-cvs-admin@lists.sourceforge.net wrote: >>> >>> >>>>Log Message: >>>>Updated Scorn temples to level 120 so high level players cannot reconsecrate them and cause DM headaches. >>>> >>> >>>Is this really the correct fix for this problem? Wouldn't it be better >>>to update the holy altar archetypes and let the individual altars >>>inherit level 120? After all, it's just too easy for a map maker to > > [...] > >>I believe the logic of why it was done that way was because >>reconsecrating altars in dungeons would not be a significant DM headache > > [...] > > Alex is correct. The only altars that were truly a problem were the > ones in Scorn where a noob may have no idea to watch out for an altar > in a temple being reconsecrated. Just modifying those maps is enough > to solve the problem. Once a noob is exploring outside Scorn, well, > the noob is on his/her own then. No more coddling. ;-) Hey now! It's not just noob's that get converted by a scorn alter being reconsecrated you know... > > Gene Alexander From josh at woosworld.net Mon Sep 26 09:08:26 2005 From: josh at woosworld.net (Joshua Wilson) Date: Mon Sep 26 09:13:47 2005 Subject: [crossfire] Unbalanced spell types In-Reply-To: <43376E6F.8070901@sonic.net> References: <20050925092456.GA27655@kirschbaum.myrealbox.com> <43376E6F.8070901@sonic.net> Message-ID: <433800DA.1070102@woosworld.net> Mark Wedel wrote: > Andreas Kirschbaum wrote: > >> I think the damage should be scaled down by the monster size (measured >> in tiles it occupies). This would mean a spell deals full damage only if >> it hits the whole monster (i.e. the spell covers all monster tiles). > > > Do note you need to cover rounding issues. In the case of the greater > demon (42 spaces), that could be a considerable amount of damage. > > And ideally, this should be handled after damage (or maybe as part of) > damage reduction from protections is taken into account, since that also > has rounding errors (but I think those might have been fixed by randomly > determing if the remainder does damage). > >> Note that bolt spells currently do have the same problem and deal >> different damage depending on how you hit the monster: hitting a hill >> giant vertically will do double damage compared to hitting it >> horizontally. >> >> For this spell type I cannot think of a simple solution that works >> correctly: >> just scaling down by either MIN(monster width, monster height) or >> MAX(monster width, monster height) either does not fix the problem, or >> weakens >> bolt spells for no apparent reason (to the player). > > > > Well, the direction of the bolt could be determined and adjusted > accordingly. The gotcha is that perhaps how much of the monster you hit > should be of relevance. > > If we take the area spells above, it is certainly likely that any spell > will only hit a portion of the monster. So cone/explosion spells are > generally going to be weaker from that change. > > Having the same logic for bolt spells doesn't seem unreasonable - if a > bolt only hits 50% of the creature, it only does 50% of the damage. This is awfully dangerous sounding - given a bolt spell can NOT hit 100% of any monster other then a 1xX monster we will end up nuking bolt spells if we are not careful here. > > That said, one thing I said long ago and hasn't been done is the idea > that a monster (or other object) no longer needs an archetype to cover > the extent of its image. With the big image support, a hill giant can > be changed so that it is only 1 square, but still appears 2 spaces tall. > > Likewise, demon lords could be greatly reduced in size - their full > height doesn't have to be set. So that can be done to also reduce the > footprint of many monsters, also fixing the problem to some extent. > > That said, some monsters, like dragons, can't really be fixed in that way. > > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > > > From mikeeusaaa at yahoo.com Mon Sep 26 09:15:44 2005 From: mikeeusaaa at yahoo.com (Mitch Obrian) Date: Mon Sep 26 09:17:11 2005 Subject: [crossfire] Re: [Crossfire-devel] (good to go?) Shop treasure lists (wish to add shop only lists) In-Reply-To: <20050926042931.43591.qmail@web61024.mail.yahoo.com> Message-ID: <20050926141544.18192.qmail@web61017.mail.yahoo.com> Any objections? If not I'll make the addition tonight. --- Mitch Obrian wrote: > Currently things such as the archery and weapon shop > tiles read from the mele and archery weapons lists. > I > would like to add a shop_archery_only list and a > shop_archery list and have the archery tile read > from > the shop_archery list. > > The shop_archery list would do as follows (note, I'm > using incorrect syntax, but it conveys the message): > > treasureone shop_archery > list archer_weapons > chance 99 > more > list shop_archery_only > chance 1 > end > > treasureone shop_archery_only > a weapon > > etc. > > these would be in shoparcherylists.trs > so no need to touch the gigantic treasurelist > > > This way one can add weapons/items that they wish > for > shops to carry but don't want to be found randomly > in > duengons. > > When I talked to Ryo about such a thing a few months > ago he though it was a pretty good idea. > > If there are no objections I can do this tomorrow or > so. > > Also could the giant treasurelist be made into a > .trs > in the arch dir (treasures.trs ?). > > Would me more convient to be in the same spot. > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam > protection around > http://mail.yahoo.com > > > ------------------------------------------------------- > SF.Net email is sponsored by: > Tame your development challenges with Apache's > Geronimo App Server. Download > it for free - -and be entered to win a 42" plasma tv > or your very own > Sony(tm)PSP. Click here to play: > http://sourceforge.net/geronimo.php > _______________________________________________ > Crossfire-devel mailing list > Crossfire-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/crossfire-devel > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From nicolas.weeger at laposte.net Mon Sep 26 09:32:36 2005 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Mon Sep 26 09:33:17 2005 Subject: [crossfire] Improved post office idea Message-ID: Hello. When we'll have the new plugin system (*ponders sending in a search party for gros*), I'll extend the post office to send items to other players. I think it's not that hard actually: * sending player drops items on a some specific altar/square * sending player says "send " * items get teleported to a unique square in a global (unlinked probably?) map * during teleportation, the "custom_name" is set to receiving player * player wanting to get sent items goes to post office, says "get items" (or opens container, ...), items get teleported back from the unique map, custom_name is cleared, et voila, item sent Event option would be used to specify on which spot the player should drop items and what map to put'em into, this would let have different post offices :) If many items are sent this way, then maybe the check on whether a player has or not items in the unique map could be skipped, and simply a message sent when items are sent. (because each time a player connects you need to open the storage map, check items for one having the right custom_name). Also, there could be fun things to do with that: * pay item-price/10 + item-weight/10 for standard send, but, alas, probability to lose the item is ~10% * pay item-price, item is either sent or you get item-price * 5 indemnity (~1% chance) * delivery takes time * receiving player pays some fees based on distance between the 2 post offices (hard to compute distance, though) * imagine some more :) Ryo Acc?dez au courrier ?lectronique de La Poste : www.laposte.net ; 3615 LAPOSTENET (0,34?/mn) ; t?l : 08 92 68 13 50 (0,34?/mn) From antonoussik at gmail.com Mon Sep 26 10:00:09 2005 From: antonoussik at gmail.com (Anton Oussik) Date: Mon Sep 26 10:01:18 2005 Subject: [crossfire] Buildable Land Plots In-Reply-To: References: Message-ID: On 26/09/05, Nicolas Weeger wrote: > Also could be based on local traffic in shops (ie if magic > shop gets much commerce, you don't have to pay much to sustain > it, but if no one comes, then you get to pay a lot, they don't > want to have too much losses!). Should the shops etc. not be player-run? From nicolas.weeger at laposte.net Mon Sep 26 10:25:33 2005 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Mon Sep 26 10:27:18 2005 Subject: [crossfire] Buildable Land Plots Message-ID: > Should the shops etc. not be player-run? I guess we could have both. But then, you'd need to have a drawback for running your own shop (high rental fee? need to be there for the shop to be opened?), else players could make much money... Ryo Acc?dez au courrier ?lectronique de La Poste : www.laposte.net ; 3615 LAPOSTENET (0,34?/mn) ; t?l : 08 92 68 13 50 (0,34?/mn) From brenlally at gmail.com Mon Sep 26 10:25:11 2005 From: brenlally at gmail.com (Brendan Lally) Date: Mon Sep 26 10:27:24 2005 Subject: [crossfire] holy altars & sacrificing. In-Reply-To: <4337737C.1040606@sonic.net> References: <4337737C.1040606@sonic.net> Message-ID: <7903f03c050926082567ae986f@mail.gmail.com> On 9/26/05, Mark Wedel wrote: > Eg, each time you sacrifice stuff, your piety goes up. Each time you pray > without sacrificing, your piety goes down. Some minimum piety is needed to get > some gifts (eg, you're not going to get the gods weapon if you never do anything). > > Perhaps the kill code can also be modified to check to see if you killed a > monster of the god - if so, piety also goes up. In some sense, piety is sort of > like exp, but less direct in that you can buy it I'd like to think this could be extended to the entire pantheon, if this piety were tracked as a separate object, then there could be one for each god. Then, anytime a monster is killed, adjust the piety (I suppose at this point it should be called favour) of the god that likes that monster downwards and of the god that hates it upwards (though probably not by as much, since, as you suggest, simony could also be necessary to have a good relationship) once this starts happening players can start restricting the way they can convert between gods (want to worship valriel? you really shouldn't have killed x thousand angels then should you?) so that some conversions could become very expensive to do (even to the point of requiring tens of millions of platinum to appease a god that you have made inordinately angry with you) extra bonus effect, if this were hooked into the charm code, it could be easier to charm monsters that worship a god that likes you, and harder to charm those who worship a god that hates you (the natural aversion that the creature will have to those they know to be heretics and agents of evil) - possibly it could also act as a modifier to banishment damage? - (if a creature banish you, but their god doesn't like you, then even if your race isn't detestable to them, still harm the player - though maybe not as much...) - side effect, the more a player focuses on one type of creature, the more dangerous being banished by them is. From brenlally at gmail.com Mon Sep 26 10:50:54 2005 From: brenlally at gmail.com (Brendan Lally) Date: Mon Sep 26 10:51:20 2005 Subject: [crossfire] Buildable Land Plots In-Reply-To: <4337F1D3.3030001@telus.net> References: <4337F1D3.3030001@telus.net> Message-ID: <7903f03c0509260850633305e7@mail.gmail.com> On 9/26/05, Alex Schultz wrote: > At the time of my original post making use of the > random map generator as well to make landscape details, and choosing > from several styles depending on what tile one tried to build the plot > on. That said, blueprints might be nice too because they would save > players who don't want to create the building from scratch some time. An easier method than blueprints, that is being suggested, is to have a building shop sell the occassional 'house in a box' which would be a container with 36 walls (the plots would be 11x11 with the outside row not directly buildable, to allow space for entrance and exit) a door, and a bed to reality. Obviously this would be horribly overpriced, for the extra convenience of not having to find all the appropriate materials individually. If the aim is to not have to build at all, whilst having somewhere to own, then I would draw your attention to the existing permenent apartments, at least the navar one is already marked is_buildable 1 in many places. I do like the idea of quested items though (rather than blueprints as such), something like a buildable chessboard would probably be a suitable quest reward. From fuchs.andy at gmail.com Mon Sep 26 11:49:21 2005 From: fuchs.andy at gmail.com (Andrew Fuchs) Date: Mon Sep 26 11:51:21 2005 Subject: [crossfire] Improved post office idea In-Reply-To: References: Message-ID: On 9/26/05, Nicolas Weeger wrote: > When we'll have the new plugin system (*ponders sending in a > search party for gros*), I'll extend the post office to send > items to other players. Was rednaxela doing something related to this (swig bindings)? > I think it's not that hard actually: > * sending player drops items on a some specific altar/square I think a box would be the easiest, to impose weight limits. ... > * items get teleported to a unique square in a global > (unlinked probably?) map A unique map could get messy. I think it is cleaner just to use the functions provided by the python plugin to store the items in a seperate file. ... > If many items are sent this way, then maybe the check on > whether a player has or not items in the unique map could be > skipped, and simply a message sent when items are sent. > (because each time a player connects you need to open the > storage map, check items for one having the right custom_name). Again, using a file would probaly be cleaner imo. > Also, there could be fun things to do with that: > * pay item-price/10 + item-weight/10 for standard send, but, > alas, probability to lose the item is ~10% > * pay item-price, item is either sent or you get item-price * > 5 indemnity (~1% chance) > * delivery takes time Just have items randomly "get lost" for a period of time, but allow a decent amount of cash to be dumped on "first class" delivery of some sort. > * receiving player pays some fees based on distance between > the 2 post offices (hard to compute distance, though) Hmm, courrupt post offices in some areas, maby. -- Andrew Fuchs From mikeeusaaa at yahoo.com Mon Sep 26 12:19:39 2005 From: mikeeusaaa at yahoo.com (Mitch Obrian) Date: Mon Sep 26 12:21:19 2005 Subject: [crossfire] Improved post office idea In-Reply-To: Message-ID: <20050926171939.55704.qmail@web61019.mail.yahoo.com> Why wait for gros? The new python is supposed to be compatable with the old stuff IIRC. --- Andrew Fuchs wrote: > On 9/26/05, Nicolas Weeger > wrote: > > When we'll have the new plugin system (*ponders > sending in a > > search party for gros*), I'll extend the post > office to send > > items to other players. > > Was rednaxela doing something related to this (swig > bindings)? > > > I think it's not that hard actually: > > * sending player drops items on a some specific > altar/square > > I think a box would be the easiest, to impose weight > limits. > > ... > > * items get teleported to a unique square in a > global > > (unlinked probably?) map > > A unique map could get messy. I think it is cleaner > just to use the > functions provided by the python plugin to store the > items in a > seperate file. > > ... > > If many items are sent this way, then maybe the > check on > > whether a player has or not items in the unique > map could be > > skipped, and simply a message sent when items are > sent. > > (because each time a player connects you need to > open the > > storage map, check items for one having the right > custom_name). > > Again, using a file would probaly be cleaner imo. > > > Also, there could be fun things to do with that: > > * pay item-price/10 + item-weight/10 for standard > send, but, > > alas, probability to lose the item is ~10% > > * pay item-price, item is either sent or you get > item-price * > > 5 indemnity (~1% chance) > > * delivery takes time > > Just have items randomly "get lost" for a period of > time, but allow a > decent amount of cash to be dumped on "first class" > delivery of some > sort. > > > * receiving player pays some fees based on > distance between > > the 2 post offices (hard to compute distance, > though) > > Hmm, courrupt post offices in some areas, maby. > > -- > Andrew Fuchs > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From alex_sch at telus.net Mon Sep 26 12:19:39 2005 From: alex_sch at telus.net (Alex Schultz) Date: Mon Sep 26 12:27:19 2005 Subject: [crossfire] Re: Buildable Land Plots References: <43377711.60004@sonic.net> <20050926070501.71376.qmail@web61018.mail.yahoo.com> Message-ID: Anton Oussik writes: > > Not tying down a deed to a space certainly makes it easier. Also > combining building plans with deeds seems sensible, since a player > would know what sort of thing they would want to buy. IMO, It would be best if there's also the option of buying a deed with a "blank" blueprint, and this one would start with nothing in in but buildable grass and such (depending on the terrain built on and made by random map generator), and this one should in my opinion be notably cheaper than the blueprints. > Another small idea - ability to name the map entrance as it will > appear on the world map, like "Casper's home". This would allow > players to easily find the right plot. Yeah, perhaps by renameing the deed to that with the player rename command could change the name of the plot entrance. Though that mechanism to name it might be a little hackish, but some way to name it would indeed be good. Alex Schultz From alex_sch at telus.net Mon Sep 26 12:21:53 2005 From: alex_sch at telus.net (Alex Schultz) Date: Mon Sep 26 12:33:40 2005 Subject: [crossfire] Re: Buildable Land Plots References: <4337F1D3.3030001@telus.net> <7903f03c0509260850633305e7@mail.gmail.com> Message-ID: Brendan Lally writes: > [snip] > the plots would be 11x11 with the outside row > not directly buildable > [snip] Hmm.. but one of the larger points of making them tiled together that I was thinking of was to allow one to make bigger houses and such by getting some plots that are connected. Perhaps it should only disallow building on the outside row where you don't own the adjecent plot. Alex Schultz From antonoussik at gmail.com Mon Sep 26 12:33:58 2005 From: antonoussik at gmail.com (Anton Oussik) Date: Mon Sep 26 12:35:57 2005 Subject: [crossfire] Buildable Land Plots In-Reply-To: References: Message-ID: On 26/09/05, Nicolas Weeger wrote: > > Should the shops etc. not be player-run? > > I guess we could have both. > But then, you'd need to have a drawback for running your own > shop (high rental fee? need to be there for the shop to be > opened?), else players could make much money... The drawback is that players would have to control what the shop buys and at what price - otherwise someone could dump a lot of useless stuff they can not sell on them and make them bancrupt. A player-run shop will not buy something they will not be able to sell for a higher price. From brenlally at gmail.com Mon Sep 26 12:44:44 2005 From: brenlally at gmail.com (Brendan Lally) Date: Mon Sep 26 12:45:20 2005 Subject: [crossfire] Buildable Land Plots In-Reply-To: References: Message-ID: <7903f03c05092610447e9da0f0@mail.gmail.com> On 9/26/05, Anton Oussik wrote: > The drawback is that players would have to control what the shop buys > and at what price - otherwise someone could dump a lot of useless > stuff they can not sell on them and make them bancrupt. I don't think that is the right approach either. Personally I would favour the creation of an auction house, when an item or number of items could be dropped by a player, and given a lot number, a reserve price, and a time limit. The other players would come along, see the lot numbers, and time remaining, and then bid for the lot, there would probably also need to be a way to 'show lot #' which would call describe_object against the items in the lot. Then, when the time expires, the highest bid wins, and x% of the money is kept by the auction house (not sure what x should be...) From antonoussik at gmail.com Mon Sep 26 13:05:08 2005 From: antonoussik at gmail.com (Anton Oussik) Date: Mon Sep 26 13:05:20 2005 Subject: [crossfire] Buildable Land Plots In-Reply-To: <7903f03c05092610447e9da0f0@mail.gmail.com> References: <7903f03c05092610447e9da0f0@mail.gmail.com> Message-ID: On 26/09/05, Brendan Lally wrote: > On 9/26/05, Anton Oussik wrote: > > The drawback is that players would have to control what the shop buys > > and at what price - otherwise someone could dump a lot of useless > > stuff they can not sell on them and make them bancrupt. > > I don't think that is the right approach either. Personally I would > favour the creation of an auction house, when an item or number of > items could be dropped by a player, and given a lot number, a reserve > price, and a time limit. What I propose is not too different, but has the advantage of scaling better with the number of users, and being more flexible. For example you can have a weapons shop which sells things a blacksmith makes. Therefore the same player can own a house of a blacksmith pattern which has its own smithery, and its own shop, which players can visit and buy weapons from. This can also be extended to other shops, like potion shops, clothes, armour, food, furniture, and so on. If (as a seperate patch) something like a cookery skill is introduced you could get bakeries, restaraunts, and taverns that are player-run too. Then the economy would regulate itself, without the need of artificially setting prices. From brenlally at gmail.com Mon Sep 26 13:31:08 2005 From: brenlally at gmail.com (Brendan Lally) Date: Mon Sep 26 13:34:30 2005 Subject: [crossfire] Buildable Land Plots In-Reply-To: References: <7903f03c05092610447e9da0f0@mail.gmail.com> Message-ID: <7903f03c050926113127ce9b8c@mail.gmail.com> On 9/26/05, Anton Oussik wrote: > What I propose is not too different, but has the advantage of scaling > better with the number of users, and being more flexible. For example > you can have a weapons shop which sells things a blacksmith makes. > Therefore the same player can own a house of a blacksmith pattern > which has its own smithery, and its own shop, which players can visit > and buy weapons from. > > This can also be extended to other shops, like potion shops, clothes, > armour, food, furniture, and so on. If (as a seperate patch) something > like a cookery skill is introduced you could get bakeries, > restaraunts, and taverns that are player-run too. Then the economy > would regulate itself, without the need of artificially setting > prices. This was tried before (adjustable economy), it didn't work, players are primarily sources of goods in the cf economy, most things are found not brought, the only exception to this are items that are rare or hard to obtain for other reasons. If you could find a coherent way to make players be consumers as well as producers, then /maybe/ such a system would work, but it would probably be exceedingly dull for whoever was sitting around in their blacksmith's shop the whole time. From AlDragon at gmail.com Mon Sep 26 13:52:45 2005 From: AlDragon at gmail.com (Alex Schultz) Date: Mon Sep 26 13:57:21 2005 Subject: [crossfire] Re: Improved post office idea References: Message-ID: Andrew Fuchs writes: > On 9/26/05, Nicolas Weeger wrote: > > When we'll have the new plugin system (*ponders sending in a > > search party for gros*), I'll extend the post office to send > > items to other players. > > Was rednaxela doing something related to this (swig bindings)? No, I was experimenting with swig bindings for the server side common/, which is not for the plugin, but for making applications in languages such as python that can easily read the maps and archetypes through the existing C code. I got it working eventually, but it was very grotty and shouldn't be included in crossfire until/unless we have something that uses it (i.e. python based map editor, or php based map render). Perhasp I should find somewhere to publicly store this though. Swig bindings could probably be used for the python plugin, but that would likely cause it to be rather bloated (swig frequently generates C source that's over 500kb which normally has to be linked to other code as well). IMHO Swig is a very good idea for making apps using maps and arches in scripting languages, however it's not well suited for the server plugin. Alex Schultz From nicolas.weeger at laposte.net Mon Sep 26 15:48:01 2005 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Mon Sep 26 15:49:23 2005 Subject: [crossfire] Improved post office idea In-Reply-To: References: Message-ID: <43385E81.80504@laposte.net> > A unique map could get messy. I think it is cleaner just to use the > functions provided by the python plugin to store the items in a > seperate file. Pretty hard to save items. Would need to call the store/load functions, messy too :) A map with unique tile lets the game handle the messy details itself... > Just have items randomly "get lost" for a period of time, but allow a > decent amount of cash to be dumped on "first class" delivery of some > sort. No, definitely lost :) "lost in a dragon crash, sorry" Ryo From brenlally at gmail.com Mon Sep 26 17:49:28 2005 From: brenlally at gmail.com (Brendan Lally) Date: Mon Sep 26 17:51:24 2005 Subject: [crossfire] Improved post office idea In-Reply-To: <43385E81.80504@laposte.net> References: <43385E81.80504@laposte.net> Message-ID: <7903f03c05092615494eaf8c5e@mail.gmail.com> On 9/26/05, Nicolas Weeger wrote: > No, definitely lost :) > "lost in a dragon crash, sorry" What would also be needed then would be a way to have a home 'adress' with the post office, one that it regards as being your local branch. Then any package would travel from the post office it was sent to, to the players local post office, and the time (and the chance of it getting lost) could be based on the distance between them (possibly each post office could have a queue of messages, and a schedule when mail coaches would arrive then there could be a way of traversing the network to figure out which mail should be on which mail coach, and when the next one will arrive). - That can wait for later though.... maybe then there could be competing delivery firms, like there are today, who would charge more, but deliver quicker (20 minutes instead of 20 hours). From temitchell at sympatico.ca Mon Sep 26 18:29:03 2005 From: temitchell at sympatico.ca (Todd Mitchell) Date: Mon Sep 26 18:29:24 2005 Subject: [crossfire] Buildable Land Plots In-Reply-To: <7903f03c0509260850633305e7@mail.gmail.com> References: <4337F1D3.3030001@telus.net> <7903f03c0509260850633305e7@mail.gmail.com> Message-ID: <4338843F.4000307@sympatico.ca> >An easier method than blueprints, that is being suggested, is to have >a building shop sell the occassional 'house in a box' which would be a >container with 36 walls (the plots would be 11x11 with the outside row >not directly buildable, to allow space for entrance and exit) a door, >and a bed to reality. > > What is the difference here? - a 'house in a box' would be a blueprint too, no? The point being made is that the store would sell a 'token' representing a building template the player would like to be built on site - the templates tells the apply invocation which maps to create and link to the exit it creates. You could call it a 'house kit' a 'blueprint' or even a 'doggydoo' if you like - you would need an arch to implement it in any case. Also I am not sure what a 'global unique map' is but I was under the impression that to instantiate a building from a blueprint you should write a copy of the appropriate map (a committed "template" in the maps module) to the *var/maps* directory. I believe this is how/where the weather code generates and stores the modified world maps with the weather effects. Building a house from a template should be as simple as grabbing the slaying field from the blueprint object to find the templates directory (e.g. /templates/house1) containing the maps in the template, replacing the return exit coordinates and perhaps some inventory checkers (set slaying to match a marker in the player's inventory so they can access their vault and trophy rooms) and then writing the new maps to the var/maps folder and poping a unique exit object on the world map on the zoned tile(s) the blueprint was invoked on. Naturally the map templates contain buildable areas, however even an 'empty' entirely buildable map would require a template since they would need a map size and return exit in the very least. Also most of the template maps I have worked on contain a few maps linked together (the basic house template I made has a basemement, a main floor and a upstairs.) >I do like the idea of quested items though (rather than blueprints as >such), something like a buildable chessboard would probably be a >suitable quest reward. > > > A good mixture of buildable areas and quest linked 'perks' like the guilds have (new floors, altars, trophy rooms...) would be best I believe. From temitchell at sympatico.ca Mon Sep 26 18:40:22 2005 From: temitchell at sympatico.ca (Todd Mitchell) Date: Mon Sep 26 18:39:25 2005 Subject: [crossfire] Improved post office idea In-Reply-To: References: Message-ID: <433886E6.2090104@sympatico.ca> I think it would be easier to sell a new container type of letter object (shipping box) at the IPO which you can place items into to mail them. It could function like a letter does now except it is a container. Then you drop it into the mailbox and it gets sent. Nicolas Weeger wrote: >Hello. > >When we'll have the new plugin system (*ponders sending in a >search party for gros*), I'll extend the post office to send >items to other players. > >I think it's not that hard actually: >* sending player drops items on a some specific altar/square >* sending player says "send " >* items get teleported to a unique square in a global >(unlinked probably?) map >* during teleportation, the "custom_name" is set to receiving >player >* player wanting to get sent items goes to post office, says >"get items" (or opens container, ...), items get teleported >back from the unique map, custom_name is cleared, et voila, >item sent > >Event option would be used to specify on which spot the player >should drop items and what map to put'em into, this would let >have different post offices :) > >If many items are sent this way, then maybe the check on >whether a player has or not items in the unique map could be >skipped, and simply a message sent when items are sent. >(because each time a player connects you need to open the >storage map, check items for one having the right custom_name). > >Also, there could be fun things to do with that: >* pay item-price/10 + item-weight/10 for standard send, but, >alas, probability to lose the item is ~10% >* pay item-price, item is either sent or you get item-price * >5 indemnity (~1% chance) >* delivery takes time >* receiving player pays some fees based on distance between >the 2 post offices (hard to compute distance, though) >* imagine some more :) > >Ryo > > > From brenlally at gmail.com Mon Sep 26 18:42:55 2005 From: brenlally at gmail.com (Brendan Lally) Date: Mon Sep 26 18:43:25 2005 Subject: [crossfire] Buildable Land Plots In-Reply-To: <4338843F.4000307@sympatico.ca> References: <4337F1D3.3030001@telus.net> <7903f03c0509260850633305e7@mail.gmail.com> <4338843F.4000307@sympatico.ca> Message-ID: <7903f03c050926164272059d56@mail.gmail.com> On 9/27/05, Todd Mitchell wrote: > > >An easier method than blueprints, that is being suggested, is to have > >a building shop sell the occassional 'house in a box' which would be a > >container with 36 walls (the plots would be 11x11 with the outside row > >not directly buildable, to allow space for entrance and exit) a door, > >and a bed to reality. > > > > > What is the difference here? - a 'house in a box' would be a blueprint > too, no? The point being made is that the store would sell a 'token' > representing a building template the player would like to be built on > site - the templates tells the apply invocation which maps to create and > link to the exit it creates. You could call it a 'house kit' a > 'blueprint' or even a 'doggydoo' if you like - you would need an arch to > implement it in any case. what I am suggesting would give constructors to do this yourself, not do it for you, this would also mean that later on (say if you wanted to add an extra room) you could use a destructor and some more constructors to build the new parts of the map. A house in a box would only need one new arch and a new treasure list (plus an addition to the existing build shop treasure lists....) as oppossed to template maps which strike me as very cold and impersonal (much like modern day suburbs) From alex_sch at telus.net Mon Sep 26 18:52:57 2005 From: alex_sch at telus.net (Alex Schultz) Date: Mon Sep 26 18:53:31 2005 Subject: [crossfire] Buildable Land Plots In-Reply-To: <4338843F.4000307@sympatico.ca> References: <4337F1D3.3030001@telus.net> <7903f03c0509260850633305e7@mail.gmail.com> <4338843F.4000307@sympatico.ca> Message-ID: <433889D9.70603@telus.net> Todd Mitchell wrote: > What is the difference here? - a 'house in a box' would be a blueprint > too, no? The point being made is that the store would sell a 'token' > representing a building template the player would like to be built on > site - the templates tells the apply invocation which maps to create > and link to the exit it creates. You could call it a 'house kit' a > 'blueprint' or even a 'doggydoo' if you like - you would need an arch > to implement it in any case. I believe what he meant by a 'house in a box' is rather different. As I understand, he just means a nice package of buildable parts to start a house with from scratch so you don't have to forage around the few small building shops there currently are when you first build it. > Also I am not sure what a 'global unique map' is but I was under the > impression that to instantiate a building from a blueprint you should > write a copy of the appropriate map (a committed "template" in the > maps module) to the *var/maps* directory. What I meant by 'global unique map' (which was a bad term), is new class of map similar to unique maps and overlay maps which would be better to call 'template maps'. Storing in var/maps would not be appropriate, because this is where overlays are stored, not complete maps based off of a template, so they should have their own directory in var, which wouldn't be restricted to land plots, as I intend the template maps feature to be potentially useful for other parts of crossfire too. Also, you seem to be missing another part that IMO is important: -That I also plan to make is possible to make unique, and template, maps using the a map generated from the random map generator as a template. > I believe this is how/where the weather code generates and stores the > modified world maps with the weather effects. Building a house from a > template should be as simple as grabbing the slaying field from the > blueprint object to find the templates directory (e.g. > /templates/house1) containing the maps in the template, replacing the > return exit coordinates and perhaps some inventory checkers (set > slaying to match a marker in the player's inventory so they can access > their vault and trophy rooms) and then writing the new maps to the > var/maps folder and poping a unique exit object on the world map on > the zoned tile(s) the blueprint was invoked on. Naturally the map > templates contain buildable areas, however even an 'empty' entirely > buildable map would require a template since they would need a map > size and return exit in the very least. IMHO, you seem to be missing what to be would be a significant part of the fun of land plots: Building the house from scratch, though it might be nice to have a prebuilt blueprint for when you don't want to spend time building details. However in my opinion, building from scratch *should* be the primary way of building, with the blueprints just as an alternative. Using the feature I'm describing above with using the random map generator, I feel more depth could be added to the land plots by making the random map generator randomly make little landscape details here and there that are different in every plot. In my opinion, if blueprints were encouraged as the primary method of making land plots, then too many would look too alike even with player modifications, which defeats a large part of what I think would make land plots so great, which is that every player's plot would be unique to them and of their own design. Such customizeability is something that I feel helps to make a great RPG. Sure you could encourage blueprints and have empty as an alternative, but I feel that the land plots may be somewhat dull if the blueprints become the primary way of making them as opposed to empty ones generated by the random map generator and built completely by the player. Alex Schultz From brenlally at gmail.com Mon Sep 26 19:03:32 2005 From: brenlally at gmail.com (Brendan Lally) Date: Mon Sep 26 19:05:25 2005 Subject: [crossfire] Buildable Land Plots In-Reply-To: <433889D9.70603@telus.net> References: <4337F1D3.3030001@telus.net> <7903f03c0509260850633305e7@mail.gmail.com> <4338843F.4000307@sympatico.ca> <433889D9.70603@telus.net> Message-ID: <7903f03c050926170319da5de8@mail.gmail.com> On 9/27/05, Alex Schultz wrote: > if blueprints > were encouraged as the primary method of making land plots, then too > many would look too alike even with player modifications, which defeats > a large part of what I think would make land plots so great, which is > that every player's plot would be unique to them and of their own > design. Such customizeability is something that I feel helps to make a > great RPG. Sure you could encourage blueprints and have empty as an > alternative, but I feel that the land plots may be somewhat dull if the > blueprints become the primary way of making them as opposed to empty > ones generated by the random map generator and built completely by the > player. exactly that, buying a pre-built house defeats the point of playing the sim^W^W with plots in crossfire.... From antonoussik at gmail.com Tue Sep 27 04:11:54 2005 From: antonoussik at gmail.com (Anton Oussik) Date: Tue Sep 27 04:13:34 2005 Subject: [crossfire] Buildable Land Plots In-Reply-To: <7903f03c050926170319da5de8@mail.gmail.com> References: <4337F1D3.3030001@telus.net> <7903f03c0509260850633305e7@mail.gmail.com> <4338843F.4000307@sympatico.ca> <433889D9.70603@telus.net> <7903f03c050926170319da5de8@mail.gmail.com> Message-ID: I agree there, but what happens when you want to build up (or down)? I guess you place a staircase up (or down), and end up on a new floor, which is unbuilt, and located above (or below) the previous map. From alex_sch at telus.net Tue Sep 27 07:42:17 2005 From: alex_sch at telus.net (Alex Schultz) Date: Tue Sep 27 07:43:38 2005 Subject: [crossfire] Buildable Land Plots In-Reply-To: References: <4337F1D3.3030001@telus.net> <7903f03c0509260850633305e7@mail.gmail.com> <4338843F.4000307@sympatico.ca> <433889D9.70603@telus.net> <7903f03c050926170319da5de8@mail.gmail.com> Message-ID: <43393E29.5000603@telus.net> Anton Oussik wrote: >I agree there, but what happens when you want to build up (or down)? I >guess you place a staircase up (or down), and end up on a new floor, >which is unbuilt, and located above (or below) the previous map. > > Hmm... that gave me a neat idea, though one very difficult to implement: When one makes an upper floor, it mirrors the floor and wall pattern of the floor below for it's start. Alex Schultz From brenlally at gmail.com Tue Sep 27 08:18:20 2005 From: brenlally at gmail.com (Brendan Lally) Date: Tue Sep 27 08:19:38 2005 Subject: [crossfire] Buildable Land Plots In-Reply-To: <43393E29.5000603@telus.net> References: <4337F1D3.3030001@telus.net> <7903f03c0509260850633305e7@mail.gmail.com> <4338843F.4000307@sympatico.ca> <433889D9.70603@telus.net> <7903f03c050926170319da5de8@mail.gmail.com> <43393E29.5000603@telus.net> Message-ID: <7903f03c0509270618cf5ddf8@mail.gmail.com> On 9/27/05, Alex Schultz wrote: > Hmm... that gave me a neat idea, though one very difficult to implement: > When one makes an upper floor, it mirrors the floor and wall pattern of > the floor below for it's start. I reckon the thing to do here would be to say that for upper floors building could be done up to one square out from any wall on the lower floor. - this would allow tudor style houses with jutting out walls, or a balcony-like structure. - practically, look to see if anything has been built on the square immediatly below, if not check that at least 2 of the squares adjacent to the one below it have been built on, if so set the can_build flag. Extra bonus points - check this on each entrance to the map, and destroy the walls if you remove their support, dropping any items that happen to be nearby, possibly destroying them, for lower floors no such restriction would be needed. -though maybe there should need to be a pillar or wall every 6 squares or so? From alex_sch at telus.net Tue Sep 27 09:55:08 2005 From: alex_sch at telus.net (Alex Schultz) Date: Tue Sep 27 10:05:41 2005 Subject: [crossfire] Re: Buildable Land Plots References: <4337F1D3.3030001@telus.net> <7903f03c0509260850633305e7@mail.gmail.com> <4338843F.4000307@sympatico.ca> <433889D9.70603@telus.net> <7903f03c050926170319da5de8@mail.gmail.com> <43393E29.5000603@telus.net> <7903f03c0509270618cf5ddf8@mail.gmail.com> Message-ID: Brendan Lally writes: > I reckon the thing to do here would be to say that for upper floors > building could be done up to one square out from any wall on the lower > floor. - this would allow tudor style houses with jutting out walls, > or a balcony-like structure. That's a good idea :-) > Extra bonus points - check this on each entrance to the map, and > destroy the walls if you remove their support, dropping any items that > happen to be nearby, possibly destroying them, Nice :-) I'd say though that somehow making them get scattered on the nearby ground on the first floor would be better than destroying them, which could take players by a little too much supprise. > for lower floors no such restriction would be needed. -though maybe > there should need to be a pillar or wall every 6 squares or so? I agree Alex Schultz From brenlally at gmail.com Tue Sep 27 10:52:55 2005 From: brenlally at gmail.com (Brendan Lally) Date: Tue Sep 27 10:53:42 2005 Subject: [crossfire] Re: Buildable Land Plots In-Reply-To: References: <4337F1D3.3030001@telus.net> <7903f03c0509260850633305e7@mail.gmail.com> <4338843F.4000307@sympatico.ca> <433889D9.70603@telus.net> <7903f03c050926170319da5de8@mail.gmail.com> <43393E29.5000603@telus.net> <7903f03c0509270618cf5ddf8@mail.gmail.com> Message-ID: <7903f03c050927085267be5357@mail.gmail.com> On 9/27/05, Alex Schultz wrote: > Brendan Lally writes: > > Extra bonus points - check this on each entrance to the map, and > > destroy the walls if you remove their support, dropping any items that > > happen to be nearby, possibly destroying them, > Nice :-) I'd say though that somehow making them get scattered on the nearby > ground on the first floor would be better than destroying them, which could > take players by a little too much supprise. Well to reach that stage a player would have to knock down a supporting wall, /in their own house/ I kinda think that whatever happens after that is fair game.... (possibly a warning message though, ("you see cracks appearing in the ceiling above your head, you are concerned that the remaining walls might not be strong enough to hold the upper floor of the building.") possibly the icecube code could be abused here, create rubble that would contain some of the items, and a shovel would be needed to clear it? From temitchell at sympatico.ca Tue Sep 27 18:04:14 2005 From: temitchell at sympatico.ca (Todd Mitchell) Date: Tue Sep 27 18:03:48 2005 Subject: [crossfire] Buildable Land Plots In-Reply-To: <7903f03c050926170319da5de8@mail.gmail.com> References: <4337F1D3.3030001@telus.net> <7903f03c0509260850633305e7@mail.gmail.com> <4338843F.4000307@sympatico.ca> <433889D9.70603@telus.net> <7903f03c050926170319da5de8@mail.gmail.com> Message-ID: <4339CFEE.8040701@sympatico.ca> Brendan Lally wrote: > >exactly that, buying a pre-built house defeats the point of playing >the sim^W^W with plots in crossfire.... > > > > Well I won't argue with that since I have no idea what it means or how you deduced it. I believe if you ask people if the built maps are superior to the random maps, you would hear that players like the built maps better. Since most players aren't into making maps - perhaps they may find it a bit hard or at least annoying to have to build things and they might like to buy something like the guild houses with things like trophy rooms, pet kennels, guest rooms and other special areas. At least with house templates you can have these nice features and make fun quests for players to access them. For personalization, well you can add many rooms that are buildable to the different house templates. Also the blueprints/templates way is an easy way to set different house styles on the map (houses, long houses, keeps, castles, guilds, temples...) to represent the building and a good way to set the starting price. Nothing stopping you from coding up a storm in any case, I'm sure you have ready counter-arguments to this post. I will upload the templates I worked on before so they are available in any case. From brenlally at gmail.com Tue Sep 27 19:23:42 2005 From: brenlally at gmail.com (Brendan Lally) Date: Tue Sep 27 19:23:50 2005 Subject: [crossfire] Buildable Land Plots In-Reply-To: <4339CFEE.8040701@sympatico.ca> References: <4337F1D3.3030001@telus.net> <7903f03c0509260850633305e7@mail.gmail.com> <4338843F.4000307@sympatico.ca> <433889D9.70603@telus.net> <7903f03c050926170319da5de8@mail.gmail.com> <4339CFEE.8040701@sympatico.ca> Message-ID: <7903f03c0509271723175442df@mail.gmail.com> On 9/28/05, Todd Mitchell wrote: > I believe if you ask people if the built maps are > superior to the random maps, you would hear that players like the built > maps better. I'm not quite sure your image of what is being described, and what is attempted to being described quite match up. we are talking about random maps yes, but random mostly empty maps. you might well have a map that looks like (in rogue style graphics...) ........... ........... ..T...T.... .....TT.... ......R..... ........... ........... .........~~ ....T.....B.~ ..........~ I've probably miscounted the width of some of those lines, but assume they are all the same width.... (T - tree B - bush R - rock ~- water) and every square would have can_build 1 on it > Since most players aren't into making maps - perhaps they > may find it a bit hard or at least annoying to have to build things They would be using constructors, not the map editor. > and > they might like to buy something like the guild houses with things like > trophy rooms, pet kennels, guest rooms and other special areas. They are already available in several towns throughout the game world... > At > least with house templates you can have these nice features and make fun > quests for players to access them. You can have nice constructors and have quests to access them too (for example a stone wall constructor, or a metal door constructor). > For personalization, well you can > add many rooms that are buildable to the different house templates. > Also the blueprints/templates way is an easy way to set different house > styles on the map (houses, long houses, keeps, castles, guilds, > temples...) to represent the building This is true, I'm not sure if there is a nice way to do this. > and a good way to set the starting price. Well, I was thinking to charge by plot (abuse the town portal marker, so that if it points to a valid plot square you 'ask' for that one), and charge based on proximity to entrances, roads etc.... although then all the constructors would have their own price, so a bigger buliding, would need more constructors than a smaller one. > Nothing stopping you from coding up a storm in any case, I'm sure you > have ready counter-arguments to this post. I will upload the templates > I worked on before so they are available in any case. Excellent, if nothing else, they will give a good idea of how to balance the building shop treasure lists to avoid any of the standard items (walls, doors, wooden floors) being too rare. From antonoussik at gmail.com Tue Sep 27 19:33:02 2005 From: antonoussik at gmail.com (Anton Oussik) Date: Tue Sep 27 19:33:49 2005 Subject: [crossfire] Buildable Land Plots In-Reply-To: <4339CFEE.8040701@sympatico.ca> References: <4337F1D3.3030001@telus.net> <7903f03c0509260850633305e7@mail.gmail.com> <4338843F.4000307@sympatico.ca> <433889D9.70603@telus.net> <7903f03c050926170319da5de8@mail.gmail.com> <4339CFEE.8040701@sympatico.ca> Message-ID: It seems there are two camps here: the "Players should build their own as it is a fun thing to do" and "players should get a pre-built map as it will make their life easier". I will propose a third, contradictory method, which sits in between, and will probably get ignored, as it will be more difficult to implement, but here we go anyways. A player buys a plot, and it starts off randomly generated. They can build the house themselves, or get themselves a house by contracting another player to build it. Something like "construction" skill would need to be introduced, so people can be professional builders and gain levels by offering their services as builders. Being high at the skill should probably decrease material cost to them, and maybe open up better construction materials (eg lvl 10 can make windows, at 20 you can place doors, at 20 stairs, and at 50 can build complex connected things). This way, a player not interested in construction can stay away from it, and for a player interested in architecture design will have a purpose in building things, and will want to get hired if not for the money, then for the ability to gain xp building the house. From brenlally at gmail.com Tue Sep 27 19:44:25 2005 From: brenlally at gmail.com (Brendan Lally) Date: Tue Sep 27 19:46:50 2005 Subject: [crossfire] Buildable Land Plots In-Reply-To: References: <4337F1D3.3030001@telus.net> <7903f03c0509260850633305e7@mail.gmail.com> <4338843F.4000307@sympatico.ca> <433889D9.70603@telus.net> <7903f03c050926170319da5de8@mail.gmail.com> <4339CFEE.8040701@sympatico.ca> Message-ID: <7903f03c050927174411aa2b79@mail.gmail.com> On 9/28/05, Anton Oussik wrote: > A player buys a plot, and it starts off randomly generated. They can > build the house themselves, or get themselves a house by contracting > another player to build it. Something like "construction" skill would > need to be introduced, so people can be professional builders and gain > levels by offering their services as builders. Being high at the skill > should probably decrease material cost to them, and maybe open up > better construction materials (eg lvl 10 can make windows, at 20 you > can place doors, at 20 stairs, and at 50 can build complex connected > things). I like this idea, but like you say, it is difficult to do, especially with the way constructors work currently. From alex_sch at telus.net Tue Sep 27 22:33:51 2005 From: alex_sch at telus.net (Alex Schultz) Date: Tue Sep 27 22:35:53 2005 Subject: [crossfire] Buildable Land Plots In-Reply-To: References: <4337F1D3.3030001@telus.net> <7903f03c0509260850633305e7@mail.gmail.com> <4338843F.4000307@sympatico.ca> <433889D9.70603@telus.net> <7903f03c050926170319da5de8@mail.gmail.com> <4339CFEE.8040701@sympatico.ca> Message-ID: <433A0F1F.2030404@telus.net> Anton Oussik wrote: >I will propose a third, contradictory method, which sits in between, >and will probably get ignored, as it will be more difficult to >implement, but here we go anyways. > >A player buys a plot, and it starts off randomly generated. They can >build the house themselves, or get themselves a house by contracting >another player to build it. Something like "construction" skill would >need to be introduced, so people can be professional builders and gain >levels by offering their services as builders. Being high at the skill >should probably decrease material cost to them, and maybe open up >better construction materials (eg lvl 10 can make windows, at 20 you >can place doors, at 20 stairs, and at 50 can build complex connected >things). > >This way, a player not interested in construction can stay away from >it, and for a player interested in architecture design will have a >purpose in building things, and will want to get hired if not for the >money, then for the ability to gain xp building the house. > Well, even if a construction skill wasn't implemented, the constructing players could still make a profit in money or traded items, and because the cost of building lots is high, they would be gaining in bargaining skill if they have that as well. Because of these factors, such behavior could potentially evolve from the social dynamics of crossfire anyways. Perhaps something like a central advertising area for one wanting a house built, and those willing to build, could be added to encourage this. Alex Schultz From mwedel at sonic.net Tue Sep 27 23:33:43 2005 From: mwedel at sonic.net (Mark Wedel) Date: Tue Sep 27 23:35:53 2005 Subject: [crossfire] Buildable Land Plots In-Reply-To: <433A0F1F.2030404@telus.net> References: <4337F1D3.3030001@telus.net> <7903f03c0509260850633305e7@mail.gmail.com> <4338843F.4000307@sympatico.ca> <433889D9.70603@telus.net> <7903f03c050926170319da5de8@mail.gmail.com> <4339CFEE.8040701@sympatico.ca> <433A0F1F.2030404@telus.net> Message-ID: <433A1D27.7020405@sonic.net> Well, I'd be in the camp that I want to buy my house prebuilt - I don't want to have to fiddle with putting walls down, doors, etc. But having a spot as a starting point could be nice. OTOH, I suppose the counter to that could why not just the scorn apartments or whatever. At some level, also have to decide how far this goes. IMO, at its heart, crossfire is an adventure type game, not a sim. The issue being that we probably can't be as good as a sim as a game dedicated for that purpose. I'd suggest getting the basics done first and worry about some of the likely less used things later (subcontracting buildings) From alex_sch at telus.net Wed Sep 28 00:33:59 2005 From: alex_sch at telus.net (Alex Schultz) Date: Wed Sep 28 00:35:55 2005 Subject: [crossfire] Buildable Land Plots In-Reply-To: <433A1D27.7020405@sonic.net> References: <4337F1D3.3030001@telus.net> <7903f03c0509260850633305e7@mail.gmail.com> <4338843F.4000307@sympatico.ca> <433889D9.70603@telus.net> <7903f03c050926170319da5de8@mail.gmail.com> <4339CFEE.8040701@sympatico.ca> <433A0F1F.2030404@telus.net> <433A1D27.7020405@sonic.net> Message-ID: <433A2B47.9020806@telus.net> Mark Wedel wrote: > Well, I'd be in the camp that I want to buy my house prebuilt - I > don't want to have to fiddle with putting walls down, doors, etc. But > having a spot as a starting point could be nice. > > OTOH, I suppose the counter to that could why not just the scorn > apartments or whatever. Whereas I would personally want to build it completely from scratch. IMHO it would be best to make both options available, with pros and cons to each, and I think that the main difference is the prebuilt ones could cost more to account for the materials cost. Even the blueprints ones do have uses other than the apartments do though, because one can invite others into it. Really, my counter is that IMHO building from scratch more fun, but really that's a rather personal thing. I have absolutely no problem with blueprints, so long as building from scratch is still available, and the pros and cons of each are properly balanced. > At some level, also have to decide how far this goes. IMO, at its > heart, crossfire is an adventure type game, not a sim. The issue > being that we probably can't be as good as a sim as a game dedicated > for that purpose. I'd suggest getting the basics done first and worry > about some of the likely less used things later (subcontracting > buildings) Indeed, which is why I'm personally starting step by step, starting with just working on the 'template maps' I've outlined in this thread. In terms of an adventure vs. sim, I feel that buildable plots in some form would enhance crossfire as a MORPG, because: 1) It increases player interaction by giving customizable maps that one can invite others into without having to bother with guilds and their storage rooms and such. IMO increased player interaction is something crossfire is in need of. 2) It plain gives players more to customize, which is a positive thing when it neither unbalances the game nor changes the genre In terms of things like contracting, I think that should be left to evolve from the social dynamics of the game, and therefore, if the players want it, they can get it, and if the players don't find it important then it won't float around without necessity. Really, a significant amount of the people who prefer MUDs to crossfire prefer the MUDs because of customizability elements such as this. Alex Schultz From nicolas.weeger at laposte.net Wed Sep 28 02:26:11 2005 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Wed Sep 28 06:09:59 2005 Subject: [crossfire] Buildable Land Plots Message-ID: > At some level, also have to decide how far this goes. IMO, at its heart, > crossfire is an adventure type game, not a sim. The issue being that we > probably can't be as good as a sim as a game dedicated for that purpose. I'd > suggest getting the basics done first and worry about some of the likely less > used things later (subcontracting buildings) I totally agree. Let's do the basics first, then we'll have fun extending :) Sometimes it's good to be real ambitious, but sometimes it's better to do step by step. Ryo Acc?dez au courrier ?lectronique de La Poste : www.laposte.net ; 3615 LAPOSTENET (0,34?/mn) ; t?l : 08 92 68 13 50 (0,34?/mn) From brenlally at gmail.com Wed Sep 28 10:21:36 2005 From: brenlally at gmail.com (Brendan Lally) Date: Wed Sep 28 10:24:05 2005 Subject: [crossfire] Buildable Land Plots In-Reply-To: <433A2B47.9020806@telus.net> References: <7903f03c0509260850633305e7@mail.gmail.com> <4338843F.4000307@sympatico.ca> <433889D9.70603@telus.net> <7903f03c050926170319da5de8@mail.gmail.com> <4339CFEE.8040701@sympatico.ca> <433A0F1F.2030404@telus.net> <433A1D27.7020405@sonic.net> <433A2B47.9020806@telus.net> Message-ID: <7903f03c05092808217e79f1af@mail.gmail.com> On 9/28/05, Alex Schultz wrote: > would enhance crossfire as a MORPG, because: > 1) It increases player interaction by giving customizable maps that one > can invite others into without having to bother with guilds and their > storage rooms and such. IMO increased player interaction is something > crossfire is in need of. > 2) It plain gives players more to customize, which is a positive thing > when it neither unbalances the game nor changes the genre You forgot a third one, it gives players something to do with all the money that they can currently collect. Currently there are ways to get money (alchemy & dungeon crawling) which work ad infinitum, however the existing ways of spending money (slot machines, apartments, equipment) is fairly limited, so that, after the first million platinum or so, there isn't a whole lot to spend money on. However introducing a status element that can require vast expenditure, should be a nice way to take money away from the fool^H^H^H^H rich. - especially if there are enough glitzy things that can costs tens of thousands of platinum each (like mikee's coloured tiled floors in constructor form) From nicolas.weeger at laposte.net Wed Sep 28 13:52:20 2005 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Wed Sep 28 13:54:08 2005 Subject: [crossfire] Improved collect.pl script Message-ID: <433AE664.4050102@laposte.net> Hello. I just committed a change to the archetypes collect script collect.pl.in that makes it easier to write and also read archetypes. You can now use "attacktype fire poison" instead of computing "fire + poison is 1028". You can even mix values and text (ie "attacktype 1028 death" to add death to existing attacktype). Note that Java Editor (and CrossEdit if it can read archetypes directly?) should be tweaked to be able to read those values. Ryo From nicolas.weeger at laposte.net Wed Sep 28 14:55:23 2005 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Wed Sep 28 14:56:09 2005 Subject: [crossfire] moving gps code Message-ID: <433AF52B.6070508@laposte.net> Hello. A while ago i added a "ground positionning system", item that lets you know your location in the world. AFAIK you can only find it on mlab maps, it's not yet on other maps. Unless someone objects with good arguments, i'll move the relevant code to a Python script. Since it's not a mandatory behaviour (it's more a convenience), a script is the perfect way for it, and that means i can trash the specially introduced item type. Note that there shouldn't be any conversion issue between old & new implementation as long as archetypes and maps are updated at the same time. Ryo From josh at woosworld.net Wed Sep 28 15:52:34 2005 From: josh at woosworld.net (Joshua Wilson) Date: Wed Sep 28 15:54:07 2005 Subject: [crossfire] moving gps code In-Reply-To: <433AF52B.6070508@laposte.net> References: <433AF52B.6070508@laposte.net> Message-ID: <433B0292.2050003@woosworld.net> So how long until I can get GPS directions to (location X) for Y payment? Nicolas Weeger wrote: > Hello. > > A while ago i added a "ground positionning system", item that lets you > know your location in the world. > AFAIK you can only find it on mlab maps, it's not yet on other maps. > > Unless someone objects with good arguments, i'll move the relevant code > to a Python script. Since it's not a mandatory behaviour (it's more a > convenience), a script is the perfect way for it, and that means i can > trash the specially introduced item type. > > Note that there shouldn't be any conversion issue between old & new > implementation as long as archetypes and maps are updated at the same time. > > Ryo > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > > > From alex_sch at telus.net Wed Sep 28 17:44:26 2005 From: alex_sch at telus.net (Alex Schultz) Date: Wed Sep 28 17:46:11 2005 Subject: [crossfire] Improved collect.pl script In-Reply-To: <433AE664.4050102@laposte.net> References: <433AE664.4050102@laposte.net> Message-ID: <433B1CCA.8010506@telus.net> Nicolas Weeger wrote: >Hello. > >I just committed a change to the archetypes collect script collect.pl.in >that makes it easier to write and also read archetypes. >You can now use "attacktype fire poison" instead of computing "fire + >poison is 1028". >You can even mix values and text (ie "attacktype 1028 death" to add >death to existing attacktype). > > If I were to do it I would have implemented this behavior in the server instead of in the collecting of archetypes (that way it could be used in maps as well), but this is fine too. >(and CrossEdit if it can read archetypes directly?) > > I'm not sure what you mean. CrossEdit reads the archetypes exactly as the server does. It won't know the difference because it will read the archetypes after they've been collected and therefore after the collect script has converted the attacktype values. Alex Schultz From nicolas.weeger at laposte.net Thu Sep 29 02:23:22 2005 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Thu Sep 29 02:24:19 2005 Subject: [crossfire] Improved collect.pl script Message-ID: > If I were to do it I would have implemented this behavior in the server > instead of in the collecting of archetypes (that way it could be used in > maps as well), but this is fine too. I voluntarily choose to do that at collect time, because doing it at item or map load time may be bad for loading performance. Also it's much easier to do it with Perl than C :) > I'm not sure what you mean. CrossEdit reads the archetypes exactly as > the server does. It won't know the difference because it will read the > archetypes after they've been collected and therefore after the collect > script has converted the attacktype values. The Java editor can use "raw" archetypes from the arch directory. Thus it needs too to support "attacktype fire". As I don't know Crossedit, I don't know whether it always uses collected archetypes or if it too can use uncollected ones. Nicolas Acc?dez au courrier ?lectronique de La Poste : www.laposte.net ; 3615 LAPOSTENET (0,34?/mn) ; t?l : 08 92 68 13 50 (0,34?/mn) From mikeeusaaa at yahoo.com Thu Sep 29 07:27:08 2005 From: mikeeusaaa at yahoo.com (Mitch Obrian) Date: Thu Sep 29 07:28:23 2005 Subject: [crossfire] Made a CVS upload error: /maps-bigworld/unlinked/mlab-devel/mlab-devel.tar.gz Message-ID: <20050929122708.33045.qmail@web61023.mail.yahoo.com> I uploaded the tar to cvs at /maps-bigworld/unlinked/mlab-devel/mlab-devel.tar.gz in my tiredness last night. Can someone remove the tarball /maps-bigworld/unlinked/mlab-devel/mlab-devel.tar.gz I uploaded it to the correct path today. __________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com From mikeeusaaa at yahoo.com Thu Sep 29 07:49:32 2005 From: mikeeusaaa at yahoo.com (Mitch Obrian) Date: Thu Sep 29 07:50:23 2005 Subject: [crossfire] moving gps code (map) In-Reply-To: <433AF52B.6070508@laposte.net> Message-ID: <20050929124932.5299.qmail@web61024.mail.yahoo.com> It can be found in the maze/palace and requires 4 players to complete the quest. There is other treasure there too, the gps is the prize though, If anyone would like to incorperate it into their servers mlab is under unlinked/mlab-devel and just needs to be moved to the root of the maps dir and the unlinked/mlab-devel/MISC/world/world_* need to be copied to the world dir. --- Nicolas Weeger wrote: > Hello. > > A while ago i added a "ground positionning system", > item that lets you > know your location in the world. > AFAIK you can only find it on mlab maps, it's not > yet on other maps. > > Unless someone objects with good arguments, i'll > move the relevant code > to a Python script. Since it's not a mandatory > behaviour (it's more a > convenience), a script is the perfect way for it, > and that means i can > trash the specially introduced item type. > > Note that there shouldn't be any conversion issue > between old & new > implementation as long as archetypes and maps are > updated at the same time. > > Ryo > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > __________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com From quisar at quisar.ambre.net Thu Sep 29 08:21:54 2005 From: quisar at quisar.ambre.net (Benjamin Lerman) Date: Thu Sep 29 08:22:23 2005 Subject: [crossfire] Summon pet monster Message-ID: <20050929132153.GA17271@marelle.ambre.net> Hi all, I write two patches that I put on the sf page. The first one allow you to summon pet that are of lower level that the current pet you can summon. It is mainly a one line patch that use the same argument that create food or create weapon use. The second one allow to use argument with the cast command so that you can use: cast create food waybread or cast summon pet monster spider What do you think about those patches? Now, I plan to create Enchant Ring and Enchant Amulet scrolls that would work like Enchant Weapon, but because it demands a little more work than for the 2 previous patch, I'd like to know if those scrolls would be Ok. I'd like to also implement think like Improve resistance to `foo' for Weapons, but once again, would that be Ok? And at least, I have a question, does there exists a way to force the client to wear a particular holy symbol whenever possible. Right now, whenever I change skill, even if I do not need any object to get my new skill, my holy symbol is unapplied, which is quite a problem when the holy symbol does a lot more than give the skill praying... -- Benjamin From brenlally at gmail.com Thu Sep 29 09:42:20 2005 From: brenlally at gmail.com (Brendan Lally) Date: Thu Sep 29 09:44:25 2005 Subject: [crossfire] Summon pet monster In-Reply-To: <20050929132153.GA17271@marelle.ambre.net> References: <20050929132153.GA17271@marelle.ambre.net> Message-ID: <7903f03c05092907423128a47b@mail.gmail.com> On 9/29/05, Benjamin Lerman wrote: > Now, I plan to create Enchant Ring and Enchant Amulet scrolls that > would work like Enchant Weapon, but because it demands a little more work > than for the 2 previous patch, I'd like to know if those scrolls would > be Ok. I'd like to also implement think like Improve resistance to `foo' > for Weapons, but once again, would that be Ok? The one comment I would make here is to be sure to deal with the item power properly. What exactly 'properly' is in this context is not neccessarily clear, too little an effect and these scrolls would make rings overpowered, too much, and they would be useless. I would suggest however that if the results of enchanting rings to the extent that their stats are about the same as one with similar item power from the item generator, then you are probably ok. Something that does interest me though, is how you intend to fit this in with the jeweler skill. From nicolas.weeger at laposte.net Thu Sep 29 10:00:45 2005 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Thu Sep 29 10:06:52 2005 Subject: [crossfire] Summon pet monster Message-ID: Hello. > The first one allow you to summon pet that are of lower level that the > current pet you can summon. It is mainly a one line patch that use the > same argument that create food or create weapon use. Saw it on SF, sounds ok. > The second one allow to use argument with the cast command so that you > can use: Isn't there already a field in player structure for spell argument? used when spells have delays, iirc. > Now, I plan to create Enchant Ring and Enchant Amulet scrolls that > would work like Enchant Weapon, but because it demands a little more work > than for the 2 previous patch, I'd like to know if those scrolls would > be Ok. I'd like to also implement think like Improve resistance to `foo' > for Weapons, but once again, would that be Ok? I'd say you must take care of the overall game balance. Rings and amulets may already be quite powerful, probably don't want to give too much new & powerful stuff. As for resistances, i'd say rather no. Unless well though, it could lead to have really high resistances almost everywhere, thus making everything too easy. > And at least, I have a question, does there exists a way to force the > client to wear a particular holy symbol whenever possible. Right now, > whenever I change skill, even if I do not need any object to get my new > skill, my holy symbol is unapplied, which is quite a problem when the > holy symbol does a lot more than give the skill praying... Afaik no. And yes it's quite a pain. Maybe something to change, ie whenever you cast a spell or something a talisman is autoapplied. Nicolas Acc?dez au courrier ?lectronique de La Poste : www.laposte.net ; 3615 LAPOSTENET (0,34?/mn) ; t?l : 08 92 68 13 50 (0,34?/mn) From quisar at quisar.ambre.net Thu Sep 29 11:05:54 2005 From: quisar at quisar.ambre.net (Benjamin Lerman) Date: Thu Sep 29 11:06:24 2005 Subject: [crossfire] Summon pet monster In-Reply-To: References: Message-ID: <20050929160554.GA19525@marelle.ambre.net> > Isn't there already a field in player structure for spell > argument? used when spells have delays, iirc. I did (and still don't) see it. If I grep for char in player.h, I obtain: logrus ~/download/crossfire/include $ grep char player.h ... snip what is not on the pl struct char maplevel[MAX_BUF]; /* On which level is the player? */ char savebed_map[MAX_BUF]; /* map where player will respawn after death */ char spellparam[MAX_BUF]; /* What param to add to spells */ const char *invis_race;/* What race invisible to? */ char own_title[MAX_NAME]; /* Title the player has chosen for themself */ char title[BIG_NAME]; /* Default title, like fighter, wizard, etc */ char killer[BIG_NAME]; /* Who killed this player. */ char last_tell[MAX_NAME]; /* last player that told you something [mids 01/14/2002] */ char write_buf[MAX_BUF]; /* Holds arbitrary input from client */ char input_buf[MAX_BUF]; /* Holds command to run */ char password[16]; /* 2 (seed) + 11 (crypted) + 1 (EOS) + 2 (safety) = 16 */ char search_str[MAX_BUF]; /* Item we are looking for */ If you remove spellparam which is the field I added, I do not see which other field you are referring to. Benjamin Lerman From mikeeusaaa at yahoo.com Thu Sep 29 12:07:05 2005 From: mikeeusaaa at yahoo.com (Mitch Obrian) Date: Thu Sep 29 12:08:26 2005 Subject: [crossfire] Summon pet monster In-Reply-To: Message-ID: <20050929170705.32310.qmail@web61015.mail.yahoo.com> Resistances are bad, I agree. That would basically make all maps in the game worthlessly easy. Same with upping ring power. One has to, as of now, search for good rings which, I think, is the correct way. If anything CF needs to be made harder. --- Nicolas Weeger wrote: > Hello. > > > The first one allow you to summon pet that are of > lower > level that the > > current pet you can summon. It is mainly a one > line patch > that use the > > same argument that create food or create weapon > use. > > Saw it on SF, sounds ok. > > > The second one allow to use argument with the > cast command > so that you > > can use: > > Isn't there already a field in player structure for > spell > argument? used when spells have delays, iirc. > > > Now, I plan to create Enchant Ring and Enchant > Amulet > scrolls that > > would work like Enchant Weapon, but because it > demands a > little more work > > than for the 2 previous patch, I'd like to know if > those > scrolls would > > be Ok. I'd like to also implement think like > Improve > resistance to `foo' > > for Weapons, but once again, would that be Ok? > > I'd say you must take care of the overall game > balance. > Rings and amulets may already be quite powerful, > probably > don't want to give too much new & powerful stuff. > As for resistances, i'd say rather no. Unless well > though, it > could lead to have really high resistances almost > everywhere, > thus making everything too easy. > > > And at least, I have a question, does there > exists a way to > force the > > client to wear a particular holy symbol whenever > possible. > Right now, > > whenever I change skill, even if I do not need any > object to > get my new > > skill, my holy symbol is unapplied, which is quite > a problem > when the > > holy symbol does a lot more than give the skill > praying... > > Afaik no. And yes it's quite a pain. > Maybe something to change, ie whenever you cast a > spell or > something a talisman is autoapplied. > > Nicolas > > Acc?dez au courrier ?lectronique de La Poste : > www.laposte.net ; > 3615 LAPOSTENET (0,34?/mn) ; t?l : 08 92 68 13 50 > (0,34?/mn) > > > > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > __________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com From mikeeusaaa at yahoo.com Thu Sep 29 12:18:49 2005 From: mikeeusaaa at yahoo.com (Mitch Obrian) Date: Thu Sep 29 12:20:27 2005 Subject: [crossfire] Summon pet monster In-Reply-To: <20050929160554.GA19525@marelle.ambre.net> Message-ID: <20050929171849.79606.qmail@web61024.mail.yahoo.com> I like the being able to specify summoned monster idea :) --- Benjamin Lerman wrote: > > Isn't there already a field in player structure > for spell > > argument? used when spells have delays, iirc. > > I did (and still don't) see it. > > If I grep for char in player.h, I obtain: > > logrus ~/download/crossfire/include $ grep char > player.h > ... snip what is not on the pl struct > char maplevel[MAX_BUF]; /* On which > level is the player? */ > char savebed_map[MAX_BUF]; /* map where > player will respawn after death */ > char spellparam[MAX_BUF]; /* What > param to add to spells */ > const char *invis_race;/* What race invisible > to? */ > char own_title[MAX_NAME]; /* Title the > player has chosen for themself */ > char title[BIG_NAME]; /* Default > title, like fighter, wizard, etc */ > char killer[BIG_NAME]; /* Who killed > this player. */ > char last_tell[MAX_NAME]; /* last > player that told you something [mids 01/14/2002] */ > char write_buf[MAX_BUF]; /* Holds > arbitrary input from client */ > char input_buf[MAX_BUF]; /* Holds command > to run */ > char password[16]; /* 2 (seed) + 11 > (crypted) + 1 (EOS) + 2 (safety) = 16 */ > char search_str[MAX_BUF]; /* Item we are > looking for */ > > If you remove spellparam which is the field I > added, I do not see which > other field you are referring to. > > Benjamin Lerman > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > __________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com From eracclists at bellsouth.net Thu Sep 29 14:02:00 2005 From: eracclists at bellsouth.net (ERACC) Date: Thu Sep 29 14:02:28 2005 Subject: [crossfire] Summon pet monster In-Reply-To: <20050929132153.GA17271@marelle.ambre.net> References: <20050929132153.GA17271@marelle.ambre.net> Message-ID: <200509291402.00382.eracclists@bellsouth.net> On Thursday 29 September 2005 08:21 am Benjamin Lerman wrote: [...] > The second one allow to use argument with the cast command so that you > can use: > > cast create food waybread > or > cast summon pet monster spider [...] Isn't this what 'invoke is meant to do? If 'cast will do it now then why have 'invoke? Seems to me we should either leave 'cast as is or make that change and remove 'invoke. There is no reason to have both. I vote to leave 'cast as is because I have an oodle of key bindings using 'invoke. :-) Gene Alexander -- Linux era4.eracc.UUCP 2.6.8.1-12mdk i686 13:57:12 up 134 days, 14:38, 8 users, load average: 0.13, 0.19, 0.14 ERA Computer Consulting - http://www.eracc.com/ eCS, Linux, FreeBSD, OpenServer & UnixWare resellers From fuchs.andy at gmail.com Thu Sep 29 14:15:48 2005 From: fuchs.andy at gmail.com (Andrew Fuchs) Date: Thu Sep 29 14:16:28 2005 Subject: [crossfire] Summon pet monster In-Reply-To: <200509291402.00382.eracclists@bellsouth.net> References: <20050929132153.GA17271@marelle.ambre.net> <200509291402.00382.eracclists@bellsouth.net> Message-ID: On 9/29/05, ERACC wrote: ... > Isn't this what 'invoke is meant to do? If 'cast will do it now then > why have 'invoke? Seems to me we should either leave 'cast as is or > make that change and remove 'invoke. There is no reason to have both. > I vote to leave 'cast as is because I have an oodle of key bindings > using 'invoke. :-) Cast readys the spell for use, while invoke imediatly uses the spell. Bolth have their place, but cast doesn't accept arguments like invoke does. -- Andrew Fuchs From eracclists at bellsouth.net Thu Sep 29 15:16:22 2005 From: eracclists at bellsouth.net (ERACC) Date: Thu Sep 29 15:18:32 2005 Subject: [crossfire] Summon pet monster In-Reply-To: References: <20050929132153.GA17271@marelle.ambre.net> <200509291402.00382.eracclists@bellsouth.net> Message-ID: <200509291516.22616.eracclists@bellsouth.net> On Thursday 29 September 2005 02:15 pm Andrew Fuchs wrote: > On 9/29/05, ERACC wrote: > ... > > Isn't this what 'invoke is meant to do? If 'cast will do it now then > > why have 'invoke? Seems to me we should either leave 'cast as is or > > make that change and remove 'invoke. There is no reason to have both. > > I vote to leave 'cast as is because I have an oodle of key bindings > > using 'invoke. :-) > > Cast readys the spell for use, while invoke imediatly uses the spell. > Bolth have their place, but cast doesn't accept arguments like invoke does. Ah, I get it now. Ready the spell *with* an argument so that when one does cast it the argument is used. Ok. Yeah, that would be good. Gene Alexander -- Linux era4.eracc.UUCP 2.6.8.1-12mdk i686 15:15:03 up 134 days, 15:56, 8 users, load average: 0.19, 0.17, 0.13 ERA Computer Consulting - http://www.eracc.com/ eCS, Linux, FreeBSD, OpenServer & UnixWare resellers From josh at woosworld.net Thu Sep 29 15:46:00 2005 From: josh at woosworld.net (Joshua Wilson) Date: Thu Sep 29 15:46:30 2005 Subject: [crossfire] Summon pet monster In-Reply-To: References: <20050929132153.GA17271@marelle.ambre.net> <200509291402.00382.eracclists@bellsouth.net> Message-ID: <433C5288.9030309@woosworld.net> Exactly. Such that if you wanted to create a few rounds of something particular you have to invoke create food yyy a few times, instead of cast create food yyy and fire a few times. Andrew Fuchs wrote: > On 9/29/05, ERACC wrote: > ... > >>Isn't this what 'invoke is meant to do? If 'cast will do it now then >>why have 'invoke? Seems to me we should either leave 'cast as is or >>make that change and remove 'invoke. There is no reason to have both. >>I vote to leave 'cast as is because I have an oodle of key bindings >>using 'invoke. :-) > > > Cast readys the spell for use, while invoke imediatly uses the spell. > Bolth have their place, but cast doesn't accept arguments like invoke does. > > -- > Andrew Fuchs > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > > > From alex_sch at telus.net Thu Sep 29 17:18:52 2005 From: alex_sch at telus.net (Alex Schultz) Date: Thu Sep 29 17:20:33 2005 Subject: [crossfire] Summon pet monster In-Reply-To: <200509291402.00382.eracclists@bellsouth.net> References: <20050929132153.GA17271@marelle.ambre.net> <200509291402.00382.eracclists@bellsouth.net> Message-ID: <433C684C.8050204@telus.net> ERACC wrote: >On Thursday 29 September 2005 08:21 am >Benjamin Lerman wrote: > >[...] > > >> The second one allow to use argument with the cast command so that you >>can use: >> >>cast create food waybread >>or >>cast summon pet monster spider >> >> >[...] > >Isn't this what 'invoke is meant to do? If 'cast will do it now then >why have 'invoke? Seems to me we should either leave 'cast as is or >make that change and remove 'invoke. There is no reason to have both. >I vote to leave 'cast as is because I have an oodle of key bindings >using 'invoke. :-) > > Well, there are many times I prefer invoke for things were I don't want to add a argument. Such as quickly using word of recall without risk of using it more than once by accident. Alex Schultz From mwedel at sonic.net Thu Sep 29 23:11:29 2005 From: mwedel at sonic.net (Mark Wedel) Date: Thu Sep 29 23:12:37 2005 Subject: [crossfire] Improved collect.pl script In-Reply-To: References: Message-ID: <433CBAF1.9020401@sonic.net> Nicolas Weeger wrote: >>If I were to do it I would have implemented this behavior in > > the server > >>instead of in the collecting of archetypes (that way it > > could be used in > >>maps as well), but this is fine too. > > > I voluntarily choose to do that at collect time, because doing > it at item or map load time may be bad for loading performance. > Also it's much easier to do it with Perl than C :) Doing it at the loader would also have the advantage that you could tweak maps or player save files more easily. And it should only effect load performance when it has to deal with those. The other gotcha might be people looking at archetypes and seeing things like 'attacktype fire godpower' and thinking they can use that for their maps or other non archetype things. But that probably isn't a very big issue either. That said, this is certainly better than was there before, and I don't really think the loader needs to be able to support this format - keeping that simpler is probably better. > The Java editor can use "raw" archetypes from the arch > directory. Thus it needs too to support "attacktype fire". > As I don't know Crossedit, I don't know whether it always uses > collected archetypes or if it too can use uncollected ones. crossedit only supports the already collected archetypes, it can't read the individual archetype files. From mwedel at sonic.net Thu Sep 29 23:37:07 2005 From: mwedel at sonic.net (Mark Wedel) Date: Thu Sep 29 23:38:38 2005 Subject: [crossfire] Re: [Crossfire-devel] Made a CVS upload error: /maps-bigworld/unlinked/mlab-devel/mlab-devel.tar.gz In-Reply-To: <20050929122708.33045.qmail@web61023.mail.yahoo.com> References: <20050929122708.33045.qmail@web61023.mail.yahoo.com> Message-ID: <433CC0F3.9050806@sonic.net> Mitch Obrian wrote: > I uploaded the tar to cvs at > /maps-bigworld/unlinked/mlab-devel/mlab-devel.tar.gz > in my tiredness last night. Can someone remove the > tarball > /maps-bigworld/unlinked/mlab-devel/mlab-devel.tar.gz > > I uploaded it to the correct path today. My personal opinion is that mlab-devel.tar.gz should not be in CVS. The untarred files are already there - the tar is just redundant data. I can't think of any compelling reason why it is needed - presumably anyone tha wants to use it is smart enough to do be able to do a 'mv' from the the current directory. It is after all sucking up an extra 5.5 megabytes of space. Mind you, that isn't a lot, but in terms of bandwdith to download it (doing a cvs update -dP on entire map directory, which is often common procedure) it is non trivial. And since it is binary, you have to get the entire thing. IMO, CVS is not well designed to hold binary files, and certainly doesn't deal well with really big ones. So unless there is a compelling reason it needs to be there (and if there is, please provide it), it should be removed. Now as far as the untarred mlab stuff, I'm more mixed on that. In the past, the stuff in the unlinked directory was basically maps that came from whatever sources and needed to be integrated, but did not have anyone actively developing them. So it was basically a holding area until someone found the time. The mlab maps obviously do not fall into that case - they are clearly being actively developed, and the person doing so has CVS. One problem that arises from this is that there really isn't any way for anyone to integrate the mlab maps - your trying to integrate a moving target. The other is that this really just seems to be a way to avoid the mapguide - I know Mike doesn't want to follow our map directory layout or some other areas of the mapguide. But it seems to me that either either the rules should be followed and these maps checked in the right places, or they shouldn't be checked in at all. I don't like the idea of stuff being thrown into CVS for someone else to take care of. I could see this leading to similar things for the client or server code - someone throwing code into a 'patches' or 'test' directory or something that doesn't meet coding guidelines - either the stuff should be mature enough to be checked into CVS, or it shouldn't be. The other possiblities is to make a new CVS repository for this - instead of unlinked being a directory in the maps tree, make a maps-unlinked CVS repository for all this stuff. But then I'm still stuck figuring out what is going to happen with all this mlab stuff - either the correct rules should be followed and this integrated in properly with the maps, or it probably shouldn't be there. > > > > > > __________________________________ > Yahoo! Mail - PC Magazine Editors' Choice 2005 > http://mail.yahoo.com > > > ------------------------------------------------------- > This SF.Net email is sponsored by: > Power Architecture Resource Center: Free content, downloads, discussions, > and more. http://solutions.newsforge.com/ibmarch.tmpl > _______________________________________________ > Crossfire-devel mailing list > Crossfire-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/crossfire-devel From alex_sch at telus.net Fri Sep 30 00:09:53 2005 From: alex_sch at telus.net (Alex Schultz) Date: Fri Sep 30 00:10:38 2005 Subject: [crossfire] Re: [Crossfire-devel] Made a CVS upload error: /maps-bigworld/unlinked/mlab-devel/mlab-devel.tar.gz In-Reply-To: <433CC0F3.9050806@sonic.net> References: <20050929122708.33045.qmail@web61023.mail.yahoo.com> <433CC0F3.9050806@sonic.net> Message-ID: <433CC8A1.2090505@telus.net> Mark Wedel wrote: > The mlab maps obviously do not fall into that case - they are clearly > being actively developed, and the person doing so has CVS. > > One problem that arises from this is that there really isn't any way > for anyone to integrate the mlab maps - your trying to integrate a > moving target. > > The other is that this really just seems to be a way to avoid the > mapguide - I know Mike doesn't want to follow our map directory layout > or some other areas of the mapguide. > > [snip] > > But then I'm still stuck figuring out what is going to happen with > all this mlab stuff - either the correct rules should be followed and > this integrated in properly with the maps, or it probably shouldn't be > there. In terms of integrating a moving target, I don't see how it would be any better if they weren't in CVS. Really, the target is still moving if one was trying to work from Mike's periodic mlab release tarballs, so though it being in CVS doesn't solve the moving target problem, it does allow the movement of the target to be tracked better which IMHO is somewhat helpful to the moving target situation, even if only slightly. In terms of mapguide issues, I agree, though if Mike is too unwilling to change, it may be possible to fix many of the mapguide issues by script (i.e. the directory layout could be autogenerated from the map name prefixes that Mike is using), however chances are this would break from time to time, so I don't see this as too appealing an option unless Mike is willing to adopt such fixes for the development of mlab. I know one of Mike's worries with changing his current layout is that scripts could possibly end up creating small errors and breakage. Question to Mike: What exactly in the mapguide are you opposed to? And why exactly? Alex Schultz From mikeeusaaa at yahoo.com Fri Sep 30 01:06:13 2005 From: mikeeusaaa at yahoo.com (Mitch Obrian) Date: Fri Sep 30 01:06:40 2005 Subject: [crossfire] Re: [Crossfire-devel] Made a CVS upload error: /maps-bigworld/unlinked/mlab-devel/mlab-devel.tar.gz In-Reply-To: <433CC8A1.2090505@telus.net> Message-ID: <20050930060613.68773.qmail@web61014.mail.yahoo.com> For all other maps sans mlab I follow the map guide. However mlab was started way before these, thus it uses the flatdirectory structure so it stays working. I've seen maps break many times before, including my tavern when it was uploaded to cvs originally. Why must there be contoversy just over a file system? If I can't upload my maps to CVS where do I back them up to? Are they that worthless? I do a fair amount of CF work in arches and non-mlab maps, could I have alittle slack? Why is there opposistion just because I put the maps in their own flatlevel dir? The reasoning that mlab doesn't even deserve to be in CVS is very alienating, I've worked years on theses maps. I work nearly constantly on maps for CF. Mlab could be intergrated into CF-proper right now if I was just given the OK. If an exception to the dir rule was made. I though after being involved in CF this long the controversy was over and I could develop as a regular without asking about every change. I uploaded mlab so it would be with CF, so if my computers go down my years of work are not lost. Sure one can say "go find some other place to back up to" but... that's basically telling the person to screw off; their work is of little value. The tar is uploaded so it itself is not lost, it is only 5 megs. --- Alex Schultz wrote: > Mark Wedel wrote: > > > The mlab maps obviously do not fall into that case > - they are clearly > > being actively developed, and the person doing so > has CVS. > > > > One problem that arises from this is that there > really isn't any way > > for anyone to integrate the mlab maps - your > trying to integrate a > > moving target. > > > > The other is that this really just seems to be a > way to avoid the > > mapguide - I know Mike doesn't want to follow our > map directory layout > > or some other areas of the mapguide. > > > > [snip] > > > > But then I'm still stuck figuring out what is > going to happen with > > all this mlab stuff - either the correct rules > should be followed and > > this integrated in properly with the maps, or it > probably shouldn't be > > there. > > In terms of integrating a moving target, I don't see > how it would be any > better if they weren't in CVS. Really, the target is > still moving if one > was trying to work from Mike's periodic mlab release > tarballs, so though > it being in CVS doesn't solve the moving target > problem, it does allow > the movement of the target to be tracked better > which IMHO is somewhat > helpful to the moving target situation, even if only > slightly. > In terms of mapguide issues, I agree, though if Mike > is too unwilling to > change, it may be possible to fix many of the > mapguide issues by script > (i.e. the directory layout could be autogenerated > from the map name > prefixes that Mike is using), however chances are > this would break from > time to time, so I don't see this as too appealing > an option unless Mike > is willing to adopt such fixes for the development > of mlab. I know one > of Mike's worries with changing his current layout > is that scripts could > possibly end up creating small errors and breakage. > Question to Mike: What exactly in the mapguide are > you opposed to? And > why exactly? > > Alex Schultz > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > __________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com From mikeeusaaa at yahoo.com Fri Sep 30 01:16:56 2005 From: mikeeusaaa at yahoo.com (Mitch Obrian) Date: Fri Sep 30 01:18:41 2005 Subject: [crossfire] Re: [Crossfire-devel] Made a CVS upload error: /maps-bigworld/unlinked/mlab-devel/mlab-devel.tar.gz In-Reply-To: <20050930060613.68773.qmail@web61014.mail.yahoo.com> Message-ID: <20050930061656.74031.qmail@web61014.mail.yahoo.com> Note: I've though about asking for just such a backup cvs dir/branch before, perhapse it would be a good idea? --- Mitch Obrian wrote: > For all other maps sans mlab I follow the map guide. > However mlab was started way before these, thus it > uses the flatdirectory structure so it stays > working. > I've seen maps break many times before, including my > tavern when it was uploaded to cvs originally. > > Why must there be contoversy just over a file > system? > > If I can't upload my maps to CVS where do I back > them > up to? Are they that worthless? I do a fair amount > of > CF work in arches and non-mlab maps, could I have > alittle slack? Why is there opposistion just because > I > put the maps in their own flatlevel dir? > > The reasoning that mlab doesn't even deserve to be > in > CVS is very alienating, I've worked years on theses > maps. I work nearly constantly on maps for CF. > > Mlab could be intergrated into CF-proper right now > if > I was just given the OK. If an exception to the dir > rule was made. > > I though after being involved in CF this long the > controversy was over and I could develop as a > regular > without asking about every change. I uploaded mlab > so > it would be with CF, so if my computers go down my > years of work are not lost. Sure one can say "go > find > some other place to back up to" but... that's > basically telling the person to screw off; their > work > is of little value. > > The tar is uploaded so it itself is not lost, it is > only 5 megs. > > --- Alex Schultz wrote: > > > Mark Wedel wrote: > > > > > The mlab maps obviously do not fall into that > case > > - they are clearly > > > being actively developed, and the person doing > so > > has CVS. > > > > > > One problem that arises from this is that there > > really isn't any way > > > for anyone to integrate the mlab maps - your > > trying to integrate a > > > moving target. > > > > > > The other is that this really just seems to be > a > > way to avoid the > > > mapguide - I know Mike doesn't want to follow > our > > map directory layout > > > or some other areas of the mapguide. > > > > > > [snip] > > > > > > But then I'm still stuck figuring out what is > > going to happen with > > > all this mlab stuff - either the correct rules > > should be followed and > > > this integrated in properly with the maps, or it > > probably shouldn't be > > > there. > > > > In terms of integrating a moving target, I don't > see > > how it would be any > > better if they weren't in CVS. Really, the target > is > > still moving if one > > was trying to work from Mike's periodic mlab > release > > tarballs, so though > > it being in CVS doesn't solve the moving target > > problem, it does allow > > the movement of the target to be tracked better > > which IMHO is somewhat > > helpful to the moving target situation, even if > only > > slightly. > > In terms of mapguide issues, I agree, though if > Mike > > is too unwilling to > > change, it may be possible to fix many of the > > mapguide issues by script > > (i.e. the directory layout could be autogenerated > > from the map name > > prefixes that Mike is using), however chances are > > this would break from > > time to time, so I don't see this as too appealing > > an option unless Mike > > is willing to adopt such fixes for the development > > of mlab. I know one > > of Mike's worries with changing his current layout > > is that scripts could > > possibly end up creating small errors and > breakage. > > Question to Mike: What exactly in the mapguide are > > you opposed to? And > > why exactly? > > > > Alex Schultz > > > > _______________________________________________ > > crossfire mailing list > > crossfire@metalforge.org > > > http://mailman.metalforge.org/mailman/listinfo/crossfire > > > > > > > __________________________________ > Yahoo! Mail - PC Magazine Editors' Choice 2005 > http://mail.yahoo.com > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > __________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com From quisar at quisar.ambre.net Fri Sep 30 04:57:17 2005 From: quisar at quisar.ambre.net (Benjamin Lerman) Date: Fri Sep 30 04:58:44 2005 Subject: [crossfire] Summon pet monster In-Reply-To: <20050929132153.GA17271@marelle.ambre.net> References: <20050929132153.GA17271@marelle.ambre.net> Message-ID: <20050930095717.GA27478@marelle.ambre.net> > And at least, I have a question, does there exists a way to force the > client to wear a particular holy symbol whenever possible. Right now, > whenever I change skill, even if I do not need any object to get my new > skill, my holy symbol is unapplied, which is quite a problem when the > holy symbol does a lot more than give the skill praying... I'm trying to work on this issue... I think the ``problem'' is line 247 of skill_util.c, but before going further, I find this line quite weird: Did I miss something, or is those line something like: if(x || y) if(y) foo() Because if it is the case, then it should be changed to: if(y) foo() and the next line should be put before this one... -- Benjamin Lerman From nicolas.weeger at laposte.net Fri Sep 30 15:07:37 2005 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Fri Sep 30 15:08:54 2005 Subject: [crossfire] Improved post office idea In-Reply-To: References: Message-ID: <433D9B09.1020401@laposte.net> Ok, just committed improved post office :) How to use it: * when talking to Colette, the post office employee, you can now say "bag", "package", "carton" followed by the name of another player * this creates a post office bag, costing 5 / 50 / 200 platinum and containing maximum 5 / 50 / 100 kg * fill in the bag, then say to Colette "send " to send packages to that player * to collect your items, just say "receive" to Colette * note that you won't have any warning of waiting packages - better warn the recipient through regular mail too! * items are not (yet) lost during transport, use at will :) * package is, for now, a regular sack with special name - maybe later specific pics/archetypes :) Also I fixed the mailscroll price, which was 5 silver instead of 5 platinum. >From a technical point of view: * sent items are stored on map /planes/IPO_storage. It's a 5x5 map with the (2, 2) floor unique. Pretty basic map * when sending item, player's inventory is checked for "package" items, and those get teleporter to the map if name matches * to receive item, script parses items at (/planes/IPO_storage, 2, 2), and get the ones for the player. * prices and names can be changed in the script, just look, shouldn't be hard to figure. Pretty basic but should work :) Warning: when upgrading map, also upgrade the code, as i needed to add 'SetWeightLimit' function. If maps are upgraded without code, well, player will be able to pay for their package, but they won't get it ^_- Not critical, just annoying I guess. Ryo From temitchell at sympatico.ca Fri Sep 30 16:12:32 2005 From: temitchell at sympatico.ca (temitchell@sympatico.ca) Date: Fri Sep 30 16:12:55 2005 Subject: [crossfire] Re: [Crossfire-devel] Made a CVS upload error: Message-ID: <20050930212147.IOEM2134.tomts48-srv.bellnexxia.net@[209.226.175.82]> The reason there is so much focus on the directory structure and map guide is that that is what makes it possible to maintain maps properly. If you can use the proper standards for your new maps - why can't you fix mlab to follow them as well. It is a lot of work to do this because mlab is so big, but really it isn't hard or special to do this - just a lot of work which is why it isn't done yet. In fact mlab is the best reason I have seen for maintaining the standards - it has been impossible to work with. I spent too much time on it and made a start but I have no time to fix it, let alone work my own maps these days. Mlab should be uploaded to the proper paths, it shouldn't be a tarball or in unlinked - both those will lead to forked and/or dead files, waste space and delay changes in the long run. Every time this comes up you go on a big pout - now you have access why don't you quit complaining and just fix the damn maps. > > From: Mitch Obrian > Date: 2005/09/30 Fri AM 02:06:13 EST > To: Crossfire Discussion Mailing List > Subject: Re: [crossfire] Re: [Crossfire-devel] Made a CVS upload error: > /maps-bigworld/unlinked/mlab-devel/mlab-devel.tar.gz > > For all other maps sans mlab I follow the map guide. > However mlab was started way before these, thus it > uses the flatdirectory structure so it stays working. > I've seen maps break many times before, including my > tavern when it was uploaded to cvs originally. > > Why must there be contoversy just over a file system? > From kirschbaum at myrealbox.com Fri Sep 30 17:35:47 2005 From: kirschbaum at myrealbox.com (Andreas Kirschbaum) Date: Fri Sep 30 17:36:57 2005 Subject: [crossfire] Summon pet monster In-Reply-To: <20050930095717.GA27478@marelle.ambre.net> References: <20050929132153.GA17271@marelle.ambre.net> <20050930095717.GA27478@marelle.ambre.net> Message-ID: <20050930223546.GA26062@kirschbaum.myrealbox.com> Benjamin Lerman wrote: > but before going further, I find this line quite weird: > > Did I miss something, or is those line something like: > > if(x || y) if(y) foo() > > Because if it is the case, then it should be changed to: > > if(y) foo() Yes, the current code does not make sense. Your proposed change seems reasonable to me. > and the next line should be put before this one... I assume you want to swap the following blocks? | if (who->chosen_skill) apply_special(who, who->chosen_skill, AP_UNAPPLY); | | /* Only goal in this case was to unapply a skill */ | if (!new_skill) return 0; If so: that probably would not be correct. According to the comment for this function, "!new_skill" means to just unapply the old skill. Therefore the call to apply_special(..., AP_UNAPPLY) must not be removed. From mikeeusaaa at yahoo.com Fri Sep 30 21:01:15 2005 From: mikeeusaaa at yahoo.com (Mitch Obrian) Date: Fri Sep 30 21:04:59 2005 Subject: [crossfire] Re: [Crossfire-devel] Made a CVS upload error: In-Reply-To: <20050930212147.IOEM2134.tomts48-srv.bellnexxia.net@[209.226.175.82]> Message-ID: <20051001020115.13713.qmail@web61011.mail.yahoo.com> Because my maps are not broken. I'm not going to go back and redo all the exits, nor am I going to risk breaking them. Fine, delete mlab, it's apparent that you all want to worship "the law" rather then accepting my work. Fuck it. --- temitchell@sympatico.ca wrote: > The reason there is so much focus on the directory > structure and map guide is that that is what makes > it possible to maintain maps properly. If you can > use the proper standards for your new maps - why > can't you fix mlab to follow them as well. It is a > lot of work to do this because mlab is so big, but > really it isn't hard or special to do this - just a > lot of work which is why it isn't done yet. In fact > mlab is the best reason I have seen for maintaining > the standards - it has been impossible to work with. > I spent too much time on it and made a start but I > have no time to fix it, let alone work my own maps > these days. Mlab should be uploaded to the proper > paths, it shouldn't be a tarball or in unlinked - > both those will lead to forked and/or dead files, > waste space and delay changes in the long run. > Every time this comes up you go on a big pout - now > you have access why don't you quit complaining and > just fix the damn maps. > > > > > > From: Mitch Obrian > > Date: 2005/09/30 Fri AM 02:06:13 EST > > To: Crossfire Discussion Mailing List > > > Subject: Re: [crossfire] Re: [Crossfire-devel] > Made a CVS upload error: > > > /maps-bigworld/unlinked/mlab-devel/mlab-devel.tar.gz > > > > For all other maps sans mlab I follow the map > guide. > > However mlab was started way before these, thus it > > uses the flatdirectory structure so it stays > working. > > I've seen maps break many times before, including > my > > tavern when it was uploaded to cvs originally. > > > > Why must there be contoversy just over a file > system? > > > > > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > __________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com From mikeeusaaa at yahoo.com Fri Sep 30 21:09:02 2005 From: mikeeusaaa at yahoo.com (Mitch Obrian) Date: Fri Sep 30 21:11:00 2005 Subject: [crossfire] Request for toplevel CVS dir. In-Reply-To: <20050930212147.IOEM2134.tomts48-srv.bellnexxia.net@[209.226.175.82]> Message-ID: <20051001020902.60772.qmail@web61017.mail.yahoo.com> 1) Given: worship of the law 2) Problem: although mlab obeys the law in most aspects, it does not in the directory structure aspect... infact it trancends the law, space, and time. 3) proposed solution by mwedel: new top level cvs dir 4) time passes 5) I request said directory 6) Problem solved: I get to upload mlab to cvs, those who love the law get to keep their faith. --- temitchell@sympatico.ca wrote: > The reason there is so much focus on the directory > structure and map guide is that that is what makes > it possible to maintain maps properly. If you can > use the proper standards for your new maps - why > can't you fix mlab to follow them as well. It is a > lot of work to do this because mlab is so big, but > really it isn't hard or special to do this - just a > lot of work which is why it isn't done yet. In fact > mlab is the best reason I have seen for maintaining > the standards - it has been impossible to work with. > I spent too much time on it and made a start but I > have no time to fix it, let alone work my own maps > these days. Mlab should be uploaded to the proper > paths, it shouldn't be a tarball or in unlinked - > both those will lead to forked and/or dead files, > waste space and delay changes in the long run. > Every time this comes up you go on a big pout - now > you have access why don't you quit complaining and > just fix the damn maps. > > > > > > From: Mitch Obrian > > Date: 2005/09/30 Fri AM 02:06:13 EST > > To: Crossfire Discussion Mailing List > > > Subject: Re: [crossfire] Re: [Crossfire-devel] > Made a CVS upload error: > > > /maps-bigworld/unlinked/mlab-devel/mlab-devel.tar.gz > > > > For all other maps sans mlab I follow the map > guide. > > However mlab was started way before these, thus it > > uses the flatdirectory structure so it stays > working. > > I've seen maps break many times before, including > my > > tavern when it was uploaded to cvs originally. > > > > Why must there be contoversy just over a file > system? > > > > > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > __________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com From mikeeusaaa at yahoo.com Fri Sep 30 22:47:55 2005 From: mikeeusaaa at yahoo.com (Mitch Obrian) Date: Fri Sep 30 22:49:02 2005 Subject: [crossfire] Re: [Crossfire-devel] Made a CVS upload error: In-Reply-To: <20051001020115.13713.qmail@web61011.mail.yahoo.com> Message-ID: <20051001034755.33928.qmail@web61022.mail.yahoo.com> (note: emotion due to needing somewhere to put my maps that's connected with CF, new module would be perfect) --- Mitch Obrian wrote: > Because my maps are not broken. > I'm not going to go back and redo all the exits, nor > am I going to risk breaking them. > > Fine, delete mlab, it's apparent that you all want > to > worship "the law" rather then accepting my work. > > Fuck it. > > --- temitchell@sympatico.ca wrote: > > > The reason there is so much focus on the directory > > structure and map guide is that that is what makes > > it possible to maintain maps properly. If you can > > use the proper standards for your new maps - why > > can't you fix mlab to follow them as well. It is > a > > lot of work to do this because mlab is so big, but > > really it isn't hard or special to do this - just > a > > lot of work which is why it isn't done yet. In > fact > > mlab is the best reason I have seen for > maintaining > > the standards - it has been impossible to work > with. > > I spent too much time on it and made a start but > I > > have no time to fix it, let alone work my own maps > > these days. Mlab should be uploaded to the proper > > paths, it shouldn't be a tarball or in unlinked - > > both those will lead to forked and/or dead files, > > waste space and delay changes in the long run. > > Every time this comes up you go on a big pout - > now > > you have access why don't you quit complaining and > > just fix the damn maps. > > > > > > > > > > From: Mitch Obrian > > > Date: 2005/09/30 Fri AM 02:06:13 EST > > > To: Crossfire Discussion Mailing List > > > > > Subject: Re: [crossfire] Re: [Crossfire-devel] > > Made a CVS upload error: > > > > > > /maps-bigworld/unlinked/mlab-devel/mlab-devel.tar.gz > > > > > > For all other maps sans mlab I follow the map > > guide. > > > However mlab was started way before these, thus > it > > > uses the flatdirectory structure so it stays > > working. > > > I've seen maps break many times before, > including > > my > > > tavern when it was uploaded to cvs originally. > > > > > > Why must there be contoversy just over a file > > system? > > > > > > > > > > > _______________________________________________ > > crossfire mailing list > > crossfire@metalforge.org > > > http://mailman.metalforge.org/mailman/listinfo/crossfire > > > > > > > __________________________________ > Yahoo! Mail - PC Magazine Editors' Choice 2005 > http://mail.yahoo.com > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > __________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com From mwedel at sonic.net Fri Sep 30 23:39:36 2005 From: mwedel at sonic.net (Mark Wedel) Date: Fri Sep 30 23:41:02 2005 Subject: [crossfire] Re: [Crossfire-devel] Made a CVS upload error: /maps-bigworld/unlinked/mlab-devel/mlab-devel.tar.gz In-Reply-To: <20050930060613.68773.qmail@web61014.mail.yahoo.com> References: <20050930060613.68773.qmail@web61014.mail.yahoo.com> Message-ID: <433E1308.7000500@sonic.net> Mitch Obrian wrote: > For all other maps sans mlab I follow the map guide. > However mlab was started way before these, thus it > uses the flatdirectory structure so it stays working. > I've seen maps break many times before, including my > tavern when it was uploaded to cvs originally. The issue is that there seems to be no work on your part to move it into the proper directory layout. If there was some progess being made in going to a non flat structure, wouldn't be a big deal. > > Why must there be contoversy just over a file system? Ask yourself the same question - why can't you fix them so they aren't in a flat directory. > > If I can't upload my maps to CVS where do I back them > up to? Are they that worthless? I do a fair amount of > CF work in arches and non-mlab maps, could I have > alittle slack? Why is there opposistion just because I > put the maps in their own flatlevel dir? Sourceforge and the crossfire distribution in particular is not meant to provide a backup service for people. There are standard practices for a reason. The second exceptions start getting made for one person, the next person shows up and says 'well, you did it for him, why not for me'. And figuring out what rules to break for who then leads to a mess of problems. > > The reasoning that mlab doesn't even deserve to be in > CVS is very alienating, I've worked years on theses > maps. I work nearly constantly on maps for CF. I don't think I said it doesn't deserve to be in CVS. I've just said that if it is in CVS, it should follow proper standards. > > Mlab could be intergrated into CF-proper right now if > I was just given the OK. If an exception to the dir > rule was made. > > I though after being involved in CF this long the > controversy was over and I could develop as a regular > without asking about every change. I uploaded mlab so > it would be with CF, so if my computers go down my > years of work are not lost. Sure one can say "go find > some other place to back up to" but... that's > basically telling the person to screw off; their work > is of little value. Simple solution is that if you make the directory structure follow the proper naming, it could be an official part of the map distribution. The only issue is that your completely unwilling to do that. Some people have even started the work to integrate your maps with proper naming structure, but you continue to keep going with yours (so that even those get updated). Sure, we could make an exception. Or you could just follow the rules. The fact that your not willing to make any effort to do so doesn't give me any reason whatever on why I should bend the rules for you.