From crossfire-devel at archives.real-time.com Sun May 2 22:20:48 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:28 2005 Subject: [CF-Devel] Looking for Redhat/Fedora maintainer? Message-ID: <200405022220.48521@join.the.twin.cities.linux.users.group.at.www.mn-linux.org> Given that Redhat 9 was deprecated on 04/30/2004 and the consumer version of Redhat linux no longer exists, I've switched to Debian and will no longer be maintaining the .spec file and RPMs for Redhat/Fedora Linux. I'm looking for someone to take over maintaining the aspect of crossfire. -- Bob Tanner | Phone : (952)943-8700 http://www.mn-linux.org, Minnesota, Linux | Fax : (952)943-8500 Key fingerprint = AB15 0BDF BCDE 4369 5B42 1973 7CF1 A709 2CC1 B288 _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Mon May 3 12:04:13 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:28 2005 Subject: [CF-Devel] perceive self and luck score Message-ID: At one time or another, did the perceive self spell display to players what their luck score is? If it did, it no longer works (tested on crossfire.metalforge.net). If it did not display their luck score, could the perceive self get tweaked so that it does display luck? -- _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Mon May 3 16:39:57 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:28 2005 Subject: [CF-Devel] Re: Patch: Win32 fixes In-Reply-To: <20040428154126.GA14748@idefix2.dvlp.in-medias-res.com> References: <408ED1E3.2010502@laposte.net> <20040428154126.GA14748@idefix2.dvlp.in-medias-res.com> Message-ID: <4096BC2D.3060503@laposte.net> Just committed it, since no linux user complained :) Nicolas Ryo _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Mon May 3 21:50:07 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:28 2005 Subject: [CF-Devel] Summoning Message-ID: <200405032150.07151.eracclists@bellsouth.net> Greetings Developers, On cf.mf.net a player, Fire, has exceeded level 25 in summoning and still summons angels - not vampires. Something is obviously not working as designed if I understand the summoning levels correctly. Gene (aka poof|Galahad) -- Linux era4.eracc.UUCP 2.4.22-28mdkenterprise i686 21:47:56 up 65 days, 15:44, 12 users, load average: 0.00, 0.01, 0.00 ERA Computer Consulting - http://www.eracc.com/ eCS, OS/2, Mandrake GNU/Linux, OpenServer & UnixWare resellers _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Tue May 4 00:25:37 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:29 2005 Subject: [CF-Devel] Summoning In-Reply-To: <200405032150.07151.eracclists@bellsouth.net> References: <200405032150.07151.eracclists@bellsouth.net> Message-ID: <40972951.8000605@sonic.net> ERACC wrote: > Greetings Developers, > > On cf.mf.net a player, Fire, has exceeded level 25 in summoning and > still summons angels - not vampires. Something is obviously not > working as designed if I understand the summoning levels correctly. I'll fix this up. It actually looks like this would apply for all all the summoning spells, it would never have used the last entry on the treasurelist. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Tue May 4 01:41:10 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:29 2005 Subject: [CF-Devel] perceive self and luck score In-Reply-To: References: Message-ID: <40973B06.80708@sonic.net> Rick Tanner wrote: > At one time or another, did the perceive self spell display to players > what their luck score is? > > If it did, it no longer works (tested on crossfire.metalforge.net). > > If it did not display their luck score, could the perceive self get > tweaked so that it does display luck? > > I'll fix this up. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Tue May 4 08:54:51 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:29 2005 Subject: [CF-Devel] More bugs, crashes noted by players Message-ID: <200405040854.51222.eracclists@bellsouth.net> Greetings Developers, Apparently I have become an unofficial player liaison for reporting bugs. Two players told me about some things last night. Here is the information they gave me: From Neil Reynolds - DrachenNiall (aka Niall, SlasherNiall) > When doing the demon quest from scorn castle, the sixth quest; on the > final map, I forget the pathname, but it was one of the peterm quests. > > The map has an onion-like layout, with 2 unique keys needed to get to > the center. > > I crashed the server 3 times. Twice by casting large icestorm around > a corner to flood the center room, the last time by using claw on the > largest demon (I believe called the summoner) > > I think the crash occured when the big demon died. > > There's an altar in the navar thaum workshop that provides horns, > ostensibly for alchemy. However it's the wrong type of horn for > alchemy. > > They weigh 4Kg, cost 20pp, and sell for 200pp. > > Taking 4000Kg a trip to the store nearby is a profit of 180,000 pp > > I'd PREFER if the altar returned unicorn horns, so that we could make > magical horns. I think that the altar should ask for at least 100PP, > if not 200pp in line with the altars in the jewelry workshops From Matteo Giassa - Fire > Holy orb doesn't explode on impact, it just hits a [creature] like > magic bullet does (I've seen this too. Gene) > Summon Pet monster never summons vampires, like it should when you > are at lvl 25 summoning, it only summons angels at best. (This was already covered by Mark Wedel. Gene) > Create earthwall[s] [and] variety of other wall spells only create > walls that are 5 tiles long, regardless of the level of the skill > used to create it (I've noticed this too. Is it related to the cone spell question below? Gene) > On the Demon Quest Scorn Royalty Map, the server crashes when the > Boss quest create (sumoner i think) is killed > > If there is a pile of 3 lanterns on the grounds, the game crashes > if one tries to apply one of them > > Is item power +50 for Rings of Miracles and Elrond intentional? > Just curious (I'm thinking "yes" . Gene) > Are cone spells only supposed to go 4 tiles when using "stay fire" > regardless of the casters level? Increase in level never seems to > increase the range of the cone spell with "stay fire". (Seems I've seen this one discussed here before. Gene) Gene (aka poof|Galahad) -- Linux era4.eracc.UUCP 2.4.22-28mdkenterprise i686 08:31:54 up 66 days, 2:28, 12 users, load average: 0.29, 0.08, 0.02 ERA Computer Consulting - http://www.eracc.com/ eCS, OS/2, Mandrake GNU/Linux, OpenServer & UnixWare resellers _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Tue May 4 10:58:51 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:29 2005 Subject: =?iso-8859-1?Q?Re:_[CF-Devel]_More_bugs,_crashes_noted_by_players?= Message-ID: > There's an altar in the navar thaum workshop that provides horns, > ostensibly for alchemy. However it's the wrong type of horn for > alchemy. > > They weigh 4Kg, cost 20pp, and sell for 200pp. > > Taking 4000Kg a trip to the store nearby is a profit of 180,000 pp > > I'd PREFER if the altar returned unicorn horns, so that we could make > magical horns. I think that the altar should ask for at least 100PP, > if not 200pp in line with the altars in the jewelry workshops I'll look into this. I'm not too keen on providing unicorn horns ala vending machine however - I would like only to provide mundane components at these altars (like boots or what have you) since it isn't always the price but the rarity of an object that maintains the alchemy balance. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Tue May 4 13:43:49 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:29 2005 Subject: [CF-Devel] More bugs, crashes noted by players In-Reply-To: References: Message-ID: <200405041343.49796.eracclists@bellsouth.net> On Tuesday 04 May 2004 10:58 Todd Mitchell wrote: > > There's an altar in the navar thaum workshop that provides horns, > > ostensibly for alchemy. However it's the wrong type of horn for > > alchemy. > > > > They weigh 4Kg, cost 20pp, and sell for 200pp. > > > > Taking 4000Kg a trip to the store nearby is a profit of 180,000 > > pp > > > > I'd PREFER if the altar returned unicorn horns, so that we could > > make magical horns. I think that the altar should ask for at > > least 100PP, if not 200pp in line with the altars in the jewelry > > workshops > > I'll look into this. I'm not too keen on providing unicorn horns > ala vending machine however - I would like only to provide mundane > components at these altars (like boots or what have you) since it > isn't always the price but the rarity of an object that maintains > the alchemy balance. That makes sense to me. It seems a unicorn horn should not be an easy buy from my point of view as a player. One should have to search for unicorn horns in the fantasy world of CF. Gene (aka poof|Galahad) -- Linux era4.eracc.UUCP 2.4.22-28mdkenterprise i686 13:41:17 up 66 days, 7:38, 12 users, load average: 0.01, 0.07, 0.02 ERA Computer Consulting - http://www.eracc.com/ eCS, OS/2, Mandrake GNU/Linux, OpenServer & UnixWare resellers _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Tue May 4 21:12:39 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:29 2005 Subject: [CF-Devel] good fixes Message-ID: <1083723159.14954.33.camel@oberon.kameria> Mark via CVS list: > common/item.c: describe_monster() - print luck when describing players > (fixex perceive self not showing luck) > > server/attack.c: kill_object() - don't give player exp if he kills > himself - compare owner against what was killed, not the hitter. > > server/pets.c: > Change summoned creatures so that the items they have are god given, > and thus disappear when they are killed - prevents players from > summoning and then looting their pets. Nice - good stuff here. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Wed May 5 00:13:36 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:29 2005 Subject: [CF-Devel] More bugs, crashes noted by players In-Reply-To: References: Message-ID: <40987800.70705@sonic.net> Todd Mitchell wrote: > >> There's an altar in the navar thaum workshop that provides horns, >> ostensibly for alchemy. However it's the wrong type of horn for alchemy. >> >> They weigh 4Kg, cost 20pp, and sell for 200pp. >> >> Taking 4000Kg a trip to the store nearby is a profit of 180,000 pp >> >> I'd PREFER if the altar returned unicorn horns, so that we could make >> magical horns. I think that the altar should ask for at least 100PP, if not >> 200pp in line with the altars in the jewelry workshops > > > > I'll look into this. I'm not too keen on providing unicorn horns ala vending > machine however - I would like only to provide mundane components at these > altars (like boots or what have you) since it isn't always the price but the > rarity of an object that maintains the alchemy balance. It appears it is creating hte right horn type (horn2) that is used for things like horn of fire/plenty/ice/etc. The real issue is probably just cost - with the new spell system, the value of the horn is now higher - list price is 5900 sp, or 118 pp. With high charisma and/or bargaining, the value of this can go up. So the real solution is to either increase the cost that the table charges, or put a horn arch with a lower value as the object that the converter creates. I believe you can now put objects in the converters archetypes and it will create a copy of the object in the inventory. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Wed May 5 01:35:23 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:29 2005 Subject: [CF-Devel] More bugs, crashes noted by players In-Reply-To: <200405040854.51222.eracclists@bellsouth.net> References: <200405040854.51222.eracclists@bellsouth.net> Message-ID: <40988B2B.9020704@sonic.net> ERACC wrote: > Greetings Developers, > > Apparently I have become an unofficial player liaison for reporting > bugs. Two players told me about some things last night. Here is the > information they gave me: Well, thank you for passing the bugs along. I've long since said that I can't really fix a bug I don't know about. > >>From Neil Reynolds - DrachenNiall (aka Niall, SlasherNiall) > >>When doing the demon quest from scorn castle, the sixth quest; on the >>final map, I forget the pathname, but it was one of the peterm quests. >> >>The map has an onion-like layout, with 2 unique keys needed to get to >>the center. >> >>I crashed the server 3 times. Twice by casting large icestorm around >>a corner to flood the center room, the last time by using claw on the >>largest demon (I believe called the summoner) >> >>I think the crash occured when the big demon died. I'll have to try to reproduce this, is deal with a core file on metalforge - problem comes in that with frequent updates of metalforge, core dump analysis is difficult. > >>Holy orb doesn't explode on impact, it just hits a [creature] like >>magic bullet does > > (I've seen this too. Gene) That is now fixed, or should be. If still broken, let me know. >>Create earthwall[s] [and] variety of other wall spells only create >>walls that are 5 tiles long, regardless of the level of the skill >>used to create it > > (I've noticed this too. Is it related to the cone spell question > below? Gene) No - problem was that the spell arch itself had no range modifier - thus, the range never change. I've updated the archs to have a range modifier, so the walls should increase in length. I'm not positive on the correct value for how fast the length should increase. >>On the Demon Quest Scorn Royalty Map, the server crashes when the >>Boss quest create (sumoner i think) is killed Can I get a more specific map name on this instead of hunting for the right one? >> >>If there is a pile of 3 lanterns on the grounds, the game crashes >>if one tries to apply one of them Not on the ground, but I was able to confirm this with 3 lanterns in the players inventory - will fix this. >> >>Is item power +50 for Rings of Miracles and Elrond intentional? >>Just curious > > (I'm thinking "yes" . Gene) Well, the item power adjustment (in the artifacts file) is 30 and 25 respectively. I'm not positive where that 50 number is coming from, but it could be some oddity in how the item power for those objects is getting calculated. > > >>Are cone spells only supposed to go 4 tiles when using "stay fire" >>regardless of the casters level? Increase in level never seems to >>increase the range of the cone spell with "stay fire". > > (Seems I've seen this one discussed here before. Gene) If you fire in direction 0 (360? radius), the range is ? that compared to if you fire in a direction. However, a minimum range of 2 is still done even in that mode. Thus, if for example a spell has a direction range of 5, it will still go 2 spaces when cast in direction 0. And until the player gets it up to a direction range of 12, they won't see its 0 direction range increase (12/4 = 3, fractions are dropped). IT can be argued that dropping the range to only 25% for casting in direction 0 is a bit harsh, so dropping it by 1/3 or the like could be fairer. That is open to discussion - cutting by 1/4 just made sense at least as far as hitting the same number of spaces is concerned. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Wed May 5 11:13:34 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:29 2005 Subject: [CF-Devel] More bugs, crashes noted by players In-Reply-To: <40988B2B.9020704@sonic.net> References: <200405040854.51222.eracclists@bellsouth.net> <40988B2B.9020704@sonic.net> Message-ID: <200405051113.34103.eracclists@bellsouth.net> On Wednesday 05 May 2004 01:35 Mark Wedel wrote: > ERACC wrote: > > Greetings Developers, [...] > >>From Neil Reynolds - DrachenNiall (aka Niall, SlasherNiall) > >> > >>When doing the demon quest from scorn castle, the sixth quest; on > >> the final map, I forget the pathname, but it was one of the > >> peterm quests. [...] > I'll have to try to reproduce this, is deal with a core file on > metalforge - problem comes in that with frequent updates of > metalforge, core dump analysis is difficult. [...] > >>On the Demon Quest Scorn Royalty Map, the server crashes when the > >>Boss quest create (sumoner i think) is killed > > Can I get a more specific map name on this instead of hunting for > the right one? I believe it is the same as the one mentioned above: euthville/demon_quest [...] > >>Is item power +50 for Rings of Miracles and Elrond intentional? > >>Just curious > > > > (I'm thinking "yes" . Gene) > > Well, the item power adjustment (in the artifacts file) is 30 and > 25 respectively. I'm not positive where that 50 number is coming > from, but it could be some oddity in how the item power for those > objects is getting calculated. So an item_power of +50 may *not* be the intent? Frankly a +40 to +50 item is nearly impossible to equip with other good items even at high player levels. Two +50 items would make using other equipment problematic or impossible, depending on the equipment, even at level 110+. If the +50 is not intended is there some way that may be adjusted down a bit? Maybe so the items are at +30 - +35 or so? That would make them more useful and less a curiosity item. Example: My character Galahad has a ring of Elrond. As of now Galahad is a level 48 human Paladin and has to wear a lot of equipment. I'm calculating that to be able to equip that ring with his other good equipment, with high item_power values, he will need to be level 80. Even then some of his equipment will not be able to be equipped with that ring. That makes ring of Elrond only useful to very high level players and completely, or nearly, useless for mid-level players. > >>Are cone spells only supposed to go 4 tiles when using "stay > >> fire" regardless of the casters level? Increase in level never > >> seems to increase the range of the cone spell with "stay fire". > > > > (Seems I've seen this one discussed here before. Gene) > > If you fire in direction 0 (360? radius), the range is ? that > compared to if you fire in a direction. However, a minimum range > of 2 is still done even in that mode. > > Thus, if for example a spell has a direction range of 5, it will > still go 2 spaces when cast in direction 0. And until the player > gets it up to a direction range of 12, they won't see its 0 > direction range increase (12/4 = 3, fractions are dropped). > > IT can be argued that dropping the range to only 25% for casting > in direction 0 is a bit harsh, so dropping it by 1/3 or the like > could be fairer. That is open to discussion - cutting by 1/4 just > made sense at least as far as hitting the same number of spaces is > concerned. I understand the argument. Perhaps hitting a few more squares with a cone spell cast in direction 0 would not really be a bad thing. I need to try some direction 0 casts with my character poof. How is the direction range calculated? What is the curve on that? Knowing that will help me see if I agree with 1/4 or 1/3 for the value. :-) Gene (aka poof|Galahad) -- Linux era4.eracc.UUCP 2.4.22-28mdkenterprise i686 10:41:07 up 67 days, 4:38, 12 users, load average: 0.05, 0.04, 0.05 ERA Computer Consulting - http://www.eracc.com/ eCS, OS/2, Mandrake GNU/Linux, OpenServer & UnixWare resellers _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Wed May 5 20:00:30 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:29 2005 Subject: [CF-Devel] configure script changes Message-ID: <1083805230.2200.9.camel@oberon.kameria> I seem to be unable to run the crossfire configure script any longer. I am getting errors such as ./configure: confXXXXX.sh: permission denied chmod: getting attributes of 'confXXXXX.sh': No such file or directory ...confXXXXX.file : permission denied ...confXXXXX.log : permission denied where the XXXXX is a number that seems to change. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Wed May 5 21:34:07 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:29 2005 Subject: [CF-Devel] bug 942581 - BROKEN MONEY Message-ID: <1083810847.2194.13.camel@oberon.kameria> Someone reported a bug with slotmachines eating their money: This certainly is not how the slotmachines are supposed to work, they are to make change automagically (they are infernal slotmachines powered by little demons you realize). My observations: - silver slot works but when player has no silver all platinum coins are removed. - gold slots remove 10 silver coins instead of one gold. Since the code for the slots didn't change and they work for non money items I expect the money code has changed. I tested the shops out on metalforge and found the same problems as reported withthe slots. If I purchase items at a shop I notice that if I have 19 pp, 6 gold and 4 silver and buy a item worth 3 gold and 1 silver once I leave the store I have 4 gold coins in my inventory. So I think it isn't the slots - it is some change to shop.c - perhaps the 64bit one from march 25th? Since it is a money issue maybe it can get some quick attention. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Thu May 6 02:03:30 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:29 2005 Subject: [CF-Devel] bug 942581 - BROKEN MONEY In-Reply-To: <1083810847.2194.13.camel@oberon.kameria> References: <1083810847.2194.13.camel@oberon.kameria> Message-ID: <4099E342.9030509@sonic.net> Todd Mitchell wrote: > Someone reported a bug with slotmachines eating their money: > > This certainly is not how the slotmachines are supposed to work, they > are to make change automagically (they are infernal slotmachines powered > by little demons you realize). > My observations: > - silver slot works but when player has no silver all platinum coins are > removed. > - gold slots remove 10 silver coins instead of one gold. > > Since the code for the slots didn't change and they work for non money > items I expect the money code has changed. I tested the shops out on > metalforge and found the same problems as reported withthe slots. If I > purchase items at a shop I notice that if I have 19 pp, 6 gold and 4 > silver and buy a item worth 3 gold and 1 silver once I leave the store I > have 4 gold coins in my inventory. > > So I think it isn't the slots - it is some change to shop.c - perhaps > the 64bit one from march 25th? Since it is a money issue maybe it can > get some quick attention. Looking at the code, the only issue seems to be that the game wasn't making change, correct? If so, at least for shops, not quite that big a deal, as at worse, you're just loosing a platinum piece. In any case, I've fixed the bug with it not making change. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Thu May 6 02:09:14 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:29 2005 Subject: [CF-Devel] configure script changes In-Reply-To: <1083805230.2200.9.camel@oberon.kameria> References: <1083805230.2200.9.camel@oberon.kameria> Message-ID: <4099E49A.8010103@sonic.net> Todd Mitchell wrote: > I seem to be unable to run the crossfire configure script any longer. I > am getting errors such as ./configure: confXXXXX.sh: permission denied > chmod: getting attributes of 'confXXXXX.sh': No such file or directory > ...confXXXXX.file : permission denied > ...confXXXXX.log : permission denied > > where the XXXXX is a number that seems to change. I'm (obviously) not seeing any problems. Have you checked the obvious things, eg, permissions of the directory that holds crossfire? From the same directory that holds the configure script, do a 'ls -ld .', and make sure the ownership/permissions seem sane (eg, owned/writable by whatever uid you are using to run configure). _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Thu May 6 02:23:05 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:29 2005 Subject: [CF-Devel] More bugs, crashes noted by players In-Reply-To: <200405051113.34103.eracclists@bellsouth.net> References: <200405040854.51222.eracclists@bellsouth.net> <40988B2B.9020704@sonic.net> <200405051113.34103.eracclists@bellsouth.net> Message-ID: <4099E7D9.70508@sonic.net> ERACC wrote: > On Wednesday 05 May 2004 01:35 > So an item_power of +50 may *not* be the intent? Frankly a +40 to +50 > item is nearly impossible to equip with other good items even at high > player levels. Two +50 items would make using other equipment > problematic or impossible, depending on the equipment, even at level > 110+. If the +50 is not intended is there some way that may be > adjusted down a bit? Maybe so the items are at +30 - +35 or so? That > would make them more useful and less a curiosity item. > > Example: My character Galahad has a ring of Elrond. As of now Galahad > is a level 48 human Paladin and has to wear a lot of equipment. I'm > calculating that to be able to equip that ring with his other good > equipment, with high item_power values, he will need to be level 80. > Even then some of his equipment will not be able to be equipped with > that ring. That makes ring of Elrond only useful to very high level > players and completely, or nearly, useless for mid-level players. Note that at least in IMO, that is some of the point of item power - to make it so that characters can not equip every best item in the game, and have to make some choices. Now some values are probably excessive, and looking at the treasure code, it seems to do some odd stuff - instead of just making item power additive, it seems to try to figure out what the item_power for the object should be based on the enchantments, and that seems wrong. As a note, while not really acted on much, I actually think item power can be used to make it more flexible for player created items. Eg, before, the enchant armor scrolls were a real bonus, because you could have +4 magic on all your items with no drawbacks. If item_power is properly used, fine, you can have +4 on all your item, but if each object now comes with a 10 item power (or whatever), it quickly becomes less appealing. And likewise, this could open it up to let players create rings and whatnot, albeit with similar item power drawbacks. > I understand the argument. Perhaps hitting a few more squares with a > cone spell cast in direction 0 would not really be a bad thing. I > need to try some direction 0 casts with my character poof. How is the > direction range calculated? What is the curve on that? Knowing that > will help me see if I agree with 1/4 or 1/3 for the value. :-) It really depends on the spell - you can look at the archetype. Eg, from the spell_burning_hand arc (only relevant fields taken): level 1 range 5 range_modifier 4 Range 5 means it starts out going spaces. For every 4 levels beyond 1st, it goes an additional space (range_modifier), eg, level 5 it goes 6 spaces, level 9 it goes 7, etc. Lets look at spell_dragonbreath: level 12 range 7 range_modifier 5 Starts out going 7 spaces. For every 5 levels beyond 12th, it goes another space (8 spaces at 17, 9 spaces at 22, etc). Note that it can probably be rightly argued that some of the range and range_modifier values are incorrect (eg, dragonbreath should go further than burning hands for example). What probably really needs to be done is write some scripts or update the dump code to output the spell information for different levels. You can look at dragonbreath and burning_hands arch, and clearly see the dragon breath is better in terms of damage, range, etc. But its a level 12 spell, so how does burning hands compare when cast by a 12'th level caster. How do the spells compare when cast at a 25th level caster, 50th level caster, etc? I have a feeling if that is done, some adjustments to be made will be pretty obvious. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Thu May 6 04:41:12 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:29 2005 Subject: [CF-Devel] From the forum Message-ID: <409A0838.3050506@laposte.net> Here's a post on the messageboard, i think it's worth forwarding it here :) ----- Hi. Here are several things with my character Azriel (on crossfire.metalforge.net) : 1) I am a dragon (ancient cold), with 82 resist in elec (obviously without any equipment, nor god given resist). Then i should be legendary, and i'm not. Someone told me that i should be, and in the sources, it is written resist>80 to be legendary. So, either it is a bug, either it does'nt work this way. I think it is because, since i am an ancient COLD, i must have 81 resist in COLD. This is unfair : to change your title, you have to gain levels. If you reach 81+ resist when you are level 90, it is easy to gain 20 levels to have the correct title to be legendary. But if you are level 110 (you know the xp table...) So, here is what i think : big, ancient and legendary should be based only on the highest resist (regardless of the focus), and titles should be recalculated at login, or when you gain a resist. 2) Treasure lists are broken on the server. Monsters that have a special item in their inventory (eg a key, etc...) don't inherit their normal treasure list. That's a good thing for most players (for exemple, the wizards in the wizard tower have a key, so they don't have their normal treasure list, and then no spell. The place is much easier. Same thing in Chaos lair). But for dragons, it is a problem : to gain resistances, you have to eat high level monsters. But almost high level monsters have a key, or something, then they don't have their normal treasure list and drop no corpse. On other servers it is hard to get 81+ resist, but here it is almost impossible. 3) I'm making maps (it takes a long time). Does someone know how to use a duplicator ? And in general, where could i find the meaning of all the types of the archs ? Thanks Az. ------ Ryo _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Thu May 6 17:21:01 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:30 2005 Subject: [CF-Devel] bug 942581 - BROKEN MONEY In-Reply-To: <4099E342.9030509@sonic.net> References: <1083810847.2194.13.camel@oberon.kameria> <4099E342.9030509@sonic.net> Message-ID: Feedback from a player on crossfire.metalforge.net They would loose all their platinum when they would try and purchase items from a shop. After a server crash earlier (assuming the CVS change went in to effect after that..) they've confirmed that the bug has been fixed. Any one else have an update? On Thu, 6 May 2004, Mark Wedel wrote: > Looking at the code, the only issue seems to be that the game wasn't making > change, correct? > > If so, at least for shops, not quite that big a deal, as at worse, you're just > loosing a platinum piece. > > In any case, I've fixed the bug with it not making change. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Thu May 6 23:20:12 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:30 2005 Subject: [CF-Devel] bug 942581 - BROKEN MONEY In-Reply-To: <4099E342.9030509@sonic.net> References: <1083810847.2194.13.camel@oberon.kameria> <4099E342.9030509@sonic.net> Message-ID: <1083903612.4135.1.camel@oberon.kameria> Yes this is all fixed now - thanks. On Thu, 2004-05-06 at 03:03, Mark Wedel wrote: > Todd Mitchell wrote: > > Someone reported a bug with slotmachines eating their money: > > > > This certainly is not how the slotmachines are supposed to work, they > > are to make change automagically (they are infernal slotmachines powered > > by little demons you realize). > > My observations: > > - silver slot works but when player has no silver all platinum coins are > > removed. > > - gold slots remove 10 silver coins instead of one gold. > > > > Since the code for the slots didn't change and they work for non money > > items I expect the money code has changed. I tested the shops out on > > metalforge and found the same problems as reported withthe slots. If I > > purchase items at a shop I notice that if I have 19 pp, 6 gold and 4 > > silver and buy a item worth 3 gold and 1 silver once I leave the store I > > have 4 gold coins in my inventory. > > > > So I think it isn't the slots - it is some change to shop.c - perhaps > > the 64bit one from march 25th? Since it is a money issue maybe it can > > get some quick attention. > > Looking at the code, the only issue seems to be that the game wasn't making > change, correct? > > If so, at least for shops, not quite that big a deal, as at worse, you're just > loosing a platinum piece. > > In any case, I've fixed the bug with it not making change. > _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Sat May 8 05:21:32 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:30 2005 Subject: [CF-Devel] Monsters not using wands/rods/horns Message-ID: <409CB4AC.30106@laposte.net> Hello. I've noticed some monsters don't use wands/rods/horns anymore. Tracking the issue, I found some hints: * monster_check_apply, which is used when a just generated item is put in monster inventory, will use manual_apply on the rod/wand/horn. Which checks for skill, ie 'use magic item'. But sometimes the monster doesn't have it yet (treasure list _after_ current one). * even if the monster has it 'FLAG_CAN_USE_SKILL' is not set, so skill can't be used. * also, change_skill is called for monsters when applying item, thus crash (who->contr == NULL) I attached a patch that enables monsters to fire their favorite wand/horn/rod :) It's dirty, and probably has some redundance (like 'FLAG_APPLIED' is set, but never really tested) Basically i grabbed the wand/rod firing code from server/player.c:fire_misc_object( ), and pasted it in server/monster.c:monster_use_range( ) to actually fire rod/bow. I think we should, at some point, use only one logic for players / monsters when firing bow/range, and for skills/spells too. Though java editor can't link between 'can use wands' flag and the 'use magic item' skill which is required, so that isn't great. Ryo -------------- next part -------------- Index: server/monster.c =================================================================== RCS file: /cvsroot/crossfire/crossfire/server/monster.c,v retrieving revision 1.69 diff -u -r1.69 monster.c --- server/monster.c 14 Apr 2004 07:24:30 -0000 1.69 +++ server/monster.c 8 May 2004 10:05:59 -0000 @@ -894,8 +894,10 @@ /* Monster will use a ranged spell attack. */ -int monster_use_range(object *head,object *part,object *pl,int dir) { +int monster_use_range(object *head,object *part,object *pl,int dir) + { object *wand, *owner; + int at_least_one = 0; if(!(dir=path_to_player(part,pl,0))) return 0; @@ -909,49 +911,54 @@ dir = absdir(dir + RANDOM()%3 + RANDOM()%3 - 2); for(wand=head->inv;wand!=NULL;wand=wand->below) - if(QUERY_FLAG(wand,FLAG_APPLIED) && - (wand->type == WAND || wand->type == ROD || wand->type==HORN)) - break; + { + if (wand->type == WAND) + { + /* Found a wand, let's see if it has charges left */ + at_least_one = 1; + if( wand->stats.food<=0 ) + continue; + + cast_spell( head, wand, dir, wand->inv, NULL ); + + if ( !( --wand->stats.food ) ) + { + object *tmp; + if ( wand->arch ) + { + CLEAR_FLAG(wand, FLAG_ANIMATE); + wand->face = wand->arch->clone.face; + wand->speed = 0; + update_ob_speed(wand); + } + } + /* Success */ + return 1; + } + else if ( wand->type == ROD || wand->type==HORN ) + { + /* Found rod/horn, let's use it if possible */ + at_least_one = 1; + if( wand->stats.hp < MAX( wand->inv->stats.sp, wand->inv->stats.grace ) ) + continue; + + cast_spell( head, wand, dir, wand->inv, NULL ); + + drain_rod_charge( wand ); + + /* Success */ + return 1; + } + } + + if ( at_least_one ) + return 0; - if(wand==NULL) { - LOG(llevError,"Error: Monster %s (%d) HAS_READY_RANG() without range.\n", + LOG(llevError,"Error: Monster %s (%d) HAS_READY_RANG() without wand/horn/rod.\n", head->name,head->count); CLEAR_FLAG(head, FLAG_READY_RANGE); return 0; } - if (!wand->inv) { - LOG(llevError,"Wand %s lacks spell\n", wand->name); - return 0; - } - if (wand->type == WAND) { - if(wand->stats.food<=0) { - manual_apply(head,wand,0); - CLEAR_FLAG(head, FLAG_READY_RANGE); - if (wand->arch) { - CLEAR_FLAG(wand, FLAG_ANIMATE); - wand->face = wand->arch->clone.face; - wand->speed = 0; - update_ob_speed(wand); - } - return 0; - } - } - else { - if(wand->stats.hpinv->stats.sp, wand->inv->stats.grace)) - return 0; /* Not recharged enough yet */ - } - - /* Spell should be cast on caster (ie, heal, strength) */ - if (wand->inv->range==0) - dir = 0; - - if(cast_spell(part,wand,dir,wand->inv,NULL)) { - if (wand->type==WAND) - wand->stats.food--; - return 1; - } - return 0; -} int monster_use_bow(object *head, object *part, object *pl, int dir) { object *owner; @@ -1246,16 +1253,40 @@ else if (item->type == WEAPON) flag = check_good_weapon(mon,item); else if (IS_ARMOR(item)) flag = check_good_armour(mon,item); /* Should do something more, like make sure this is a better item */ - else if (item->type == SKILL || item->type == RING || item->type==WAND || - item->type == ROD || item->type==HORN) flag=1; + else if (item->type == RING) + flag=1; + else if ( item->type==WAND || item->type == ROD || item->type==HORN ) + { + /* We never really 'ready' the wand/rod/horn, because that would mean the + * weapon would get undone. + */ + if (!(can_apply_object(mon, item) & CAN_APPLY_NOT_MASK)) + { + SET_FLAG(mon, FLAG_READY_RANGE); + SET_FLAG(item, FLAG_APPLIED); + } + return; + } else if (item->type == BOW) { - /* We never really 'ready' the bow, because that would mean the - * weapon would get undone. - */ - if (!(can_apply_object(mon, item) & CAN_APPLY_NOT_MASK)) - SET_FLAG(mon, FLAG_READY_BOW); - return; - } + /* We never really 'ready' the bow, because that would mean the + * weapon would get undone. + */ + if (!(can_apply_object(mon, item) & CAN_APPLY_NOT_MASK)) + SET_FLAG(mon, FLAG_READY_BOW); + return; + } + else if ( item->type == SKILL ) + { + /* + * Ryo 2004-05-08 + * skills are specials: monsters must have the 'FLAG_CAN_USE_SKILL' flag set, + * else they can't use the skill... + * Skills also don't need to get applied, so return now. + */ + SET_FLAG( item, FLAG_CAN_USE_SKILL ); + return; + } + /* if we don't match one of the above types, return now. * can_apply_object will say that we can apply things like flesh, @@ -1270,7 +1301,6 @@ */ if (can_apply_object(mon, item) & CAN_APPLY_NOT_MASK) return; - /* should only be applying this item, not unapplying it. * also, ignore status of curse so they can take off old armour. * monsters have some advantages after all. Index: server/skill_util.c =================================================================== RCS file: /cvsroot/crossfire/crossfire/server/skill_util.c,v retrieving revision 1.47 diff -u -r1.47 skill_util.c --- server/skill_util.c 8 Apr 2004 06:48:51 -0000 1.47 +++ server/skill_util.c 8 May 2004 10:06:01 -0000 @@ -229,7 +229,12 @@ int change_skill (object *who, object *new_skill, int flag) { - int old_range = who->contr->shoottype; + int old_range; + + if ( who->type != PLAYER ) + return 0; + + old_range = who->contr->shoottype; if (who->chosen_skill && who->chosen_skill == new_skill) { -------------- next part -------------- _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Sun May 9 12:33:29 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:30 2005 Subject: [CF-Devel] remove curse spell broken Message-ID: <1084124008.29597.11.camel@d5110227.lss.emc.com> I applied a cursed ring, and then cast "remove curse." It told me that I do not have any cursed items applied, and didn't remove the curse. Also, I noticed that it did use the mana points. It used to be that when spells like identify, remove curse, disarm, and consecrate were unable to do anything, they didn't use up spell/mana points. Was that an intentional change, or an oversight? Similarly, when a prayer fails, it doesn't cost any mana points, whereas it used to randomly charge points; again, was that intentional? --PC _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Tue May 11 01:54:09 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:30 2005 Subject: [CF-Devel] remove curse spell broken In-Reply-To: <1084124008.29597.11.camel@d5110227.lss.emc.com> References: <1084124008.29597.11.camel@d5110227.lss.emc.com> Message-ID: <40A07891.30704@sonic.net> Preston Crow wrote: > I applied a cursed ring, and then cast "remove curse." It told me that > I do not have any cursed items applied, and didn't remove the curse. I just tried this, and it worked as expected. Are you sure the item wasn't damned? In that case, remove_curse won't do anything with it. > > Also, I noticed that it did use the mana points. It used to be that > when spells like identify, remove curse, disarm, and consecrate were > unable to do anything, they didn't use up spell/mana points. Was that > an intentional change, or an oversight? Similarly, when a prayer fails, > it doesn't cost any mana points, whereas it used to randomly charge > points; again, was that intentional? It is intentional that all spells, when you cast them, such the mana/grace points, whether or not the spell in fact does anything. It makes the code a bit simpler, but arguable makes more sense (you are still casting the spell). One could argue if that wasn't the case, things like healing should only cost the points if they heal someone, etc. In terms of spell failure not costing points, I'll fix that up. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Tue May 11 23:19:18 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:30 2005 Subject: [CF-Devel] faster portgate (context diff) Message-ID: As i hate waiting, i made this patch for the gate to the port in Scorn. With this patch, the gates will open immediately when you step up to them. Furthermore the guards only speak if there is something to say. The patch was made on the bigworld maps, but ought to work on smallworld too. Multipart oddities i discovered with this map: 1) All parts of the dragon except the head (upper-left) ended up below the teleporters. I managed to work around this by giving the teleporters is_floor 1. Other items (e.g. ones that can be picked up) are more troublesome. This problem ought to vanish with the new layering system. 2) Only the dragons head can push a button. So, if you move one of the buttons triggering the guards' speech from the upper-left to any other corner, it no longer works. -------------- next part -------------- Index: scorn/anthony/portgate =================================================================== RCS file: /cvsroot/crossfire/maps-bigworld/scorn/anthony/portgate,v retrieving revision 1.2 diff -c -5 -r1.2 portgate *** scorn/anthony/portgate 3 Nov 2002 07:04:16 -0000 1.2 --- scorn/anthony/portgate 12 May 2004 02:14:31 -0000 *************** *** 3,13 **** msg Creator: Anthony Thyssen Email: anthony@cit.gu.edu.au Date: Mon Dec 28 11:08:59 1998 endmsg ! width 18 height 13 outdoor 1 end arch cobblestones2 end --- 3,13 ---- msg Creator: Anthony Thyssen Email: anthony@cit.gu.edu.au Date: Mon Dec 28 11:08:59 1998 endmsg ! width 22 height 13 outdoor 1 end arch cobblestones2 end *************** *** 1438,1448 **** end arch mine2 x 12 y 3 end ! arch dungeon_magic x 12 y 4 end arch magic_mouth name magic_mouth (gate open/close) --- 1438,1448 ---- end arch mine2 x 12 y 3 end ! arch blocked x 12 y 4 end arch magic_mouth name magic_mouth (gate open/close) *************** *** 1451,1497 **** a loud noise as anchient machinary is set in motion to move the rusty gates. endmsg connected 10 x 12 - y 4 - end - arch dungeon_magic - x 12 y 5 end ! arch mine16 ! x 12 ! y 5 ! end ! arch dungeon_magic ! x 12 ! y 6 ! end ! arch mine12 x 12 y 6 end ! arch dungeon_magic ! x 12 ! y 7 ! end ! arch button_small ! connected 10 ! x 12 ! y 7 ! end ! arch gateTrg1 ! connected 11 x 12 y 7 end ! arch dungeon_magic ! x 12 ! y 8 ! end ! arch mine9 x 12 y 8 end arch dungeon_magic x 12 --- 1451,1486 ---- a loud noise as anchient machinary is set in motion to move the rusty gates. endmsg connected 10 x 12 y 5 end ! arch magic_mouth ! name magic_mouth (port pass) ! msg ! On seeing you have a port pass the guard ! turns a rusty handle and says... ! Everything appears in order. Pass friend. ! endmsg ! connected 22 ! activate_on_release 0 x 12 y 6 end ! arch magic_mouth ! name magic_mouth (hero of scorn) ! msg ! The guard seeing that the Hero approches ! turns the handle to open the gate. ! endmsg ! connected 23 ! activate_on_release 0 x 12 y 7 end ! arch blocked x 12 y 8 end arch dungeon_magic x 12 *************** *** 1538,1616 **** end arch mine2 x 13 y 3 end ! arch dungeon_magic x 13 y 4 end ! arch magic_mouth ! name magic_mouth (port pass) ! msg ! On seeing you have a port pass the guard ! turns a rusty handle and says... ! Everything appears in order. Pass friend. ! endmsg ! connected 12 ! x 13 ! y 4 ! end ! arch dungeon_magic x 13 y 5 end ! arch mine2 x 13 y 5 end ! arch dungeon_magic ! x 13 ! y 6 ! end ! arch button_small ! connected 10 ! x 13 ! y 6 ! end ! arch gateTrg1 connected 12 x 13 ! y 6 end ! arch dungeon_magic x 13 ! y 7 end ! arch button_small ! face button_sma.112 ! value 1 ! connected 20 x 13 ! y 7 end ! arch spikes_open ! speed 0.500000 ! connected 20 x 13 ! y 7 end ! arch boulder x 13 y 7 end ! arch dungeon_magic ! x 13 ! y 8 ! end ! arch button_small ! connected 10 ! x 13 ! y 8 ! end ! arch gateTrg1 ! connected 14 x 13 y 8 end arch dungeon_magic x 13 --- 1527,1597 ---- end arch mine2 x 13 y 3 end ! arch blocked x 13 y 4 end ! arch creator ! name creator 14 password ! other_arch scroll ! lifesave 1 ! connected 14 x 13 y 5 end ! arch creator ! name creator 13 hero ! other_arch scroll ! lifesave 1 ! connected 13 x 13 y 5 end ! arch creator ! name creator 12 pass ! other_arch scroll ! lifesave 1 connected 12 x 13 ! y 5 end ! arch creator ! name creator 11 lever ! other_arch scroll ! connected 11 ! lifesave 1 x 13 ! y 5 end ! arch permanent_lava x 13 ! y 5 end ! arch altar_trigger ! name altartrig gate ! slaying scroll ! food 1 ! connected 10 ! exp 100 x 13 ! y 5 end ! arch card ! name Hero Pass ! msg ! This is the HERO Pass ;-) ! endmsg ! slaying hero_of_scorn ! value 2500 ! identified 1 x 13 y 7 end ! arch blocked x 13 y 8 end arch dungeon_magic x 13 *************** *** 1657,1715 **** end arch mine2 x 14 y 3 end ! arch dungeon_magic ! x 14 ! y 4 ! end ! arch magic_mouth ! name magic_mouth (hero of scorn) ! msg ! The guard seeing that the Hero approches ! turns the handle to open the gate. ! endmsg ! connected 13 x 14 y 4 end ! arch dungeon_magic ! x 14 ! y 5 ! end ! arch mine16 x 14 y 5 end ! arch dungeon_magic ! x 14 ! y 6 ! end ! arch mine4 x 14 y 6 end ! arch dungeon_magic ! x 14 ! y 7 ! end ! arch button_small ! connected 10 x 14 y 7 end ! arch gateTrg1 ! connected 13 ! x 14 ! y 7 ! end ! arch dungeon_magic ! x 14 ! y 8 ! end ! arch mine10 x 14 y 8 end arch dungeon_magic x 14 --- 1638,1664 ---- end arch mine2 x 14 y 3 end ! arch blocked x 14 y 4 end ! arch blocked x 14 y 5 end ! arch blocked x 14 y 6 end ! arch blocked x 14 y 7 end ! arch blocked x 14 y 8 end arch dungeon_magic x 14 *************** *** 1772,1806 **** end arch dungeon_magic x 15 y 5 end ! arch mine14 x 15 y 5 end arch dungeon_magic x 15 y 6 end ! arch mine9 x 15 y 6 end arch dungeon_magic x 15 y 7 end ! arch mine3 x 15 y 7 end arch dungeon_magic x 15 y 8 end ! arch mine14 x 15 y 8 end arch dungeon_magic x 15 --- 1721,1755 ---- end arch dungeon_magic x 15 y 5 end ! arch mine11 x 15 y 5 end arch dungeon_magic x 15 y 6 end ! arch mine11 x 15 y 6 end arch dungeon_magic x 15 y 7 end ! arch mine11 x 15 y 7 end arch dungeon_magic x 15 y 8 end ! arch mine11 x 15 y 8 end arch dungeon_magic x 15 *************** *** 1966,1970 **** --- 1915,2159 ---- end arch grass x 17 y 12 end + arch blocked + x 18 + end + arch blocked + x 18 + y 1 + end + arch blocked + x 18 + y 2 + end + arch blocked + x 18 + y 3 + end + arch blocked + x 18 + y 4 + end + arch blocked + x 18 + y 5 + end + arch blocked + x 18 + y 6 + end + arch blocked + x 18 + y 7 + end + arch blocked + x 18 + y 8 + end + arch blocked + x 18 + y 9 + end + arch blocked + x 18 + y 10 + end + arch blocked + x 18 + y 11 + end + arch blocked + x 18 + y 12 + end + arch blocked + x 19 + end + arch blocked + x 19 + y 1 + end + arch blocked + x 19 + y 2 + end + arch blocked + x 19 + y 3 + end + arch blocked + x 19 + y 4 + end + arch blocked + x 19 + y 5 + end + arch blocked + x 19 + y 5 + end + arch blocked + x 19 + y 6 + end + arch blocked + x 19 + y 7 + end + arch blocked + x 19 + y 8 + end + arch blocked + x 19 + y 9 + end + arch blocked + x 19 + y 10 + end + arch blocked + x 19 + y 11 + end + arch blocked + x 19 + y 12 + end + arch teleporter + name teleporter 12 pass + hp 20 + sp 6 + connected 12 + speed 0.0 + x 20 + end + arch teleporter + name teleporter 13 hero + hp 20 + sp 3 + connected 13 + speed 0.0 + is_floor 1 + x 20 + y 1 + end + arch blocked + x 20 + y 2 + end + arch button_small + name button 23 hero + connected 23 + activate_on_release 0 + x 20 + y 3 + end + arch teleporter + name teleporter back + hp 20 + sp 0 + connected 99 + speed 0.0 + x 20 + y 4 + end + arch blocked + x 20 + y 5 + end + arch button_small + name button 22 pass + connected 22 + activate_on_release 0 + x 20 + y 6 + end + arch teleporter + name teleporter back + hp 20 + sp 0 + connected 99 + speed 0.0 + x 20 + y 7 + end + arch blocked + x 20 + y 8 + end + arch teleporter + name teleporter back + hp 20 + sp 0 + connected 99 + speed 0.0 + x 20 + y 9 + end + arch blocked + x 20 + y 11 + end + arch creator + name creator 10 + other_arch scroll + connected 10 + lifesave 1 + x 20 + y 12 + end + arch altar_trigger + name altartrig back + slaying scroll + food 2 + connected 99 + exp 10 + last_sp 1 + x 20 + y 12 + end + arch teleporter + name teleporter 11 lever + hp 20 + sp 9 + connected 11 + speed 0.0 + is_floor 1 + x 21 + end + arch teleporter + name teleporter 14 password + hp 20 + sp 9 + connected 14 + speed 0.0 + is_floor 1 + x 21 + y 1 + end + arch blocked + x 21 + y 2 + end + arch blocked + x 21 + y 5 + end + arch blocked + x 21 + y 8 + end + arch blocked + x 21 + y 11 + end + arch chinese_dragon + unaggressive 1 + stand_still 1 + randomitems none + x 20 + end -------------- next part -------------- _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Tue May 11 23:54:23 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:30 2005 Subject: [CF-Devel] Monsters not using wands/rods/horns In-Reply-To: <409CB4AC.30106@laposte.net> References: <409CB4AC.30106@laposte.net> Message-ID: <40A1ADFF.5010101@sonic.net> Nicolas Weeger wrote: > Hello. > > I've noticed some monsters don't use wands/rods/horns anymore. > Tracking the issue, I found some hints: > > * monster_check_apply, which is used when a just generated item is put > in monster inventory, will use manual_apply on the rod/wand/horn. Which > checks for skill, ie 'use magic item'. But sometimes the monster doesn't > have it yet (treasure list _after_ current one). > * even if the monster has it 'FLAG_CAN_USE_SKILL' is not set, so skill > can't be used. > * also, change_skill is called for monsters when applying item, thus > crash (who->contr == NULL) It may make sense to change the logic a bit - such that we don't set all the flags for the monster until after all the monsters treasure has been generated. That said, there is some amount of leftover cruft in terms of objects monsters can and can not use. With the body_info code, this can arguably be removed (at one point, the can_use flags were the only real way to tell that a monster had a arm for example). The only case where it may still show up is cases where a creature is 'humanoid' but not considered smart enough to use sophisticated items like wands or rods. > > > I attached a patch that enables monsters to fire their favorite > wand/horn/rod :) > > It's dirty, and probably has some redundance (like 'FLAG_APPLIED' is > set, but never really tested) I notice some code was lost, like checking the type of spell being fired and adjusting direction if it is a zero range spell. But at a quick glance, it looks OK, but probably should be thoroughly tested. > > Basically i grabbed the wand/rod firing code from > server/player.c:fire_misc_object( ), and pasted it in > server/monster.c:monster_use_range( ) to actually fire rod/bow. > > I think we should, at some point, use only one logic for players / > monsters when firing bow/range, and for skills/spells too. > Though java editor can't link between 'can use wands' flag and the 'use > magic item' skill which is required, so that isn't great. Probably using the same logic makes sense, except as mentioned above, if there are cases where a creature is deemed too stupid yet has a hand or whatever. But a lot of the problem may be that many monsters need to get updated treasurelists for the skills they do have. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Wed May 12 02:13:40 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:30 2005 Subject: [CF-Devel] Monsters not using wands/rods/horns In-Reply-To: <40A1ADFF.5010101@sonic.net> References: <409CB4AC.30106@laposte.net> <40A1ADFF.5010101@sonic.net> Message-ID: <40A1CEA4.7000304@laposte.net> > It may make sense to change the logic a bit - such that we don't set > all the flags for the monster until after all the monsters treasure has > been generated. Yes, could be done. Didn't think of that :) > I notice some code was lost, like checking the type of spell being > fired and adjusting direction if it is a zero range spell. But at a > quick glance, it looks OK, but probably should be thoroughly tested. Hum, i'll check my code. I copied only the last fragment, actually firing the spell, so some checks indeed went to the trash. What would be useful, I think, is to merge as much as the spell/firing/... code we can so it works for both players & monsters. (not only for this precise case, but for everything) > Probably using the same logic makes sense, except as mentioned above, > if there are cases where a creature is deemed too stupid yet has a hand > or whatever. Then we shouldn't give it the skill 'use magic item' :) > But a lot of the problem may be that many monsters need to get updated > treasurelists for the skills they do have. yes, probably that too... Nicolas _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Wed May 12 02:22:54 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:30 2005 Subject: [CF-Devel] From the forum In-Reply-To: <409A0838.3050506@laposte.net> References: <409A0838.3050506@laposte.net> Message-ID: <40A1D0CE.6080606@sonic.net> Nicolas Weeger wrote: > Here's a post on the messageboard, i think it's worth forwarding it here :) > > ----- > > Hi. Here are several things with my character Azriel (on > crossfire.metalforge.net) : > > 1) I am a dragon (ancient cold), with 82 resist in elec (obviously > without any equipment, nor god given resist). Then i should be > legendary, and i'm not. Someone told me that i should be, and in the > sources, it is written resist>80 to be legendary. So, either it is a > bug, either it does'nt work this way. > I think it is because, since i am an ancient COLD, i must have 81 resist > in COLD. This is unfair : to change your title, you have to gain levels. > If you reach 81+ resist when you are level 90, it is easy to gain 20 > levels to have the correct title to be legendary. But if you are level > 110 (you know the xp table...) > So, here is what i think : big, ancient and legendary should be based > only on the highest resist (regardless of the focus), and titles should > be recalculated at login, or when you gain a resist. This could be done, but I don't know how big an issue it is (are there any quests or the like that require someone to be a legendary dragon?) Also, there is the case that the proposed change means the title is based only on resistances. Arguably, the attack and special abilities that the player gets based on the focuses they are using is just as relevant as everything else. So it wouldn't hard to change it so that title is based on overall resistance if people think that is a good idea. Just set the title based on highest resistance. > > 2) Treasure lists are broken on the server. Monsters that have a special > item in their inventory (eg a key, etc...) don't inherit their normal > treasure list. That's a good thing for most players (for exemple, the > wizards in the wizard tower have a key, so they don't have their normal > treasure list, and then no spell. The place is much easier. Same thing > in Chaos lair). But for dragons, it is a problem : to gain resistances, > you have to eat high level monsters. But almost high level monsters have > a key, or something, then they don't have their normal treasure list and > drop no corpse. On other servers it is hard to get 81+ resist, but here > it is almost impossible. This is now fixed. > > 3) I'm making maps (it takes a long time). Does someone know how to use > a duplicator ? And in general, where could i find the meaning of all the > types of the archs ? General starting place is the doc directory in the server area. Unfortunately, there appears to be no docs there. Looking at the code, this is what I gather: The duplicator is triggered by some other connected object (button, altar, whatever). When triggered, it then looks for objects on top of the duplicator that match the same name as the other_arch field (why that was used instead of slaying, I don't know). Thus, if it is something like other_arch dagger, it won't duplicate swords. The level of the duplicator determines the new number of objects (if level is 0, object is removed). This, an example might be something like arch duplicator level 2 other_arch sword connected 5 end Where 5 is connected to a lever. When the lever is pulled, if a sword object is on top, its number is doubled. If there is anything else on top, it is unaffected. If the lever it is connected to is not pulled, it is also unaffected. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Wed May 12 02:47:57 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:30 2005 Subject: [CF-Devel] From the forum In-Reply-To: <40A1D0CE.6080606@sonic.net> References: <409A0838.3050506@laposte.net> <40A1D0CE.6080606@sonic.net> Message-ID: <40A1D6AD.3080708@laposte.net> Pasted to forum, as i'm not sure the player asking reads this list :) Nicolas _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Wed May 12 03:17:02 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:31 2005 Subject: [CF-Devel] Re: [CF-maps] buggy map In-Reply-To: <40A1C51F.1000607@sonic.net> References: <20040507024827.033207b8.kstenger@montevideo.com.uy> <40A1C51F.1000607@sonic.net> Message-ID: On Tue, 11 May 2004, Mark Wedel wrote: > Karla Stenger wrote: > > Hi all, > > > > /lake_country/Butakis/Wist_study > > > > this map uses a pentagram to teleport a monster to the right place, but for some > > reason the monster is beeing teleported altogether with the surrounding walls > > that are on the pentagram too... and the teleporter the player is meant to use > > to go through the map gets useless when one of those walls steps on it... > > maybe the pentagram is working wrong? > > maybe a teleporter should be used instead? > > maybe the weight of the walls is wrong and the movement comming from spells > > beeing casted is moving them along onto the teleporter? > > > > i couldnt find out how the pentagram works *shrugs* hope you can find it out > > 'til next time > > Katia > > > The bug is actually relatively easy to fix - just don't teleport anything with > a 0 weight. > > The problem is I'm not sure if this might have other side effects, eg, > teleporters that are meant to teleport walls or the like that would no longer work. > > Anyone know off the top of their head if not teleporter walls (or other 0 > weight objects) would actually break any maps? > > > Walls are teleported in the warrior's tower.(The shortcut altar) So there is at least one map. Maybe the pentagram problem is related to the multi-part problem of confusing below and above. (see portgate mail) I think the correct solution here really is to use a teleporter. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Wed May 12 09:40:31 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:31 2005 Subject: [CF-Devel] faster portgate (context diff) In-Reply-To: References: Message-ID: <40A2375F.1040806@laposte.net> IMO waiting is part of the game. And you can also use dimension door to cross faster :) _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Wed May 12 10:33:15 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:31 2005 Subject: [CF-Devel] faster portgate (context diff) In-Reply-To: <40A2375F.1040806@laposte.net> References: <40A2375F.1040806@laposte.net> Message-ID: <200405121033.15909.eracclists@bellsouth.net> On Wednesday 12 May 2004 09:40 Nicolas Weeger wrote: > IMO waiting is part of the game. > And you can also use dimension door to cross faster :) My thoughts exactly. :-) I was going to suggest dimension door for our impatient friend. I also *like* seeing the guards messages. Perhaps if there were a way to randomize what the guard says so it does not seem monotonous our dissenting friend would be less irritated. :-) Gene (aka poof|Galahad) -- Linux era4.eracc.UUCP 2.4.22-28mdkenterprise i686 10:28:38 up 74 days, 4:26, 12 users, load average: 0.01, 0.04, 0.00 ERA Computer Consulting - http://www.eracc.com/ eCS, OS/2, Mandrake GNU/Linux, OpenServer & UnixWare resellers _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Fri May 14 00:40:01 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:31 2005 Subject: [CF-Devel] Monsters not using wands/rods/horns In-Reply-To: <40A1CEA4.7000304@laposte.net> References: <409CB4AC.30106@laposte.net> <40A1ADFF.5010101@sonic.net> <40A1CEA4.7000304@laposte.net> Message-ID: <40A45BB1.2080606@sonic.net> Nicolas Weeger wrote: > > Hum, i'll check my code. I copied only the last fragment, actually > firing the spell, so some checks indeed went to the trash. > What would be useful, I think, is to merge as much as the > spell/firing/... code we can so it works for both players & monsters. > (not only for this precise case, but for everything) The problem here is that players have intelligence, and monsters don't. EG, if as a player, you fire your horn until it has no charges, you're not going to try to fire it again immediately. Likewise, you're not going to fire wands with no charges, or use spell items that have useless spells. To mimic this logic for monsters, the monster fire code examines the potential object, eg, would it actually fire right now (have charges or if horn/rod, enough power in it right now). If not, lets look for another object. Once you put that much logic in, there really isn't that much left to do the actual firing of the object. Eg, we know if will fire, so we don't need to recheck that all again. So for monsters, its really a 'choose and fire logic', where for players, it is just a simple fire logic. > >> Probably using the same logic makes sense, except as mentioned above, >> if there are cases where a creature is deemed too stupid yet has a >> hand or whatever. > > > Then we shouldn't give it the skill 'use magic item' :) Yes. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Wed May 12 13:58:38 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:31 2005 Subject: [CF-Devel] faster portgate (context diff) In-Reply-To: <200405121033.15909.eracclists@bellsouth.net> Message-ID: Yeah, waiting is as much part of the game as having to spend 15 mins to get to Navar from Scorn on foot. Maybe it's intended, tho I wonder if there was a real reason to make players suffer such things. Just to make things harder so it's much better a challenge? Sure things ain't bad if they are hard sometimes. Messing with players real time thru such pitiful things ain't good either IMO. (And I _love_ poof's another conformist sidenote, which has absolutely no relevant information in it, and it's clear that he doesn't think of _others_ but himself... Would be a good dev, mayhap. Such is the way of free MUDs, it seems.) I wonder how CF will look like in 3 years. Oh... how did it look like 3 yeas ago...? > On Wednesday 12 May 2004 09:40 > Nicolas Weeger wrote: > > > IMO waiting is part of the game. > > And you can also use dimension door to cross faster :) > > My thoughts exactly. :-) > > I was going to suggest dimension door for our impatient friend. I > also *like* seeing the guards messages. Perhaps if there were a way > to randomize what the guard says so it does not seem monotonous our > dissenting friend would be less irritated. :-) > > Gene (aka poof|Galahad) > -- > Linux era4.eracc.UUCP 2.4.22-28mdkenterprise i686 > 10:28:38 up 74 days, 4:26, 12 users, load average: 0.01, 0.04, 0.00 > ERA Computer Consulting - http://www.eracc.com/ > eCS, OS/2, Mandrake GNU/Linux, OpenServer & UnixWare resellers > > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Fri May 14 09:05:01 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:31 2005 Subject: [CF-Devel] faster portgate (context diff) In-Reply-To: <200405121033.15909.eracclists@bellsouth.net> References: <40A2375F.1040806@laposte.net> <200405121033.15909.eracclists@bellsouth.net> Message-ID: On Wed, 12 May 2004, ERACC wrote: > On Wednesday 12 May 2004 09:40 > Nicolas Weeger wrote: > > > IMO waiting is part of the game. > > And you can also use dimension door to cross faster :) > > My thoughts exactly. :-) > > I was going to suggest dimension door for our impatient friend. I > also *like* seeing the guards messages. Perhaps if there were a way > to randomize what the guard says so it does not seem monotonous our > dissenting friend would be less irritated. :-) > Games are supposed to be fun. (Obviously not so obvious as it sounds.) Useless waiting is not my idea of fun. If you like waiting so much, you can still wait before the already opened gates. The idea of using dim door at those gates did only come up because these gates opened so annoyingly slow in the first place. And while my character does have dim door, others do not. Anyway i think there are other people who are not in for the SM kind of play. (suffering and seeing others suffer) As to the messages, if you had tested the map, you'd have noticed that i did not remove them, but refined their logic. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Fri May 14 16:29:25 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:31 2005 Subject: [CF-Devel] Consecrate, spell runes Message-ID: <200405141629.25203.eracclists@bellsouth.net> Greetings Developers, On crossfire.metalforge.net the altars in the temples in Scorn were ALL consecrated to Valriel recently (level 110). I "fixed" the altars by resetting the maps but it was too late for at least one player who prayed and lost about 15 praying levels. The DMs have a good idea who did it by examining circumstantial evidence, no hard proof. BUT it would be nice to have the player's name tied to a consecrated altar like is done when a player casts a marking rune. Best would be to fix the temple altars so they can't be reconsecrated. I have looked at where I *think* this could done but am really clueless about whether or not I am looking at the correct code. :-/ Come to think of it, it would be a good idea to embed the player's name in ANY rune as well as in items the player might change. It would help finding those players that have evil intent and place harming runes in newbie areas "as a joke". Perhaps leave some sort of marker where the rune was until the map resets to help DMs root out the trouble makers. Gene (aka poof|Galahad) -- Linux era4.eracc.UUCP 2.4.22-28mdkenterprise i686 16:01:24 up 76 days, 9:58, 12 users, load average: 0.10, 0.08, 0.05 ERA Computer Consulting - http://www.eracc.com/ eCS, OS/2, Mandrake GNU/Linux, OpenServer & UnixWare resellers _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Fri May 14 18:52:02 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:31 2005 Subject: [CF-Devel] Shoes of Fire: Item bug? Message-ID: <000501c43a0e$74956f00$0100000a@archaios> Hi, I just received an anecdotal report of a uh, slightly messed up shoes of fire. Str+26, Dex+21, Con+28, Int+22, res. (magic, fire, cold, depletion, everything) +100 That's obviously not a good thing. The player (Soul) reports being able to kill cyclops at level 6... Is this just a singular glitch or a wider bug? -archaios _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Fri May 14 19:12:12 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:31 2005 Subject: [CF-Devel] Shoes of Fire: Item bug? In-Reply-To: <000501c43a0e$74956f00$0100000a@archaios> References: <000501c43a0e$74956f00$0100000a@archaios> Message-ID: This looks to be the same problem I just reported to the SF bug tracker. https://sourceforge.net/tracker/index.php?func=detail&aid=954273&group_id=13833&atid=113833 On Sat, 15 May 2004, David McIlwraith wrote: > I just received an anecdotal report of a uh, slightly messed up shoes of > fire. > > Str+26, Dex+21, Con+28, Int+22, res. (magic, fire, cold, depletion, > everything) +100 > > That's obviously not a good thing. The player (Soul) reports being able to > kill cyclops at level 6... > > Is this just a singular glitch or a wider bug? _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Sat May 15 05:14:52 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:31 2005 Subject: [CF-Devel] Patch: new sound proposal Message-ID: <40A5ED9C.6000608@laposte.net> Ok, finally did some code for new sound support. I prefer to submit it here before committing :p Only server-side code is here, client or client/server one isn't there yet. Attached a diff, and a sounds.c that should go into common. Sound works like that: * add to archetypes something like: Object waybread ... soundinfo apply eat_waybread 100 <- a sound name, and a probability. endsoundinfo end * create a 'sound_arch' file in share/ directory, put sound eat_waybread endsound That should be enough to get a (wrong) sound when eating a waybread. Code-wise: * items have a 'sounds' field, containing for some event codes the sound(s) to be played. Multiple sounds per event, random one chosen (or none played, depending on total probability) * a 'sound_cache' field helps know quickly if a sound is defined or not for an event * right now, only events are 'death', 'move', 'apply', and only that one is used (from manual_apply). There are #define in sounds.h for those codes, and an array with 'readable' names in (new) common/sounds.c * if a sound has no sounds for an event type, archetype is checked. * when loading, sound info is cleared, since archetype is used by default. * also, sounds structure is always saved if not null. Because if not null it means item has a special sound structure, so should be saved. what needs yet to be done: * change the collect script to get merge sound info from (yet to be done) .snd files * make a way for client to get that list * add a field for 'new sound support' to NewSocket, for backwards compatibility Ryo -------------- next part -------------- Index: common/init.c =================================================================== RCS file: /cvsroot/crossfire/crossfire/common/init.c,v retrieving revision 1.36 diff -u -r1.36 init.c --- common/init.c 8 May 2004 13:38:04 -0000 1.36 +++ common/init.c 15 May 2004 09:51:36 -0000 @@ -176,6 +176,7 @@ init_objects(); init_vars(); init_block(); + init_sounds( ); ReadBmapNames (); ReadSmooth(); init_anim(); /* Must be after we read in the bitmaps */ Index: common/loader.l =================================================================== RCS file: /cvsroot/crossfire/crossfire/common/loader.l,v retrieving revision 1.57 diff -u -r1.57 loader.l --- common/loader.l 26 Mar 2004 21:59:28 -0000 1.57 +++ common/loader.l 15 May 2004 09:51:42 -0000 @@ -479,6 +479,7 @@ %x MESSAGE %x LORE %x SCRIPT +%x SOUNDINFO /* Don't have to link with -lfl with this */ %option noyywrap @@ -565,7 +566,11 @@ tmp=get_object(); tmp->arch = find_archetype(yval()); if (tmp->arch!=NULL) - copy_object(&tmp->arch->clone,tmp); + { + copy_object(&tmp->arch->clone,tmp); + /* Remove soundinfo */ + free_soundinfo_for_object( tmp ); + } strcpy(msgbuf, ""); strcpy(lorebuf, ""); lex_load(tmp, map_flags); @@ -574,7 +579,12 @@ /* This is the actual archetype definition then */ else { op->arch=find_archetype(yval()); - if (op->arch!=NULL) copy_object(&op->arch->clone,op); + if (op->arch!=NULL) + { + copy_object(&op->arch->clone,op); + /* Remove soundinfo */ + free_soundinfo_for_object( op ); + } } } @@ -1150,6 +1160,10 @@ }; } +^soundinfo{WS}$ { BEGIN( SOUNDINFO ); } +.* { read_sound_info( op, yytext ); } +^endsoundinfo$ { BEGIN( INITIAL ); } + <*>(^{WS}$)|\n {/* ignore empty lines, newlines we don't do above */} #.*\n {} @@ -1506,6 +1520,31 @@ } + if ( op->sounds ) + { + soundinfo* info; + const char* name; + int sound; + + FAST_STRCAT( fastbuf, "soundinfo\n" ); + + for ( info = op->sounds; info; info = info->next ) + { + name = get_sound_event_name( info->type ); + for ( sound = 0; sound < info->count; sound++ ) + { + FAST_STRCAT( fastbuf, name ); + FAST_STRCAT( fastbuf, " " ); + FAST_STRCAT( fastbuf, get_sound_name( info->sounds[ sound ] ) ); + FAST_STRCAT( fastbuf, " " ); + FAST_STRCAT( fastbuf, ltostr10( info->chance[ sound ] ) ); + FAST_STRCAT( fastbuf, "\n" ); + } + } + + FAST_STRCAT( fastbuf, "endsoundinfo\n" ); + } + if (op->animation_id != op2->animation_id) { if (op->animation_id) { ADD_STRINGLINE_ENTRY(fastbuf,"animation ",animations[GET_ANIM_ID(op)].name,10); @@ -1840,9 +1879,3 @@ } return NULL; } - - - - - - Index: common/object.c =================================================================== RCS file: /cvsroot/crossfire/crossfire/common/object.c,v retrieving revision 1.86 diff -u -r1.86 object.c --- common/object.c 14 Apr 2004 07:24:30 -0000 1.86 +++ common/object.c 15 May 2004 09:51:48 -0000 @@ -479,6 +479,7 @@ op->lore = NULL; op->current_weapon_script = NULL; op->events=NULL; + op->sounds = NULL; clear_object(op); } /* @@ -507,6 +508,16 @@ } op->events = NULL; + while ( op->sounds ) + { + soundinfo* info = op->sounds->next; + free( op->sounds->sounds ); + free( op->sounds->chance ); + free( op->sounds ); + + op->sounds = info; + } + op->sounds = NULL; /* the memset will clear all these values for us, but we need * to reduce the refcount on them. @@ -565,6 +576,7 @@ void copy_object(object *op2, object *op) { int is_freed=QUERY_FLAG(op,FLAG_FREED),is_removed=QUERY_FLAG(op,FLAG_REMOVED); event *evt, *evt2, *evt_new; + soundinfo* info; if(op->name!=NULL) free_string(op->name); if(op->name_pl!=NULL) free_string(op->name_pl); @@ -589,6 +601,8 @@ } op->events = NULL; + free_soundinfo_for_object( op ); + (void) memcpy((void *)((char *) op +offsetof(object,name)), (void *)((char *) op2+offsetof(object,name)), sizeof(object)-offsetof(object, name)); @@ -629,7 +643,23 @@ evt2 = evt_new; } - + + /* Copy sound info */ + info = op2->sounds; + op->sounds = NULL; + while ( info ) + { + soundinfo* new = ( soundinfo* )malloc( sizeof( soundinfo ) ); + memcpy( new, info, sizeof( soundinfo ) ); + new->sounds = ( int* )malloc( new->count * sizeof( int ) ); + memcpy( new->sounds, info->sounds, sizeof( int ) * new->count ); + new->chance = ( int* )malloc( new->count * sizeof( int ) ); + memcpy( new->chance, info->chance, sizeof( int ) * new->count ); + new->next = op->sounds; + op->sounds = new; + info = info->next; + } + update_ob_speed(op); } @@ -709,6 +739,7 @@ op->prev=NULL; op->active_next = NULL; op->active_prev = NULL; + op->sounds = NULL; if(objects!=NULL) objects->prev=op; objects=op; Index: include/libproto.h =================================================================== RCS file: /cvsroot/crossfire/crossfire/include/libproto.h,v retrieving revision 1.56 diff -u -r1.56 libproto.h --- include/libproto.h 28 Apr 2004 22:04:09 -0000 1.56 +++ include/libproto.h 15 May 2004 09:55:40 -0000 @@ -414,3 +414,11 @@ extern void save_object(FILE *fp, object *op, int flag); extern void insert_event(object *op, int etype, char *ehook, char *eplug, char *eoptions); extern event *find_event(object *op, int etype); +/* sounds.c */ +int init_sounds( ); +int get_sound_event_count( ); +extern void read_sound_info( object* op, const char* line ); +void play_object_sound( object* ob, int sound_type, object* onlyfor ); +void free_soundinfo_for_object( object* ob ); +const char* get_sound_name( int sound_number ); +const char* get_sound_event_name( int event_code ); Index: include/object.h =================================================================== RCS file: /cvsroot/crossfire/crossfire/include/object.h,v retrieving revision 1.34 diff -u -r1.34 object.h --- include/object.h 16 Feb 2004 18:05:32 -0000 1.34 +++ include/object.h 15 May 2004 09:55:41 -0000 @@ -52,6 +52,19 @@ struct _event *next; } event; +/** + * This contains information for one sound event type. + */ +typedef struct _soundinfo + { + int type; + int count; + int total_chance; + int* sounds; + int* chance; + struct _soundinfo* next; + } soundinfo; + /* Definition for WILL_APPLY values. Replaces having harcoded values * sprinkled in the code. Note that some of these also replace fields * that were in the can_apply area. What is the point of having both @@ -219,6 +232,9 @@ char *custom_name; /* Custom name assigned by player */ + soundinfo* sounds; /* Object sounds */ + int sound_cache[ 1 ]; /* Flags for sound events */ + } object; typedef struct oblnk { /* Used to link together several objects */ Index: include/sounds.h =================================================================== RCS file: /cvsroot/crossfire/crossfire/include/sounds.h,v retrieving revision 1.1.1.1 diff -u -r1.1.1.1 sounds.h --- include/sounds.h 2 Apr 1999 19:10:04 -0000 1.1.1.1 +++ include/sounds.h 15 May 2004 09:55:42 -0000 @@ -51,4 +51,27 @@ /* NROF_SOUNDS is defined in "defines.h". Don't forget to change this number * if you add or remove any sound. */ + +/** + * New sound event mechanism: + * like plugin events, define event types. Items will have 'soundinfo' blocks + * with all needed info. + * Note that you need to make those define match with sound_events[ ] (in common/sounds.c). + */ + +#define SE_DEATH 0 +#define SE_MOVE 1 +#define SE_APPLY 2 + +/** + * Sound event cache: to avoid going through the sound lists, just cache values + */ + +#define QUERY_SE( xyz, p ) \ + ((xyz)->sound_cache[ p / 32 ] & ( 1U << ( p % 32 ) ) ) +#define SET_SE(xyz, p) \ + ((xyz)->sound_cache[p/32] |= (1U << (p % 32))) +#define CLEAR_SE(xyz, p) \ + ((xyz)->sound_cache[p/32] &= ~(1U << (p % 32))) + #endif Index: server/apply.c =================================================================== RCS file: /cvsroot/crossfire/crossfire/server/apply.c,v retrieving revision 1.107 diff -u -r1.107 apply.c --- server/apply.c 8 May 2004 13:38:05 -0000 1.107 +++ server/apply.c 15 May 2004 09:56:39 -0000 @@ -280,6 +280,7 @@ CLEAR_FLAG(tmp, FLAG_APPLIED); fix_player(op); decrease_ob(tmp); + return 1; } @@ -2280,6 +2281,10 @@ if (rtn_script!=0) return 1; } } + + /* Play sound event 'apply' */ + play_object_sound( tmp, SE_APPLY, op ); + switch (tmp->type) { case CF_HANDLE: -------------- next part -------------- /* * static char *rcsid_sound_c = * "$Id$"; */ /* CrossFire, A Multiplayer game for X-windows Copyright (C) 2001-2003 Mark Wedel & Crossfire Development Team Copyright (C) 1992 Frank Tore Johansen This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. The authors can be reached via e-mail at crossfire-devel@real-time.com */ /** * This file deals with sound support. * It'll load sound definition from file(s), and assign unique numbers * to sounds, things like that. * * Author: Ryo * Date: April 28th 2004 (start) */ #include #include #include static const char** sounds = NULL; static int sound_count = 0; /**< Sound count, to go fast & alloc memory for sound structures */ static int sound_event_count = 0; /**< Sound event count, to alloc memory for events */ /** * This is the text-int match for 'sound' lines in archetypes. */ const char* sound_events[ ] = { "death", "move", "apply", NULL }; /** * Get sound event count. * Just a wrapper to return sound_event_count */ int get_sound_event_count( ) { return sound_event_count; } /** * Get soundname from number. * Just a wrapper to sounds[ number ]. */ const char* get_sound_name( int sound_number ) { if ( ( sound_number < 0 ) || ( sound_number >= sound_count ) ) return NULL; return sounds[ sound_number ]; } /** * Adds specified sound to our sound list. Doesn't check for duplicates. */ void add_sound( const char* soundname ) { if ( !soundname || ( strlen( soundname ) == 0 ) ) { LOG( llevDebug, "Empty sound line" ); return; } sound_count++; sounds = ( const char** )realloc( ( void* )sounds, sizeof( const char* ) * sound_count ); sounds[ sound_count - 1 ] = strdup( soundname ); } #define SOUND_WORD "sound " #define SOUND_LEN 6 /** * This parses specified sound file. * Basically just looks for lines 'sound xxx', adds 'xxx' to * internal list if not yet, ignore the rest. */ int parse_sound_file( const char* filename ) { FILE* fp; int comp; char buf[ MAX_BUF ]; char* nl; LOG( llevDebug, "Reading sound info from %s...", filename ); if ( ( fp = open_and_uncompress( filename, 0, &comp ) ) == NULL) { LOG( llevError, "Can't open sound file %s.\n", filename ); return 0; } while ( fgets( buf, MAX_BUF, fp ) != NULL ) { if ( nl = strstr( buf, "\n" ) ) *nl = '\0'; if ( !strncmp( buf, SOUND_WORD, SOUND_LEN ) ) /* Found a sound, add it */ add_sound( buf + SOUND_LEN ); } LOG( llevDebug, "done.\n" ); close_and_delete( fp, comp ); return 1; } /** * Returns sound identifier by name. * -1 if not found, else < get_sound_event_count( ) */ int get_sound_by_name( const char* sound_name ) { int sound = 0; if ( !sound_name || ( strlen( sound_name ) == 0 ) ) { LOG( llevDebug, "get_sound_by_name: NULL or empty event_code._n" ); return -1; } while ( sound < sound_count ) { if ( !strcmp( sound_name, sounds[ sound ] ) ) return sound; sound++; } return -1; } /** * Returns sound event identifier for specified name. */ int get_sound_event_code( const char* event_name ) { int sound = 0; if ( !event_name || ( strlen( event_name ) == 0 ) ) { LOG( llevDebug, "get_sound_event_code: NULL or empty event_code.\n" ); return -1; } while ( sound < sound_event_count ) { if ( !strcmp( event_name, sound_events[ sound ] ) ) return sound; sound++; } return -1; } /** * Return sound event name, used for saving. */ const char* get_sound_event_name( int event_code ) { if ( event_code < 0 || event_code >= sound_event_count ) { LOG( llevDebug, "get_sound_event_name: invalid sound %d\n", event_code ); return NULL; } return sound_events[ event_code ]; } /** * Init sounds. * Reads sound file, inits some variables. */ int init_sounds( ) { char filename[MAX_BUF]; sprintf( filename, "%s/sounds_arch", settings.datadir ); if ( !parse_sound_file( filename ) ) return 0; LOG( llevDebug, "Done loading sounds, %d found, ", sound_count ); while ( sound_events[ sound_event_count ] ) sound_event_count++; LOG( llevDebug, "%d sound events.\n", sound_event_count ); return 1; } /** * Parses a soundinfo (called from loader.c). */ void read_sound_info( object* op, const char* line ) { soundinfo* info; char stype[ HUGE_BUF ], name[ HUGE_BUF ]; int chance, type, number; if ( sscanf( line, "%s %s %d", &stype, &name, &chance ) != 3 ) { LOG( llevDebug, "invalid sound line: %s\n", line ); return; } type = get_sound_event_code( stype ); if ( type == -1 ) { LOG( llevDebug, "invalid sound type: %s\n", line ); return; } number = get_sound_by_name( name ); if ( number == -1 ) { LOG( llevDebug, "invalid sound name: %s\n", line ); return; } for ( info = op->sounds; info; info = info->next ) { if ( info->type == type ) break; } if ( !info ) { info = ( soundinfo* )malloc( sizeof( soundinfo ) ); info->type = type; info->count = 0; info->total_chance = 0; info->sounds = NULL; info->chance = NULL; info->next = op->sounds; op->sounds = info; } info->count++; info->total_chance += chance; info->sounds = ( int* )realloc( info->sounds, sizeof( int* ) * info->count ); info->sounds[ info->count - 1 ] = number; info->chance = ( int* )realloc( info->chance, sizeof( int* ) * info->count ); info->chance[ info->count - 1 ] = chance; SET_SE( op, type ); if ( info->total_chance > 100 ) { LOG( llevDebug, "Object %s has sound total chance > 100 for type %d !\n", op->name, type ); } } /** * Plays sound for object & type. */ void play_object_sound( object* ob, int sound_type, object* onlyfor ) { soundinfo* info; int chance, sound; if ( !QUERY_SE( ob, sound_type ) && !QUERY_SE( &ob->arch->clone, sound_type ) ) return; if ( onlyfor && onlyfor->type != PLAYER ) return; if ( !ob ) { LOG( llevDebug, "play_sound_object: NULL object!\n" ); return; } if ( !ob->map ) { if ( !onlyfor ) { LOG( llevDebug, "play_sound_object: NULL map and onlyfor!\n" ); return; } if ( !onlyfor->contr ) { LOG( llevDebug, "play_sound_object: NULL onlyfor->contr!\n" ); return; } } info = NULL; if ( QUERY_SE( ob, sound_type ) ) info = ob->sounds; else info = ob->arch->clone.sounds; for ( ; info; info = info->next ) { if ( info->type == sound_type ) break; } if ( !info ) { LOG( llevDebug, "play_sound_event: no sound list %d for object!\n", sound_type ); CLEAR_SE( ob, sound_type ); return; } chance = 1 + RANDOM( ) % 100; if ( chance > info->total_chance ) /* Not playing any sound */ return; sound = -1; while ( chance > 0 ) { chance -= info->chance[ ++sound ]; } if ( !onlyfor ) play_sound_map( ob->map, ob->x, ob->y, info->sounds[ sound ] ); else play_sound_player_only( onlyfor->contr, info->sounds[ sound ], ob->x, ob->y ); } /** * Free sound information structure. */ void free_soundinfo_for_object( object* ob ) { soundinfo* info; while ( ob->sounds ) { info = ob->sounds->next; free( ob->sounds->sounds ); free( ob->sounds->chance ); free( ob->sounds ); ob->sounds = info; } } -------------- next part -------------- _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Sat May 15 05:48:57 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:31 2005 Subject: [CF-Devel] Suggestion: random diseases in maps Message-ID: <40A5F599.9060208@laposte.net> Hello. As the title suggests, I was wondering about putting random diseases in maps. Right now, as far as I know, the only diseases come from spells or traps. It could be fun to randomly infect some monsters here and there, or put diseased squares. Of course, high probability for non-fatal diseases, but I don't have anything against killing ones too, with a low probability. It would give some more challenge, imo. What'd be everyone's point of view? Nicolas _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Sat May 15 11:59:08 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:31 2005 Subject: [CF-Devel] Suggestion: random diseases in maps In-Reply-To: <40A5F599.9060208@laposte.net> Message-ID: On 15-May-2004 Nicolas Weeger wrote: > Right now, as far as I know, the only diseases come from spells or traps. > It could be fun to randomly infect some monsters here and there, or > put diseased squares. > > What'd be everyone's point of view? The only problem with that, is that the monsters might self-destruct upon entering the map. You could hang out at the entrance, and they would spread the disease around, and either die, or cure themselves of it. I think you would need something to mark the disease as communicable to players only.. --- Tim Rightnour NetBSD: Free multi-architecture OS http://www.netbsd.org/ NetBSD supported hardware database: http://mail-index.netbsd.org/cgi-bin/hw.cgi _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Sat May 15 13:22:10 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:31 2005 Subject: [CF-Devel] New item: ground positioning system Message-ID: <40A65FD2.5040800@laposte.net> Hello. Just added a new item type & associated item: 'ground positioning system' (gps). This will let players know their position in the world (only on 'world_xxx_xxx' maps). Item must first be marked then applied to reset its origin, then simply applied (without being marked) to know one's location. Position is just map's x * size + player's x, same for y. Note that you can change the origin as much as you want :p Image is based on a copyright-less picture. I was planning on putting that at the end of some quest. If anyone wants to take care of map making, or integrating to existing map, feel free, else i'll find something someday :) Nicolas _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Sat May 15 20:39:11 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:32 2005 Subject: [CF-Devel] rods changing spells Message-ID: <20040515223911.33cf9b35.kstenger@montevideo.com.uy> hi all, today, many players have been complaining (or just making a note) about their rods, they seem to be changing the spell they have inside when they disconnect... i haven't tested this myself yet... but looks like when a player disconnects and comes back it's somehow messed up hope you guys can find the problem :/ -- +-----------------------------+ | Karla M? Stenger S?bat | | Pando . Canelones . Uruguay | | kstenger@montevideo.com.uy | +-----------------------------+ _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Sat May 15 21:09:48 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:32 2005 Subject: [CF-Devel] traps stacking order Message-ID: <1084673388.11267.1.camel@d5110227.lss.emc.com> I just noticed that if there's a chest with a bunch of traps in a random map and you leave the map and come back, the order of the traps is reversed. It probably doesn't matter, but it's possible that it's a symptom of a bug with more serious consequences that haven't been noticed yet. --PC _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Sat May 15 21:50:06 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:32 2005 Subject: [CF-Devel] request: time stamp or other info in the banish_file Message-ID: I noticed that when a DM uses the banish command to ban a player from the server, only the target player's IP address is added to the banish_file Would it be possible to include a time stamp with the IP address? How about the target player's name? How about the DM's name that exected the banish command? IMO, I think this would make things easier for allowing players back or if they need to be added to the permanent ban_file Thanks. -- _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Sat May 15 23:04:11 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:32 2005 Subject: [CF-Devel] faster portgate (context diff) In-Reply-To: References: <40A2375F.1040806@laposte.net> <200405121033.15909.eracclists@bellsouth.net> Message-ID: <40A6E83B.3080701@sonic.net> Bernd Edler wrote: > > Games are supposed to be fun. (Obviously not so obvious as it sounds.) > Useless waiting is not my idea of fun. > If you like waiting so much, you can still wait before the already opened > gates. The idea of using dim door at those gates did only come up because > these gates opened so annoyingly slow in the first place. > And while my character does have dim door, others do not. > Anyway i think there are other people who are not in for the SM kind of > play. (suffering and seeing others suffer) Just as a note, I personally don't see any harm in quickening it up. While patience may be a virtue, it can get annoying to constantly have to wait 5 seconds (or whatever it is). The first dozen times may not be that big a deal, but after the 100'th, it seems a bit excessive. I know that I've personally thought 'will those darn guards hurry up and open the gate'? Maybe we need an express pass :) - more money == faster access. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Sat May 15 23:21:09 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:32 2005 Subject: [CF-Devel] Consecrate, spell runes In-Reply-To: <200405141629.25203.eracclists@bellsouth.net> References: <200405141629.25203.eracclists@bellsouth.net> Message-ID: <40A6EC35.8090108@sonic.net> ERACC wrote: > Greetings Developers, > > On crossfire.metalforge.net the altars in the temples in Scorn were > ALL consecrated to Valriel recently (level 110). I "fixed" the altars > by resetting the maps but it was too late for at least one player who > prayed and lost about 15 praying levels. The DMs have a good idea who > did it by examining circumstantial evidence, no hard proof. BUT it > would be nice to have the player's name tied to a consecrated altar > like is done when a player casts a marking rune. Best would be to fix > the temple altars so they can't be reconsecrated. I have looked at > where I *think* this could done but am really clueless about whether > or not I am looking at the correct code. :-/ Well, simplest fix would be to make all the altars in the temples 'level 150' or something - a level higher than the player could ever achieve, and thus not something that can be consecrated. Tying player name to all that can be difficult, because finding a field in the object could be a problem. Much easier would be to just generate a log message, similiar to what is done for player killing. Then the admins could look over the logs and say 'oh, so and so cast a bunch of consecrate spells on altars' - if the log messages include the map name, it makes tying that information very easy. And I'm not sure if putting the players name in the altar may somehow break things (I'd actually bet if a player had a name of 'of', it actually might - you'd get something like "of's altar of lythander", and it is possible that code parsing could get confused by that first of. > > Come to think of it, it would be a good idea to embed the player's > name in ANY rune as well as in items the player might change. It > would help finding those players that have evil intent and place > harming runes in newbie areas "as a joke". Perhaps leave some sort of > marker where the rune was until the map resets to help DMs root out > the trouble makers. This may be doable for these runes in that I don't think the name matters. OTOH, doing it in the log files may still be better cosmetically (how, for example, should another player be able to know that Bob cast that fireball rune) _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Sat May 15 23:40:01 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:32 2005 Subject: [CF-Devel] faster portgate (context diff) In-Reply-To: References: Message-ID: <40A6F0A1.4090003@sonic.net> Palfy Tamas wrote: > > Yeah, waiting is as much part of the game as having to spend 15 mins to > get to Navar from Scorn on foot. Maybe it's intended, tho I wonder if > there was a real reason to make players suffer such things. Just to make > things harder so it's much better a challenge? Sure things ain't bad if > they are hard sometimes. Messing with players real time thru such pitiful > things ain't good either IMO. Well, there are certainly shortcuts, eg, get gobs of money, expand your apartment, and use the teleporters. Note that the bigworld goal wasn't to waste player time. But it was to increase travel time a bit - it never made a lot of sense on the old smallworld where walking from town to town was only about 3 times longer than walking across the town itself. But it was a side goal to increase travel times some, so that it was no longer especially easy to visit every shop out there in 2 minutes flat. while it may be a bit frustrating at times (I really want a book of XYZ, but this town doesn't have it), I think that is a reasonable part of the game. Now I do plan to make changes sometime soon that changes the player speed model some - players will be less likely to be blindingly fast, but player minimum speed will also be increased, so that players will no longer move at a crawl like that sometimes do when heavily loaded (and heavily loaded for a weak character might not be all that much stuff right now). Note that a longer term goal is to add other travel mechanisms (horses, boats, griffins, etc) that perhaps change travel times. I also wouldn't be all to adverse to adding a 'teleporter shop/guild' - has teleporters to a few fixed locations (major towns that are normally easy to get to) for a price - say like 100 pp or something. So you then weight money vs time. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Sat May 15 23:48:18 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:32 2005 Subject: [CF-Devel] Shoes of Fire: Item bug? In-Reply-To: References: <000501c43a0e$74956f00$0100000a@archaios> Message-ID: <40A6F292.9070600@sonic.net> Rick Tanner wrote: > This looks to be the same problem I just reported to the SF bug tracker. > > https://sourceforge.net/tracker/index.php?func=detail&aid=954273&group_id=13833&atid=113833 This is almost certainly caused by my change to clean up removed objects in main.c My _guess_ is that artifact template item got freed. And just by luck, a player logged in, and used that same object structure that the artifact pointed to. Thus, shoes of fire got pointed to a player in terms of stats and other adjustments. The likelihood of this happening is quite low, but apparantly did happen. I've fixed up the code in main.c so that shouldn't happen again. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Sat May 15 23:55:10 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:32 2005 Subject: [CF-Devel] Suggestion: random diseases in maps In-Reply-To: References: Message-ID: <40A6F42E.2020003@sonic.net> Tim Rightnour wrote: > On 15-May-2004 Nicolas Weeger wrote: > >>Right now, as far as I know, the only diseases come from spells or traps. >>It could be fun to randomly infect some monsters here and there, or >>put diseased squares. >> >>What'd be everyone's point of view? > > > The only problem with that, is that the monsters might self-destruct upon > entering the map. You could hang out at the entrance, and they would spread > the disease around, and either die, or cure themselves of it. I think you > would need something to mark the disease as communicable to players only.. Yep. You'd also probably need to change the fact that diseases normally die out after a little while. This could be a potential problem in that players enters map, quickly catches disease so leaves map, casts cure disease, waits a few minutes, and by the time he re-enters, the disease is gone from the map with a bunch of a dead monsters. What I think would probably be more interesting, and taking a note from other games, is that some monsters could carry diseases, and thus infect the player when they hit. the other thought I've long had is that flesh could decompose (like demon ichor does right now). However, it'd probably be in three stages: 1) flesh is still fresh, and perfectly fine. 2) flesh is rotting, perhap diseased, perhaps poisoned, perhaps ok to eat, perhaps not. 3) flesh disintegrates - no longer on map. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Sun May 16 00:02:42 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:32 2005 Subject: [CF-Devel] traps stacking order In-Reply-To: <1084673388.11267.1.camel@d5110227.lss.emc.com> References: <1084673388.11267.1.camel@d5110227.lss.emc.com> Message-ID: <40A6F5F2.2050500@sonic.net> Preston Crow wrote: > I just noticed that if there's a chest with a bunch of traps in a random > map and you leave the map and come back, the order of the traps is > reversed. > > It probably doesn't matter, but it's possible that it's a symptom of a > bug with more serious consequences that haven't been noticed yet. > This is a long standing 'feature'. You'd actually notice it with your inventory, except that the client sorts the inventory. This could actually be fixed pretty easily, but at some performance loss. Basically, when the game saves a map/player/whatever, it saves the objects in order, eg, first object in inventory is saved, then the next one, then the next one, etc. However, when it comes to loading them back in, instead of processing the list of objects and adding it to the end, it adds it to the head of the list. This is much more simple, as it is just a simple tmp->next = op->inv; op->inv=tmp (there is a bit more to it, but basically that is it). To add to the tail end, it would have to find the last object in the op->inv, and then put it in. This gets quite costly if there are lots of objects in the inventory (it's an O(n^2) operation vs O(1)). The more efficient way to do it would actually be to load them as above, and then reverse them after they are all loaded, as that would only be an O(n) operation. You'd actually see the same thing with objects stored in a container on the ground. Eg, if you have a chest in your apartment, you may notice the order changes each time the map goes through a load/save operation. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Sun May 16 00:30:04 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:32 2005 Subject: [CF-Devel] request: time stamp or other info in the banish_file In-Reply-To: References: Message-ID: <40A6FC5C.6060109@sonic.net> Rick Tanner wrote: > I noticed that when a DM uses the banish command to ban a player from the > server, only the target player's IP address is added to the banish_file > > Would it be possible to include a time stamp with the IP address? > > How about the target player's name? > > How about the DM's name that exected the banish command? > > IMO, I think this would make things easier for allowing players back or if > they need to be added to the permanent ban_file > > Thanks. Done: server/c_wiz.c: Modify command_banish() to record dm name, player name, and date of command. MSW 2004-05-15 _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Sun May 16 00:38:58 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:32 2005 Subject: [CF-Devel] Latest CVS client crashing Message-ID: <200405160038.58808.eracclists@bellsouth.net> Dear all, Anyone else getting client crashes when using SDL? When I try to log off metalforge the client crashes. I've gotten one core file from it so far if anyone wants to see the core. Also, when metalforge crashed last night my client crashed. This is latest CVS just downloaded and freshly rolled. FYI, running with SDL and NO smoothing "solved" my memory leak problem. But this crashing client one is almost as annoying. Gene (aka poof|Galahad) -- Linux era4.eracc.UUCP 2.4.22-28mdkenterprise i686 00:36:22 up 77 days, 18:30, 12 users, load average: 0.00, 0.02, 0.00 ERA Computer Consulting - http://www.eracc.com/ eCS, OS/2, Mandrake GNU/Linux, OpenServer & UnixWare resellers _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Sun May 16 01:09:29 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:32 2005 Subject: [CF-Devel] Latest CVS client crashing In-Reply-To: <200405160038.58808.eracclists@bellsouth.net> References: <200405160038.58808.eracclists@bellsouth.net> Message-ID: <40A70599.6040908@sonic.net> ERACC wrote: > Dear all, > > Anyone else getting client crashes when using SDL? When I try to log > off metalforge the client crashes. I've gotten one core file from it > so far if anyone wants to see the core. Also, when metalforge crashed > last night my client crashed. This is latest CVS just downloaded and > freshly rolled. > > FYI, running with SDL and NO smoothing "solved" my memory leak > problem. But this crashing client one is almost as annoying. Fixed in CVS: gtk/gx11.c: Comment out printing of size when we receive config event. gtk/image.c: Remove some superfluos LIL_ENDIAN code that would never be used because it was already in an #ifdef LIL_ENDIAN/#else block. Fix up freeing of data - need to free the pixel info before freeing the surface, don't free the fog pixels since SDL will do that for us. MSW 2004-05-15 _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Sun May 16 03:01:27 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:32 2005 Subject: [CF-Devel] Suggestion: random diseases in maps In-Reply-To: References: Message-ID: <40A71FD7.4050008@laposte.net> > The only problem with that, is that the monsters might self-destruct upon > entering the map. You could hang out at the entrance, and they would spread > the disease around, and either die, or cure themselves of it. I think you > would need something to mark the disease as communicable to players only.. didn't think of that lol. right now, i think diseases propagate to everyone. Maybe we could tweak something so that with value in some field it only harms players, but could still propagate to monsters (to spread it :p) Nicolas _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Sun May 16 05:45:23 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:32 2005 Subject: [CF-Devel] Rune & other bugs Message-ID: <40A74643.1060407@laposte.net> Hello. I tried a few things with rune/glyph/pentagram. There are a few bugs, don't know exactly how to correct'em :) You can create a glyph of word of recall, but it won't work. spring_trap, in server/rune.c, calls cast_spell with (trap, trap) as op & caster. Maybe need to be changed to (victim, trap)? It seems to work, but I'm not 100% sure of side effects. Also, glyph of holy word don't work, probably same issue. And 'confusion' is weird, makes my hands glow red lol Nicolas _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Sun May 16 11:53:03 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:32 2005 Subject: [CF-Devel] Suggestion: random diseases in maps In-Reply-To: <40A71FD7.4050008@laposte.net> Message-ID: On 16-May-2004 Nicolas Weeger wrote: > didn't think of that lol. > right now, i think diseases propagate to everyone. Maybe we could > tweak something so that with value in some field it only harms > players, but could still propagate to monsters (to spread it :p) The problem then is, that you walk in, catch it, and give it back to the monsters. I think to work properly, it would have to be a special player-only disease, with no timeout on the monsters. Basically, make them carriers, but immune. As Mark suggested.. you could make it so they are like certain real life animals, which have diseases in thier saliva, and cause disease on bite. --- Tim Rightnour NetBSD: Free multi-architecture OS http://www.netbsd.org/ NetBSD supported hardware database: http://mail-index.netbsd.org/cgi-bin/hw.cgi _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Sun May 16 12:33:08 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:32 2005 Subject: [CF-Devel] Suspicious code in common/object.c Message-ID: <20040516173308.GA14823@idefix2.dvlp.in-medias-res.com> I think the function get_search_arr() in common/object.c does not work correctly: it should return a permutation of [0..48] but the result nearly always contains more than one 0 value. For example: If the statement "tmp=(RANDOM()%(5-i+1))+1" at the end of the function (for the range i=1..4) always evaluates to "tmp=1", the result is search_nums[1..4]={1,2,3,0}. This is not correct because it should be a permutation of {1,2,3,4}. To fix this issue, I would like to replace the function with: /* * The function permute() randomly reorders the array arr[begin..end-1]. */ static void permute(int *arr, int begin, int end) { int i, j, tmp, len; len = end-begin; for(i = begin; i < end; i++) { j = begin+RANDOM()%len; tmp = arr[i]; arr[i] = arr[j]; arr[j] = tmp; } } void get_search_arr(int *search_arr) { int i; for(i = 0; i < SIZEOFFREE; i++) { search_arr[i] = i; } permute(search_arr, 1, SIZEOFFREE1+1); permute(search_arr, SIZEOFFREE1+1, SIZEOFFREE2+1); permute(search_arr, SIZEOFFREE2+1, SIZEOFFREE); } I think this new function is correct, easier to understand (it it smaller and does not contain a lot hardcoded values), and is a little bit faster. Note: The old function basically did something like permute(search_arr, 0, 1); /* a */ permute(search_arr, 1, 5); /* b */ permute(search_arr, 5, 9); /* c */ permute(search_arr, 9, 13); /* d */ permute(search_arr, 13, 21); /* e */ permute(search_arr, 21, 29); /* F */ permute(search_arr, 29, 37); /* g */ permute(search_arr, 37, 49); /* h */ The freearr_x/y[] is: 46 47 48 25 26 27 28 45 23 24 9 10 11 29 44 22 8 1 2 12 30 43 21 7 0 3 13 31 42 20 6 5 4 14 32 41 19 18 17 16 15 33 40 39 38 37 36 35 34 That is, the old function permutes as follows: (For each letter, the positions are permuted.) h--h--h /F--F--F--F h F--F/ d--d--d g h F c b--b d g h F c a b e g h e c--c b e g h e--e--e--e--e g h--h--h--h g--g--g I could not find out the reason for these range borderss. Especially the permutation for "F" is suspicious to me because it covers more than one distance. Because of this my function simply permutes the positions within each distance. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Sun May 16 23:01:09 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:33 2005 Subject: [CF-Devel] Rune & other bugs In-Reply-To: <40A74643.1060407@laposte.net> References: <40A74643.1060407@laposte.net> Message-ID: <40A83905.6010203@sonic.net> Nicolas Weeger wrote: > Hello. > > I tried a few things with rune/glyph/pentagram. > There are a few bugs, don't know exactly how to correct'em :) > > You can create a glyph of word of recall, but it won't work. > spring_trap, in server/rune.c, calls cast_spell with (trap, trap) as op > & caster. Maybe need to be changed to (victim, trap)? It seems to work, > but I'm not 100% sure of side effects. I'd bet some serious side effects - that would make 'victim' the owner of the spell that is detonated. Thus, if there is a rune of fireball lets say, player steps on it, and now anything killed with that fireball, the victim will now get credit for. IMO, have some spells not work correctly with runes is probably perfectly fine. I note that it doesn't appear that you can cast word of recall on friends even - it always seems it is a personal spell, and as long as that holds true, it won't work. The fix here isn't in the rune code, it would be in word of recall - if it is modified to look for players in the direction cast, it would probably work fine. > Also, glyph of holy word don't work, probably same issue. Vaguely - code wasn't in place to properly find the god for the casting of the spell. > > And 'confusion' is weird, makes my hands glow red lol That I believe is borrowed from nethack. It basically means you now have the attacktype of confusion. Such an attacktype was actually useful in nethack - not so in crossfire. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Sun May 16 23:15:20 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:33 2005 Subject: [CF-Devel] Suspicious code in common/object.c In-Reply-To: <20040516173308.GA14823@idefix2.dvlp.in-medias-res.com> References: <20040516173308.GA14823@idefix2.dvlp.in-medias-res.com> Message-ID: <40A83C58.3010304@sonic.net> Andreas Kirschbaum wrote: > I think the function get_search_arr() in common/object.c does not work > correctly: it should return a permutation of [0..48] but the result > nearly always contains more than one 0 value. > > For example: If the statement "tmp=(RANDOM()%(5-i+1))+1" at the end of > the function (for the range i=1..4) always evaluates to "tmp=1", the > result is search_nums[1..4]={1,2,3,0}. This is not correct because it > should be a permutation of {1,2,3,4}. > > > To fix this issue, I would like to replace the function with: That looks fine. Note that the efficiency/correctness of get_search_arr isn't really critical - it is basically so that the monsters don't always favor the same directions. However, I agree your function is much clearer, and should replace what is there now. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Mon May 17 01:23:29 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:33 2005 Subject: [CF-Devel] Patch: new sound proposal In-Reply-To: <40A5ED9C.6000608@laposte.net> References: <40A5ED9C.6000608@laposte.net> Message-ID: <40A85A61.50503@sonic.net> Nicolas Weeger wrote: > Ok, finally did some code for new sound support. > I prefer to submit it here before committing :p > Only server-side code is here, client or client/server one isn't there yet. > > Attached a diff, and a sounds.c that should go into common. A few notes.. > > Sound works like that: > > * add to archetypes something like: > Object waybread > ... > soundinfo > apply eat_waybread 100 <- a sound name, and a probability. > endsoundinfo > end > Looks fine. > Code-wise: > * items have a 'sounds' field, containing for some event codes the > sound(s) to be played. Multiple sounds per event, random one chosen (or > none played, depending on total probability) Looks good. > * a 'sound_cache' field helps know quickly if a sound is defined or not > for an event Looks fine, although the suffixe SE for the query/set/clear isn't all that intuitive IMO. Better woudl be QUERY_SOUND_EVENT (or FLAG, or the like). Otherwise, if someone run across this someplace in the code, it would be 'what is an SE?' > * right now, only events are 'death', 'move', 'apply', and only that one > is used (from manual_apply). There are #define in sounds.h for those > codes, and an array with 'readable' names in (new) common/sounds.c Minor note - I usually like to leave '0' not defined for anything - in that way, it is easier to tell if it hasn't been properly initialized or the like. > * if a sound has no sounds for an event type, archetype is checked. not good behaviour. > * when loading, sound info is cleared, since archetype is used by default. not good behaviour. > * also, sounds structure is always saved if not null. Because if not > null it means item has a special sound structure, so should be saved. not good behaviour. For all other objects, it is normal practice for the object to inherit the properties of its archetype, and those properties, not the archetypes, and used from that point on. To change that expected behavior probably isn't a good thing. I'm curious the rationale for making that change. If it was a matter of just being able to know if the data should be saved out, surely a flag could be used for that. Is this just a way to try and save memory? If so, it isn't all that efficient - most of the copy objects calls are dealt with loading, and then we free that data. I'd also think you're going to get odd behaviour with respect to generators or anything else that generates an object 'in game' - the data isn't getting cleared out in those cases, so when it goes to save them, it will save all the sound info. This then creates problems down the road - if the archetype is updated with new sounds, all those items won't get it if they had any sound info before. I wonder if perhaps a better approach would be to have a flag in the object itself to denote if this is custom information or if the soundinfo is in fact a private copy or points to the original. In that way, copy object and all that stuff works fine, doesn't use much memory, and the code is simple. If the loader then sees any sound info, it then clears that flag and copies all the sound info so it is now private. And in this case, saves it out. Also, given the current code, the behaviour seems to be that any sound info replaces existing sound info, and is not merged. This probably makes sense if I am overriding an event already set. But it may not make sense for a different event. For example, right now there are 3 sound events. Suppose I create a monster on a map that has a custom entry. Now, as time passes, more sound events are added, including one for that monster. Now I may still want my custom monster to get those new sound events (imagine the pain of this if a fair number of monsters/objects have custom values). So I wonder if something within the object sound info itself like: clearsoundinfo |all might be reasonable? Multiple lines could be used to clear multiple events. Code to do that is probably relative easy - the more complicated part is knowing to save that out (This is more an issue if you think about objects that players pick up - ideally, you probably want them to keep getting updated sound info). I'd think it'd be pretty easy within the sound event itself to have a 'loaded from object' flag, so you know which ones come from the object, and which ones are customized. Perhaps also a flag like 'cleared'? Thus, there could be a sound event allocated, with no sound, just to record it is a cleared event. > > what needs yet to be done: > * change the collect script to get merge sound info from (yet to be > done) .snd files > * make a way for client to get that list > * add a field for 'new sound support' to NewSocket, for backwards > compatibility Documentation for all of this. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Mon May 17 02:12:56 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:33 2005 Subject: [CF-Devel] Patch: new sound proposal In-Reply-To: <40A85A61.50503@sonic.net> References: <40A5ED9C.6000608@laposte.net> <40A85A61.50503@sonic.net> Message-ID: <40A865F8.1020803@laposte.net> > Looks fine, although the suffixe SE for the query/set/clear isn't all > that intuitive IMO. Better woudl be QUERY_SOUND_EVENT (or FLAG, or the > like). Otherwise, if someone run across this someplace in the code, it > would be 'what is an SE?' ok, i'll change accordingly. > Minor note - I usually like to leave '0' not defined for anything - in > that way, it is easier to tell if it hasn't been properly initialized or > the like. same as above :p > not good behaviour. > > For all other objects, it is normal practice for the object to inherit > the properties of its archetype, and those properties, not the > archetypes, and used from that point on. To change that expected > behavior probably isn't a good thing. I'm curious the rationale for > making that change. > Also, given the current code, the behaviour seems to be that any sound > info replaces existing sound info, and is not merged. The logic behind my inheritance choice is to solve the loading /saving / changing issue. When loading an object, first a copy of archetype is made. And then object is loaded. So if sound info gets copied from archetype, then how can we override events? Will there be a flag so that, when loading object, first time a certain sound event type (apply, cast, ...) is found, clear matching sound structure? Seems overkill. It seemed easier to clear sound info first, then load custom ones, using archetype's sounds if not found. Note that you can override only one event type. As the 'play_object_sound' is implemented, we query the sound info for item, and if not found for archetype. So you could have in archetypes: Object potion_generic soundinfo apply apply_potion 100 pick pick_potion 100 endsoundinfo and in an object: arch potion_generic soundinfo apply apply_special_potion 100 endsoundinfo The item will replace 'apply' with it's own version, but keep the 'pick' from archetype - thats how play_object_sound works (or i missed something :p) Note that this also solves the saving issue, since archetype contains information - thus only 'special' sounds are saved with object. And if the archetype's sound ever changes, objects will be updated automatically if they don't have their own version. Now my code may be totally wrong, but that's what i was planning on doing ^_- > Documentation for all of this. lol, always the thing i forget :) > > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Mon May 17 02:16:35 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:33 2005 Subject: [CF-Devel] Rune & other bugs In-Reply-To: <40A83905.6010203@sonic.net> References: <40A74643.1060407@laposte.net> <40A83905.6010203@sonic.net> Message-ID: <40A866D3.8050404@laposte.net> > IMO, have some spells not work correctly with runes is probably > perfectly fine. I note that it doesn't appear that you can cast word of > recall on friends even - it always seems it is a personal spell, and as > long as that holds true, it won't work. Then if some spells can't be put in runes, we should prevent a player from doing that :) > The fix here isn't in the rune code, it would be in word of recall - if > it is modified to look for players in the direction cast, it would > probably work fine. Hum, then you could have side effects sometimes when you want to cast wor on yourself, but a friend is in the direction you're looking in :) Not saying that's bad, just that we'll hafta take care :p > That I believe is borrowed from nethack. It basically means you now > have the attacktype of confusion. > > Such an attacktype was actually useful in nethack - not so in crossfire. Oh! lol I thought confusion was a cone spell, like burning hands & such :p Nicolas _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Sun May 16 08:35:04 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:33 2005 Subject: [CF-Devel] faster portgate (context diff) In-Reply-To: <40A6F0A1.4090003@sonic.net> Message-ID: On Sat, 15 May 2004, Mark Wedel wrote: > Palfy Tamas wrote: > > > > Yeah, waiting is as much part of the game as having to spend 15 mins to > > get to Navar from Scorn on foot. Maybe it's intended, tho I wonder if > > there was a real reason to make players suffer such things. Just to make > > things harder so it's much better a challenge? Sure things ain't bad if > > they are hard sometimes. Messing with players real time thru such pitiful > > things ain't good either IMO. > > Well, there are certainly shortcuts, eg, get gobs of money, expand your > apartment, and use the teleporters. > > Note that the bigworld goal wasn't to waste player time. But it was to > increase travel time a bit - it never made a lot of sense on the old smallworld > where walking from town to town was only about 3 times longer than walking > across the town itself. This I admit, tho it wasn't a bad thing for sure. Many-many games (some examples: Final Fantasy and co., Baldur's Gate II, Temple of EE, lotsa old good stuff) had the same issue. The idea behind this is, that we now there are interesting places, and ones that are _not_. But we cannot put the interesting places next to each other, it would be against our illusion of reality. So we simply use another scale for by-pass areas, so the feeling would be still ok, and we don't have to suffer boredom while traveling from one "interesting area" to another. But I'm sure it's not a new thing for you either... I understand that the main idea was to make the world something like in Wizardy 8, a continous field of gameplay. But without interesting side-areas and/or random encounters, and with unrecognizable and unmemorizable pathways it's just missed the point IMO. (Tho I've argued this before, I made the mistake not suggesting some solutiona. So here are some: ) - New maps and/with new quests. It would be great, would bring new challanges, new excitement - most important things in any game. (I fear without new maps CF is doomed...) - Rearrange bigworld facade. Like make really memorizable large-sclae landscape features, and put in some neat recognizable obstacles. Like a real map and a real land. With real forests and mountains, swamps, deserts and stuff. In it's current stage it's like a random-generated messed up compound. Even some messages could help orientation. (Like "Before you lies the magnificent Great Drake Mountains. This far-flung highland separates Northwest Coursefall [here could be the name of the World - Coursefall is just an example {Coursefall - CF ;-) }] from the the Eastern Wastelands..." Or something like that, more poetic descriptions could increase the game experience really much.) - Idea of random encounters should be considered. (Random monsters are _not_ good, for it could lead to many low-lvl players' deaths. Random encounter could be things like this: Suddenly you teleport into a small random map area with some random monsters. The maps and monsters could be specific to the area you are at on the world map. And of course the map would have an exit teleporter next to you, so you can flee if you want, and it's good also for players who don't want to deal with too many random encounters... Tho, I'm not sure it's a very good idea. Simple random encounters on simple random maps could be simply annoying. Hmm, maybe some _quests_ could be made which mark you as a player that can recieve certain random or random-like encouters in certain places. Would be a difficoult one to code, I admit. > > But it was a side goal to increase travel times some, so that it was no longer > especially easy to visit every shop out there in 2 minutes flat. while it may > be a bit frustrating at times (I really want a book of XYZ, but this town > doesn't have it), I think that is a reasonable part of the game. Hmm, this sounds reasonable, tho I want to point out, that this is another feature that makes differences beetween low-lvl and high-lvl players deeper. (It much more frustrating for a low-lvl player than for a high-lvl one. And it's not "of course, what do you want man, high-lvl players have easier life, zat bad"! It's that high-lvl players can _advance_(relatively)_)faster_ than low-lvl players... The two things are different!) > > Now I do plan to make changes sometime soon that changes the player speed > model some - players will be less likely to be blindingly fast, but player > minimum speed will also be increased, so that players will no longer move at a > crawl like that sometimes do when heavily loaded (and heavily loaded for a weak > character might not be all that much stuff right now). > > Note that a longer term goal is to add other travel mechanisms (horses, boats, > griffins, etc) that perhaps change travel times. Good idea. (Don't forget about dragons, Qz and Fireborns tho... They could have a new ability at certain lvl, some fast-travel-flying abilty, which stops working whenever you attack somebody or cast a spell.) > > I also wouldn't be all to adverse to adding a 'teleporter shop/guild' - has > teleporters to a few fixed locations (major towns that are normally easy to get > to) for a price - say like 100 pp or something. So you then weight money vs time. It's a good idea, but I wonder when will it be realized. (In fact there is one in Stoneville, the Dragon Hangar. But there should be a teleporter guild _net_, so ma' heart wont stop when I realize, I pushed the apply button on a bed of reality in Navar...) > > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Mon May 17 12:33:27 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:33 2005 Subject: [CF-Devel] faster portgate (context diff) In-Reply-To: References: Message-ID: <40A8F767.5090900@laposte.net> > - New maps and/with new quests. It would be great, would bring new > challanges, new excitement - most important things in any game. (I fear > without new maps CF is doomed...) Yes, so just make some, everyone will benefit from that :) JavaEditor should work on any platform ^_- Note that I committed a few days ago a 'ground positioning system' that lets players know where they are in the world - up to them to write down interesting locations... (should be quest reward, probably, can't yet be found anywhere) Nicolas _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Mon May 17 13:12:21 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:33 2005 Subject: [CF-Devel] faster portgate (context diff) In-Reply-To: <40A8F767.5090900@laposte.net> References: <40A8F767.5090900@laposte.net> Message-ID: <200405171312.21826.eracclists@bellsouth.net> On Monday 17 May 2004 12:33 Nicolas Weeger wrote: > Note that I committed a few days ago a 'ground positioning system' > that lets players know where they are in the world - up to them to > write down interesting locations... > (should be quest reward, probably, can't yet be found anywhere) This is a good idea indeed. However, I don't want to write down all these locations offline. Could players get (buy or find) a Log Book that allows more entries than the limited scrolls and books they can get now? I run into the inscription limitation on a regular basis while writing scrolls to inform guild members of events in the guild. I'm not asking for an unlimited device for recording things. But a new device, specifically a book, that allows recording a significant enough amount of information to be useful. Perhaps a 10K, 25K or 50K limit and some way to determine how much space is left. Hmmm, thinking as I type here ... the scrolling of this text could be a problem I see. So, how about a new container called Binder and Binder of Holding that holds only non-magical scrolls? Thus one could have a collection of scrolls with information on locations, etc. Yes, this can be done with scroll case or whatever. BUT I'd like some way to get the non-magical scrolls into a specific container just for them. For use as a log book and general reference if I so desire. If there is already a way to handle this, other than a scroll case, I obviously don't know it. :-) Gene (poof|Galahad) -- Linux era4.eracc.UUCP 2.4.22-28mdkenterprise i686 12:56:48 up 79 days, 6:51, 12 users, load average: 0.02, 0.04, 0.03 ERA Computer Consulting - http://www.eracc.com/ eCS, OS/2, Mandrake GNU/Linux, OpenServer & UnixWare resellers _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Mon May 17 13:27:46 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:33 2005 Subject: [CF-Devel] faster portgate (context diff) In-Reply-To: <200405171312.21826.eracclists@bellsouth.net> References: <40A8F767.5090900@laposte.net> <200405171312.21826.eracclists@bellsouth.net> Message-ID: <1084818466.15408.14.camel@d5110227.lss.emc.com> On Mon, 2004-05-17 at 14:12, ERACC wrote: > On Monday 17 May 2004 12:33 > Nicolas Weeger wrote: > > > Note that I committed a few days ago a 'ground positioning system' > > that lets players know where they are in the world - up to them to > > write down interesting locations... > > (should be quest reward, probably, can't yet be found anywhere) > > This is a good idea indeed. However, I don't want to write down all > these locations offline. Could players get (buy or find) a Log Book > that allows more entries than the limited scrolls and books they can > get now? I run into the inscription limitation on a regular basis > while writing scrolls to inform guild members of events in the guild. How about an item that can hold one location only. When you are on the same map, a map that is directly tiled with that map, or a world map (if the location is on a world map), then it will tell you exactly how many squares away from the location you are in each direction. Some of these could be found pre-set to a given location, such as the goblin-chief's lair. Blank ones could be set by a player. Not that I'm offering to code it... --PC _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Mon May 17 13:57:24 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:33 2005 Subject: [CF-Devel] faster portgate (context diff) In-Reply-To: <200405171312.21826.eracclists@bellsouth.net> References: <40A8F767.5090900@laposte.net> <200405171312.21826.eracclists@bellsouth.net> Message-ID: <40A90B14.6080609@laposte.net> > This is a good idea indeed. However, I don't want to write down all > these locations offline. Could players get (buy or find) a Log Book > that allows more entries than the limited scrolls and books they can > get now? I run into the inscription limitation on a regular basis > while writing scrolls to inform guild members of events in the guild. Well, as i implemented it, the 'gps' will not give the same position for all players. You must set its origin to use it, and obviously players won't use the same. Granted, it's only a fixed difference in location. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Tue May 18 00:17:02 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:33 2005 Subject: [CF-Devel] faster portgate (context diff) In-Reply-To: <200405171312.21826.eracclists@bellsouth.net> References: <40A8F767.5090900@laposte.net> <200405171312.21826.eracclists@bellsouth.net> Message-ID: <40A99C4E.6060204@sonic.net> ERACC wrote: > On Monday 17 May 2004 12:33 > Nicolas Weeger wrote: > > >>Note that I committed a few days ago a 'ground positioning system' >>that lets players know where they are in the world - up to them to >>write down interesting locations... >>(should be quest reward, probably, can't yet be found anywhere) > > > This is a good idea indeed. However, I don't want to write down all > these locations offline. Could players get (buy or find) a Log Book > that allows more entries than the limited scrolls and books they can > get now? I run into the inscription limitation on a regular basis > while writing scrolls to inform guild members of events in the guild. I'll increase the size of messages the books can hold - there is no real reason for the current limitation. There can be potential issues with messages so long that they don't fit on one screen - the gtk client at least has a scrollbar, so that shouldn't be a problem. But in any case, that is more an issue for those people that are writing the books. > > I'm not asking for an unlimited device for recording things. But a > new device, specifically a book, that allows recording a significant > enough amount of information to be useful. Perhaps a 10K, 25K or 50K > limit and some way to determine how much space is left. I've upped the limit from 800 characters to about 4000. Going beyond that requires a bit more work, as the messages are stored in op->msg, and while I can increase that buf, have to be more certain to catch all the references. > > Hmmm, thinking as I type here ... the scrolling of this text could > be a problem I see. So, how about a new container called Binder and > Binder of Holding that holds only non-magical scrolls? Thus one could > have a collection of scrolls with information on locations, etc. That'd be trivial to done, since it is really just a type of container. I'm not 100% sure if it is possible to limit it to only non magical scrolls/books. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Tue May 18 00:36:31 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:33 2005 Subject: [CF-Devel] faster portgate (context diff) In-Reply-To: References: Message-ID: <40A9A0DF.3010908@sonic.net> Palfy Tamas wrote: > > This I admit, tho it wasn't a bad thing for sure. Many-many games (some > examples: Final Fantasy and co., Baldur's Gate II, Temple of EE, lotsa > old good stuff) had the same issue. The idea behind this is, that we now > there are interesting places, and ones that are _not_. But we cannot > put the interesting places next to each other, it would be against our > illusion of reality. So we simply use another scale for by-pass areas, so > the feeling would be still ok, and we don't have to suffer boredom while > traveling from one "interesting area" to another. But I'm sure it's not a > new thing for you either... > I understand that the main idea was to make the world something like in > Wizardy 8, a continous field of gameplay. But without interesting > side-areas and/or random encounters, and with unrecognizable and > unmemorizable pathways it's just missed the point IMO. (Tho I've argued > this before, I made the mistake not suggesting some solutiona. So > here are some: ) The other problem was that there were getting to be so many maps on the old world maps, they started getting cluttered (eg, a dungeon, ruin, temple, castle, etc, every 5-10 spaces). So things needed to be spread out somewhat, simply so things that should be hard to find can be. > > - New maps and/with new quests. It would be great, would bring new > challanges, new excitement - most important things in any game. (I fear > without new maps CF is doomed...) I agree. I'm uncertain why there aren't more new maps showing up - as said, the java editor runs on any platform, and arguably, this is a less technical task to do compared to coding and so forth. > > - Rearrange bigworld facade. Like make really memorizable large-sclae > landscape features, and put in some neat recognizable obstacles. Like a > real map and a real land. With real forests and mountains, > swamps, deserts and stuff. In it's current stage it's like a > random-generated messed up compound. Even some messages could help > orientation. (Like "Before you lies the magnificent Great Drake Mountains. > This far-flung highland separates Northwest Coursefall [here could be > the name of the World - Coursefall is just an example {Coursefall - CF > ;-) }] from the the Eastern Wastelands..." Or something like that, more > poetic descriptions could increase the game experience really much.) Certainly some rivers could get added to add landmarks. Arguably, more terrain types also, so that you could have multipled forests, but one of jungle, one of connifers, one of oaks, etc. > > - Idea of random encounters should be considered. (Random monsters are > _not_ good, for it could lead to many low-lvl players' deaths. Random > encounter could be things like this: Suddenly you teleport into a small > random map area with some random monsters. The maps and monsters could be > specific to the area you are at on the world map. And of course the map > would have an exit teleporter next to you, so you can flee if you want, > and it's good also for players who don't want to deal with too many random > encounters... Tho, I'm not sure it's a very good idea. Simple random > encounters on simple random maps could be simply annoying. Hmm, maybe > some _quests_ could be made which mark you as a player that can recieve > certain random or random-like encouters in certain places. Would be a > difficoult one to code, I admit. There used to be code that did this. It proved really annoying - you'd be heading west, get tossed onto a random map, and had to find your way out. Even if you place an exit near where the player enters, you get the problem of if you put it in the direction the player is moving, he is probably out of hte map as soon as he enters it. If its not in the same direction, the player, hitting run west or whatever, finds himself 5 spaces from it before he notices he is on a random map. I'd personally rather put the monsters on the world maps. Travel in theory should be dangerous. I personally have two thoughts about how do this: 1) Create spawn spaces - sprinkle these on maps where you want monsters to show up. This, low level areas near towns could be free of these spaces. 2) Add info to the map header about random encounters. Once again, maps near low level areas/cities could be set with no such info. In both cases, I'd put logic in that limits the number of monsters (eg, before monsters are generated, so how many are currently on the map, and if above some threshold, don't make any more). Also perhaps record where the maps where generated, and put in logic so they don't wander too far from home (so nasty players can't lure the monsters next to the town. I'd note that most monsters are pretty slow, relative to players, so in most cases, the players should be able to outrun the monsters. > > >> But it was a side goal to increase travel times some, so that it was no longer >>especially easy to visit every shop out there in 2 minutes flat. while it may >>be a bit frustrating at times (I really want a book of XYZ, but this town >>doesn't have it), I think that is a reasonable part of the game. > > > Hmm, this sounds reasonable, tho I want to point out, that this is another > feature that makes differences beetween low-lvl and high-lvl players > deeper. (It much more frustrating for a low-lvl player than for a > high-lvl one. And it's not "of course, what do you want man, high-lvl > players have easier life, zat bad"! It's that high-lvl players can > _advance_(relatively)_)faster_ than low-lvl players... The two things are > different!) But it is less likely low level players will be hunting for specific objects (simply because there are few rare items that low level players can afford) _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Tue May 18 01:22:16 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:33 2005 Subject: [CF-Devel] Rune & other bugs In-Reply-To: <40A866D3.8050404@laposte.net> References: <40A74643.1060407@laposte.net> <40A83905.6010203@sonic.net> <40A866D3.8050404@laposte.net> Message-ID: <40A9AB98.4070008@sonic.net> Nicolas Weeger wrote: >> IMO, have some spells not work correctly with runes is probably >> perfectly fine. I note that it doesn't appear that you can cast word >> of recall on friends even - it always seems it is a personal spell, >> and as long as that holds true, it won't work. > > > Then if some spells can't be put in runes, we should prevent a player > from doing that :) Probably not worth the effort - as long as there are not bad side effects (eg, crash, gobs of exp, whatever), we should generally let players do whatever they want. There are many things in real life that you can do but is not a smart thing to do (build a bridge out of styrofoam). Yet nothing is preventing you from doing it - I see the same thing as crossfire. > >> The fix here isn't in the rune code, it would be in word of recall - >> if it is modified to look for players in the direction cast, it would >> probably work fine. > > > Hum, then you could have side effects sometimes when you want to cast > wor on yourself, but a friend is in the direction you're looking in :) > Not saying that's bad, just that we'll hafta take care :p Yep - it would change behaviour, although perhaps no different than how the healing spells are now - players would just have to get to casting in direction 0 or whatever. > Oh! lol > I thought confusion was a cone spell, like burning hands & such :p Mass confusion is a cone spell. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Tue May 18 01:43:02 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:33 2005 Subject: [CF-Devel] Patch: new sound proposal In-Reply-To: <40A865F8.1020803@laposte.net> References: <40A5ED9C.6000608@laposte.net> <40A85A61.50503@sonic.net> <40A865F8.1020803@laposte.net> Message-ID: <40A9B076.9000004@sonic.net> Nicolas Weeger wrote: > > Note that this also solves the saving issue, since archetype contains > information - thus only 'special' sounds are saved with object. > And if the archetype's sound ever changes, objects will be updated > automatically if they don't have their own version. But that actually isn't true. Since copy_object() copies the sound information, and since anything that is generated on the map after loading involves copy_object(), all those objects will now have sound information which is the same as the archetype, but because sound_info is now set, will get saved out. That isn't terrible, but is a bit odd. I also do expect it will be desired to clear sound events from the archetype without replacing them (Eg, making a 'quiet' item). _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Tue May 18 02:06:41 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:34 2005 Subject: [CF-Devel] From the board: comet & meteor swarm Message-ID: <40A9B601.3040901@laposte.net> Copied from the message board, since it's about a spell bug ---- Ok, I'm a bit fuzzy on the intended logic here, but, I THINK this is a bug. Comet: Makes a big lasting fire effect. Yet, if ANOTHER comet is cast in the same area, IT DOES NOT PROPAGATE. The 2nd Comet will ONLY propagate if there is a free (no fire spell occupying from the 1st comet) space to expand in. 2 Comets spawning from the same (fire covered) area = 1 comet filling the area it should, and the 2nd filling NOTHING until the first comet expires, then it expands a few squares and ends (appropriate for it's "active" time). Now, let's advance to Meteor Swarm. The same logic from Comet applies still. ONLY the first Meteor (Comet) expands fully. The rest DO NOT propagate at all, until the FIRST one dies off. This makes for ONE "full damage area" attack, and a secondary attack that is, well... useless... like 10x10 at max, and lasts a second or 2. I'm thinking this behavior is not intended. PERHAPS it was meant as a limiting factor for Comet, but the fact that Meteor swarm is a multiple-comet attack and is STILL bound by the same rules, I'm thinking this is a bug/unintended effect. As it stands now, Comet and Meteor Swarm are equal in damage, but one takes MUCH more SP to cast. ---- I guess this is related to how propagation works, no? The 2nd won't move because there is already some fire spell on other squares? Nicolas _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Tue May 18 02:24:00 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:34 2005 Subject: [CF-Devel] Patch: new sound proposal In-Reply-To: <40A9B076.9000004@sonic.net> References: <40A5ED9C.6000608@laposte.net> <40A85A61.50503@sonic.net> <40A865F8.1020803@laposte.net> <40A9B076.9000004@sonic.net> Message-ID: <40A9BA10.1000008@laposte.net> > But that actually isn't true. Since copy_object() copies the sound > information, and since anything that is generated on the map after > loading involves copy_object(), all those objects will now have sound > information which is the same as the archetype, but because sound_info > is now set, will get saved out. That isn't terrible, but is a bit odd. Well, it isn't nice, but soundinfo gets cleared in loader.[lc]. Just after doing a copy_object, there's a free_soundinfo_for_object( tmp ); Actually, the copy in copy_object is there only for the loading of archetypes, i think - since an object is first loaded, then copied as arch.clone, we need to copy sound info at that point. > I also do expect it will be desired to clear sound events from the > archetype without replacing them (Eg, making a 'quiet' item). True, didn't think of that. Well, that can be a 'no_sound' sound :) _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Tue May 18 04:31:18 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:34 2005 Subject: [CF-Devel] Darkness Message-ID: <20040518113118.28616828.scachi@gmx.de> Hello, do you too have these failures in the dark/light areas on you screen ? Look at the screenshot. I think there is something wrong. This looks somehow like a chess board. Or should it be that way ? I am using the gtkclient cvs-version checked out 18.05.2004. It is the same with gtkclient 1.7 Sorry for my bad english. -------------- next part -------------- A non-text attachment was scrubbed... Name: darkness.png Type: application/octet-stream Size: 7993 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20040518/6c35f9b9/darkness.obj -------------- next part -------------- _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Tue May 18 11:07:40 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:34 2005 Subject: =?iso-8859-1?Q?Re:_Re:_[CF-Devel]_faster_portgate_(context_diff)?= Message-ID: > > Hmmm, thinking as I type here ... the scrolling of this text could > > be a problem I see. So, how about a new container called Binder and > > Binder of Holding that holds only non-magical scrolls? Thus one could > > have a collection of scrolls with information on locations, etc. > > That'd be trivial to done, since it is really just a type of container. I'm > not 100% sure if it is possible to limit it to only non magical scrolls/books. > So long as the scroll objects and the container use the same new race field this is real easy to do. Make a scroll object to write notes, in set the race to journal then create a container called a journal with the race set to journal and there you go. The hardest part would be if you wanted to convert some existing notes in maps to the journal race and not others. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Tue May 18 12:06:40 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:34 2005 Subject: [CF-Devel] Firing spells from ranged weapons Message-ID: I've been wanting to make explosive arrows, but couldn't get them to work. After mucking about in the code a bit, I found that it's because only spell-bullets (102) get checked for detonation and suchlike, but if you change the type 13 archs to 102, they aren't ammo any more and you can't fire them in the first place. So, I came up with this. It's rather hackish and probably still has a bug or two left in it, but it doesn't double-remove_ob() any more, at least. If the other_arch field of the shot being fired is blank, it proceeds normally; otherwise, it spawns one of those archetypes and removes the original projectile. Thus, by setting an arrow with, say, other_arch firebullet, you'll be shooting fireballs instead of arrows. And the arrows will be unrecoverable, although this may not always be desireable. The new arch inherits hp/maxhp/dam_modifier/range from the parent ammo, if it has them. There's also a check to make sure that hp doesn't get overwritten by the original value of dam; since we won't be retrieving the missile afterwards, this doesn't really matter. Lastly, there's a check at the end that calls move_bullet rather than move_arrow if the itemtype isn't ARROW - using move_arrow results in odd bugs when firing at point blank range. Oh, and there's no check to see if arch_to_object worked. This is probably very unsafe. I'm not sure if this will work for cone/beam weapons, I haven't looked at the code for those much yet, but something in fire_bow based on (or calling) drop_cone and move_cone will probably be necessary. A sample archetype: Object bolt_fb race crossbow bolts name bolt title Firey Blast type 13 hp 8 maxhp 4 dam_modifier 4 range 10 other_arch firebullet face bolt.101 animation firebullet is_animated 0 is_turnable 1 nrof 1 weight 50 value 2 material 2 food 10 dam 3 wc 2 editable 1024 attacktype 5 name_pl bolts client_type 165 editor_folder arch/weapon/bow end $ diff player.c player.orig.c 1471c1471 < object *left, *bow, *tmp; --- > object *left, *bow; 1540,1566d1539 < < if(arrow->other_arch) { < tmp = arch_to_object(arrow->other_arch); < if(arrow->range) < tmp->range = arrow->range; < if(arrow->stats.hp) < tmp->stats.hp = arrow->stats.hp; < if(arrow->stats.maxhp) < tmp->stats.maxhp = arrow->stats.maxhp; < if(arrow->dam_modifier) < tmp->dam_modifier = arrow->dam_modifier; < free_object(arrow); < arrow = tmp; < } < 1582,1583c1555 < if(!arrow->stats.hp) /* hack so that hp (duration) doesn't get overwritten */ < arrow->stats.hp = arrow->stats.dam; --- > arrow->stats.hp = arrow->stats.dam; 1634,1640c1606,1607 < if (!was_destroyed(arrow, tag)) { < if(arrow->type == ARROW) { < move_arrow(arrow); < } else { < move_bullet(arrow); < } < } --- > if (!was_destroyed(arrow, tag)) > move_arrow(arrow); _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Tue May 18 18:55:06 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:34 2005 Subject: [CF-DEVEL] bug 942581 - BROKEN MONEY In-Reply-To: References: Message-ID: > Feedback from a player on crossfire.metalforge.net They would loose all > their platinum when they would try and purchase items from a shop. > After a server crash earlier (assuming the CVS change went in to effect > after that..) they've confirmed that the bug has been fixed. > > Any one else have an update? Seeing the same thing here, with a 1.6.0 server running locally. I haven't had a chance to put the latest CVS into effect, the server appears to be down. Quite annoying - walk into a shop with 44pp, buy 26pp worth of books and get shop-mugged for all 44. -ToxicFrog _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Tue May 18 23:20:20 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:34 2005 Subject: =?iso-8859-1?Q?Re:_Re:_[CF-DEVEL]_bug_942581_-_BROKEN_MONEY?= Message-ID: This bug concerned with making change was recently fixed (and closed) and is in CVS. > > Feedback from a player on crossfire.metalforge.net They would loose all > > their platinum when they would try and purchase items from a shop. > > After a server crash earlier (assuming the CVS change went in to effect > > after that..) they've confirmed that the bug has been fixed. > > > > Any one else have an update? > > Seeing the same thing here, with a 1.6.0 server running locally. I haven't > had a chance to put the latest CVS into effect, the server appears to be > down. > Quite annoying - walk into a shop with 44pp, buy 26pp worth of books and > get shop-mugged for all 44. > -ToxicFrog _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Tue May 18 12:01:03 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:34 2005 Subject: [CF-Devel] Suspicious code in common/object.c In-Reply-To: <40A83C58.3010304@sonic.net> References: <20040516173308.GA14823@idefix2.dvlp.in-medias-res.com> <40A83C58.3010304@sonic.net> Message-ID: <20040518170103.GA15985@idefix2.dvlp.in-medias-res.com> Commited to CVS. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Wed May 19 12:50:57 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:34 2005 Subject: [CF-Devel] Darkness In-Reply-To: <20040518113118.28616828.scachi@gmx.de> References: <20040518113118.28616828.scachi@gmx.de> Message-ID: <200405191951.08935.tchize@myrealbox.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Problems in the interpolation algorithm. In when i look at code, it's not an interpolation algorithm but an extrapolation using the horizontal and vertical light lines running thru center of squares. So problems at corner (diagonals informtions not used). Will change it to use some bilinear interpolation (should give correct result at good performances) Le mardi 18 Mai 2004 11:31, ScaChi a ?crit : Hello, do you too have these failures in the dark/light areas on you screen ? Look at the screenshot. I think there is something wrong. This looks somehow like a chess board. Or should it be that way ? I am using the gtkclient cvs-version checked out 18.05.2004. It is the same with gtkclient 1.7 Sorry for my bad english. - -- - -- 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAq56IHHGOa1Q2wXwRAsE5AKCotVy4fkhIe2Cbu912t3bv9rzYywCgjOhj ONrqZcBUFlXJHYHxX26i5N8= =RL07 -----END PGP SIGNATURE----- _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Wed May 19 21:12:47 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:34 2005 Subject: [CF-Devel] Icestorm - could not move - death Message-ID: <200405192112.47098.eracclists@bellsouth.net> Greetings Developers, In the Wizard Tower in Lake Country my character Galahad was just killed because the Grand Master's icestorm pushed him into the little hallway at the bottom and he could not move while the cold resist potion wore off. It was not paralyzation as he had +100 against that with the equipment. Is that the desired result? I noticed Galahad being shoved around a lot by icestorm. This is the first time I've ever gone to the Wizard Tower with this character. It is also the first time there since the code changed to where these spells push things. If there was something else I could have done to prepare for this I don't know what it is. Galahad was able to go back and kill it even though all his stats are down, again. Very frustrating that it could not be done the first time because he was trapped by icestorm. :-( Gene (poof|Galahad) -- Linux era4.eracc.UUCP 2.4.22-28mdkenterprise i686 20:12:48 up 81 days, 14:07, 12 users, load average: 0.78, 0.90, 0.88 ERA Computer Consulting - http://www.eracc.com/ eCS, OS/2, Mandrake GNU/Linux, OpenServer & UnixWare resellers _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Thu May 20 00:22:33 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:34 2005 Subject: [CF-Devel] Icestorm - could not move - death In-Reply-To: <200405192112.47098.eracclists@bellsouth.net> References: <200405192112.47098.eracclists@bellsouth.net> Message-ID: <40AC4099.3040901@sonic.net> ERACC wrote: > Greetings Developers, > > In the Wizard Tower in Lake Country my character Galahad was just > killed because the Grand Master's icestorm pushed him into the little > hallway at the bottom and he could not move while the cold resist > potion wore off. It was not paralyzation as he had +100 against that > with the equipment. Is that the desired result? > > I noticed Galahad being shoved around a lot by icestorm. This is the > first time I've ever gone to the Wizard Tower with this character. It > is also the first time there since the code changed to where these > spells push things. If there was something else I could have done to > prepare for this I don't know what it is. > > Galahad was able to go back and kill it even though all his stats are > down, again. Very frustrating that it could not be done the first > time because he was trapped by icestorm. :-( Well, I notice that it is intentional that icestorm does puch the players back. What is probably missing here is that check_spell_knockback doesn't care about the resistances the target may have. I'm thinking that should probably be changed - perhaps the effect of knockback is adjusted based on resistance to the attacktype. But looking at the code, I wonder if the knockback code could get moved into the hit_map or the like - since that already traverses the spaces, looking for objects to damage/destroy, and also processes the resistances, it would seem more efficient to modify hit_map to perhaps take an extra paramter or two to denote hitback effect (or perhaps hit_map can just look at the type/subtype that is passed in on op, and figure it out from there) _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Thu May 20 02:16:05 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:34 2005 Subject: [CF-Devel] Darkness In-Reply-To: <200405191951.08935.tchize@myrealbox.com> References: <20040518113118.28616828.scachi@gmx.de> <200405191951.08935.tchize@myrealbox.com> Message-ID: <40AC5B35.70106@sonic.net> tchize wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Problems in the interpolation algorithm. In when i look at code, it's not > an interpolation algorithm but an extrapolation using the horizontal and > vertical light lines running thru center of squares. So problems at corner > (diagonals informtions not used). > Will change it to use some bilinear interpolation (should give correct result > at good performances) As the person that originally wrote that code... There are lots of problem with trying to interpolate the darkness code. That is because it often isn't set for all the spaces around the spaces you are trying to fill it. The problem is really apparantly for blank spaces. You have no idea if the space is dark, or just empty. One might think you can always treat these empty spaces as completely dark, but then you start to get odd issues relating to things like the edge of the map, or even internall dark areas. Think of something like: DDDDD ----- ..... Where D are blocked (dark) spaces, ----- is the wall, and ..... is visible area. You really don't want to use the D spaces to figure out what the wall should look like (imagine a case where the wall is well illuminate, eg, a light source on each of the . spaces. The real solution is to redo all that code on the client/server. Instead of the client having to try and figure out relative light/darkness of each space, the server could simply say 'these are where the light sources are'. I had sent out mail a little while back about new protocol command to deal with all of that - haven't had time to work on it yet. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Thu May 20 02:20:06 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:34 2005 Subject: [CF-Devel] Patch: new sound proposal In-Reply-To: <40A9BA10.1000008@laposte.net> References: <40A5ED9C.6000608@laposte.net> <40A85A61.50503@sonic.net> <40A865F8.1020803@laposte.net> <40A9B076.9000004@sonic.net> <40A9BA10.1000008@laposte.net> Message-ID: <40AC5C26.2070400@sonic.net> Nicolas Weeger wrote: >> But that actually isn't true. Since copy_object() copies the sound >> information, and since anything that is generated on the map after >> loading involves copy_object(), all those objects will now have sound >> information which is the same as the archetype, but because sound_info >> is now set, will get saved out. That isn't terrible, but is a bit odd. > > > Well, it isn't nice, but soundinfo gets cleared in loader.[lc]. > Just after doing a copy_object, there's a free_soundinfo_for_object( tmp ); > Actually, the copy in copy_object is there only for the loading of > archetypes, i think - since an object is first loaded, then copied as > arch.clone, we need to copy sound info at that point. But I'm thinking of things like generators. Generators have other_arch set. When that monster is created from a generator, the calls that are used to create it will not free the sound information. Same would actually be true for the treasure code for that matter. So the only sound info that is getting cleared is that that is in the map file. All items generated after the fact, unless copies from the map (eg, black puddings perhaps) will have the full sound info, because it won't get freed, so it will get saved out to disk. A better approach than this is really needed. As said previously, it should be pretty easy to add a flag saying 'this sound is unmodified from the archetype, and just points at that sound data' vs a 'this sound is customized'. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Thu May 20 02:29:16 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:34 2005 Subject: [CF-Devel] From the board: comet & meteor swarm In-Reply-To: <40A9B601.3040901@laposte.net> References: <40A9B601.3040901@laposte.net> Message-ID: <40AC5E4C.1030302@sonic.net> Nicolas Weeger wrote: > Copied from the message board, since it's about a spell bug > > ---- > > Ok, I'm a bit fuzzy on the intended logic here, but, I THINK this is a bug. > > Comet: Makes a big lasting fire effect. Yet, if ANOTHER comet is cast in > the same area, IT DOES NOT PROPAGATE. The 2nd Comet will ONLY propagate > if there is a free (no fire spell occupying from the 1st comet) space to > expand in. 2 Comets spawning from the same (fire covered) area = 1 comet > filling the area it should, and the 2nd filling NOTHING until the first > comet expires, then it expands a few squares and ends (appropriate for > it's "active" time). I'll fix this up - its just a problem of the unique spell tag (maxhp) not being set. > > Now, let's advance to Meteor Swarm. The same logic from Comet applies > still. ONLY the first Meteor (Comet) expands fully. The rest DO NOT > propagate at all, until the FIRST one dies off. This makes for ONE "full > damage area" attack, and a secondary attack that is, well... useless... > like 10x10 at max, and lasts a second or 2. Fix should also fix that. > > I'm thinking this behavior is not intended. PERHAPS it was meant as a > limiting factor for Comet, but the fact that Meteor swarm is a > multiple-comet attack and is STILL bound by the same rules, I'm thinking > this is a bug/unintended effect. Its not intended, and the bug currently effects all exploding ball spells. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Thu May 20 09:24:24 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:35 2005 Subject: =?iso-8859-1?Q?Re:_Re:_[CF-Devel]_Icestorm_-_could_not_move_-_death?= Message-ID: The intention of spell knockback was entirely to simulate the force of a moving object based on the weight and force of the object- nothing to do with the attacktype. It takes it's force from the spell level and the spell object weight so it is very tunable (you can have a light windstorm or a nasty cone of bricks or even a cone of light or heavy bricks). This was actually some underused existing code in the cone spell area the only change I made was to polish up the effect a bit and take advantage of the new spell code to assign some weights to different cone objects (like wind, icestorm, fire, water...) to simulate different push effects. I also moved the code out of the cone spell section so it could be reused for other types of spells (like for bolts.) I am not keen on having resistance apply against the effect as it should be a purely physics/weight thing. The resistance would should(does?) apply to the damage sustained but I think that in this case the icestorm worked properly, a high level icestorm would be pretty hard to move around in even if you were cold immune. But that may be a game play issue since there is likely some balanceing to be done to allow higher level characters to manage high level push effects (a high level wave spell is designed to push around titans and stuff so a player would be pretty easily knocked back.) I would rather see either the weights of the spell objects changed, the level multiplier changed or apply modifiers based on either stats or skills (dexerity or strength modifiers, special skills to resist getting pushed or items like 'boots of the spider' or a 'potion of glue foot' that modify your friction). Maybe you will see people looking for heavy things to take with them into the cave of winds. As for moving the code or making it more efficient - I'm all for that. Right now the push calculation is pretty simple too and I think it deserves better but I was worried if it was too complex it would slow things down a lot. > > Greetings Developers, > > > > In the Wizard Tower in Lake Country my character Galahad was just > > killed because the Grand Master's icestorm pushed him into the little > > hallway at the bottom and he could not move while the cold resist > > potion wore off. It was not paralyzation as he had +100 against that > > with the equipment. Is that the desired result? > > > > I noticed Galahad being shoved around a lot by icestorm. This is the > > first time I've ever gone to the Wizard Tower with this character. It > > is also the first time there since the code changed to where these > > spells push things. If there was something else I could have done to > > prepare for this I don't know what it is. > > > > Galahad was able to go back and kill it even though all his stats are > > down, again. Very frustrating that it could not be done the first > > time because he was trapped by icestorm. :-( > > Well, I notice that it is intentional that icestorm does puch the players back. > > What is probably missing here is that check_spell_knockback doesn't care about > the resistances the target may have. I'm thinking that should probably be > changed - perhaps the effect of knockback is adjusted based on resistance to the > attacktype. > > But looking at the code, I wonder if the knockback code could get moved into > the hit_map or the like - since that already traverses the spaces, looking for > objects to damage/destroy, and also processes the resistances, it would seem > more efficient to modify hit_map to perhaps take an extra paramter or two to > denote hitback effect (or perhaps hit_map can just look at the type/subtype that > is passed in on op, and figure it out from there) > _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Thu May 20 15:04:46 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:35 2005 Subject: [CF-Devel] Darkness In-Reply-To: <40AC5B35.70106@sonic.net> References: <20040518113118.28616828.scachi@gmx.de> <200405191951.08935.tchize@myrealbox.com> <40AC5B35.70106@sonic.net> Message-ID: <200405202205.07249.d.delbecq@laposte.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Yeah, getting some issues related to unknown area. I seem to get god results for now, fixing the issue and then will suggest a change. Am pretty sure i can build some fast algorithm which cares of the fact he doesn't know the value of a square. Stay tuned :) Le jeudi 20 Mai 2004 09:16, Mark Wedel a ?crit : tchize wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Problems in the interpolation algorithm. In when i look at code, it's not > an interpolation algorithm but an extrapolation using the horizontal and > vertical light lines running thru center of squares. So problems at corner > (diagonals informtions not used). > Will change it to use some bilinear interpolation (should give correct > result at good performances) As the person that originally wrote that code... There are lots of problem with trying to interpolate the darkness code. That is because it often isn't set for all the spaces around the spaces you are trying to fill it. The problem is really apparantly for blank spaces. You have no idea if the space is dark, or just empty. One might think you can always treat these empty spaces as completely dark, but then you start to get odd issues relating to things like the edge of the map, or even internall dark areas. Think of something like: DDDDD - ----- ..... Where D are blocked (dark) spaces, ----- is the wall, and ..... is visible area. You really don't want to use the D spaces to figure out what the wall should look like (imagine a case where the wall is well illuminate, eg, a light source on each of the . spaces. The real solution is to redo all that code on the client/server. Instead of the client having to try and figure out relative light/darkness of each space, the server could simply say 'these are where the light sources are'. I had sent out mail a little while back about new protocol command to deal with all of that - haven't had time to work on it yet. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel - -- - -- David Delbecq d.delbecq@laposte.net 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFArQ9lHHGOa1Q2wXwRAgvZAKCdDfAPho6NAUMXskIZeTgI9webfACfXE6d jJBCngt7vmFunyr8jUjrNTA= =asHu -----END PGP SIGNATURE----- _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Thu May 20 22:41:41 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:35 2005 Subject: [CF-Devel] Scorn Sale Shop - big world Message-ID: <200405202241.41892.eracclists@bellsouth.net> Hi all, I just created a shop for Scorn similar to the one in Santo Dominion where players can drop items and they will stay in the shop for other players to buy. I also updated world/world_105_115 to include this shop on the Scorn maps near the square. Hopefully players will drop items in this shop instead of cluttering up the square. I play tested this on a localhost server running CVS downloaded this afternoon. It seems to work fine. If it can be included in the CVS with big world that would be great. I do not know how to do a diff so I zipped the maps and put them on our web site here: http://www.eracc.com/files/scorn_sale_shop.zip Would be wonderful to see this on metalforge soon. I enjoyed creating it. :-) Gene (poof|Galahad) -- Linux era4.eracc.UUCP 2.4.22-28mdkenterprise i686 22:34:53 up 82 days, 16:29, 12 users, load average: 0.30, 0.09, 0.02 ERA Computer Consulting - http://www.eracc.com/ eCS, OS/2, Mandrake GNU/Linux, OpenServer & UnixWare resellers _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Fri May 21 06:57:39 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:35 2005 Subject: [CF-Devel] Bug ? Automatic Pickup of Arrows and Client crash Message-ID: <20040521135739.66f62e94.scachi@gmx.de> Hello, I think this is a bug, and maybe this crashes my linux gcfclient so often. When my Character (Thagore) get hit by an arrow he automatically picks the arrow up (I have disabled automatic pickup in the Options). As mentioned above, my gcfclient crashes a lot. I use the cvs gcfclient checked out 18.05.2004. Crashes means: The client freezes. I can't walk, fight, do anything in the client. I even can't close it by clicking on the x on the window. Only "kill" helps. I don't think that this is a connection problem since I have a dsl 768/128bps connection and when I ping the server during play I have a ping of 160ms with no packet loss. No packet loss when the client crashes, too. Another problem I have is with the map box. When I start the gcfclient the map box is positioned at the bottom of the client, so I can't see the hitpoints, mana... and the resistances box. Map height and width is set to 18. I have to move the map box to the right position every time I start the client. Maybe you have some hints how I can locate the problem with my client. I don't know how to use a debugger. I started the client through ddd /gdb once and when the client crashed and I killed the client the debugger told me: Program received signal SIGINT, Interrupt. 0x40487078 in write () from /lib/libc.so.6 I don't know if that is any help. -- Thagore _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Tue May 18 12:05:41 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:35 2005 Subject: [CF-Devel] Re: Possible item price bug In-Reply-To: <40875506.60108@sonic.net> References: <20040415192832.GA27496@idefix2.dvlp.in-medias-res.com> <20040421155818.GA32337@idefix2.dvlp.in-medias-res.com> <40875506.60108@sonic.net> Message-ID: <20040518170541.GA24110@idefix2.dvlp.in-medias-res.com> Mark Wedel wrote: > Well, at least having a #define at the top of shop.c isn't a bad idea > instead of it just being harcoded in the code itself. I did not like to introduce this #define PRICE_LIMIT because it would not work very well with the current function. Therefore I searched for an appropriate function to use and got: val = (PRICE_LIMIT-200)+20*isqrt(x-(PRICE_LIMIT-100)) (For values x>PRICE_LIMIT and "val = x" for x Message-ID: Applying resistance against pushback effect of certain attack type may not be logic, BUT there are things to be considered before applying such changes in the game. (Mah God, why is it _not_ obvious...?) First of all, the balance. "Would my change endanger the balance in the game?" "Is it fair considering the current settings and features?" Like, there are already lotsa bad effects in the game that can be applied on players. Paralysis, confusion, fear, etc. You came up with another, then someone will think "oh, I too have a good idea, how to make players life much worse" and so on. What you _didn't_ do is thinking about a solution to _counter_ this effect. (I thought it's obvious - I make up a new thing, I also think about it's consequences and make sure that it's harmful (side)effects can be taken care of. Why is it so hard to make decisions _with_ responsibility?) Currently I know no spell, item, resistance or any other thing available to help a player against pushback. (Except being overloaded, but I hope it's not only me who thinks it's ridiculous.) And icestorm is not one of the rarest thing. And this pushback is just like fear, but you still cannot do anything when cornered. It's _insane_. Inventing such new effects should be done with care anyway. Consider the fact that players have limited item slots. It's not fair adding new bad effects while leaving them with the ability to defend themselves only against a few of them. For this pushback I could think about a spell (like a resistance spell), it could be called like "aerodinamic shield", it makes the wind and such move around you, weakening the pushback effect. Xenon _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Fri May 21 12:56:21 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:35 2005 Subject: [CF-Devel] Bug ? Automatic Pickup of Arrows and Client crash In-Reply-To: <20040521135739.66f62e94.scachi@gmx.de> References: <20040521135739.66f62e94.scachi@gmx.de> Message-ID: <200405211956.30412.tchize@myrealbox.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 3 things: 1) client freeze: Try to deisable sound. When soundserver hangs, the pipe with client start filling and in the end the client is waiting for pipe to empty. Should fix it in the more or less near future 2) map area location: Put everything you want at the place you want it. Then go to thce client menu, there is somewhere something named 'save windows position'. Activate it, quit, rerun client. Things should be magically at the good place (thanks gtk, nothing to do with client implementation i think :) 3) gdb: To get help with you gdb, when you gdb does give you a prompt (after the kill), type 'bt' this will do a backtrace. This is far more usefull thant the C function in which kill was invoked (please not as this is wrtie this may be a write to the pipe to soundserv :) ) The output of client in console may be usefull too (messages from soundserver are send there) 4) Have a nice day! Le vendredi 21 Mai 2004 13:57, ScaChi a ?crit : Hello, I think this is a bug, and maybe this crashes my linux gcfclient so often. When my Character (Thagore) get hit by an arrow he automatically picks the arrow up (I have disabled automatic pickup in the Options). As mentioned above, my gcfclient crashes a lot. I use the cvs gcfclient checked out 18.05.2004. Crashes means: The client freezes. I can't walk, fight, do anything in the client. I even can't close it by clicking on the x on the window. Only "kill" helps. I don't think that this is a connection problem since I have a dsl 768/128bps connection and when I ping the server during play I have a ping of 160ms with no packet loss. No packet loss when the client crashes, too. Another problem I have is with the map box. When I start the gcfclient the map box is positioned at the bottom of the client, so I can't see the hitpoints, mana... and the resistances box. Map height and width is set to 18. I have to move the map box to the right position every time I start the client. Maybe you have some hints how I can locate the problem with my client. I don't know how to use a debugger. I started the client through ddd /gdb once and when the client crashed and I killed the client the debugger told me: Program received signal SIGINT, Interrupt. 0x40487078 in write () from /lib/libc.so.6 I don't know if that is any help. - -- - -- 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFArkLLHHGOa1Q2wXwRAooWAKC8kV9wP1zk5QLmbQ0Z9rCo6tMKQwCgzEV/ Zn1sV7Fqsh2MWFaYdDfcsjI= =8JlF -----END PGP SIGNATURE----- _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Fri May 21 16:08:02 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:35 2005 Subject: [CF-Devel] Bug ? Automatic Pickup of Arrows and Client crash In-Reply-To: <200405211956.30412.tchize@myrealbox.com> References: <20040521135739.66f62e94.scachi@gmx.de> <200405211956.30412.tchize@myrealbox.com> Message-ID: <20040521230802.7cfaa6be.scachi@gmx.de> Thank you Tchize, Client crashs: I disabled the sound and the client doesn't crash anymore. Map area location: Okay, the save position option worked. Didn't see that because I searched before in the "Client" Configure option. But the option is actually located in "File". Pickup-Bug: It looks like my character collect everything thrown at him not only arrows. I checked that together with another player called "Magus": you pickup everything thrown at you, when the weight isn't to much for your character to carry. -- Thagore _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Fri May 21 16:31:16 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:35 2005 Subject: [CF-Devel] Bug ? Automatic Pickup of Arrows and Client crash In-Reply-To: <20040521230802.7cfaa6be.scachi@gmx.de> References: <20040521135739.66f62e94.scachi@gmx.de> <200405211956.30412.tchize@myrealbox.com> <20040521230802.7cfaa6be.scachi@gmx.de> Message-ID: <200405212331.21991.tchize@myrealbox.com> Skipped content of type multipart/signed-------------- next part -------------- _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Fri May 21 16:44:51 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:35 2005 Subject: [CF-Devel] Bug ? Automatic Pickup of Arrows and Client crash In-Reply-To: <20040521230802.7cfaa6be.scachi@gmx.de> References: <20040521135739.66f62e94.scachi@gmx.de> <200405211956.30412.tchize@myrealbox.com> <20040521230802.7cfaa6be.scachi@gmx.de> Message-ID: >From what I have observed, a thrown object that hits you ends up in your inventory. Or, are you using the NEWPickup capability in the GTK client? On Fri, 21 May 2004, ScaChi wrote: > Pickup-Bug: > It looks like my character collect everything thrown at him not only > arrows. > I checked that together with another player called "Magus": > you pickup everything thrown at you, when the weight isn't to much > for your character to carry. > > -- _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Fri May 21 17:19:33 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:35 2005 Subject: [CF-Devel] Bug ? Automatic Pickup of Arrows and Client crash In-Reply-To: References: <20040521135739.66f62e94.scachi@gmx.de> <200405211956.30412.tchize@myrealbox.com> <20040521230802.7cfaa6be.scachi@gmx.de> Message-ID: <20040522001933.6492dc21.scachi@gmx.de> > From what I have observed, a thrown object that hits you ends up in your > inventory. That is exactly what I tried to say. > Or, are you using the NEWPickup capability in the GTK client? No, both automatic pickup functions are disabled. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Sat May 22 11:33:44 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:36 2005 Subject: [CF-Devel] Darkness In-Reply-To: <20040518113118.28616828.scachi@gmx.de> References: <20040518113118.28616828.scachi@gmx.de> Message-ID: <200405221833.49350.d.delbecq@laposte.net> Skipped content of type multipart/signed-------------- next part -------------- _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Sat May 22 15:02:20 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:36 2005 Subject: [CF-Devel] Fog Of War code in Gtk Message-ID: <200405222202.26633.tchize@myrealbox.com> Skipped content of type multipart/signed-------------- next part -------------- _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Sat May 22 18:09:03 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:36 2005 Subject: =?iso-8859-1?Q?Re:_[CF-Devel]_Fog_Of_War_code_in_Gtk?= Message-ID: > Currently, the gtk client fog of war code behaviour (at least with sdl) is to > display a light grey version of the invisible squares. However, to be honest, > i don't like it. It's always either too dark or too light and it's a bit > confusing IMO when dealing with darness. > I agree it is confusing, I can't stand the light grey - it is counter intuitive. In the past I suggested making it a much darker grey. It would be lovely to have fog of war remove all 'object' items from the display as well - just leaving landscape features, but just changing the colour to a really dark grey would get the point across anyway I think. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Sun May 23 03:22:13 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:36 2005 Subject: [CF-Devel] throwing bombs... Message-ID: <20040523052213.0e5e99bd.kstenger@montevideo.com.uy> hi all, som players just reported to me and showed me some bombs they had just thrown away right after casting them, the strange thing was they wouldnt blow up like they should. Examining them and comparing to a fresh newly casted bomb's dump i found out differences that appear to be added by the throwing items code. fresh new bomb: arch bomb name bomb name_pl bomb skill pyromancy other_arch explosion face bomb.112 animation bomb dam 13 x 12 y 31 speed 0.200000 speed_left -0.500000 type 102 subtype 8 attacktype 1 weight 4000 state 2 duration 8 range 5 is_animated 1 end not working bomb: arch bomb name bomb name_pl bomb skill throwing <--- other_arch explosion face bomb.111 animation bomb food 7 <--- dam 1 wc 12 <--- x 10 y 31 speed 0.100000 speed_left -0.600000 direction 5 type 48 <---------------- subtype 8 attacktype 1 weight 4000 last_sp 12 duration 8 range 5 walk_on 1 is_animated 1 flying 1 fly_on 1 end marked with "<---" the differences as you can see, the skill's name made me see what was going on, and the type of the bomb was concluding when i changed it back to 102 and it blowed up after a few seconds. I'm sure this change is intended so the thrown object gives xp when hitting a monster to the throwing skill, but maybe there should be a special case for bombs or some other idea about it that makes this dangerous sport a bit more interesting :D Until next time :) -- +-----------------------------+ | Karla M? Stenger S?bat | | Pando . Canelones . Uruguay | | kstenger@montevideo.com.uy | +-----------------------------+ _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Sun May 23 11:02:38 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:36 2005 Subject: [CF-Devel] bugs Message-ID: <1085328158.24277.8.camel@myth.crowcastle.com> Several minor bugs: When I use the "skills" command, for each skill it lists the current xp, xp for the next level, and a percentage. The percentage is always 0%. I thought it was supposed to be the percentage of the way through the current level (e.g., at 1000xp, you are 50% of the way to 2nd level). The spellbook names are all singular possessive except for the "summoners's" spellbooks. For consistency, they should be "summoner's" spellbooks. I've seen at least one map with a fire chest that used to shoot out fireballs shooting out magic bullets instead. (The tower near the department store has an example--I'll find the map name if someone requests it.) Spellbooks seem to have the wrong spells. At the end of the CTower quest, it's just a random spellbook. I think this is the same bug that is causing spellbooks to change spells in your apartment and not stack properly (they have different values). --PC _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Sun May 23 16:25:22 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:36 2005 Subject: [CF-Devel] throwing bombs... In-Reply-To: <20040523052213.0e5e99bd.kstenger@montevideo.com.uy> References: <20040523052213.0e5e99bd.kstenger@montevideo.com.uy> Message-ID: <20040523232522.186d2504.scachi@gmx.de> On Sun, 23 May 2004 05:22:13 -0300 Karla Stenger wrote: > hi all, > som players just reported to me and showed me some bombs they had just thrown > away right after casting them, the strange thing was they wouldnt blow up like > they should. Examining them and comparing to a fresh newly casted bomb's dump i > found out differences that appear to be added by the throwing items code. I 've thrown some bombs too. The bombs always exploded, but the bomb image remains where it exploded. When the bomb is thrown at an enemy (only tested it with Goblins) the enemy picks it up. It's funny. You see them pick it up, walk a bit and ... *kaboom. It's hard that this can happen to you too. Maybe we should all bind a key "throw bomb", for the case you get a bomb thrown at you by your party members by accident :) _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Mon May 24 02:25:30 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:36 2005 Subject: [CF-Devel] Patch: new sound proposal In-Reply-To: <40AC5C26.2070400@sonic.net> References: <40A5ED9C.6000608@laposte.net> <40A85A61.50503@sonic.net> <40A865F8.1020803@laposte.net> <40A9B076.9000004@sonic.net> <40A9BA10.1000008@laposte.net> <40AC5C26.2070400@sonic.net> Message-ID: <40B1A36A.7050903@laposte.net> > But I'm thinking of things like generators. Generators have other_arch > set. When that monster is created from a generator, the calls that are > used to create it will not free the sound information. > > Same would actually be true for the treasure code for that matter. So > the only sound info that is getting cleared is that that is in the map > file. All items generated after the fact, unless copies from the map > (eg, black puddings perhaps) will have the full sound info, because it > won't get freed, so it will get saved out to disk. > > A better approach than this is really needed. As said previously, it > should be pretty easy to add a flag saying 'this sound is unmodified > from the archetype, and just points at that sound data' vs a 'this sound > is customized'. Didn't think of generators - my mistake. Guess i'll hafta go back to design board :p _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Mon May 24 06:31:12 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:36 2005 Subject: [CF-Devel] Icestorm - could not move - death References: Message-ID: <004001c44182$a1431ae0$0100000a@archaios> I agree. The new effect of icestorm, &c. that *moves* objects is utterly ridiculous: in real life, would one expect an 'ice storm' to actually push a great distance? I think not. Same for 'burning hands', et al and all the other area spells that have been negatively affected. -archaios ----- Original Message ----- From: "Palfy Tamas" To: Sent: Friday, May 21, 2004 7:36 PM Subject: Re: Re: Re: [CF-Devel] Icestorm - could not move - death > > > Applying resistance against pushback effect of certain attack type may not > be logic, BUT there are things to be considered before applying such > changes in the game. (Mah God, why is it _not_ obvious...?) > First of all, the balance. "Would my change endanger the balance in the > game?" "Is it fair considering the current settings and features?" > > Like, there are already lotsa bad effects in the game that can be applied > on players. Paralysis, confusion, fear, etc. You came up with another, > then someone will think "oh, I too have a good idea, how to make players > life much worse" and so on. What you _didn't_ do is thinking about a > solution to _counter_ this effect. (I thought it's obvious - I make up > a new thing, I also think about it's consequences and make sure that > it's harmful (side)effects can be taken care of. Why is it so hard to > make decisions _with_ responsibility?) Currently I know no spell, item, > resistance or any other thing available to help a player against > pushback. (Except being overloaded, but I hope it's not only me who > thinks it's ridiculous.) And icestorm is not one of the rarest thing. And > this pushback is just like fear, but you still cannot do anything when > cornered. It's _insane_. > > Inventing such new effects should be done with care anyway. Consider the > fact that players have limited item slots. It's not fair adding new bad > effects while leaving them with the ability to defend themselves only > against a few of them. > > For this pushback I could think about a spell (like a resistance spell), > it could be called like "aerodinamic shield", it makes the wind and such > move around you, weakening the pushback effect. > > Xenon > > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Mon May 24 06:37:58 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:36 2005 Subject: [CF-Devel] Scorn Sale Shop - big world References: <200405202241.41892.eracclists@bellsouth.net> Message-ID: <005501c44183$90421e70$0100000a@archaios> This won't work. Why? Because items are left in the square so other players can *freely* use them - for free. Payment is completely beside the point. -archaios ----- Original Message ----- From: "ERACC" To: Sent: Friday, May 21, 2004 1:41 PM Subject: [CF-Devel] Scorn Sale Shop - big world > Hi all, > > I just created a shop for Scorn similar to the one in Santo Dominion > where players can drop items and they will stay in the shop for other > players to buy. I also updated world/world_105_115 to include this > shop on the Scorn maps near the square. Hopefully players will drop > items in this shop instead of cluttering up the square. > > I play tested this on a localhost server running CVS downloaded this > afternoon. It seems to work fine. If it can be included in the CVS > with big world that would be great. > > I do not know how to do a diff so I zipped the maps and put them on > our web site here: > > http://www.eracc.com/files/scorn_sale_shop.zip > > Would be wonderful to see this on metalforge soon. I enjoyed creating > it. :-) > > Gene (poof|Galahad) > -- > Linux era4.eracc.UUCP 2.4.22-28mdkenterprise i686 > 22:34:53 up 82 days, 16:29, 12 users, load average: 0.30, 0.09, 0.02 > ERA Computer Consulting - http://www.eracc.com/ > eCS, OS/2, Mandrake GNU/Linux, OpenServer & UnixWare resellers > > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Mon May 24 06:45:32 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:36 2005 Subject: [CF-Devel] remove curse spell broken References: <1084124008.29597.11.camel@d5110227.lss.emc.com> <40A07891.30704@sonic.net> Message-ID: <009601c44184$9ef01840$0100000a@archaios> On a related note, why doesn't remove curse/remove damned work on items that are not applied, a la praying at an altar? This would be far more useful behaviour. -archaios ----- Original Message ----- From: "Mark Wedel" To: Sent: Tuesday, May 11, 2004 4:54 PM Subject: Re: [CF-Devel] remove curse spell broken > Preston Crow wrote: > > I applied a cursed ring, and then cast "remove curse." It told me that > > I do not have any cursed items applied, and didn't remove the curse. > > I just tried this, and it worked as expected. > > Are you sure the item wasn't damned? In that case, remove_curse won't do > anything with it. > > > > > Also, I noticed that it did use the mana points. It used to be that > > when spells like identify, remove curse, disarm, and consecrate were > > unable to do anything, they didn't use up spell/mana points. Was that > > an intentional change, or an oversight? Similarly, when a prayer fails, > > it doesn't cost any mana points, whereas it used to randomly charge > > points; again, was that intentional? > > It is intentional that all spells, when you cast them, such the mana/grace > points, whether or not the spell in fact does anything. It makes the code a bit > simpler, but arguable makes more sense (you are still casting the spell). One > could argue if that wasn't the case, things like healing should only cost the > points if they heal someone, etc. > > In terms of spell failure not costing points, I'll fix that up. > > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Mon May 24 07:08:42 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:36 2005 Subject: [CF-Devel] remove curse spell broken In-Reply-To: <009601c44184$9ef01840$0100000a@archaios> References: <1084124008.29597.11.camel@d5110227.lss.emc.com> <40A07891.30704@sonic.net> <009601c44184$9ef01840$0100000a@archaios> Message-ID: <40B1E5CA.5000708@laposte.net> David McIlwraith wrote: > On a related note, why doesn't remove curse/remove damned work on items that > are not applied, a la praying at an altar? This would be far more useful > behaviour. That's how it works. And that's actually pretty right, considering what 'curse' means: can't remove once applied. So well, remove curse obviously can't work for non applied items :) And the 'remove curse from non cursed items' is a god present, so it shouldn't be easy to get when not praying... Nicolas _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Mon May 24 10:46:21 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:36 2005 Subject: [CF-Devel] Icestorm - could not move - death In-Reply-To: <004001c44182$a1431ae0$0100000a@archaios> References: <004001c44182$a1431ae0$0100000a@archaios> Message-ID: <1085413581.2909.19.camel@oberon.kameria> In real-life (if it even matters) heavy winds cause damage to property every day - even to the point to tearing the roof off of buildings and flipping over vehicles so I don't see how it is such a ridiculous notion - let alone an 'utterly ridiculous' one. I have been out in a moderate blizzard and believe me it is hard to move, hard to see and hard to do anything while the freezing wind and snow whips past. As for fire - even excluding the heat that much air moving is certainly a force to be considered. More unusual is that in the game they do *not* push objects IMHO. Anyway I removed the weights from icestorm and firebreath/burning hands so they will not use the knockback effect. Windstorm I have left alone as it *always* used this code in the past and the new wave spell I have also left alone since no existing maps use it. As I said before the knockback effect was not new. Perhaps the move object function is highlighting the problem however in that it appears to have an paralyzing effect on players in addition to pushing them. Anyway my mistake was to apply weights to incorporate a new effect in some existing spells and I have corrected that in CVS. On Mon, 2004-05-24 at 07:31, David McIlwraith wrote: > I agree. The new effect of icestorm, &c. that *moves* objects is utterly > ridiculous: in real life, would one expect an 'ice storm' to actually push a > great distance? > > I think not. Same for 'burning hands', et al and all the other area spells > that have been negatively affected. > > -archaios _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Mon May 24 11:56:14 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:36 2005 Subject: [CF-Devel] Scorn Sale Shop - big world In-Reply-To: <005501c44183$90421e70$0100000a@archaios> References: <200405202241.41892.eracclists@bellsouth.net> <005501c44183$90421e70$0100000a@archaios> Message-ID: <200405241156.14304.eracclists@bellsouth.net> On Monday 24 May 2004 06:37 David McIlwraith wrote: > ----- Original Message ----- > From: "ERACC" > To: > Sent: Friday, May 21, 2004 1:41 PM > Subject: [CF-Devel] Scorn Sale Shop - big world > > > Hi all, > > > > I just created a shop for Scorn similar to the one in Santo > > Dominion where players can drop items and they will stay in the > > shop for other players to buy. I also updated world/world_105_115 > > to include this shop on the Scorn maps near the square. Hopefully > > players will drop items in this shop instead of cluttering up the > > square. [...] > > http://www.eracc.com/files/scorn_sale_shop.zip [...] > This won't work. Why? Because items are left in the square so other > players can *freely* use them - for free. Payment is completely > beside the point. > > -archaios I respectfully disagree. :-) Actually, there is a large, three tile wide corridor in the store entrance that is large enough to accommodate "free" stuff. If people on this list will playtest it and suggest needed changes, if any, to make it more attractive to drop items I will be glad to make the changes. Hmmm, I suppose I could make the corridor 5 tiles wide and add "charity tables" in the corridor to give a hint to players to use the corridor for "freebie" items. I think I'll do that, add a sign about it and overwrite that file on the web site. Stay tuned ... Gene (poof|Galahad) -- Linux era4.eracc.UUCP 2.4.22-28mdkenterprise i686 11:44:21 up 86 days, 5:39, 12 users, load average: 0.06, 0.05, 0.02 ERA Computer Consulting - http://www.eracc.com/ eCS, OS/2, Mandrake GNU/Linux, OpenServer & UnixWare resellers _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Mon May 24 12:05:17 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:37 2005 Subject: [CF-Devel] Icestorm - could not move - death In-Reply-To: <1085413581.2909.19.camel@oberon.kameria> References: <004001c44182$a1431ae0$0100000a@archaios> <1085413581.2909.19.camel@oberon.kameria> Message-ID: <200405241205.17183.eracclists@bellsouth.net> On Monday 24 May 2004 10:46 Todd Mitchell wrote: > In real-life (if it even matters) heavy winds cause damage to > property every day - even to the point to tearing the roof off of > buildings and flipping over vehicles so I don't see how it is such > a ridiculous notion - let alone an 'utterly ridiculous' one. I > have been out in a moderate blizzard and believe me it is hard to > move, hard to see and hard to do anything while the freezing wind > and snow whips past. As for fire - even excluding the heat that > much air moving is certainly a force to be considered. More unusual > is that in the game they do *not* push objects IMHO. Anyway I > removed the weights from icestorm and firebreath/burning hands so > they will not use the knockback effect. Windstorm I have left > alone as it *always* used this code in the past and the new wave > spell I have also left alone since no existing maps use it. > As I said before the knockback effect was not new. Perhaps the > move object function is highlighting the problem however in that it > appears to have an paralyzing effect on players in addition to > pushing them. Anyway my mistake was to apply weights to incorporate > a new effect in some existing spells and I have corrected that in > CVS. Actually, I don't have a problem with the effect itself. I have a problem with the fact there are no countermeasures that I can find for it. The idea of these spells pushing players around is not bad. What IS bad is that players have no way to counter it. Someone suggested a new spell to counter pushback. For non-magic players some sort of magic footgear or a magic cloak or an amulet or all the above that counters pushback would be cool. For now, since there is no way to counteract the effect, I agree it should not be there. But if changes could be made to magically reduce or annul the pushback with a spell or item(s) I'd have no objection to having it in the game. It would add another level of challenge. Gene (poof|Galahad) -- Linux era4.eracc.UUCP 2.4.22-28mdkenterprise i686 11:57:42 up 86 days, 5:52, 12 users, load average: 0.07, 0.06, 0.01 ERA Computer Consulting - http://www.eracc.com/ eCS, OS/2, Mandrake GNU/Linux, OpenServer & UnixWare resellers _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Mon May 24 12:36:07 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:37 2005 Subject: [CF-Devel] Scorn Sale Shop - big world In-Reply-To: <200405241156.14304.eracclists@bellsouth.net> References: <200405202241.41892.eracclists@bellsouth.net> <005501c44183$90421e70$0100000a@archaios> <200405241156.14304.eracclists@bellsouth.net> Message-ID: <200405241236.07330.eracclists@bellsouth.net> Hi all, The Scorn Sale Shop has been updated with a larger entryway, a sign about charity and Charity Tables: http://www.eracc.com/files/scorn_sale_shop.zip Playtesting it here it all works fine. Please download and playtest these two maps. One is an update to /world/world_105_115 to add the shop near Scorn Square. The other is the shop map itself which goes in as /scorn/misc/scorn.sale. Constructive positive (or negative) feedback is welcome and desired. Gene (poof|Galahad) -- Linux era4.eracc.UUCP 2.4.22-28mdkenterprise i686 12:29:02 up 86 days, 6:24, 12 users, load average: 0.08, 0.10, 0.08 ERA Computer Consulting - http://www.eracc.com/ eCS, OS/2, Mandrake GNU/Linux, OpenServer & UnixWare resellers _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Mon May 24 12:42:41 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:37 2005 Subject: [CF-Devel] Scorn Sale Shop - big world In-Reply-To: <200405241156.14304.eracclists@bellsouth.net> References: <200405202241.41892.eracclists@bellsouth.net> <005501c44183$90421e70$0100000a@archaios> <200405241156.14304.eracclists@bellsouth.net> Message-ID: <1085420560.3314.6.camel@oberon.kameria> Could you map this shop to the building in the south of Scorn (the newbie area) on map world_105_116 x11 y2 instead of having it right off of town square? I would prefer to spread things out a tiny bit more than has been done in the past, and this area in southern Scorn is a 'newbie zone' so it makes sense to put the shop here. The building also matches the scale a bit better IMHO. Just my 2sp anyway. On Mon, 2004-05-24 at 12:56, ERACC wrote: > On Monday 24 May 2004 06:37 > David McIlwraith wrote: > > > ----- Original Message ----- > > From: "ERACC" > > To: > > Sent: Friday, May 21, 2004 1:41 PM > > Subject: [CF-Devel] Scorn Sale Shop - big world > > > > > Hi all, > > > > > > I just created a shop for Scorn similar to the one in Santo > > > Dominion where players can drop items and they will stay in the > > > shop for other players to buy. I also updated world/world_105_115 > > > to include this shop on the Scorn maps near the square. Hopefully > > > players will drop items in this shop instead of cluttering up the > > > square. > [...] > > > http://www.eracc.com/files/scorn_sale_shop.zip > [...] > > This won't work. Why? Because items are left in the square so other > > players can *freely* use them - for free. Payment is completely > > beside the point. > > > > -archaios > > I respectfully disagree. :-) > > Actually, there is a large, three tile wide corridor in the store > entrance that is large enough to accommodate "free" stuff. If people > on this list will playtest it and suggest needed changes, if any, to > make it more attractive to drop items I will be glad to make the > changes. > > Hmmm, I suppose I could make the corridor 5 tiles wide and add > "charity tables" in the corridor to give a hint to players to use the > corridor for "freebie" items. I think I'll do that, add a sign about > it and overwrite that file on the web site. Stay tuned ... > > Gene (poof|Galahad) _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Mon May 24 12:47:20 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:37 2005 Subject: [CF-Devel] Icestorm - could not move - death References: <004001c44182$a1431ae0$0100000a@archaios><1085413581.2909.19.camel@oberon.kameria> <200405241205.17183.eracclists@bellsouth.net> Message-ID: <012301c441b7$2c7ee1f0$8024a2cd@YUANC8000> I could definitely see something like a highly-coveted "Amulet of Free Action" that would ignore all pushbacks. :) It would be nice to see a spell of the same make that has a VERY LIMITED duration. Monsters w/ breath attacks and the like would quickly become deadly to fight for those without the ability to ignore pushbacks and make Crossfire more interesting overall. ----- Original Message ----- From: "ERACC" To: Sent: Monday, May 24, 2004 12:05 PM Subject: Re: [CF-Devel] Icestorm - could not move - death > On Monday 24 May 2004 10:46 > Todd Mitchell wrote: > > > In real-life (if it even matters) heavy winds cause damage to > > property every day - even to the point to tearing the roof off of > > buildings and flipping over vehicles so I don't see how it is such > > a ridiculous notion - let alone an 'utterly ridiculous' one. I > > have been out in a moderate blizzard and believe me it is hard to > > move, hard to see and hard to do anything while the freezing wind > > and snow whips past. As for fire - even excluding the heat that > > much air moving is certainly a force to be considered. More unusual > > is that in the game they do *not* push objects IMHO. Anyway I > > removed the weights from icestorm and firebreath/burning hands so > > they will not use the knockback effect. Windstorm I have left > > alone as it *always* used this code in the past and the new wave > > spell I have also left alone since no existing maps use it. > > As I said before the knockback effect was not new. Perhaps the > > move object function is highlighting the problem however in that it > > appears to have an paralyzing effect on players in addition to > > pushing them. Anyway my mistake was to apply weights to incorporate > > a new effect in some existing spells and I have corrected that in > > CVS. > > Actually, I don't have a problem with the effect itself. I have a > problem with the fact there are no countermeasures that I can find > for it. The idea of these spells pushing players around is not bad. > What IS bad is that players have no way to counter it. > > Someone suggested a new spell to counter pushback. For non-magic > players some sort of magic footgear or a magic cloak or an amulet > or all the above that counters pushback would be cool. > > For now, since there is no way to counteract the effect, I agree it > should not be there. But if changes could be made to magically reduce > or annul the pushback with a spell or item(s) I'd have no objection > to having it in the game. It would add another level of challenge. > > Gene (poof|Galahad) > -- > Linux era4.eracc.UUCP 2.4.22-28mdkenterprise i686 > 11:57:42 up 86 days, 5:52, 12 users, load average: 0.07, 0.06, 0.01 > ERA Computer Consulting - http://www.eracc.com/ > eCS, OS/2, Mandrake GNU/Linux, OpenServer & UnixWare resellers > > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Mon May 24 13:24:28 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:37 2005 Subject: [CF-Devel] Scorn Sale Shop - big world In-Reply-To: <1085420560.3314.6.camel@oberon.kameria> References: <200405202241.41892.eracclists@bellsouth.net> <200405241156.14304.eracclists@bellsouth.net> <1085420560.3314.6.camel@oberon.kameria> Message-ID: <200405241324.28183.eracclists@bellsouth.net> On Monday 24 May 2004 12:42 Todd Mitchell wrote: > Could you map this shop to the building in the south of Scorn (the > newbie area) on map world_105_116 x11 y2 instead of having it right > off of town square? I would prefer to spread things out a tiny bit > more than has been done in the past, and this area in southern > Scorn is a 'newbie zone' so it makes sense to put the shop here. > The building also matches the scale a bit better IMHO. Just my 2sp > anyway. Yup, I can. However, the problem with dropped "free" items is the NON-newbie players hop out of their permanent apt and the items get dropped in the square (which is conveniently nearby). This clutters up the square and makes it a PITA to go through there with autopickup on. Having the shop where it is places it only 6 moves away from the permanent apartments. Moving the shop to the southern half of Scorn would place it inconveniently out of the way and would not alleviate the problem as I see it. As for scale, I placed it where it is to align with the other small buildings just south of the road that leads to the East gate of Scorn. It does not appear out of scale to me being in that position. I also considered placing it just above the Imperial Post which would make it even more convenient to the permanent apartments. However, people coming from guilds would have to go farther and navigate around Scorn City Hall which was part of the consideration for placing it where it is. I'm not saying "no" I'm just giving you the reason for why I created the shop and why I placed it where it is. If it has to go in south Scorn then I see no real reason to have it at all. The Ball > Your Court :-) Gene (poof|Galahad) -- Linux era4.eracc.UUCP 2.4.22-28mdkenterprise i686 12:54:17 up 86 days, 6:49, 12 users, load average: 0.14, 0.06, 0.02 ERA Computer Consulting - http://www.eracc.com/ eCS, OS/2, Mandrake GNU/Linux, OpenServer & UnixWare resellers _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Mon May 24 14:11:19 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:37 2005 Subject: [CF-Devel] Scorn Sale Shop - big world In-Reply-To: <200405241324.28183.eracclists@bellsouth.net> References: <200405202241.41892.eracclists@bellsouth.net> <200405241156.14304.eracclists@bellsouth.net> <1085420560.3314.6.camel@oberon.kameria> <200405241324.28183.eracclists@bellsouth.net> Message-ID: <1085425879.3314.35.camel@oberon.kameria> Yes I know what you mean - but it is no wonder people dislike the bigworld maps if taking 23 steps is such a chore. I suspect if that is too far then no amount of distance is going to make people use it. They would rather dump it onto the ground anyway. If you cave in to this pressure pretty soon everything will be within 10 steps of the scorn apartments and no one will go anywhere. How about including about a sign that says no littering or some other piece of social engeneering to keep the streets clean as well? OTHO, how about moving the General store to Southern Scorn and placing this shop directly across from the apartments - that may be a better solution. The general store is likely more Newbie friendly anyway. On Mon, 2004-05-24 at 14:24, ERACC wrote: > On Monday 24 May 2004 12:42 > Todd Mitchell wrote: > > > Could you map this shop to the building in the south of Scorn (the > > newbie area) on map world_105_116 x11 y2 instead of having it right > > off of town square? I would prefer to spread things out a tiny bit > > more than has been done in the past, and this area in southern > > Scorn is a 'newbie zone' so it makes sense to put the shop here. > > The building also matches the scale a bit better IMHO. Just my 2sp > > anyway. > > Yup, I can. However, the problem with dropped "free" items is the > NON-newbie players hop out of their permanent apt and the items get > dropped in the square (which is conveniently nearby). This clutters > up the square and makes it a PITA to go through there with autopickup > on. Having the shop where it is places it only 6 moves away from the > permanent apartments. Moving the shop to the southern half of Scorn > would place it inconveniently out of the way and would not alleviate > the problem as I see it. > > As for scale, I placed it where it is to align with the other small > buildings just south of the road that leads to the East gate of > Scorn. It does not appear out of scale to me being in that position. > I also considered placing it just above the Imperial Post which would > make it even more convenient to the permanent apartments. However, > people coming from guilds would have to go farther and navigate > around Scorn City Hall which was part of the consideration for > placing it where it is. > > I'm not saying "no" I'm just giving you the reason for why I created > the shop and why I placed it where it is. If it has to go in south > Scorn then I see no real reason to have it at all. > > The Ball > Your Court :-) > > Gene (poof|Galahad) _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Mon May 24 15:07:40 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:37 2005 Subject: [CF-Devel] Scorn Sale Shop - big world In-Reply-To: <1085425879.3314.35.camel@oberon.kameria> References: <200405202241.41892.eracclists@bellsouth.net> <200405241324.28183.eracclists@bellsouth.net> <1085425879.3314.35.camel@oberon.kameria> Message-ID: <200405241507.40447.eracclists@bellsouth.net> On Monday 24 May 2004 14:11 Todd Mitchell wrote: > Yes I know what you mean - but it is no wonder people dislike the > bigworld maps if taking 23 steps is such a chore. I suspect if that > is too far then no amount of distance is going to make people use > it. They would rather dump it onto the ground anyway. If you cave > in to this pressure pretty soon everything will be within 10 steps > of the scorn apartments and no one will go anywhere. How about > including about a sign that says no littering or some other piece > of social engeneering to keep the streets clean as well? > OTHO, how about moving the General store to Southern Scorn and > placing this shop directly across from the apartments - that may be > a better solution. The general store is likely more Newbie > friendly anyway. Ok, I'll go with the general consensus on this list then. What does everyone want to see done with this map? X Vote -------- - Keep it where it is near the square. - Move the General Store to south Scorn, move the sale shop across from the apartments and put a "no littering" sign on the square. - Forget it, it'll never work (archaios, no need to vote ;-). Before voting please try to look at the Scorn map as is modified in the .zip file if you can. If I move the stores around I will look at modifying an existing medium sized building to go where the General Store is now. TIA Gene (poof|Galahad) -- Linux era4.eracc.UUCP 2.4.22-28mdkenterprise i686 14:53:03 up 86 days, 8:48, 12 users, load average: 0.00, 0.05, 0.04 ERA Computer Consulting - http://www.eracc.com/ eCS, OS/2, Mandrake GNU/Linux, OpenServer & UnixWare resellers _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Mon May 24 20:22:10 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:37 2005 Subject: [CF-Devel] Fog Of War code in Gtk In-Reply-To: <200405222202.26633.tchize@myrealbox.com> References: <200405222202.26633.tchize@myrealbox.com> Message-ID: The blur effect, while a clever approach, I don't think my eyes could withstand that effect for too long! ;-) On Sat, 22 May 2004, tchize wrote: > How to vote? > Simply reply to mailing list, assigning to each possible behaviour, a value > from 0 to 2 meaning: > 0 - I don't like, current behaviour is better. > 1 - I don't mind/That's the same as current behaviour IMO. > 2 - I enjoy it, Better than current behaviour. > > Ok, here we go! And check twice you are voting for the good one > > [ 1 ] Keep Current Behaviour > [ 2 ] http://users.skynet.be/tchize/brol/fow1.png > [ 2 ] http://users.skynet.be/tchize/brol/fow2.png > [ 0 ] http://users.skynet.be/tchize/brol/fow3.png (Childrens away!) > [ 0 ] http://users.skynet.be/tchize/brol/fow4.png > [ 0 ] http://users.skynet.be/tchize/brol/fow5.png > [ 0 ] http://users.skynet.be/tchize/brol/fow6.png > [ 0 ] http://users.skynet.be/tchize/brol/fow7.png > [ 0 ] http://users.skynet.be/tchize/brol/fow8.png > [ 1 ] http://users.skynet.be/tchize/brol/fow9.png > [ 0 ] http://users.skynet.be/tchize/brol/fow10.png > [ - ] Maque a suggestion > > -- _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Mon May 24 22:39:21 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:37 2005 Subject: [CF-Devel] Scorn Sale Shop - big world In-Reply-To: <1085425879.3314.35.camel@oberon.kameria> Message-ID: On 24-May-2004 Todd Mitchell wrote: > How about including about a > sign that says no littering or some other piece of social engeneering to > keep the streets clean as well? On the mud, we had janitors who would wander the city picking up things left on the ground. We set aside an areas where players could dump goods, called the well. Players could just type "donate sword" and it would magically transfer to the well. Eventualy, players started killing janitors, and we replaced them with invulnerable gelatinous cubes. --- Tim Rightnour NetBSD: Free multi-architecture OS http://www.netbsd.org/ NetBSD supported hardware database: http://mail-index.netbsd.org/cgi-bin/hw.cgi _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Mon May 24 22:43:09 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:37 2005 Subject: [CF-Devel] random maps Message-ID: <1085456589.3314.66.camel@oberon.kameria> I notice that random maps now place a return exit on the final_map - It would be great to be able to disable this with a mesg entry or to specify the destination x/y coords on the final_map so that different random maps can point to the same final map without having an exit always showing up at the enrty of that map. Also I suppose this means the random map doc can be updated as not providing a return exit on the final map was a big no-no in the past. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Tue May 25 01:16:25 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:37 2005 Subject: [CF-Devel] random maps In-Reply-To: <1085456589.3314.66.camel@oberon.kameria> References: <1085456589.3314.66.camel@oberon.kameria> Message-ID: <40B2E4B9.6000207@sonic.net> Todd Mitchell wrote: > I notice that random maps now place a return exit on the final_map - It > would be great to be able to disable this with a mesg entry or to > specify the destination x/y coords on the final_map so that different > random maps can point to the same final map without having an exit > always showing up at the enrty of that map. Also I suppose this means > the random map doc can be updated as not providing a return exit on the > final map was a big no-no in the past. If I recall, the return exit, when placed automatically, pops back to the original location to that entry. Eg, if you have two series of maps (say A and B) that you want to use for the same final map, the quick return should point back appropriately. Note that it is not possible for A and B to use the same real map - each one would probably still need to have its own copy (final_map_A, final_map_B), at least from the server standpoint. Otherwise, you'd get the issue that the exit that leads back up could only lead to one set of those maps. For example, player on series B wanders down, after someone on A already has done so (so final map has been loaded). When he gets to the final map, you don't want the up exit to lead to the bottom of A - you want it to lead to the bottom of B. However, as I think about it, I believe all current final maps are designed for a specific location, and it is the final map itself (located in the map folder) which has the 'pop back to top' exit on it, and it isn't the random map code that is doing this. It just so happens that things are set so that the exit the leads back up one level is placed on the same space (and above) any explicity placed return exits. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Tue May 25 01:28:32 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:37 2005 Subject: [CF-Devel] Bug ? Automatic Pickup of Arrows and Client crash In-Reply-To: <20040522001933.6492dc21.scachi@gmx.de> References: <20040521135739.66f62e94.scachi@gmx.de> <200405211956.30412.tchize@myrealbox.com> <20040521230802.7cfaa6be.scachi@gmx.de> <20040522001933.6492dc21.scachi@gmx.de> Message-ID: <40B2E790.4010803@sonic.net> ScaChi wrote: >>From what I have observed, a thrown object that hits you ends up in your >>inventory. > > That is exactly what I tried to say. > > >>Or, are you using the NEWPickup capability in the GTK client? > > No, both automatic pickup functions are disabled. it is I believe an intentional feature in the code that things that are thrown at you that hit you end up in your inventory. This wasn't a big deal when the only thing this happened for was arrows (I suppose the theory being they were stuck in you). It doesn't make a lot of sense for things like boulders. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Tue May 25 01:26:32 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:37 2005 Subject: [CF-Devel] Scorn Sale Shop - big world In-Reply-To: References: Message-ID: <40B2E718.6080100@sonic.net> Tim Rightnour wrote: > On 24-May-2004 Todd Mitchell wrote: > >>How about including about a >>sign that says no littering or some other piece of social engeneering to >>keep the streets clean as well? > > > On the mud, we had janitors who would wander the city picking up things left on > the ground. We set aside an areas where players could dump goods, called the > well. Players could just type "donate sword" and it would magically transfer > to the well. > > Eventualy, players started killing janitors, and we replaced them with > invulnerable gelatinous cubes. Right now blobs pick up everything they gather I believe. So that code is already in crossfire, and you could off course make them immune to everything. The trickier part is having them move about properly, and not wander from where they are not suppose to (in the case of scorn, probably not an issue since they can't use exits - could be a case in say santo dominion, but a mover could be used for that). However, since blobs just pick everything up and never destroy it,eventually they would become 'full'. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Tue May 25 01:22:16 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:37 2005 Subject: [CF-Devel] Icestorm - could not move - death In-Reply-To: <012301c441b7$2c7ee1f0$8024a2cd@YUANC8000> References: <004001c44182$a1431ae0$0100000a@archaios><1085413581.2909.19.camel@oberon.kameria> <200405241205.17183.eracclists@bellsouth.net> <012301c441b7$2c7ee1f0$8024a2cd@YUANC8000> Message-ID: <40B2E618.6010303@sonic.net> Just as a minor note on this - one problem that may occur is the potential disparity between weights of monsters and players. If you want the spell to be able to push around any moderately sized monsters, it basically means that players will be blown all over the place. This sort of falls back to the different hp levels between players and monsters. However, the players have many ways to counteract that - highers resistances, faster than most monsters (so can move out of the effect), faster hp regen (after a ring of life or other nice regen +2 item), and intelligent use of healing. Probably the easiest way to fix this would be to add a KNOCKBACK attacktype. This would be like the confusion or slow attacktypes - doesn't do actual damage (so needs to be teamed with something else), but denotes the creature needs to be pushed back, if appropriate roles fail. It could be interesting to add support for that to various weapons even (can't use wait as easily, but could do something - getting hit by a bonecrusher would suggest you perhaps should be moved back a space or so) _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Tue May 25 01:38:34 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:37 2005 Subject: [CF-Devel] Fog Of War code in Gtk In-Reply-To: References: <200405222202.26633.tchize@myrealbox.com> Message-ID: <40B2E9EA.7030006@sonic.net> Rick Tanner wrote: > The blur effect, while a clever approach, I don't think my eyes could > withstand that effect for too long! ;-) I agree, and the minor blurs are not that different. Now the quick hack I did to make it grey was mostly because before then, they were shown as if it was 50% dark. So for maps with darkness, it was very hard to tell if in fact the space was just dark, or out of view. I do like the faded look. The problem which is very apparant is that it doesn't work very well for objects that are only grey (looking at sample 2, there is only a very minor difference noticable between the visible cobblestones under the grate, and the blocked ones behind it/in the corners). Minor enough that without having that visible one as a reference, for me at least, I wouldn't be able to tell you those others were blocked. Which probably brings up the issue that no method will work perfectly for everything. The current method works OK for some images, and not good for others. I wonder if some logic to try and figure out how 'colorful' the image is could be done, and for images that are mostly grey/black, do an intensity reduction. In terms of votes, I personally like #1 or #2 - hard to tell exactly how they are different, since #1 was done on a different map. In terms of removing objects, this is harder. It wouldn't be hard to just draw the bottom most image, but that probably isn't write - things like statues, grates, walls on top of other terrain, etc, would all disappear. And you can't really get much more intelligent logic, because the client doesn't necessarily know that image X is a wall and Y is a dagger, and it should draw X and not Y. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Tue May 25 01:44:19 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:38 2005 Subject: [CF-Devel] bugs In-Reply-To: <1085328158.24277.8.camel@myth.crowcastle.com> References: <1085328158.24277.8.camel@myth.crowcastle.com> Message-ID: <40B2EB43.6080801@sonic.net> Preston Crow wrote: > Several minor bugs: > > When I use the "skills" command, for each skill it lists the current xp, > xp for the next level, and a percentage. The percentage is always 0%. > I thought it was supposed to be the percentage of the way through the > current level (e.g., at 1000xp, you are 50% of the way to 2nd level). I believe that percentage is what % of the exp is permantent exp. It may be that for simplicity, that is still displayed even on systems not using the permanent exp code. Or it oculd be that the awarding/calculation of permanent exp is just broken with the new code. > > The spellbook names are all singular possessive except for the > "summoners's" spellbooks. For consistency, they should be "summoner's" > spellbooks. That's easy enough - I'll fix that up. > > I've seen at least one map with a fire chest that used to shoot out > fireballs shooting out magic bullets instead. (The tower near the > department store has an example--I'll find the map name if someone > requests it.) Could be useful - it is supposed to get updated automatically. Unfornately, the old spell code was a real mismash - some things used 'sp' to denote what they fired, others other_arch, and others yet some other fields. > > Spellbooks seem to have the wrong spells. At the end of the CTower > quest, it's just a random spellbook. I think this is the same bug that > is causing spellbooks to change spells in your apartment and not stack > properly (they have different values). It could be, but that bug should now be fixed (although, old books generated before the fix won't get updated, so will remain broken). But once again, it is supposed to automatically fix those up when loading, but perhaps that is broken - I'll take a look. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Tue May 25 03:35:43 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:38 2005 Subject: [CF-Devel] Scorn Sale Shop - big world In-Reply-To: <40B2E718.6080100@sonic.net> Message-ID: On 25-May-2004 Mark Wedel wrote: > However, since blobs just pick everything up and never destroy > it,eventually > they would become 'full'. We had them devour items in thier inventory, after a few hours. You could set up a shop in town, and have the blobs be "agents" for the shop. It could be like a town dump. The blobs collect items, and teleport them to the dump. The owner of the dump would be glad to sell you anything he finds, of course. That way.. an object accidentally lost to a blob, could be retrieved, for a price. You could also have a "junk" command, that would teleport an item from your inventory to the dump. It's an easy way to clean crap out of your bag, or off the floor below you. --- Tim Rightnour NetBSD: Free multi-architecture OS http://www.netbsd.org/ NetBSD supported hardware database: http://mail-index.netbsd.org/cgi-bin/hw.cgi _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Tue May 25 08:35:51 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:38 2005 Subject: =?iso-8859-1?Q?Re:_Re:_[CF-Devel]_random_maps?= Message-ID: > If I recall, the return exit, when placed automatically, pops back to the > original location to that entry. > > Eg, if you have two series of maps (say A and B) that you want to use for the > same final map, the quick return should point back appropriately. Note that it > is not possible for A and B to use the same real map - each one would probably > still need to have its own copy (final_map_A, final_map_B), at least from the > server standpoint. Otherwise, you'd get the issue that the exit that leads back > up could only lead to one set of those maps. This is the problem - I would rather be able to switch off the return exit in that case so I could use the same final map for both A and B. The current behaviour is propably correct for a default but I think we need a way to switch it off and not place an exit at all. This would give you the ability to map multiple routes to the same place so long as they are understood to be a one way ticket. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Tue May 25 10:17:55 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:38 2005 Subject: [CF-Devel] bugs In-Reply-To: <40B2EB43.6080801@sonic.net> References: <1085328158.24277.8.camel@myth.crowcastle.com> <40B2EB43.6080801@sonic.net> Message-ID: <1085498274.13959.5.camel@myth.crowcastle.com> On Tue, 2004-05-25 at 02:44, Mark Wedel wrote: > > When I use the "skills" command, for each skill it lists the current xp, > > xp for the next level, and a percentage. The percentage is always 0%. > > I thought it was supposed to be the percentage of the way through the > > current level (e.g., at 1000xp, you are 50% of the way to 2nd level). > > I believe that percentage is what % of the exp is permantent exp. It may be > that for simplicity, that is still displayed even on systems not using the > permanent exp code. If that's something that is turned off, should the display of the percentage be turned off, too? > > I've seen at least one map with a fire chest that used to shoot out > > fireballs shooting out magic bullets instead. (The tower near the > > department store has an example--I'll find the map name if someone > > requests it.) > > Could be useful - it is supposed to get updated automatically. Unfornately, > the old spell code was a real mismash - some things used 'sp' to denote what > they fired, others other_arch, and others yet some other fields. I think the one I noticed is in /wolfsburg/eeur/tower1.3. I seem to recall a similar monster elsewhere, so a good grep might find more hits. --PC _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Tue May 25 12:35:53 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:38 2005 Subject: [CF-Devel] Fog Of War code in Gtk In-Reply-To: <40B2E9EA.7030006@sonic.net> References: <200405222202.26633.tchize@myrealbox.com> <40B2E9EA.7030006@sonic.net> Message-ID: <200405251936.00684.tchize@myrealbox.com> Skipped content of type multipart/signed-------------- next part -------------- _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Wed May 26 01:21:02 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:38 2005 Subject: [CF-Devel] Fog Of War code in Gtk In-Reply-To: <200405251936.00684.tchize@myrealbox.com> References: <200405222202.26633.tchize@myrealbox.com> <40B2E9EA.7030006@sonic.net> <200405251936.00684.tchize@myrealbox.com> Message-ID: <40B4374E.2010707@sonic.net> tchize wrote: > That's true shading to grey is a problem with already grey items :) > The 3 solutions are > 1) darken all items too, so the grey looks darker grey (bad IMO) > 2) detect when a picture is grey only (perhaps with a small amount of > possible deviation for 'nearly grey' pictures, like shades of very light > yellow items) and daken only those. > 3) detect when a picture is grey and then play with saturation/hue (like > increasing the yellow compound?) need to play a bit with it to see results Yeah - hard to see what #3 would look like. It would seem that figuring out greyness of an image shouldn't be that difficult - a simple averaging of all the color variance on the set pixels could be done, eg, something like: for xy loop { if nottransparent(xy) { ++numsetpixels; maxcolordiff += MAXDIFF(r, g, b of pixel xy) } } averagecolordensity = maxcolordiff / numsetpixels If that density is below some threshold (which probably needs to be determined experimentally), treat it as greyscale. this also sort of works on the basis that an image that is all grey but has a few colorful pixels will probably get averaged out. > I didn't notice while i messed with fow (cause i did quite quickly the various > screenshot) but that's true the blur has problem. Seems the natural behaviour > of eye is to try to fix the blur, which obviously the eye can't, but can end > up in headaches (and we don't want players with headaches, do we?) > > Removing non static object is an impossible thing to do with current protocol. > But stay tuned... (did i ever say we should put the static part of the map > client side?) probably, but I think that opens a can of worms that isn't worth the effort. The problem there are lots of objects which are somewhat static, but not really static. The only true static objects are floors and walls (and even in those cases, may not be truely static, eg, weak walls or gold floors are obvious examples). So I think if you limit it to only truely static objects, you'd have the same issue of the fog not being that useful. And IMO, I really want fog to show all those not really static objects, but things that tend to remain the same (chairs, objects on the ground, etc). All that fog is really acting as is a memory aid - after all, it isn't getting any info from the server the player doesn't already know - if you didn't have fog, the player could mimic it by doing screen captures and whatnot. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Wed May 26 01:24:15 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:38 2005 Subject: [CF-Devel] random maps In-Reply-To: References: Message-ID: <40B4380F.20805@sonic.net> Todd Mitchell wrote: > >> If I recall, the return exit, when placed automatically, pops back to the >> original location to that entry. >> >> Eg, if you have two series of maps (say A and B) that you want to use for >> the same final map, the quick return should point back appropriately. Note >> that it is not possible for A and B to use the same real map - each one >> would probably still need to have its own copy (final_map_A, final_map_B), >> at least from the server standpoint. Otherwise, you'd get the issue that >> the exit that leads back up could only lead to one set of those maps. > > > This is the problem - I would rather be able to switch off the return exit in > that case so I could use the same final map for both A and B. The current > behaviour is propably correct for a default but I think we need a way to > switch it off and not place an exit at all. This would give you the ability > to map multiple routes to the same place so long as they are understood to be > a one way ticket. I suppose that could be done easily enough. OTOH, the idea of two maps leading to the same place with no return seems a bit odd to be. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Wed May 26 01:22:22 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:38 2005 Subject: [CF-Devel] bugs In-Reply-To: <1085498274.13959.5.camel@myth.crowcastle.com> References: <1085328158.24277.8.camel@myth.crowcastle.com> <40B2EB43.6080801@sonic.net> <1085498274.13959.5.camel@myth.crowcastle.com> Message-ID: <40B4379E.3080104@sonic.net> Preston Crow wrote: > On Tue, 2004-05-25 at 02:44, Mark Wedel wrote: > >>>When I use the "skills" command, for each skill it lists the current xp, >>>xp for the next level, and a percentage. The percentage is always 0%. >>>I thought it was supposed to be the percentage of the way through the >>>current level (e.g., at 1000xp, you are 50% of the way to 2nd level). >> >> I believe that percentage is what % of the exp is permantent exp. It may be >>that for simplicity, that is still displayed even on systems not using the >>permanent exp code. > > > If that's something that is turned off, should the display of the > percentage be turned off, too? Maybe. It could just have been a case where it made things cleaner to display it, and there was no real harm in doing so. But to be honest, I'd have to look at the code and really see what it is doing. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Wed May 26 11:17:53 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:38 2005 Subject: =?iso-8859-1?Q?Re:_Re:_[CF-Devel]_random_maps?= Message-ID: Looking at the code it seems simple - I can *try* to implement this if there are no objections to the idea and if someone else does not do it better faster. I was thinking of having a 'no_final_exit' or similar named field which if included in the random map mesg field will disable the exit being written to the final_map. As for it being odd - yes it is strange. Strange and Wonderful. > > I suppose that could be done easily enough. OTOH, the idea of two maps > leading to the same place with no return seems a bit odd to be. > _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Wed May 26 12:55:04 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:38 2005 Subject: [CF-Devel] Fog Of War code in Gtk In-Reply-To: <40B2E9EA.7030006@sonic.net> References: <200405222202.26633.tchize@myrealbox.com> <40B2E9EA.7030006@sonic.net> Message-ID: <200405261955.10118.tchize@myrealbox.com> Skipped content of type multipart/signed-------------- next part -------------- _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Wed May 26 15:37:11 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:38 2005 Subject: =?iso-8859-1?Q?Re:_Re:_[CF-Devel]_Fog_Of_War_code_in_Gtk?= Message-ID: I am surprised no one mentioned just blacking out the tiles covered by fog of war. The more I think of this the more I like the idea. It would be easier. Fog of war in a stragety game is a convienient tool but in a adventure/RPG maybe it is too much assistance. If you can't remember what's around the corner then you better take another look... > > --Boundary-02=_+nNtAIl4ANWMXXT > Content-Type: text/plain; > charset="iso-8859-1" > Content-Transfer-Encoding: quoted-printable > Content-Disposition: inline > > Just put an example with grey pictures detection. Work quite well. > Please note the base dungeon floor is NOT grey but made of light yellow and > dark green :). I walked a bit in the game seems the detection algorithm did > not fail anywhere!! > > I choose to move grey picture to the light blue. Give better results than > yellow, and i thing nobody wants magenta or cyan :) > http://users.skynet.be/tchize/brol/fow11.png > > Le mardi 25 Mai 2004 08:38, Mark Wedel a écrit : > Rick Tanner wrote: > > The blur effect, while a clever approach, I don't think my eyes could > > withstand that effect for too long! ;-) > > I agree, and the minor blurs are not that different. > > Now the quick hack I did to make it grey was mostly because before then, > they were shown as if it was 50% dark. So for maps with darkness, it was > very hard to tell if in fact the space was just dark, or out of view. > > I do like the faded look. The problem which is very apparant is that it > doesn't work very well for objects that are only grey (looking at sample 2, > there is only a very minor difference noticable between the visible > cobblestones under the grate, and the blocked ones behind it/in the > corners). > > Minor enough that without having that visible one as a reference, for me at > least, I wouldn't be able to tell you those others were blocked. > > Which probably brings up the issue that no method will work perfectly for > everything. The current method works OK for some images, and not good for > others. I wonder if some logic to try and figure out how 'colorful' the > image is could be done, and for images that are mostly grey/black, do an > intensity reduction. > > In terms of votes, I personally like #1 or #2 - hard to tell exactly how > they are different, since #1 was done on a different map. > > In terms of removing objects, this is harder. It wouldn't be hard to just > draw the bottom most image, but that probably isn't write - things like > statues, grates, walls on top of other terrain, etc, would all disappear. > And you can't really get much more intelligent logic, because the client > doesn't necessarily know that image X is a wall and Y is a dagger, and it > should draw X and not Y. > > > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > > -- > -- > 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 > > --Boundary-02=_+nNtAIl4ANWMXXT > Content-Type: application/pgp-signature > Content-Description: signature > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.4 (GNU/Linux) > > iD8DBQBAtNn+HHGOa1Q2wXwRAjhIAKDWfeFAXNdcB/1SLhDZKSAW8lDsHQCgxMXw > iE35FxBo0h2fBWijgAZsRWE 0b > -----END PGP SIGNATURE----- > > --Boundary-02=_+nNtAIl4ANWMXXT-- > > > _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Thu May 27 12:16:15 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:39 2005 Subject: [CF-Devel] Fog Of War code in Gtk In-Reply-To: References: Message-ID: <200405271916.23386.tchize@myrealbox.com> Skipped content of type multipart/signed-------------- next part -------------- _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Thu May 27 06:52:32 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:39 2005 Subject: =?iso-8859-1?Q?Re:_Re:_[CF-Devel]_Fog_Of_War_code_in_Gtk?= In-Reply-To: Message-ID: > I am surprised no one mentioned just blacking out the tiles covered by fog = > of war. The more I think of this the more I like the idea. It would be ea= > sier. Fog of war in a stragety game is a convienient tool but in a adventu= > re/RPG maybe it is too much assistance. If you can't remember what's aroun= Now _this_ I really can't understand. Why on Earth would it be "too much assistance"? Have you _played_ this game? Well, as for my experiences, peepo of the human race overall is a visal type entity (_man_, what words am I using), and we should not only accept it, but appreciate it as well. Playing via games is _not_ like acting in reality. No. If I were there in the dungeon I may consider move slowly and put significant energy to make sure I can remember things. But a game is different. As for me, I play it for fun, not for being in some reality-simulation. We move that way - we won't be able to have an answer for such aspersions like "computer games are good for nothin' shit for children who want to escape reality". To prevent that, games should be more exciting, and yes, less realistic. And there are tools to accomplish that, tools, that makes the players life better and easier, while not breaking the game. Fog of war is such a tool, it logically represents the _characters_ possible memory - which is _definietly_ shouldn't be the same as the _players_ memory. (Not to mention, in reality, the worlds features are unique wherever you go, while in the game, the walls and the floor etc. are just the same as anywhere else (almost), so it's not a bad idea helping peepo in their orientation.) > d the corner then you better take another look... > > > = > > > --Boundary-02=3D_+nNtAIl4ANWMXXT > > Content-Type: text/plain; > > charset=3D"iso-8859-1" > > Content-Transfer-Encoding: quoted-printable > > Content-Disposition: inline > > = > > > Just put an example with grey pictures detection. Work quite well. > > Please note the base dungeon floor is NOT grey but made of light yellow a= > nd = > > > dark green :). I walked a bit in the game seems the detection algorithm d= > id = > > > not fail anywhere!! > > = > > > I choose to move grey picture to the light blue. Give better results than= > = > > > yellow, and i thing nobody wants magenta or cyan :) > > http://users.skynet.be/tchize/brol/fow11.png > > = > > > Le mardi 25 Mai 2004 08:38, Mark Wedel a =E9crit : > > Rick Tanner wrote: > > > The blur effect, while a clever approach, I don't think my eyes could > > > withstand that effect for too long! ;-) > > = > > > I agree, and the minor blurs are not that different. > > = > > > Now the quick hack I did to make it grey was mostly because before then= > , > > they were shown as if it was 50% dark. So for maps with darkness, it wa= > s > > very hard to tell if in fact the space was just dark, or out of view. > > = > > > I do like the faded look. The problem which is very apparant is that i= > t > > doesn't work very well for objects that are only grey (looking at sample = > 2, > > there is only a very minor difference noticable between the visible > > cobblestones under the grate, and the blocked ones behind it/in the > > corners). > > = > > > Minor enough that without having that visible one as a reference, for m= > e at > > least, I wouldn't be able to tell you those others were blocked. > > = > > > Which probably brings up the issue that no method will work perfectly f= > or > > everything. The current method works OK for some images, and not good fo= > r > > others. I wonder if some logic to try and figure out how 'colorful' the > > image is could be done, and for images that are mostly grey/black, do an > > intensity reduction. > > = > > > In terms of votes, I personally like #1 or #2 - hard to tell exactly ho= > w > > they are different, since #1 was done on a different map. > > = > > > In terms of removing objects, this is harder. It wouldn't be hard to j= > ust > > draw the bottom most image, but that probably isn't write - things like > > statues, grates, walls on top of other terrain, etc, would all disappear= > . = > > > And you can't really get much more intelligent logic, because the client > > doesn't necessarily know that image X is a wall and Y is a dagger, and i= > t > > should draw X and not Y. > > = > > > = > > > = > > > _______________________________________________ > > crossfire-devel mailing list > > crossfire-devel@lists.real-time.com > > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > > = > > > -- = > > > -- > > 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 > > = > > > --Boundary-02=3D_+nNtAIl4ANWMXXT > > Content-Type: application/pgp-signature > > Content-Description: signature > > = > > > -----BEGIN PGP SIGNATURE----- > > Version: GnuPG v1.2.4 (GNU/Linux) > > = > > > iD8DBQBAtNn+HHGOa1Q2wXwRAjhIAKDWfeFAXNdcB/1SLhDZKSAW8lDsHQCgxMXw > > iE35FxBo0h2fBWijgAZsRWE=0C0b > > -----END PGP SIGNATURE----- > > = > > > --Boundary-02=3D_+nNtAIl4ANWMXXT-- > > = > > > = > > > = > > > > > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Thu May 27 14:23:30 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:39 2005 Subject: [CF-Devel] Fog Of War code in Gtk In-Reply-To: References: Message-ID: <200405272123.38072.d.delbecq@laposte.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Well if i were a general of an army, let's say invading some petrol rich country (just supposition that's not real life) i would to appreciate to have a fog of war instead of black boxes :) (just a useless note because games are not so far from reality. The only difference is well... it's not reality) Le jeudi 27 Mai 2004 13:52, Palfy Tamas a ?crit : > I am surprised no one mentioned just blacking out the tiles covered by fog > = of war. The more I think of this the more I like the idea. It would be > ea= sier. Fog of war in a stragety game is a convienient tool but in a > adventu= re/RPG maybe it is too much assistance. If you can't remember > what's aroun= Now _this_ I really can't understand. Why on Earth would it be "too much assistance"? Have you _played_ this game? Well, as for my experiences, peepo of the human race overall is a visal type entity (_man_, what words am I using), and we should not only accept it, but appreciate it as well. Playing via games is _not_ like acting in reality. No. If I were there in the dungeon I may consider move slowly and put significant energy to make sure I can remember things. But a game is different. As for me, I play it for fun, not for being in some reality-simulation. We move that way - we won't be able to have an answer for such aspersions like "computer games are good for nothin' shit for children who want to escape reality". To prevent that, games should be more exciting, and yes, less realistic. And there are tools to accomplish that, tools, that makes the players life better and easier, while not breaking the game. Fog of war is such a tool, it logically represents the _characters_ possible memory - which is _definietly_ shouldn't be the same as the _players_ memory. (Not to mention, in reality, the worlds features are unique wherever you go, while in the game, the walls and the floor etc. are just the same as anywhere else (almost), so it's not a bad idea helping peepo in their orientation.) > d the corner then you better take another look... > > > = > > > > --Boundary-02=3D_+nNtAIl4ANWMXXT > > Content-Type: text/plain; > > charset=3D"iso-8859-1" > > Content-Transfer-Encoding: quoted-printable > > Content-Disposition: inline > > = > > > > Just put an example with grey pictures detection. Work quite well. > > Please note the base dungeon floor is NOT grey but made of light yellow > > a= > > nd = > > > dark green :). I walked a bit in the game seems the detection algorithm > > d= > > id = > > > not fail anywhere!! > > = > > > > I choose to move grey picture to the light blue. Give better results > > than= > > = > > > yellow, and i thing nobody wants magenta or cyan :) > > http://users.skynet.be/tchize/brol/fow11.png > > = > > > > Le mardi 25 Mai 2004 08:38, Mark Wedel a =E9crit : > > > > Rick Tanner wrote: > > > The blur effect, while a clever approach, I don't think my eyes could > > > withstand that effect for too long! ;-) > > > > = > > > > I agree, and the minor blurs are not that different. > > = > > > > Now the quick hack I did to make it grey was mostly because before > > then= > > , > > > they were shown as if it was 50% dark. So for maps with darkness, it > > wa= > > s > > > very hard to tell if in fact the space was just dark, or out of view. > > = > > > > I do like the faded look. The problem which is very apparant is that > > i= > > t > > > doesn't work very well for objects that are only grey (looking at sample > > = > > 2, > > > there is only a very minor difference noticable between the visible > > cobblestones under the grate, and the blocked ones behind it/in the > > corners). > > = > > > > Minor enough that without having that visible one as a reference, for > > m= > > e at > > > least, I wouldn't be able to tell you those others were blocked. > > = > > > > Which probably brings up the issue that no method will work perfectly > > f= > > or > > > everything. The current method works OK for some images, and not good > > fo= > > r > > > others. I wonder if some logic to try and figure out how 'colorful' the > > image is could be done, and for images that are mostly grey/black, do an > > intensity reduction. > > = > > > > In terms of votes, I personally like #1 or #2 - hard to tell exactly > > ho= > > w > > > they are different, since #1 was done on a different map. > > = > > > > In terms of removing objects, this is harder. It wouldn't be hard to > > j= > > ust > > > draw the bottom most image, but that probably isn't write - things like > > statues, grates, walls on top of other terrain, etc, would all > > disappear= > > . = > > > And you can't really get much more intelligent logic, because the client > > doesn't necessarily know that image X is a wall and Y is a dagger, and > > i= > > t > > > should draw X and not Y. > > = > > > > = > > > > = > > > > _______________________________________________ > > crossfire-devel mailing list > > crossfire-devel@lists.real-time.com > > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > > = > > > > -- = > > > > -- > > 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 > > = > > > > --Boundary-02=3D_+nNtAIl4ANWMXXT > > Content-Type: application/pgp-signature > > Content-Description: signature > > = > > > > -----BEGIN PGP SIGNATURE----- > > Version: GnuPG v1.2.4 (GNU/Linux) > > = > > > > iD8DBQBAtNn+HHGOa1Q2wXwRAjhIAKDWfeFAXNdcB/1SLhDZKSAW8lDsHQCgxMXw > > iE35FxBo0h2fBWijgAZsRWE=0C0b > > -----END PGP SIGNATURE----- > > = > > > > --Boundary-02=3D_+nNtAIl4ANWMXXT-- > > = > > > > = > > > > = > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel - -- - -- David Delbecq d.delbecq@laposte.net 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAtkA3HHGOa1Q2wXwRAhANAJ0YGTvxyn1q7xLOUXfMiMfguH6PPACg3kOb /cmcH2/TwUHOxHj14CUlsc0= =SMXI -----END PGP SIGNATURE----- _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Thu May 27 21:32:38 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:39 2005 Subject: [CF-Devel] Fog Of War code in Gtk In-Reply-To: <200405272123.38072.d.delbecq@laposte.net> References: <200405272123.38072.d.delbecq@laposte.net> Message-ID: <1085711558.4083.33.camel@oberon.kameria> In a realtime strategy game fog of war is very much a part of the game as these games have an exploration and sphere of influence component as part of the game mechanism. In an RPG - fog of war is not helpful in the same way and in fact may even be misleading or unhelpful in some conditions since it shows things that were and not thing that are. Also your sphere of influence is a lot smaller and you can move a lot quicker in crossfire. Now a spell that expanded your field of vision is a lot more interesting to me than fog of war. As for fun - I'm entitled to have an opinion on fun as well. Netrek is fun. (this is not an out of the blue reference). Automatic food consumption is not really fun. Suspense and challange and good gameplay is fun. Instant gratification is not always fun. Personally I didn't mind the fog of war especially since it is something you can turn on and off in the client but you have made me decide not to use it for a while to see if I enjoy life more without it. On Thu, 2004-05-27 at 15:23, David Delbecq wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Well if i were a general of an army, let's say invading some petrol rich > country (just supposition that's not real life) i would to appreciate to have > a fog of war instead of black boxes :) > > (just a useless note because games are not so far from reality. The only > difference is well... it's not reality) > > Le jeudi 27 Mai 2004 13:52, Palfy Tamas a ?crit : > > I am surprised no one mentioned just blacking out the tiles covered by fog > > = of war. The more I think of this the more I like the idea. It would be > > ea= sier. Fog of war in a stragety game is a convienient tool but in a > > adventu= re/RPG maybe it is too much assistance. If you can't remember > > what's aroun= > > Now _this_ I really can't understand. Why on Earth would it be "too much > assistance"? Have you _played_ this game? Well, as for my experiences, > peepo of the human race overall is a visal type entity (_man_, what words > am I using), and we should not only accept it, but appreciate it as well. > Playing via games is _not_ like acting in reality. No. If I were there in > the dungeon I may consider move slowly and put significant energy to make > sure I can remember things. But a game is different. As for me, I play it > for fun, not for being in some reality-simulation. We move that way - we > won't be able to have an answer for such aspersions like "computer games > are good for nothin' shit for children who want to escape reality". To > prevent that, games should be more exciting, and yes, less realistic. And > there are tools to accomplish that, tools, that makes the players life > better and easier, while not breaking the game. > Fog of war is such a tool, it logically represents the _characters_ > possible memory - which is _definietly_ shouldn't be the same as the > _players_ memory. > (Not to mention, in reality, the worlds features are unique wherever you > go, while in the game, the walls and the floor etc. are just the same as > anywhere else (almost), so it's not a bad idea helping peepo in their > orientation.) > > > d the corner then you better take another look... > > > > > = > > > > > > --Boundary-02=3D_+nNtAIl4ANWMXXT > > > Content-Type: text/plain; > > > charset=3D"iso-8859-1" > > > Content-Transfer-Encoding: quoted-printable > > > Content-Disposition: inline > > > = > > > > > > Just put an example with grey pictures detection. Work quite well. > > > Please note the base dungeon floor is NOT grey but made of light yellow > > > a= > > > > nd = > > > > > dark green :). I walked a bit in the game seems the detection algorithm > > > d= > > > > id = > > > > > not fail anywhere!! > > > = > > > > > > I choose to move grey picture to the light blue. Give better results > > > than= > > > > = > > > > > yellow, and i thing nobody wants magenta or cyan :) > > > http://users.skynet.be/tchize/brol/fow11.png > > > = > > > > > > Le mardi 25 Mai 2004 08:38, Mark Wedel a =E9crit : > > > > > > Rick Tanner wrote: > > > > The blur effect, while a clever approach, I don't think my eyes could > > > > withstand that effect for too long! ;-) > > > > > > = > > > > > > I agree, and the minor blurs are not that different. > > > = > > > > > > Now the quick hack I did to make it grey was mostly because before > > > then= > > > > , > > > > > they were shown as if it was 50% dark. So for maps with darkness, it > > > wa= > > > > s > > > > > very hard to tell if in fact the space was just dark, or out of view. > > > = > > > > > > I do like the faded look. The problem which is very apparant is that > > > i= > > > > t > > > > > doesn't work very well for objects that are only grey (looking at sample > > > = > > > > 2, > > > > > there is only a very minor difference noticable between the visible > > > cobblestones under the grate, and the blocked ones behind it/in the > > > corners). > > > = > > > > > > Minor enough that without having that visible one as a reference, for > > > m= > > > > e at > > > > > least, I wouldn't be able to tell you those others were blocked. > > > = > > > > > > Which probably brings up the issue that no method will work perfectly > > > f= > > > > or > > > > > everything. The current method works OK for some images, and not good > > > fo= > > > > r > > > > > others. I wonder if some logic to try and figure out how 'colorful' the > > > image is could be done, and for images that are mostly grey/black, do an > > > intensity reduction. > > > = > > > > > > In terms of votes, I personally like #1 or #2 - hard to tell exactly > > > ho= > > > > w > > > > > they are different, since #1 was done on a different map. > > > = > > > > > > In terms of removing objects, this is harder. It wouldn't be hard to > > > j= > > > > ust > > > > > draw the bottom most image, but that probably isn't write - things like > > > statues, grates, walls on top of other terrain, etc, would all > > > disappear= > > > > . = > > > > > And you can't really get much more intelligent logic, because the client > > > doesn't necessarily know that image X is a wall and Y is a dagger, and > > > i= > > > > t > > > > > should draw X and not Y. > > > = > > > > > > = > > > > > > = > > > > > > _______________________________________________ > > > crossfire-devel mailing list > > > crossfire-devel@lists.real-time.com > > > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > > > = > > > > > > -- = > > > > > > -- > > > 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 > > > = > > > > > > --Boundary-02=3D_+nNtAIl4ANWMXXT > > > Content-Type: application/pgp-signature > > > Content-Description: signature > > > = > > > > > > -----BEGIN PGP SIGNATURE----- > > > Version: GnuPG v1.2.4 (GNU/Linux) > > > = > > > > > > iD8DBQBAtNn+HHGOa1Q2wXwRAjhIAKDWfeFAXNdcB/1SLhDZKSAW8lDsHQCgxMXw > > > iE35FxBo0h2fBWijgAZsRWE=0C0b > > > -----END PGP SIGNATURE----- > > > = > > > > > > --Boundary-02=3D_+nNtAIl4ANWMXXT-- > > > = > > > > > > = > > > > > > = > > > > _______________________________________________ > > crossfire-devel mailing list > > crossfire-devel@lists.real-time.com > > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > > - -- > - -- > David Delbecq > d.delbecq@laposte.net > 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 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.4 (GNU/Linux) > > iD8DBQFAtkA3HHGOa1Q2wXwRAhANAJ0YGTvxyn1q7xLOUXfMiMfguH6PPACg3kOb > /cmcH2/TwUHOxHj14CUlsc0= > =SMXI > -----END PGP SIGNATURE----- > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Thu May 27 21:40:30 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:39 2005 Subject: [CF-Devel] Icestorm - could not move - death References: <004001c44182$a1431ae0$0100000a@archaios> <1085413581.2909.19.camel@oberon.kameria> Message-ID: <00dd01c4445d$24acacc0$0100000a@archaios> Another point: the name of the game isn't realism. Maybe you missed it, but, besides challenging, the game is supposed to be *fun*. Being killed by an icestorm gone awry is not. Stupid effect, at best - the new behaviour cheapens the effect of earth walls, among other spells... -archaios ----- Original Message ----- From: "Todd Mitchell" To: "crossfire dev" Sent: Tuesday, May 25, 2004 1:46 AM Subject: Re: Re: Re: [CF-Devel] Icestorm - could not move - death > In real-life (if it even matters) heavy winds cause damage to property > every day - even to the point to tearing the roof off of buildings and > flipping over vehicles so I don't see how it is such a ridiculous notion > - let alone an 'utterly ridiculous' one. I have been out in a moderate > blizzard and believe me it is hard to move, hard to see and hard to do > anything while the freezing wind and snow whips past. As for fire - > even excluding the heat that much air moving is certainly a force to be > considered. More unusual is that in the game they do *not* push objects > IMHO. Anyway I removed the weights from icestorm and firebreath/burning > hands so they will not use the knockback effect. Windstorm I have left > alone as it *always* used this code in the past and the new wave spell I > have also left alone since no existing maps use it. > As I said before the knockback effect was not new. Perhaps the move > object function is highlighting the problem however in that it appears > to have an paralyzing effect on players in addition to pushing them. > Anyway my mistake was to apply weights to incorporate a new effect in > some existing spells and I have corrected that in CVS. > > On Mon, 2004-05-24 at 07:31, David McIlwraith wrote: > > I agree. The new effect of icestorm, &c. that *moves* objects is utterly > > ridiculous: in real life, would one expect an 'ice storm' to actually push a > > great distance? > > > > I think not. Same for 'burning hands', et al and all the other area spells > > that have been negatively affected. > > > > -archaios > > > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Thu May 27 21:43:43 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:39 2005 Subject: [CF-Devel] remove curse spell broken References: <1084124008.29597.11.camel@d5110227.lss.emc.com> <40A07891.30704@sonic.net><009601c44184$9ef01840$0100000a@archaios> <40B1E5CA.5000708@laposte.net> Message-ID: <011e01c4445d$97a09f70$0100000a@archaios> I don't agree. The "god present" is an extremely easy effect to obtain, and there is *no reason* why the spell can't serve the same purpose, perhaps uncursing one un-applied item at a time. -archaios ----- Original Message ----- From: "Nicolas Weeger" To: Sent: Monday, May 24, 2004 10:08 PM Subject: Re: [CF-Devel] remove curse spell broken > David McIlwraith wrote: > > On a related note, why doesn't remove curse/remove damned work on items that > > are not applied, a la praying at an altar? This would be far more useful > > behaviour. > > That's how it works. > And that's actually pretty right, considering what 'curse' means: can't > remove once applied. So well, remove curse obviously can't work for non > applied items :) > And the 'remove curse from non cursed items' is a god present, so it > shouldn't be easy to get when not praying... > > Nicolas > > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Thu May 27 23:35:06 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:39 2005 Subject: [CF-Devel] Fog Of War code in Gtk In-Reply-To: <1085711558.4083.33.camel@oberon.kameria> References: <200405272123.38072.d.delbecq@laposte.net> <1085711558.4083.33.camel@oberon.kameria> Message-ID: <40B6C17A.9050306@sonic.net> Todd Mitchell wrote: > In a realtime strategy game fog of war is very much a part of the game > as these games have an exploration and sphere of influence component as > part of the game mechanism. In an RPG - fog of war is not helpful in > the same way and in fact may even be misleading or unhelpful in some > conditions since it shows things that were and not thing that are. Also > your sphere of influence is a lot smaller and you can move a lot quicker > in crossfire. Now a spell that expanded your field of vision is a lot > more interesting to me than fog of war. > > As for fun - I'm entitled to have an opinion on fun as well. > Netrek is fun. (this is not an out of the blue reference). > Automatic food consumption is not really fun. > Suspense and challange and good gameplay is fun. > Instant gratification is not always fun. > > Personally I didn't mind the fog of war especially since it is something > you can turn on and off in the client but you have made me decide not to > use it for a while to see if I enjoy life more without it. I was about to comment that since fog of war can be turned off, I don't see any issue with having it in the game/client. People can use the tool if they want to, disable it if they don't. I personally find it is convenient to know if you've grabbed everything on the map, without having to re go down every hallway, etc - you can pretty quickly see if something is left behind or not. So in that regard, it is a time saver. Re, no darkening of grey - I like it - blue is perhaps a good choice in that it is normally used to denote darkness and shadows for most things. I wonder if it could just be a bit more blue, or perhaps instead of adding more blue, reduce the intensity of the other colors (eg, leave the blue value as is, but reduce the green and red values). Or maybe make this a setting, as it seems the color rendering on different monitors varies quite a bit - on one of my monitors, it is more blue, and thus much more visible a change, compared to the other monitor, where the change in color is much more subdued. As far as drawing the not visible spaces something different - I think it will be difficult to find something that is going to look better than black. The problem with smoothing the edges is that it could seem pretty odd if the map doesn't otherwise use darkness. OTOH, it is perhaps more realistic - things fade from view. One of the things I always wanted to do was have partial blocking. EG, something like fog wouldn't completely obscure your view, but reduce it by say 50%, so then everything behind it should be darker (effectively). A second fog would block the view 100%. This could be really nice for things like forests/jungles - you can see a few rows in, with diminishing visibility, and then it just gets completely dark. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Fri May 28 00:32:34 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:39 2005 Subject: [CF-Devel] remove curse spell broken In-Reply-To: <011e01c4445d$97a09f70$0100000a@archaios> References: <1084124008.29597.11.camel@d5110227.lss.emc.com> <40A07891.30704@sonic.net><009601c44184$9ef01840$0100000a@archaios> <40B1E5CA.5000708@laposte.net> <011e01c4445d$97a09f70$0100000a@archaios> Message-ID: <40B6CEF2.50803@sonic.net> David McIlwraith wrote: > I don't agree. The "god present" is an extremely easy effect to obtain, and > there is *no reason* why the spell can't serve the same purpose, perhaps > uncursing one un-applied item at a time. But as I recall, not all gods give that effect. So if the effect is cheapened by letting the remove curse spell take care of it, that potentially makes some gods less desirable. And as you say, it is easy effect to obtain, so probably isn't a big reason to add it to the spell. One note about having it be as something you have to pray for is that it also makes it a little less difficult to just remove curse from objects while your deep in the dungeon or the like, and to me, that seems like a good thing. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Fri May 28 16:02:51 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:40 2005 Subject: [CF-Devel] Bug in stealing code Message-ID: <20040528210251.GA13849@idefix2.dvlp.in-medias-res.com> When an attempt to steal an item fails, the moved object may vanish from the inventory view in the client. In server/skills.c the function attempt_steal() reads else if (roll < chance ) { if (op->type == PLAYER) esrv_del_item(op->contr, tmp->count); pick_up(who, tmp); The function pick_up() may fail (for various reasons). When this happens, the item has been removed from the inventory view but may actually remain in the inventory. My attached patch tries to fix this. I tested it (player stealing from monster into inventory or container; monster stealing from player with or without success) but I still have some questions: 1. I assume that for(tmp = op->inv; tmp != NULL; tmp = next) assert(tmp->env == op); hold for all items in the game. Is this assumption correct? If not: how can I detect if the object was actually moved? (The current "who == is_player_inv(tmp)" does not hold for monsters stealing items, I presume.) 2. If the function pick_up() destroys the object (though don't know if that can happen here) attempt_steal() uses this object afterwards (as "tmp" or "success"). Is this acceptable? 3. The character weight in the client does not get updated. Even the command 'fix_me' executed from the client does not fix it. How should I fix this issue? -------------- next part -------------- Index: server/skills.c =================================================================== RCS file: /cvsroot/crossfire/crossfire/server/skills.c,v retrieving revision 1.51 diff -u -w -r1.51 skills.c --- server/skills.c 12 May 2004 04:43:06 -0000 1.51 +++ server/skills.c 28 May 2004 19:41:19 -0000 @@ -146,15 +146,18 @@ if((chance=adj_stealchance(who,op,(stats_value+skill->level * 10 - op->level * 3)))==-1) return 0; else if (roll < chance ) { - if (op->type == PLAYER) - esrv_del_item(op->contr, tmp->count); + tag_t tmp_count = tmp->count; + pick_up(who, tmp); /* need to see if the player actually stole this item - * if it is in the players inv, assume it is. This prevents * abuses where the player can not carry the item, so just * keeps stealing it over and over. */ - if (who == is_player_inv(tmp)) { + if(was_destroyed(tmp, tmp_count) || tmp->env != op) { + if(op->type == PLAYER) { + esrv_del_item(op->contr, tmp_count); + } /* for players, play_sound: steals item */ success = tmp; CLEAR_FLAG(tmp, FLAG_INV_LOCKED); -------------- next part -------------- _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Sat May 29 02:26:27 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:40 2005 Subject: [CF-Devel] DM - God Finger - bleah! Message-ID: <200405290226.27153.eracclists@bellsouth.net> Greetings Developers, While in DM mode I noticed that DMs cannot "see invisible". A player had equipped God Finger and was invisible to me even though I was DM. I would think that DM, an all powerful being, would be able to see invisible automatically without having to cast the spell "show invisible". A problem player could use God Finger to keep a DM from seeing what s/he was doing. Having to cast a spell to make the player visible would defeat a DMs ability to hide and watch a problem player that had equipped God Finger. Another problem. Players should pass through DMs as if the DM is an ethereal being. If bumped while hidden a player will try to push a hidden DM. I'm betting they see something about this in the message window. This sort of defeats the purpose of being hidden. If players ALWAYS passed through a DM that would be a good thing I think. At the least a player should pass through a DM when the DM is hidden. So, what do you think? Am I being silly or are these something that should be addressed? TIA Gene (poof|Galahad) -- Linux era4.eracc.UUCP 2.4.22-28mdkenterprise i686 01:55:49 up 90 days, 19:50, 14 users, load average: 0.04, 0.06, 0.25 ERA Computer Consulting - http://www.eracc.com/ eCS, OS/2, Mandrake GNU/Linux, OpenServer & UnixWare resellers _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Sat May 29 03:07:50 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:40 2005 Subject: [CF-Devel] DM - God Finger - bleah! In-Reply-To: <200405290226.27153.eracclists@bellsouth.net> References: <200405290226.27153.eracclists@bellsouth.net> Message-ID: <200405291007.59312.tchize@myrealbox.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I agree with you a dm should be able to spy a specific player to see if he goes against the policy rules of the server. Anyway as dm is the most powerfull thing in game, to help spy, why not have a command like 'spy playername' which would make the dm goes out of his corpse and in that player corpse? So no need to be invisible or pass thru, you see EXACTLY what the spied player see, thru his eyes. Perhaps adding some more complicated things like getting a copy of all messages send to player (except for the tells and says only things like shouts, and notify messages, we don't want to get private conversations of the player, that may be illegal in most countries!) Le samedi 29 Mai 2004 09:26, ERACC a ?crit : Greetings Developers, While in DM mode I noticed that DMs cannot "see invisible". A player had equipped God Finger and was invisible to me even though I was DM. I would think that DM, an all powerful being, would be able to see invisible automatically without having to cast the spell "show invisible". A problem player could use God Finger to keep a DM from seeing what s/he was doing. Having to cast a spell to make the player visible would defeat a DMs ability to hide and watch a problem player that had equipped God Finger. Another problem. Players should pass through DMs as if the DM is an ethereal being. If bumped while hidden a player will try to push a hidden DM. I'm betting they see something about this in the message window. This sort of defeats the purpose of being hidden. If players ALWAYS passed through a DM that would be a good thing I think. At the least a player should pass through a DM when the DM is hidden. So, what do you think? Am I being silly or are these something that should be addressed? TIA Gene (poof|Galahad) - -- - -- 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAuETcHHGOa1Q2wXwRAjbzAKDDB3ruTc0mQC5v+kXn1+49n+0u6QCgwlKC XGaFlUxWrW4TpZJ/GcU0Zkg= =vmvm -----END PGP SIGNATURE----- _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Sat May 29 08:10:55 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:40 2005 Subject: [CF-Devel] DM - God Finger - bleah! In-Reply-To: <200405290226.27153.eracclists@bellsouth.net> Message-ID: This is purely my opinion, but I think spying on someone brings up some "net-personality rights" problems. It's like "Big Bro" and such things should be considered. I know some muds, but in the fair ones creators, game masters, call them what you want have the spying ability while they _have_to_tell_this_ the person they are spying on. You could say "but even players can spy on others unnoticed", but anyone who brings up such an argument surely does not understand an important thing: It's about morality. DMs have responsibilities, not only rights. (So there are some things DMs should never do what players can. Like spying on others unnoticed. Don't forget - DMs have _powers_ as well!) (And of course I know there might be situations that you have to spy on someone _unnoticed_,like someone who is suspected of doing something "illegal", but if you are fair enough to him and to yourself, after the case you tell him the _reason_ of spying.) Besides this all, I agree that DMs should see invisible in DM mode automatically.(The see invisible spell is useless against God Finger anyway. Or if it's not, I know there _is_ at least one item that grants the wearer invisibility against which no "see invisible" spell works.) > Greetings Developers, > > While in DM mode I noticed that DMs cannot "see invisible". A player > had equipped God Finger and was invisible to me even though I was DM. > I would think that DM, an all powerful being, would be able to see > invisible automatically without having to cast the spell "show > invisible". A problem player could use God Finger to keep a DM from > seeing what s/he was doing. Having to cast a spell to make the player > visible would defeat a DMs ability to hide and watch a problem player > that had equipped God Finger. > > Another problem. Players should pass through DMs as if the DM is an > ethereal being. If bumped while hidden a player will try to push a > hidden DM. I'm betting they see something about this in the message > window. This sort of defeats the purpose of being hidden. If players > ALWAYS passed through a DM that would be a good thing I think. At the > least a player should pass through a DM when the DM is hidden. > > So, what do you think? Am I being silly or are these something that > should be addressed? TIA > > Gene (poof|Galahad) > -- > Linux era4.eracc.UUCP 2.4.22-28mdkenterprise i686 > 01:55:49 up 90 days, 19:50, 14 users, load average: 0.04, 0.06, 0.25 > ERA Computer Consulting - http://www.eracc.com/ > eCS, OS/2, Mandrake GNU/Linux, OpenServer & UnixWare resellers > > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Sat May 29 12:59:09 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:40 2005 Subject: [CF-Devel] Scorn Sale Shop - big world In-Reply-To: <200405241507.40447.eracclists@bellsouth.net> References: <200405202241.41892.eracclists@bellsouth.net> <1085425879.3314.35.camel@oberon.kameria> <200405241507.40447.eracclists@bellsouth.net> Message-ID: <200405291259.09751.eracclists@bellsouth.net> On Monday 24 May 2004 15:07 ERACC wrote: > On Monday 24 May 2004 14:11 > > Todd Mitchell wrote: > > Yes I know what you mean - but it is no wonder people dislike the > > bigworld maps if taking 23 steps is such a chore. I suspect if > > that is too far then no amount of distance is going to make > > people use it. They would rather dump it onto the ground anyway. [...] > > Ok, I'll go with the general consensus on this list then. Hmmm, no one votes. Ok. I will do the following. > - Move the General Store to south Scorn, move the sale shop > across from the apartments and put a "no littering" sign on > the square. I haven't figured out how to create a new image and archetype for the store (little extra time). So, I'll use an existing building. Of course, Todd, if you have something new I could use I'd be happy to use it. :-) BTW, to make a "diff" do I just run the diff command with specific switches? If so which switches? An example would be great. TIA Gene (poof|Galahad) -- Linux era4.eracc.UUCP 2.4.22-28mdkenterprise i686 12:46:18 up 91 days, 6:41, 14 users, load average: 0.02, 0.03, 0.00 ERA Computer Consulting - http://www.eracc.com/ eCS, OS/2, Mandrake GNU/Linux, OpenServer & UnixWare resellers _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Sat May 29 17:05:32 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:40 2005 Subject: [CF-Devel] Map bug Message-ID: <40B9092C.5000505@laposte.net> Hello. On cf.mf.net, players had some issue with map sisters/necro_ruin1. They were in the 2 square space south of map, and couldn't get out. Youg et there through a trapdoor, on which a cooblestone is (and a pushable statue). It seems the cobblestones too fell through the trapdoor, getting on the ladder back up & trapping players. Did someone change behaviour of trapdoors? Or is it a map bug? Nicolas _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Sun May 30 09:57:22 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:40 2005 Subject: [CF-Devel] Hard skill: inscription Message-ID: <40B9F652.4020606@laposte.net> Hello. Inscription is, imo, too hard to level into. I'm level 24 (got xp via undefined skill bug on rods/wands), and when i write a level 16 spell (nightfall), i get 700xp. I'll let to the reader as an exercice how many scrolls need to be written to level :) Ok, leveling in inscription doesn't have that much interest at first sight, but it lets use high-level spells without using mana/gr (nightfall, or sanctuary, protection from xxx and such), and also cast spells you can't use else (i'm a Gaea fellower and can't cast diseases, but i can write'em, and then use the written scroll. granted, i can find scrolls, but funnier to write some :)) My suggestion would be to add a multiplier to experience based on level. I think alchemy does that, already. What do you think? Nicolas _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Sun May 30 11:37:42 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:40 2005 Subject: [CF-Devel] Hard skill: inscription In-Reply-To: <40B9F652.4020606@laposte.net> References: <40B9F652.4020606@laposte.net> Message-ID: <40BA0DD6.7000900@laposte.net> Forgot to add :) I'll suggest multiplying exp by something like (level/2). This way a level 20 player would get approx 8k per scroll (ok, that means he'll still need some thousand scrolls...) _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Sun May 30 23:23:46 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:40 2005 Subject: [CF-Devel] Hard skill: inscription In-Reply-To: <40BA0DD6.7000900@laposte.net> References: <40B9F652.4020606@laposte.net> <40BA0DD6.7000900@laposte.net> Message-ID: <40BAB352.6020800@sonic.net> Nicolas Weeger wrote: > Forgot to add :) > I'll suggest multiplying exp by something like (level/2). > This way a level 20 player would get approx 8k per scroll (ok, that > means he'll still need some thousand scrolls...) This is an effect of the simple skill system. When using that, it basically says don't factor level into calculation. This makes sense for things like monsters - an orc is always 10 exp (or whatever) no matter what level you are and the orc is. If non simple is used, exp is adjusted, based on your level and that of the target. For inscription, I agree it doesn't make a lot of sense, because they only way we can calculate a meaningful exp total is to do it ourselves. Note that the code does give exp based on the value of the scroll - higher level scrolls are generally worth more, but this is probably closer to a linear scale, which doesn't work out as well since exp is not linear. It also perhaps doesn't make a lot of sense, since the value may not really match the difficulty - difficulty is based 100% on level of the desired spell. So I guess after saying all that, I have no problem factoring level in. However, I'd be tempted to just put the code you want into the inscription routine, and not call calc_skill_exp() at all, since I think if you did so after manipulating it for level, you could get some really odd effects for people using the non simple exp system. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Sun May 30 23:33:23 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:40 2005 Subject: [CF-Devel] Map bug In-Reply-To: <40B9092C.5000505@laposte.net> References: <40B9092C.5000505@laposte.net> Message-ID: <40BAB593.7010909@sonic.net> Nicolas Weeger wrote: > Hello. > > On cf.mf.net, players had some issue with map sisters/necro_ruin1. > They were in the 2 square space south of map, and couldn't get out. > Youg et there through a trapdoor, on which a cooblestone is (and a > pushable statue). > It seems the cobblestones too fell through the trapdoor, getting on the > ladder back up & trapping players. > > Did someone change behaviour of trapdoors? Or is it a map bug? It does not appear that the code has changed for a long time at least (looking back at the 1.4.0 code, it appears the trapdoor and move_ob code is exactly the same as it is now, and that is about 20 months back). That said, one could add some basic sanity checking, like not have floors drop through. But I'm not sure if that might not break other maps. It's also potentially possible that the logic for choosing the space to drop objects has changed, but I don't think that is the case either. So I'd probably attribute this to broken map. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Sun May 30 23:38:16 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:40 2005 Subject: [CF-Devel] Scorn Sale Shop - big world In-Reply-To: <200405291259.09751.eracclists@bellsouth.net> References: <200405202241.41892.eracclists@bellsouth.net> <1085425879.3314.35.camel@oberon.kameria> <200405241507.40447.eracclists@bellsouth.net> <200405291259.09751.eracclists@bellsouth.net> Message-ID: <40BAB6B8.70501@sonic.net> ERACC wrote: > BTW, to make a "diff" do I just run the diff command with specific > switches? If so which switches? An example would be great. TIA I typically do 'cvs diff -cw'. You can specify which file/directory to diff - by default, it will do the current directory and all subdirectories. -c is a context diff - includes the 3 lines before and after the actual changes. This is really nice for code changes, because you can see the code around what is being changed, and thus have a better idea (context) of the actual change. -w says don't show diffs that are only whitespace changes. This doesn't come up that much unless making formatting changes, but still handy. For archs, -c still applies, but can be just as clear to include the entire arch. For maps, diffs make no real sense, other than to provide a way to get the changes out there (hard to look at the diffs on a map and get much idea of the changes - really need to load it into the editor). _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Sun May 30 23:56:01 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:40 2005 Subject: [CF-Devel] DM - God Finger - bleah! In-Reply-To: References: Message-ID: <40BABAE1.7040704@sonic.net> In terms of privacy issues, hard to say. One can make the case that if you were a police officer and had to tell someone if they were under surveillance, you'd never actually catch them doing anything (or they are really stupid criminals). One can make the same case for crossfire - if there is a report of abuse, the DM may want to check it out, and not notify the player involved. Because if the player suddenly got a notice 'you are under surveillance', of course that player is going to stop doing whatever abusive actions. I personally find it hard to envision what one would do in crossfire that is so secretive. I could see things like private messages perhaps - even to the extent of things like 'says', if a couple players on by themselves on a map and are thinking of having a private conversation. As far as a 'snoop' for the dm - to see what the player sees without being there, this probably isn't that hard to do. Add something a field to the player/socket, and when a dm starts to snoop, that is set to point to the player he is snooping on. Then when it comes time to render the map, it uses the data for the snooped player, and not the one the dm is currently on. One could extend this a bit of course - include things like the commands the player enters, so you could see if they are invoking spells and what not. Because as I think about it, trying to discern/filter messages is very difficult - by the time new_draw_info() gets the message, and that is the obvious place to send a copy to the dm, there isn't really any context about the message itself, other than color. So you could perhaps say 'if the color is ..., don't send to snooping dm'. (aside, one of the things on the TODO list is to change the passed in values to be context and not color). Now going back to the original issue - DM's not being able to see invisible - that is actually much more difficult to fix. That is because each square is generated once, and every player that can see it, sees the same thing. If you notice for example, see invisible is actually an area of effect spell (makes invisible things visible for everyone), and not a personal spell such that only the caster can see the invisible objects. So to make that work for the DM, the map code would have to get redone - now for each and every space, you'd have to figure out what the dm sees special. This perhaps get easier if we limit see invisible of dm's to only see invisible players, which may be what is really desired. That is a bit simpler (can fairly quickly cycle through all the players, see if any are invisible, and treat that special). As far as blocking players - the DM is a living creature, and thus when it goes to check if the space is blocked, it sees there is a living creature there, and then finds that there is the DM. This may be simpler to fix - the update_space() code (or is it update_position()) could be modified - if the creature is a player, and has DM set, don't set the flags for that space. However, I'm not 100% if that will fix everything - monsters may still be able to 'find' the DM, because they search the list of players for nearby players (as a shortcut of searching all the spaces). That could certainly get changed to skip DM's, etc, but there might be lots of bits like that. So if the goal is really to be able to spy on players, adding a spy/snoop command is probably the way to go. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Mon May 31 03:56:01 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:40 2005 Subject: [CF-Devel] DM - God Finger - bleah! In-Reply-To: <40BABAE1.7040704@sonic.net> References: <40BABAE1.7040704@sonic.net> Message-ID: <200405311056.16392.tchize@myrealbox.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Well some player may discuss real life thing on a 'tell' basis, like other people use irc private chats to do this. You may argue the tell command is not easy to use and so is not really used. May change in future (the sdl client should provide a chat area based on tell / shout / say commands). One easy way i see to spy while taking care of privacy is this one: 1) Have server log **every** attempt to spy a player on a file (server owner is responsible for checking this file on a regular basis for dm abuses) 2) Have a policy amongst the dms which says a player can only be spyed by a dm (don't care which dm, if a player is under investigation, any dm online at the moment of login may be able to spy him) if at least 3 dms agree this player need spying. Perhaps also define policy for the 'need spying'. 3) Have an investigation file containing name of players under investigations. This file should contain name of player and for each of the 3 dms who approved the investingation, a comment on the reason of investigation. The dms who allowed the investigation (probably with a command like 'vote spying playername reason') shouldn't be allowed to do the investigation themself (this prevent abuses, though we should thrust the dms, at least a little bit ;) 4) at any time, any dm who approved the investigation can unapprove it. The investigation will then end and track will be kept of who approved the investigation and for what reason. 5) When an investigation end, have the player notified automatically he had been under investigation, have him shown the name of the 3 dms who approved the investigation and perhaps also the name of dm who spyed him. This way spying is not a common thing to do and can't be done unnotified. Of course, the number of '3' dms for approval could be configured so small servers don't need a pack of fake dm to do the job and big servers could need more dms for approval. Le lundi 31 Mai 2004 06:56, Mark Wedel a ?crit : In terms of privacy issues, hard to say. One can make the case that if you were a police officer and had to tell someone if they were under surveillance, you'd never actually catch them doing anything (or they are really stupid criminals). One can make the same case for crossfire - if there is a report of abuse, the DM may want to check it out, and not notify the player involved. Because if the player suddenly got a notice 'you are under surveillance', of course that player is going to stop doing whatever abusive actions. I personally find it hard to envision what one would do in crossfire that is so secretive. I could see things like private messages perhaps - even to the extent of things like 'says', if a couple players on by themselves on a map and are thinking of having a private conversation. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAuvMoHHGOa1Q2wXwRAsnBAJ43YqXzMkYNl5wGcAZ+sddTTbLg9ACfbSsD xNjszxGZuXQidQsnZxttkOk= =c9xu -----END PGP SIGNATURE----- _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Mon May 31 04:15:47 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:41 2005 Subject: [CF-Devel] DM - God Finger - bleah! In-Reply-To: <40BABAE1.7040704@sonic.net> Message-ID: > > In terms of privacy issues, hard to say. > > One can make the case that if you were a police officer and had to tell > someone if they were under surveillance, you'd never actually catch them doing > anything (or they are really stupid criminals). > > One can make the same case for crossfire - if there is a report of abuse, the > DM may want to check it out, and not notify the player involved. Because if the > player suddenly got a notice 'you are under surveillance', of course that player > is going to stop doing whatever abusive actions. I too mentioned this, and said it would be fair telling the player that (s)he was being observed - after "the case is closed". On the other hand, CF is (yet?) a small community, I can hardly imagine "corrupt" bad DMs who override their commissions. I hope it'll never happen, and I think we can say we don't have to worry about this. But it could be a good stance - let's not forget, children play CF as well, it's not irrelevant what we show them there. And what's fair - it's fair, no matter it's in the game or in reality. Besides, surveillance methods which tell players that they are being snooped would be more _efficient_ than one would think! As I said, CF has a small community, and if the message was not only 'you are under surveillance' but 'X is under surveillance by Y' would be much better, cause other players would know the fact that a certain player is suspicous. It could be some kind of a warning for X. If X was under surv. for several times, peepo would know he's a problematic guy. Kinda more "democratic" too. > I personally find it hard to envision what one would do in crossfire that is > so secretive. I could see things like private messages perhaps - even to the > extent of things like 'says', if a couple players on by themselves on a map and > are thinking of having a private conversation. Personally I find it hard too. BUT, as for one reason - one that's not to be neglected - peepo hate to know they can be observed anytime. And _this_ fact they _really_ should know. (I mean - the fact that they _can_ be under surveillance anytime, without a warning.) How would it look like in the MOTD: "On this server you may be observed secretely by a DM anytime." And don't tell me anybody it wouldn't be fair! And for example there may be peepo who could seem to be "crazy" for a usual observer. (Like having strange habits. For example moving in a circle in his apt in every 15 min, etc. If I were such a player I wouldn't like the thought some DM could see me while doing such things, maybe laughing at me and telling his/her friends...) > As far as a 'snoop' for the dm - to see what the player sees without being > there, this probably isn't that hard to do. Add something a field to the > player/socket, and when a dm starts to snoop, that is set to point to the player > he is snooping on. Then when it comes time to render the map, it uses the data > for the snooped player, and not the one the dm is currently on. > > One could extend this a bit of course - include things like the commands the > player enters, so you could see if they are invoking spells and what not. > Because as I think about it, trying to discern/filter messages is very difficult > - by the time new_draw_info() gets the message, and that is the obvious place to > send a copy to the dm, there isn't really any context about the message itself, > other than color. So you could perhaps say 'if the color is ..., don't send to > snooping dm'. (aside, one of the things on the TODO list is to change the passed > in values to be context and not color). > > Now going back to the original issue - DM's not being able to see invisible - > that is actually much more difficult to fix. > > That is because each square is generated once, and every player that can see > it, sees the same thing. If you notice for example, see invisible is actually > an area of effect spell (makes invisible things visible for everyone), and not a > personal spell such that only the caster can see the invisible objects. > > So to make that work for the DM, the map code would have to get redone - now > for each and every space, you'd have to figure out what the dm sees special. > > This perhaps get easier if we limit see invisible of dm's to only see > invisible players, which may be what is really desired. That is a bit simpler > (can fairly quickly cycle through all the players, see if any are invisible, and > treat that special). > > As far as blocking players - the DM is a living creature, and thus when it > goes to check if the space is blocked, it sees there is a living creature there, > and then finds that there is the DM. > > This may be simpler to fix - the update_space() code (or is it > update_position()) could be modified - if the creature is a player, and has DM > set, don't set the flags for that space. However, I'm not 100% if that will fix > everything - monsters may still be able to 'find' the DM, because they search > the list of players for nearby players (as a shortcut of searching all the > spaces). That could certainly get changed to skip DM's, etc, but there might be > lots of bits like that. > > So if the goal is really to be able to spy on players, adding a spy/snoop > command is probably the way to go. > > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel