From crossfire-devel at archives.real-time.com Sun Feb 1 04:58:59 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:59 2005 Subject: [CF-Devel] Crossfire client 1.6.1 released! Message-ID: <200402011147.54672.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 Sun Feb 1 20:19:00 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:00 2005 Subject: [CF-Devel] Combat animations/sound Message-ID: Death animations are not needed. Thoes would get old. Fighting animations are needed though. I know the artwork would take a lot of work, but without it it is very hard to get into Crossfire. The slowing down combat would be a good idea as well. Adopt a... Quality > Quantity approach to the game Instead of 100 orcs, have 25 orcs 4 times as strong with 4 times the xp and such. _________________________________________________________________ Let the new MSN Premium Internet Software make the most of your high-speed experience. http://join.msn.com/?pgmarket=en-us&page=byoa/prem&ST=1 _______________________________________________ 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 Feb 1 21:57:04 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:00 2005 Subject: [CF-Devel] Combat animations/sound In-Reply-To: References: Message-ID: <1075675610.585.45.camel@oberon.kameria> I don't think that combat animations would be worth the effort. In fact it took me a while to animate most of the PC races and classes (this pretty much works as battle animation BTW, in addition to telling you when you are blocked or just lagged). Even these simple animations take a long time to do and have not been finished so I don't see much hope of adding in whole new 'layer' of animation. I would for a start like to see all the arches that need animation animated though. Been puttering away at that actually, hopefully large images will help make that more accessable to people. As for death animations - perhaps some sort of red flash or other death notification would actually be pretty good if it was subtle. I've wanted some sort of aura system for a while now so you could easily see poision and magic states like cursed and blessed or whatever. I think there was discussusion of this in relation to the smoothing code in the client? A death 'aura' could use this sort of system too. > Death animations are not needed. Thoes would get old. Fighting animations > are needed though. I know the artwork would take a lot of work, but without > it it is very hard to get into Crossfire. The slowing down combat would be > a good idea as well. > > Adopt a... > Quality > Quantity approach to the game > > > Instead of 100 orcs, have 25 orcs 4 times as strong with 4 times the xp and > such. That would be great for a game not based on Gauntlet, but the CF combat system is based in the mob approach to combat and IMHO many of the better maps are more like tetris than diablo if you get my meaning. Quality is derived from the experience of the entire game, not any specific implementation - 100 orcs is better than 25 if the map (or the combat system) was designed for 100 orcs. -my two cents anyway, Todd. _______________________________________________ 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 Feb 4 17:23:09 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:00 2005 Subject: [CF-Devel] Fwd: [Crossfire-cvs] CVS commit: crossfire/doc Message-ID: <200402041719.06782@Twin.Cities.Linux.Users.Group-www.mn-linux.org> What the heck, I made the following changes to the Makefile.am, did an automake from the main project directory, for just the doc directory and now the rules for installing the man pages are gone. -- 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 -------------- next part -------------- An embedded message was scrubbed... From: crossfire-cvs-admin@lists.sourceforge.net Subject: [Crossfire-cvs] CVS commit: crossfire/doc Date: Wed, 04 Feb 2004 12:51:03 -0800 Size: 4948 Url: http://shadowknight.real-time.com/pipermail/crossfire/attachments/20040204/a378bd84/attachment.mht -------------- 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 Feb 5 09:29:36 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:00 2005 Subject: [CF-Devel] Ball Lightning and fear Message-ID: <1075994448.24580.36.camel@d5110227.lss.emc.com> I believe I just observed ball lightning reacting to fear. Is this possible? If so, is it a feature or a bug? --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 Thu Feb 5 16:38:01 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:00 2005 Subject: [CF-Devel] Crossfire client 1.6.1 released! In-Reply-To: <200402011147.54672.tchize@myrealbox.com> References: <200402011147.54672.tchize@myrealbox.com> Message-ID: <200402051636.28656@Twin.Cities.Linux.Users.Group-www.mn-linux.org> On Sunday 01 February 2004 4:47 am, tchize wrote: > Crossfire client 1.6.1 has been released. > This version is mainly a bug fix version of 1.6.0. It also comes with some > additional features. Client won't build unless you have gnome installed, even if you --disable-gnome. Ditto for client that is in cvs as of 02/05/2004. -- 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 Thu Feb 5 18:07:46 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:00 2005 Subject: [CF-Devel] Crossfire client 1.6.1 released! In-Reply-To: <200402051636.28656@Twin.Cities.Linux.Users.Group-www.mn-linux.org> References: <200402011147.54672.tchize@myrealbox.com> <200402051636.28656@Twin.Cities.Linux.Users.Group-www.mn-linux.org> Message-ID: <200402051751.22879@Twin.Cities.Linux.Users.Group-www.mn-linux.org> On Thursday 05 February 2004 4:36 pm, Bob Tanner wrote: > On Sunday 01 February 2004 4:47 am, tchize wrote: > > Crossfire client 1.6.1 has been released. > > This version is mainly a bug fix version of 1.6.0. It also comes with > > some additional features. > > Client won't build unless you have gnome installed, even if you > --disable-gnome. > > Ditto for client that is in cvs as of 02/05/2004. Had to install the gnome development packages. ./configure -not- using --disable-gnome Worse: $ cd gnome/ $ make echo "Gnome client currently not supported" Gnome client currently not supported Argh! Doesn't make sense to force the gnome development environment to be installed, so configure can work and not even allow the building of the gnome client. If it's not supported, I vote to remove it from configure. -- 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 Fri Feb 6 01:13:13 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:00 2005 Subject: [CF-Devel] Fwd: [Crossfire-cvs] CVS commit: crossfire/doc In-Reply-To: <200402041719.06782@Twin.Cities.Linux.Users.Group-www.mn-linux.org> References: <200402041719.06782@Twin.Cities.Linux.Users.Group-www.mn-linux.org> Message-ID: <40233ED7.9010902@sonic.net> Bob Tanner wrote: > What the heck, I made the following changes to the Makefile.am, did an > automake from the main project directory, for just the doc directory and now > the rules for installing the man pages are gone. Make sure you have up to date, or at least relatively recent, automake and autoconf installed. _______________________________________________ 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 Feb 6 01:18:13 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:00 2005 Subject: [CF-Devel] Ball Lightning and fear In-Reply-To: <1075994448.24580.36.camel@d5110227.lss.emc.com> References: <1075994448.24580.36.camel@d5110227.lss.emc.com> Message-ID: <40233F46.3040606@sonic.net> Preston Crow wrote: > I believe I just observed ball lightning reacting to fear. Is this > possible? If so, is it a feature or a bug? I'd call it a bug. I can certainly envision how it could happen however. _______________________________________________ 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 Feb 6 01:42:38 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:00 2005 Subject: [CF-Devel] Crossfire client 1.6.1 released! In-Reply-To: <200402051636.28656@Twin.Cities.Linux.Users.Group-www.mn-linux.org> References: <200402011147.54672.tchize@myrealbox.com> <200402051636.28656@Twin.Cities.Linux.Users.Group-www.mn-linux.org> Message-ID: <4023434A.3090309@sonic.net> Bob Tanner wrote: > On Sunday 01 February 2004 4:47 am, tchize wrote: > >>Crossfire client 1.6.1 has been released. >>This version is mainly a bug fix version of 1.6.0. It also comes with some >>additional features. > > > Client won't build unless you have gnome installed, even if you > --disable-gnome. > > Ditto for client that is in cvs as of 02/05/2004. > > Just fixed this in CVS (basically, don't even bother checking for gnome, since we don't need it) _______________________________________________ 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 Feb 6 10:12:34 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:00 2005 Subject: [CF-Devel] Talisman bugs Message-ID: <4023B9A7.7050708@laposte.net> Playing on crossfire.metalforge.net, there's a bug with talismans. I have a talisman of unified mind, but it's never used. Old skill system made it that player would automatically use a talisman when available, to boost magic (assuming player got the spell, of course, else talisman with that skill becomes required) So it seems talismans aren't used, and holy symbols aren't either... 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 Sat Feb 7 22:42:37 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:00 2005 Subject: [CF-Devel] Talisman bugs In-Reply-To: <4023B9A7.7050708@laposte.net> References: <4023B9A7.7050708@laposte.net> Message-ID: <4025BCFF.9080302@sonic.net> Nicolas Weeger wrote: > Playing on crossfire.metalforge.net, there's a bug with talismans. > > I have a talisman of unified mind, but it's never used. Old skill system > made it that player would automatically use a talisman when available, > to boost magic (assuming player got the spell, of course, else talisman > with that skill becomes required) > > So it seems talismans aren't used, and holy symbols aren't either... I've just fixed the code so that you can now manually apply talismans and other skill objects. If applied, you then get whatever benefit they object provides when casting the spell. IT is intentional that the code uses innate/learned skills if available. One can argue that this is more realistic (if you can just cast something, you're not going to fumble about for a talisman/holy symbol). Some of this is code simplicity. Some of this is that there is no good answer - if you have a talisman that grants you a skill, but has some negative aspects (repelled or denied spellpaths), the question then comes up of whether you really want that to be used instead of a skill which may have no negative side effects. And in fact, I recall there were past complaints on auto apply talismans simply because of that (as a note, the order of a players inventory is effectively random, so you also get into problems of one time, talisman X might be used, but next time you play, talisman y). And I really don't want to go down the path of trying to find the right talisman for the spell. The skill code isn't really designed for that (the finding the necessary skill right now is quite abstract - it is used for all skills - I don't want something of 'well, if a spell is being cast, then the past object is the spell, so lets find the best talisman for that. Oh, user is using a a lockpicking skill - lets find best item for that, etc)'. So I think the fix is the best way to go - player can decide what talisman/holy symbol to use, or can just use the native skill they have if they select nothing. _______________________________________________ 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 Feb 8 08:46:55 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:00 2005 Subject: [CF-Devel] become_follower patch In-Reply-To: <20040125162311.14500a31.kstenger@montevideo.com.uy> References: <20040124172335.2b0c3aa3.kstenger@montevideo.com.uy> <40136CD9.1040802@sonic.net> <20040125162311.14500a31.kstenger@montevideo.com.uy> Message-ID: <20040208113301.7cc97205.kstenger@montevideo.com.uy> I was wondering if this patch was comitted to CVS -- +-----------------------------+ | 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 Feb 8 11:07:38 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:01 2005 Subject: [CF-Devel] sack_can_hold() patch Message-ID: <20040208135748.7547a72b.kstenger@montevideo.com.uy> just a missing return 0 that was making containers able to hold infinite weight. Katia. -- +-----------------------------+ | Karla M? Stenger S?bat | | Pando . Canelones . Uruguay | | kstenger@montevideo.com.uy | +-----------------------------+ -------------- next part -------------- A non-text attachment was scrubbed... Name: sack_can_hold_patch.diff Type: application/octet-stream Size: 539 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20040208/6ca6eba7/sack_can_hold_patch.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 Sun Feb 8 11:12:29 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:01 2005 Subject: [CF-Devel] become_follower patch In-Reply-To: <20040208113301.7cc97205.kstenger@montevideo.com.uy> References: <20040124172335.2b0c3aa3.kstenger@montevideo.com.uy> <40136CD9.1040802@sonic.net> <20040125162311.14500a31.kstenger@montevideo.com.uy> <20040208113301.7cc97205.kstenger@montevideo.com.uy> Message-ID: <40266D3A.9030207@laposte.net> Karla Stenger a ?crit : > I was wondering if this patch was comitted to CVS > Just committed it. 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 Sun Feb 8 11:27:50 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:01 2005 Subject: [CF-Devel] sack_can_hold() patch In-Reply-To: <20040208135748.7547a72b.kstenger@montevideo.com.uy> References: <20040208135748.7547a72b.kstenger@montevideo.com.uy> Message-ID: <40266EE4.1000805@laposte.net> Karla Stenger a ?crit : > just a missing return 0 that was making containers able to hold infinite weight. > > Katia. Committed it, as it was pretty obvious. 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 Sun Feb 8 23:41:52 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:01 2005 Subject: [CF-Devel] Combat animations/sound In-Reply-To: <1075675610.585.45.camel@oberon.kameria> References: <1075675610.585.45.camel@oberon.kameria> Message-ID: <40271D2F.6060806@sonic.net> Todd Mitchell wrote: > As for death animations - perhaps some sort of red flash or other death > notification would actually be pretty good if it was subtle. I've > wanted some sort of aura system for a while now so you could easily see > poision and magic states like cursed and blessed or whatever. I think > there was discussusion of this in relation to the smoothing code in the > client? A death 'aura' could use this sort of system too. Well, the entire map sending approach probably needs to be re-written. It is really a mess, and the extended map data just adds to that mess. But that is really a different topic. >> >>Instead of 100 orcs, have 25 orcs 4 times as strong with 4 times the xp and >>such. > > > That would be great for a game not based on Gauntlet, but the CF combat > system is based in the mob approach to combat and IMHO many of the > better maps are more like tetris than diablo if you get my meaning. > Quality is derived from the experience of the entire game, not any > specific implementation - 100 orcs is better than 25 if the map (or the > combat system) was designed for 100 orcs. Well, I think a fewer but tougher/longer approach is better. Now certainly, it can shift balance - spell casters, which have spells that hit a large area, but don't do a lot of damage per space, obviously prefer mobs of monsters that they can kill with such spells. If those 25 orcs was replaced with 1 orc, they'd be out of luck. However, if 100 orcs was replaced with 25 orcs, that would still balance out. But the issue is more going through and fixing all those maps. The mob of monsters is actually a no-no in the mapguide list. But going back and fixing all the maps current out there is no simple matter. _______________________________________________ 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 Feb 9 00:01:43 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:01 2005 Subject: [CF-Devel] Bug: resistances changes not always displayed In-Reply-To: <4015960B.1030803@laposte.net> References: <4015960B.1030803@laposte.net> Message-ID: <402721A4.2000206@sonic.net> Nicolas Weeger wrote: > Hello. > > Playing on crossfire.metalforge.net, latest cvs i guess. > > It seems resistances are not announced when going up. > IE pray on altar, get holy possession. You'll see the 'resistance to god > power goes down to 0', but not the going up :) > > Same goes for protection spells, and maybe other things... I fixed this for spells - should also fix it for altars, which I think just cast the spell on the player. I notice that for actual equipment (eg, rings) the message was properly printed. _______________________________________________ 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 Feb 9 06:17:24 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:01 2005 Subject: [CF-Devel] Combat animations/sound Message-ID: <1076328457.c892e69ctchize@myrealbox.com> Speaking about map protocol redo: Here are some map related suggestions that i plan to implement one day or another, as part of a complete protocol refresh/clean up - additionnal layers (bottom of everything, bottom, middle, top, on top of everything). Not yet fixed, see point below. - More than one visible item available in a layer (they just stack at that layer) - Map is made of 2 concurrent part: * The mostly fixed one (ground, buildings, non pickable/non killable items) * The non fixed one (mainly monsters and pickables). The mostly fixed part of map would be send to client only one time. This would includes additionnal info like blocked squares (so client can precalculate moves, and make things look softer). Changes to this part of map (which may happen from time to time) will trigger a patch event from server to client so map are against in sync. I am thinking about using a big picture for the map background/buildings/Walls(so mapmakers could design a map made of something else than squares) The dynamic part will be send in a way similar to actual one (but in a reworked protocol to have clean code) No need to say map animations would be handled only by client. -----Original Message----- From: Mark Wedel To: crossfire-devel@lists.real-time.com Date: Sun, 08 Feb 2004 21:39:59 -0800 Subject: Re: [CF-Devel] Combat animations/sound Todd Mitchell wrote: > As for death animations - perhaps some sort of red flash or other death > notification would actually be pretty good if it was subtle. I've > wanted some sort of aura system for a while now so you could easily see > poision and magic states like cursed and blessed or whatever. I think > there was discussusion of this in relation to the smoothing code in the > client? A death 'aura' could use this sort of system too. Well, the entire map sending approach probably needs to be re-written. It is really a mess, and the extended map data just adds to that mess. But that is really a different topic. >> >>Instead of 100 orcs, have 25 orcs 4 times as strong with 4 times the xp and >>such. > > > That would be great for a game not based on Gauntlet, but the CF combat > system is based in the mob approach to combat and IMHO many of the > better maps are more like tetris than diablo if you get my meaning. > Quality is derived from the experience of the entire game, not any > specific implementation - 100 orcs is better than 25 if the map (or the > combat system) was designed for 100 orcs. Well, I think a fewer but tougher/longer approach is better. Now certainly, it can shift balance - spell casters, which have spells that hit a large area, but don't do a lot of damage per space, obviously prefer mobs of monsters that they can kill with such spells. If those 25 orcs was replaced with 1 orc, they'd be out of luck. However, if 100 orcs was replaced with 25 orcs, that would still balance out. But the issue is more going through and fixing all those maps. The mob of monsters is actually a no-no in the mapguide list. But going back and fixing all the maps current out there is no simple matter. _______________________________________________ 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 Feb 9 07:21:39 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:01 2005 Subject: [CF-Devel] Combat animations/sound In-Reply-To: <1076328457.c892e69ctchize@myrealbox.com> References: <1076328457.c892e69ctchize@myrealbox.com> Message-ID: <402785FF.5040003@laposte.net> tchize a ?crit : (snipped most parts out) > The mostly fixed part of map would be send to client only one time. This would includes additionnal info like blocked squares (so client can precalculate moves, and make things look softer). Changes to this part of map (which may happen from time to time) will trigger a patch event from server to client so map are against in sync. I am thinking about using a big picture for the map background/buildings/Walls(so mapmakers could design a map made of something else than squares) The thing, though, is that client mustn't know more than player should. Because all sources are available. If you send all fixed info once and for all, any hacking player will be able to see this fixed part from the beginning, thus having more info than s/he should. So they only way is to send only what the player can see, nothing more. Making client handle animations is an obvious simplification, and would even let clients disable'em if they are too heavy on their computer :) 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 Feb 9 08:07:03 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:01 2005 Subject: [CF-Devel] Combat animations/sound Message-ID: <1076334739.43f1bf5ctchize@myrealbox.com> That's why 'mostly fixed' should be choosen with care. Nothing. Also note that client already knows more than player (aka disable darkness code an see better. i know complete dark is not send but nearly complete dark is alaos difficult to see). The main idea is to prevent sending map info to client if they are the same as in released maps. -----Original Message----- From: Nicolas Weeger To: crossfire-devel@lists.real-time.com Date: Mon, 09 Feb 2004 14:07:11 +0100 Subject: Re: [CF-Devel] Combat animations/sound tchize a ?crit : (snipped most parts out) > The mostly fixed part of map would be send to client only one time. This would includes additionnal info like blocked squares (so client can precalculate moves, and make things look softer). Changes to this part of map (which may happen from time to time) will trigger a patch event from server to client so map are against in sync. I am thinking about using a big picture for the map background/buildings/Walls(so mapmakers could design a map made of something else than squares) The thing, though, is that client mustn't know more than player should. Because all sources are available. If you send all fixed info once and for all, any hacking player will be able to see this fixed part from the beginning, thus having more info than s/he should. So they only way is to send only what the player can see, nothing more. Making client handle animations is an obvious simplification, and would even let clients disable'em if they are too heavy on their computer :) Nicolas 'Ryo' _______________________________________________ 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 Feb 9 13:21:36 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:01 2005 Subject: [CF-Devel] Combat animations/sound In-Reply-To: <1076334739.43f1bf5ctchize@myrealbox.com> References: <1076334739.43f1bf5ctchize@myrealbox.com> Message-ID: <1076335959.550.16.camel@oberon.kameria> I beg of you guys to crack open the blocking code before working on fixes for a new clean protocol for the client. Or at least plan for changes. Blocking right now is a huge handicap for both skill creation and map making. A simple blocking system that allows for flying over stuff (including missiles and spells), swimming/sailing, mountain climbing and other types of movement would be so very useful. Being able to use a bitmask comparison instead of a simple blocked flag for blocking movement may be the sort of thing to consider? Also once you decide what is 'fixed' map info you will be cutting down on the stuff that is possible to do. Handle with care. On Mon, 2004-02-09 at 13:52, tchize wrote: > That's why 'mostly fixed' should be choosen with care. > Nothing. Also note that client already knows more than player (aka disable darkness code an see better. i know complete dark is not send but nearly complete dark is alaos difficult to see). The main idea is to prevent sending map info to client if they are the same as in released maps. > > -----Original Message----- > From: Nicolas Weeger > To: crossfire-devel@lists.real-time.com > Date: Mon, 09 Feb 2004 14:07:11 +0100 > Subject: Re: [CF-Devel] Combat animations/sound > > tchize a ?crit : > > (snipped most parts out) > > > The mostly fixed part of map would be send to client only one time. This would includes additionnal info like blocked squares (so client can precalculate moves, and make things look softer). Changes to this part of map (which may happen from time to time) will trigger a patch event from server to client so map are against in sync. I am thinking about using a big picture for the map background/buildings/Walls(so mapmakers could design a map made of something else than squares) > > The thing, though, is that client mustn't know more than player should. > Because all sources are available. > If you send all fixed info once and for all, any hacking player will be > able to see this fixed part from the beginning, thus having more info > than s/he should. So they only way is to send only what the player can > see, nothing more. > > Making client handle animations is an obvious simplification, and would > even let clients disable'em if they are too heavy on their computer :) > > Nicolas 'Ryo' > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > > > > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Tue Feb 10 02:00:32 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:01 2005 Subject: [CF-Devel] Combat animations/sound In-Reply-To: <1076335959.550.16.camel@oberon.kameria> References: <1076334739.43f1bf5ctchize@myrealbox.com> <1076335959.550.16.camel@oberon.kameria> Message-ID: <40288DBC.1090200@sonic.net> Todd Mitchell wrote: > I beg of you guys to crack open the blocking code before working on > fixes for a new clean protocol for the client. Or at least plan for > changes. Blocking right now is a huge handicap for both skill creation > and map making. A simple blocking system that allows for flying over > stuff (including missiles and spells), swimming/sailing, mountain > climbing and other types of movement would be so very useful. > Being able to use a bitmask comparison instead of a simple blocked flag > for blocking movement may be the sort of thing to consider? Just a note, bringing up the topic doesn't mean I'm going to start cod on it tomorrow. It was more that at some point, that code really needs to be re-written. _______________________________________________ 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 Feb 10 02:03:10 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:01 2005 Subject: [CF-Devel] Combat animations/sound In-Reply-To: <1076335959.550.16.camel@oberon.kameria> References: <1076334739.43f1bf5ctchize@myrealbox.com> <1076335959.550.16.camel@oberon.kameria> Message-ID: <200402100847.07507.tchize@myrealbox.com> Le Lundi 9 F?vrier 2004 15:12, Todd Mitchell a ?crit : > I beg of you guys to crack open the blocking code before working on > fixes for a new clean protocol for the client. Or at least plan for > changes. Blocking right now is a huge handicap for both skill creation > and map making. A simple blocking system that allows for flying over > stuff (including missiles and spells), swimming/sailing, mountain > climbing and other types of movement would be so very useful. > Being able to use a bitmask comparison instead of a simple blocked flag > for blocking movement may be the sort of thing to consider? > Good point! (and don't forget the 'jump over' and 'go thru using magic'') > Also once you decide what is 'fixed' map info you will be cutting down > on the stuff that is possible to do. Handle with care. No that's why i used the term 'mostly fixed'. Considering server scripting possibilities, *anything* in a map can change. But because grounds and buildings don't change often, there is no need to send them to client each time a building/ground enter the visual part. We could have something like server sending fixed part along with an always increasing 32bit timestamp and a check sum, so client could check at mapenter: - 1st if server map is same a standard map - 2nd if not, if the last map sent by server has changed This would also let client show map before server send info (like suppose server map is standard one and if not change the visual when we get response form server). Anyone i don't plan to implement the new protocol in a quick and dirty way. i plan to submit first a detailed list of expeted behaviour of new protocol The main ideas will be 'reduce bandwith usage' and 'reduce server lags' > > On Mon, 2004-02-09 at 13:52, tchize wrote: > > That's why 'mostly fixed' should be choosen with care. > > Nothing. Also note that client already knows more than player (aka > > disable darkness code an see better. i know complete dark is not send but > > nearly complete dark is alaos difficult to see). The main idea is to > > prevent sending map info to client if they are the same as in released > > maps. > > > > -----Original Message----- > > From: Nicolas Weeger > > To: crossfire-devel@lists.real-time.com > > Date: Mon, 09 Feb 2004 14:07:11 +0100 > > Subject: Re: [CF-Devel] Combat animations/sound > > > > tchize a ?crit : > > > > (snipped most parts out) > > > > > The mostly fixed part of map would be send to client only one time. > > > This would includes additionnal info like blocked squares (so client > > > can precalculate moves, and make things look softer). Changes to this > > > part of map (which may happen from time to time) will trigger a patch > > > event from server to client so map are against in sync. I am thinking > > > about using a big picture for the map background/buildings/Walls(so > > > mapmakers could design a map made of something else than squares) > > > > The thing, though, is that client mustn't know more than player should. > > Because all sources are available. > > If you send all fixed info once and for all, any hacking player will be > > able to see this fixed part from the beginning, thus having more info > > than s/he should. So they only way is to send only what the player can > > see, nothing more. > > > > Making client handle animations is an obvious simplification, and would > > even let clients disable'em if they are too heavy on their computer :) > > > > Nicolas 'Ryo' > > > > _______________________________________________ > > crossfire-devel mailing list > > crossfire-devel@lists.real-time.com > > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > > > > > > > > > > _______________________________________________ > > crossfire-devel mailing list > > crossfire-devel@lists.real-time.com > > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel _______________________________________________ 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 Feb 10 02:31:27 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:01 2005 Subject: [CF-Devel] Combat animations/sound In-Reply-To: <1076334739.43f1bf5ctchize@myrealbox.com> References: <1076334739.43f1bf5ctchize@myrealbox.com> Message-ID: <4028962B.9070007@sonic.net> tchize wrote: > - additionnal layers (bottom of everything, bottom, middle, top, on top of > everything). Not yet fixed, see point below. > - More than one visible item available in a layer (they just stack at that > layer) Note that also requires rework on the server side - currently, the server only calculates the face for 3 layers (floor, middle, top). So at some level, there will always be some imposed limit on the number of layers - there is some practical limit (in very early hacking I did (before the client/server split), aside from performance of drawing every object on a space, after you get a few, the pile just looks like a complete jumble - only the top couple were distinguishable). That said, adding layers could be nice. One of the problems right now related to the map sending is that faces can 'change' layers. eG, you could have floor, food, orc. However, now an arrow is fired, and passes over the orc - that space would now be drawn as floor, orc, arrow - basically meaning 2 faces get updated. If you say there are like 4 layers, that could work reasonably well - you could basically have up to 2 objects/layer - the layers being floor, equipment/misc objects, creatures (monsters & players), and flying objects. That would generally fix the problem above - food would be on the equipment layer, orc on the monster layer. So when the arrow shows up, it just goes on the flying laying, so the stuff underneath doesn't need to get updated. > - Map is made of 2 concurrent part: * The mostly fixed one (ground, > buildings, non pickable/non killable items) * The non fixed one (mainly > monsters and pickables). As I mention below, I don't see the gain in doing this. Server already works on not re-sending data the client knows about. So the only perceived gain I could really see is that somehow the protocol itself could be made more efficiently. > > The mostly fixed part of map would be send to client only one time. This > would includes additionnal info like blocked squares (so client can > precalculate moves, and make things look softer). Changes to this part of map > (which may happen from time to time) will trigger a patch event from server > to client so map are against in sync. I am thinking about using a big picture > for the map background/buildings/Walls(so mapmakers could design a map made > of something else than squares) Well, a big picture is a different issue. The idea itself is nice. However, that is more of a nature of the client itself sending the background, and the other layers still being drawn on top of it. So I'd then say that gets into an issue that the map shouldn't have the extra layers if it is designed with that background. > No need to say map animations would be handled only by client. Note that map animations get trickier than inventory animations. This is mainly for two reasons - 1) inventory animations don't change much (eg, the only one I am aware of that will change animation speed is the power crystal) and 2) You need to send more state info for map animations. The second point is consider a map with 20 orcs. You don't want them all animated in the same phase - there is code to make it so that doesn't happen (There speed is randomized). Likewise, there are many more things that can effect the animation phase of creatures (spells, terrain, etc). So now for those 20 orcs, for each orc, you need to store away the phase, animation speed, and animation. And I'd have to look at the code, but the time to next phase may be necessary (eg, a creature that has speed 0.25 will sit in phase 1 for 4 ticks. So even if we say it is on phase 1, does it stay on phase 1 for 1 more ticks, 3 ticks, etc). So it becomes a much trickier issue of whether the client handling all that, and the server sending that once is greatly more efficient. Eg, if the player is standing still, kills an orc, and another orc steps up, need to send all that stuff for the new orc, which is not likely to be on the same phase Now there are some cases where it is more a clear cut gain. The moving spikes, burnouts, etc, are things that won't get effected, and our stationary. > That's why 'mostly fixed' should be choosen with care. Nothing. Also note > that client already knows more than player (aka disable darkness code an see > better. i know complete dark is not send but nearly complete dark is alaos > difficult to see). The main idea is to prevent sending map info to client if > they are the same as in released maps. But darkness was always optional - it is a visual effect, and is known that clients may display it differently (some settings within the gtk client may make the images more/less visible). However, for all purposes, a dark space is still considered with view (eg, if you look at the space, you get the same level of detail). Note that the server already does work to make sure we don't send data the client already knows about. So I'm not really sure what is gained by trying to send the static data only once - that is basically already happens only once. And I really don't want to add the extra complexity of 'this is a public map, handle with method X' vs 'this is a custom map, handle with method y'. And from a client perspective, this can get more complicated. Eg, one can rightfully consider using fog of war not cheating (it is just showing you what you've seen before). But the simplest implentation of the client basically says if we have info for a space draw it. So now you could get players seeing stuff on the fog map that they havent' actually seen yet. In a sense cheating, but not intentional on the client side. Since I started this, a few thoughts on what I'd like to see in the map protocol: 1) Sound support. Current sound stuff could use this, but I'm also thinking about if you have recurring sounds or the like (sounds of a waterfall, those moving spikes, etc.) 2) Lighting - instead of sending darkness for each space, tell the clien that the map is dark X, and instead send the light sources (and their intensity). This would actually reduce bandwidth, and should also make it easier for better lighting effects (server would still calculate darkness just in terms of line of sight). Related to this, light sources could potentially have different colors - of course, up to the client if it can do anything with that. 3) Clean up some of the handling as related to big images and their heads. Ideally, server can mark there is a head object on a space so that the code for sending the packet doesn't have to do as much work. _______________________________________________ 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 Feb 10 04:22:29 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:01 2005 Subject: [CF-Devel] Combat animations/sound In-Reply-To: <4028962B.9070007@sonic.net> References: <1076334739.43f1bf5ctchize@myrealbox.com> <4028962B.9070007@sonic.net> Message-ID: <200402101115.24239.tchize@myrealbox.com> Le Mardi 10 F?vrier 2004 09:28, Mark Wedel a ?crit : > tchize wrote: > > - additionnal layers (bottom of everything, bottom, middle, top, on top > > of everything). Not yet fixed, see point below. > > > > - More than one visible item available in a layer (they just stack at > > that layer) > > Note that also requires rework on the server side - currently, the server > only calculates the face for 3 layers (floor, middle, top). So at some > level, there will always be some imposed limit on the number of layers - > there is some practical limit (in very early hacking I did (before the > client/server split), aside from performance of drawing every object on a > space, after you get a few, the pile just looks like a complete jumble - > only the top couple were distinguishable). > > That said, adding layers could be nice. One of the problems right now > related to the map sending is that faces can 'change' layers. > > eG, you could have floor, food, orc. However, now an arrow is fired, and > passes over the orc - that space would now be drawn as floor, orc, arrow - > basically meaning 2 faces get updated. > > If you say there are like 4 layers, that could work reasonably well - you > could basically have up to 2 objects/layer - the layers being floor, > equipment/misc objects, creatures (monsters & players), and flying objects. > > That would generally fix the problem above - food would be on the > equipment layer, orc on the monster layer. So when the arrow shows up, it > just goes on the flying laying, so the stuff underneath doesn't need to get > updated. > > > - Map is made of 2 concurrent part: * The mostly fixed one (ground, > > buildings, non pickable/non killable items) * The non fixed one (mainly > > monsters and pickables). > > As I mention below, I don't see the gain in doing this. Server already > works on not re-sending data the client knows about. Not really true. Move one step left, you get a mapscroll followed by the left map column sent by server. But then move one step right, the server send again the right column which disappeared when you moved left. And the backgrounds animations are a big problem too. Be near the seen ad you get agian and again map updates. > > So the only perceived gain I could really see is that somehow the > protocol itself could be made more efficiently. > > > The mostly fixed part of map would be send to client only one time. This > > would includes additionnal info like blocked squares (so client can > > precalculate moves, and make things look softer). Changes to this part of > > map (which may happen from time to time) will trigger a patch event from > > server to client so map are against in sync. I am thinking about using a > > big picture for the map background/buildings/Walls(so mapmakers could > > design a map made of something else than squares) > > Well, a big picture is a different issue. The idea itself is nice. > However, that is more of a nature of the client itself sending the > background, and the other layers still being drawn on top of it. So I'd > then say that gets into an issue that the map shouldn't have the extra > layers if it is designed with that background. > Yeah idea is nice, didn't think deeply about it yet. Anyway not a priority. > > No need to say map animations would be handled only by client. > > Note that map animations get trickier than inventory animations. > > This is mainly for two reasons - 1) inventory animations don't change > much (eg, the only one I am aware of that will change animation speed is > the power crystal) and 2) You need to send more state info for map > animations. > > The second point is consider a map with 20 orcs. You don't want them all > animated in the same phase - there is code to make it so that doesn't > happen (There speed is randomized). Likewise, there are many more things > that can effect the animation phase of creatures (spells, terrain, etc). > So now for those 20 orcs, for each orc, you need to store away the phase, > animation speed, and animation. And I'd have to look at the code, but the > time to next phase may be necessary (eg, a creature that has speed 0.25 > will sit in phase 1 for 4 ticks. So even if we say it is on phase 1, does > it stay on phase 1 for 1 more ticks, 3 ticks, etc). > Already thought about it. Think about something like sending 'object (eg orc 5147831)' at location, and along with it a value derivated from speed_left (which is used to know when next step of animation is to trigger) the speed value and the animation. Because some object have different animation at different time,s server could send info like or could send infos like , but those info should only be send for non fixed part and only if is visible by player (or becomes visible or disappear) so this would prevent 'look thru wall/ track monster' cheats > So it becomes a much trickier issue of whether the client handling all > that, and the server sending that once is greatly more efficient. Eg, if > the player is standing still, kills an orc, and another orc steps up, need > to send all that stuff for the new orc, which is not likely to be on the > same phase > > Now there are some cases where it is more a clear cut gain. The moving > spikes, burnouts, etc, are things that won't get effected, and our > stationary. and sea > > > That's why 'mostly fixed' should be choosen with care. Nothing. Also note > > that client already knows more than player (aka disable darkness code an > > see better. i know complete dark is not send but nearly complete dark is > > alaos difficult to see). The main idea is to prevent sending map info to > > client if they are the same as in released maps. > > But darkness was always optional - it is a visual effect, and is known > that clients may display it differently (some settings within the gtk > client may make the images more/less visible). However, for all purposes, > a dark space is still considered with view (eg, if you look at the space, > you get the same level of detail). > > Note that the server already does work to make sure we don't send data > the client already knows about. So I'm not really sure what is gained by > trying to send the static data only once - that is basically already > happens only once. > > And I really don't want to add the extra complexity of 'this is a public > map, handle with method X' vs 'this is a custom map, handle with method y'. No the idea is <> (like images are cache handled for now) > > And from a client perspective, this can get more complicated. Eg, one > can rightfully consider using fog of war not cheating (it is just showing > you what you've seen before). But the simplest implentation of the client > basically says if we have info for a space draw it. So now you could get > players seeing stuff on the fog map that they havent' actually seen yet. > In a sense cheating, but not intentional on the client side. > > Since I started this, a few thoughts on what I'd like to see in the map > protocol: > > 1) Sound support. Current sound stuff could use this, but I'm also > thinking about if you have recurring sounds or the like (sounds of a > waterfall, those moving spikes, etc.) Yeah and ambiant music (gros did a hack for this) > > 2) Lighting - instead of sending darkness for each space, tell the clien > that the map is dark X, and instead send the light sources (and their > intensity). This would actually reduce bandwidth, and should also make it > easier for better lighting effects (server would still calculate darkness > just in terms of line of sight). Related to this, light sources could > potentially have different colors - of course, up to the client if it can > do anything with that. agree > > 3) Clean up some of the handling as related to big images and their heads. > Ideally, server can mark there is a head object on a space so that the code > for sending the packet doesn't have to do as much work. > > > _______________________________________________ > 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 Wed Feb 11 01:40:27 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:02 2005 Subject: [CF-Devel] Combat animations/sound In-Reply-To: <200402101115.24239.tchize@myrealbox.com> References: <1076334739.43f1bf5ctchize@myrealbox.com> <4028962B.9070007@sonic.net> <200402101115.24239.tchize@myrealbox.com> Message-ID: <4029DB7F.20807@sonic.net> tchize wrote: > Not really true. Move one step left, you get a mapscroll followed by the left > map column sent by server. But then move one step right, the server send > again the right column which disappeared when you moved left. True. At one point, and perhaps still for some clients, the client didn't store what disappeared off the edge. However, the bigger problem is how much do you presume the client will hold? 20 spaces? 50 spaces? How do you deal with the tiled world maps. I'd also note that there is the potential trading of bandwidth, similar to image caching (spend time at load time to get all the images, so it doesn't spend any time during play, or get the images during play). The same would hold true on maps. First time you enter a map, potential larger delay as the entire map is sent down, but then less because you can move around with less data getting uploaded. The biggest problem I see is this adds a lot of complications - the server has to have some idea on what is defined as a stable space. The client has to have some caching mechanism for these maps (being able to load and save them), verification if the map is the same different, whether the map is one that should be sent down or not, and probably other considerations. Also, while the argument that public maps are already in CVS, so players could download them, there is still the problem of giving stuff away. Some maps I can think of are series of small rooms connected by teleporters - the client getting hte entire stable area now means it is much easier to see potential areas of secret chambers, and perhaps makes them immediately visible (I can see the wall, I can see there is floor behind it.. hmm). If the client displays info the player isn't suppose to know about, you can't ask players to ignore that info. > > And the backgrounds animations are a big problem too. Be near the seen ad you > get agian and again map updates. Well, depends on number of animations and how fast they are animated. Sure, standing near something that is animated will cause constant updates. But if your only sending a few hundred bytes/second, that is hardly a big deal at all. Animating some images may make sense - if it can be figured what objects won't move, and which ones have constant animations, sending animation info for those probably makes sense. However, for some, syncrhonization here is also vitally important. This certainly is not the case for anything in the player inventory. But if you have something like spikes or gates, you have to be 100% sure that the client is displaying the same phase as what the server thinks it is - if it is off even a little, could cause serious player injury or death. And keeping them syncrhonized that closely could be difficult. Probably the ones most worthwhile to animate are temporary images (burnouts, spell effects). These are ones that can show up a lot over a map and animate relatively quickly. Thus, there is little danger for the client to get too far out of sync with those, it saves a bunch of animations, and if the client knows they expire, means that the server can even save the bandwidth of 'clear this layer'. > > Already thought about it. Think about something like sending 'object (eg orc > 5147831)' at location, and along with it a value derivated from speed_left > (which is used to know when next step of animation is to trigger) the speed > value and the animation. Because some object have different animation at > different time,s server could send info like 5147831 to animation number 7452> > or could send infos like , but those info should > only be send for non fixed part and only if is visible by > player (or becomes visible or disappear) so this would prevent 'look thru > wall/ track monster' cheats Yeah, there are lots of ways this could be done. The real question is how big a gain it is (if your sending creature, animation speed, animation phase, and animation number, you are now talking potentially 8 bytes of data for that, vs 2 bytes for just an image). It pays for itself in 4 frames, if the creature stays in place that long. But it also adds a lot of complication. >> Now there are some cases where it is more a clear cut gain. The moving >>spikes, burnouts, etc, are things that won't get effected, and our >>stationary. > > > and sea And sea is another one of those good cases - synchronization not important, phases isn't important, etc. However, in some cases, like sea, you'd almost want a simpler model - all seas are animated at speed X, so ideally, you'd want to be able to establish that speed once, and then just say 'space x,y is animated sea', and let the client go 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 Wed Feb 11 20:15:59 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:02 2005 Subject: [CF-Devel] Combat animations/sound In-Reply-To: <40288DBC.1090200@sonic.net> References: <1076334739.43f1bf5ctchize@myrealbox.com> <1076335959.550.16.camel@oberon.kameria> <40288DBC.1090200@sonic.net> Message-ID: <1076534069.561.11.camel@oberon.kameria> On Tue, 2004-02-10 at 07:52, Mark Wedel wrote: > Todd Mitchell wrote: > > I beg of you guys to crack open the blocking code before working on > > fixes for a new clean protocol for the client. Or at least plan for > > changes. Blocking right now is a huge handicap for both skill creation > > and map making. A simple blocking system that allows for flying over > > stuff (including missiles and spells), swimming/sailing, mountain > > climbing and other types of movement would be so very useful. > > Being able to use a bitmask comparison instead of a simple blocked flag > > for blocking movement may be the sort of thing to consider? > > Just a note, bringing up the topic doesn't mean I'm going to start cod on it > tomorrow. > > It was more that at some point, that code really needs to be re-written. > I suppose we can give you a day or two ;) Actually I just wanted to make sure that it wasn't left out of the conversation if anyone did actually start thinking about changes to the protocol related to blocking info. _______________________________________________ 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 Feb 12 15:16:37 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:02 2005 Subject: [CF-Devel] 'Light' question Message-ID: <402BEBF2.10801@laposte.net> Browsing the code, i found that a 'light source' has 2 different types in the code: in object structure, sint16 glow_radius; /* indicates the glow radius of the object */ but in mapspace structure: sint8 light; /* How much light this space provides */ Maybe those should be made coherent, specially since map.c:update_position will update the space with the object's value... 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 Thu Feb 12 15:35:46 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:02 2005 Subject: [CF-Devel] 'Light' question In-Reply-To: <402BEBF2.10801@laposte.net> References: <402BEBF2.10801@laposte.net> Message-ID: <20040212202247.GS17485@laranja.org> On Thu, Feb 12, 2004 at 10:11:14PM +0100, Nicolas Weeger wrote: > Browsing the code, i found that a 'light source' has 2 different types in > the code: > > in object structure, > sint16 glow_radius; /* indicates the glow radius of the object */ > > but in mapspace structure: > sint8 light; /* How much light this space provides */ > > Maybe those should be made coherent, specially since map.c:update_position > will update the space with the object's value... not sure about this particular instance, but there re two different light values: the glow radius, and the light level. The light level is something that ranges from "completely bright" to "completely dark". Take a walk to the dragon hatchery to see it in use. The radius works by decreasing the light level by 1 every N squares; I don't remember, but I think N is so that if you are glow_radius+1 squares from the light source, it provides zero light (so if there are no other sources, you'll be seeing the map's ambient level). You probably know this better than I do, but I'll post this anyway in the hopes of throwing some light into the subject (heh) []s, |alo +---- -- Those who trade freedom for security lose both and deserve neither. -- http://www.laranja.org/ mailto:lalo@laranja.org pgp key: http://www.laranja.org/pessoal/pgp GNU: never give up freedom http://www.gnu.org/ _______________________________________________ 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 Feb 12 15:40:59 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:02 2005 Subject: [CF-Devel] 'Light' question In-Reply-To: <20040212202247.GS17485@laranja.org> References: <402BEBF2.10801@laposte.net> <20040212202247.GS17485@laranja.org> Message-ID: <402BF269.3000406@laposte.net> > not sure about this particular instance, but there re two > different light values: the glow radius, and the light level. > The light level is something that ranges from "completely > bright" to "completely dark". Take a walk to the dragon > hatchery to see it in use. No, not the same light value. The global map value is 'darkness' field. 'update_position' will find the highest 'glow_radius' for current square, and assign it to 'light'. That's why i think the 2 types here are not coherent :) > []s, > |alo > +---- 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 Thu Feb 12 16:06:07 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:02 2005 Subject: [CF-Devel] Unused fields in structures Message-ID: <402BF587.8020105@laposte.net> Some fields in structures are not used anywhere in the server code: in object (include/object.h): * thrownthaco * tooltype is used only by command_build() (c_object.c), which is not used afaik (and code is between #if 0) and loader.l/.c in player (include/player.h): * new_x * new_y * known_spell is just set in apply_special, but used nowhere else in weathermap_t (include/maps.h): * path (char [HUGE_BUF] !!) * tmpname * name I'd suggest just removing'em, but who knows, maybe they are indeed used somewhere not obvious for doxygen (note that I also rebuilt sources without those variables, and it worked fine, thanks), so I prefer playing it safe :). 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 Fri Feb 13 01:21:46 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:02 2005 Subject: [CF-Devel] 'Light' question In-Reply-To: <402BF269.3000406@laposte.net> References: <402BEBF2.10801@laposte.net> <20040212202247.GS17485@laranja.org> <402BF269.3000406@laposte.net> Message-ID: <402C7AFD.9000500@sonic.net> Nicolas Weeger wrote: >> not sure about this particular instance, but there re two >> different light values: the glow radius, and the light level. >> The light level is something that ranges from "completely >> bright" to "completely dark". Take a walk to the dragon >> hatchery to see it in use. > > > > No, not the same light value. The global map value is 'darkness' field. > > 'update_position' will find the highest 'glow_radius' for current > square, and assign it to 'light'. That's why i think the 2 types here > are not coherent :) > The two types aren't coherent. However, since the max light value right now is something like 4 or whatever, so is no danger in overflowing the smaller value in the map structure. The more correct fix for this is to reduce the size of the field in the object structure. _______________________________________________ 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 Feb 13 01:31:48 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:02 2005 Subject: [CF-Devel] Unused fields in structures In-Reply-To: <402BF587.8020105@laposte.net> References: <402BF587.8020105@laposte.net> Message-ID: <402C7BA3.5010300@sonic.net> Nicolas Weeger wrote: > Some fields in structures are not used anywhere in the server code: > > in object (include/object.h): > * thrownthaco That looks like it could go. > * tooltype is used only by command_build() (c_object.c), which is not > used afaik (and code is between #if 0) and loader.l/.c > I'm less certain on that one - I'm not sure if the code is disabled because more tweaking is needed to enable it and have it balanced, or if its disabled because it should be removed at some point. I'm pretty sure it is the former. > in player (include/player.h): > * new_x > * new_y > * known_spell is just set in apply_special, but used nowhere else Yeah, those don't look like they are needed. > > in weathermap_t (include/maps.h): > * path (char [HUGE_BUF] !!) > * tmpname > * name Not that familar with the weather stuff, but yeah, if not used, those could 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 Sat Feb 14 11:03:30 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:02 2005 Subject: [CF-Devel] god_removes_curse question Message-ID: <402E5274.4090702@laposte.net> Hello. Playing with thaumaturgy, i made a holy symbol of Probity, but cursed. So i prayed at my god's altar (Gaea) till curse was removed. But the symbol still had a negative power value! So i'm wondering if that's the intended behaviour or not... I think to remember gods used to fix potions & such, so i thought this negative bonus would have been fixed too... but i may be wrong :) 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 Sun Feb 15 22:54:45 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:02 2005 Subject: [CF-Devel] god_removes_curse question In-Reply-To: <402E5274.4090702@laposte.net> References: <402E5274.4090702@laposte.net> Message-ID: <40304D15.30009@sonic.net> Nicolas Weeger wrote: > Hello. > > Playing with thaumaturgy, i made a holy symbol of Probity, but cursed. > So i prayed at my god's altar (Gaea) till curse was removed. But the > symbol still had a negative power value! > So i'm wondering if that's the intended behaviour or not... I think to > remember gods used to fix potions & such, so i thought this negative > bonus would have been fixed too... but i may be wrong :) That is the way the code works. and I do think that is the intended results. Arguably, the many benefit of gods removing curse was to be able to get rid of cursed armor, weapons, etc, that you may have applied. The reason that uncursing works for potions to make them normal potions is the actual potion applying code. A cursed potion (if you looked at one saved in a player file) is still listed with something like 'Str 1'. It just that when you apply it, the code looks to see if it is cursed or not, and if cursed, then subtracts instead of adds the value. To my knowledge, that is the only class of objects that uncursing by gods makes it a normal object. For things like weapons, armors, etc, the cursed flag might get removed, but they still have their negative value. _______________________________________________ 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 Feb 16 18:41:54 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:02 2005 Subject: [CF-Devel] Some bugs/comments in crossfire.metalforge.net In-Reply-To: <20040107003059.087292a1.kstenger@montevideo.com.uy> References: <20040107003059.087292a1.kstenger@montevideo.com.uy> Message-ID: <40316352.10408@sonic.net> Karla Stenger wrote: > 1) (some?) Random maps shops do not *buy* stuff, is that supossed to work that > way? No, but without a bad map to diagnosis the problem, hard to really know what is going on here. > > 2) While in my apt if i click on a container that is on the floor it will show > me all it's contents (DM mode OFF!) > > For example go to /scorn/houses/cornerbrook and enter the room to the right, it > has a dresser which will show you this if you click on it: > - dresser. > - mace 16 > - claypipe 4.5 > - woodfloor. > > This doesn't happen to random maps chests, i still cant understand the > difference between one case and the other. Fixed. > > 3) Spell delays: "identify/large icestorm/dragonbreath are totally useless > right now" is the comment a player told me, and i partly agree, i think the > delay is just too much in some cases, did you try these? I just put in code to make the delays more consistent. In all cases, the delays were reduced. there was also a bug in that the player was getting hit twice - in handle player, the speed_left was decreased by 1, and then in cast_spell, the player speed further reduced. I put code in to make sure the the players speed_left is capped at a maximum of how long it shoudl take them to recover. > > 4) Hiscore list (and probably still some player file) messed up because of the > rods bug. Players affected by the bug dont like it cause they cannot play their > chars corrctly and players not affected doesnt like it cause they think they > will have no chance to ever enter the hiscore list. The highscore list is OK now I think. I'm also going to recompile the code so that there are more slots for highscore list (1000 slots in fact). I can't think of any good reason why there should only be space for 10 people (even with 1000 slots, the top people will still know where they stand) > > 5) horns of plenty will shoot bullets instead, pretty deadly :p This is fixed. Note that this is a generation bug, so already broken horns won't be fixed, but any newly generated horns should to the right thing. Note that potions were also similarly broken - for those that cast spell effects - not the stat potions. _______________________________________________ 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 Feb 16 20:12:20 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:02 2005 Subject: [CF-Devel] Two things - item_power, Divine Shock Message-ID: <200402162012.20199.eracclists@bellsouth.net> Gentlepeople, It appears, on crossfire.metalforge.net, that item_power does not SUM correctly. For example if I have a character that is level 14 then that character can apply two items that have an item_power of +13. Thus the total item power equipped is OVER 14. I believe this is not working as intended. My thought about item power is that the total one equips is not supposed exceed the level of the character. Feel free to correct my thinking if it is flawed. :-) Ok, who made Sorig's Divine Shock worthless? I don't mean the delay. I mean the prayer Divine Shock (ball lightning with god power) is no longer a useful attack spell. My character has level 24 praying. It takes casting Divine Shock about 63 - 65 times to kill a wyvern. This is NOT even CLOSE to how the spell used to work. I can cast "cause heavy wounds" 3 - 4 times and kill individual wyverns. Divine Shock, being a deity granted medium level prayer, should be MORE powerful that cause heavy wounds. Heck, it should be more powerful than ball lightning at the equivalent pyromancy level. It is not. Please fix it. I still don't have the skill in C needed to find the problem and fix it myself. :-/ Gene (aka poof) -- Linux era4.eracc.UUCP 2.4.22-26mdkenterprise i686 19:57:09 up 16 days, 22:01, 11 users, load average: 0.00, 0.00, 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 Mon Feb 16 21:27:56 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:02 2005 Subject: [CF-Devel] Two things - item_power, Divine Shock In-Reply-To: <200402162012.20199.eracclists@bellsouth.net> References: <200402162012.20199.eracclists@bellsouth.net> Message-ID: <40318A3C.6020409@sonic.net> ERACC wrote: > Gentlepeople, > > It appears, on crossfire.metalforge.net, that item_power does not SUM > correctly. For example if I have a character that is level 14 then > that character can apply two items that have an item_power of +13. > Thus the total item power equipped is OVER 14. I believe this is not > working as intended. My thought about item power is that the total > one equips is not supposed exceed the level of the character. Feel > free to correct my thinking if it is flawed. :-) That is the way it should work (note that this can be customized, so that it can be 1.5 * character level, or 0.5 * character level, etc. But on metalforge at least, it is set to 1.0. Looking at the code, it seems pretty straightforward. CAn you provide a character name, as well as items you are trying to apply? Might give a better clue as to what is going on. > > Ok, who made Sorig's Divine Shock worthless? I don't mean the delay. > I mean the prayer Divine Shock (ball lightning with god power) is no > longer a useful attack spell. My character has level 24 praying. It > takes casting Divine Shock about 63 - 65 times to kill a wyvern. This > is NOT even CLOSE to how the spell used to work. I can cast "cause > heavy wounds" 3 - 4 times and kill individual wyverns. Divine Shock, > being a deity granted medium level prayer, should be MORE powerful > that cause heavy wounds. Heck, it should be more powerful than ball > lightning at the equivalent pyromancy level. It is not. Please fix > it. I still don't have the skill in C needed to find the problem and > fix it myself. :-/ The spells were generally converted as the old system had them, but may have been some typos, or some other oddities. I'll beef up the spell a bit. Note that while divine shock is god given, it is a level 1 spell without a real high cost. So in that sense, it could be considered an odd spell - low level, but you probably have to be reasonably high level before the god will give it to you. But the old parameters of the spell more reflected the level of the spell, not how hard it is to get. _______________________________________________ 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 Feb 16 23:55:20 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:02 2005 Subject: [CF-Devel] Two things - item_power, Divine Shock In-Reply-To: <40318A3C.6020409@sonic.net> References: <200402162012.20199.eracclists@bellsouth.net> <40318A3C.6020409@sonic.net> Message-ID: <200402162355.20396.eracclists@bellsouth.net> On Monday 16 February 2004 21:27 Mark Wedel wrote: > ERACC wrote: > > Gentlepeople, > > > > It appears, on crossfire.metalforge.net, that item_power does not > > SUM correctly. For example if I have a character that is level 14 > > then that character can apply two items that have an item_power > > of +13. Thus the total item power equipped is OVER 14. [...] [...] > > Looking at the code, it seems pretty straightforward. CAn you > provide a character name, as well as items you are trying to apply? > Might give a better clue as to what is going on. Actually, I discovered this in a discussion with another player. He was level 19 and had equipped item power total of well over 19. Katia was on the server at the time and may remember who it was. I can't recall. My character, poof, is over level 50 so unless some items exist that he can equip to go over the total for his level I won't be able to test it personally without starting a new character. > > Ok, who made Sorig's Divine Shock worthless? I don't mean the > > delay. I mean the prayer Divine Shock (ball lightning with god > > power) is no longer a useful attack spell. My character has level > > 24 praying. It takes casting Divine Shock about 63 - 65 times to > > kill a wyvern. [...] > > The spells were generally converted as the old system had them, > but may have been some typos, or some other oddities. I'll beef up > the spell a bit. > > Note that while divine shock is god given, it is a level 1 spell > without a real high cost. So in that sense, it could be considered > an odd spell - low level, but you probably have to be reasonably > high level before the god will give it to you. > > But the old parameters of the spell more reflected the level of > the spell, not how hard it is to get. Burning Hands is a level 1 spell yet it gets more powerful with the level of the caster. Or at least it appears to. I double checked and found that divine shock is a low level prayer, native grace of 50. I still believe it has been castrated in the new code however. It also seems to not be getting any more powerful with the increase in the praying skill of my character. That doesn't follow the path of other spells which *do* get more powerful with higher levels. Raise the cost for it some if needed but please fix it where it is again useful to have and use. IMO it should be at *least* as powerful as ball lightning once the character reaches level 12 in praying. Get REAL, I mean it is a *deity* granted spell for Sorig's sake. :-P Gene (aka poof, aka eracc) -- Linux era4.eracc.UUCP 2.4.22-26mdkenterprise i686 23:10:26 up 17 days, 1:15, 11 users, load average: 0.00, 0.00, 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 Feb 17 11:59:46 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:02 2005 Subject: [CF-Devel] Two things - item_power, Divine Shock In-Reply-To: <200402162355.20396.eracclists@bellsouth.net> References: <200402162012.20199.eracclists@bellsouth.net> <40318A3C.6020409@sonic.net> <200402162355.20396.eracclists@bellsouth.net> Message-ID: <20040217145946.25ff2b3f.kstenger@montevideo.com.uy> > On Monday 16 February 2004 21:27 > Mark Wedel wrote: > > > ERACC wrote: > > > Gentlepeople, > > > > > > It appears, on crossfire.metalforge.net, that item_power does not > > > SUM correctly. For example if I have a character that is level 14 > > > then that character can apply two items that have an item_power > > > of +13. Thus the total item power equipped is OVER 14. [...] > [...] > > > > Looking at the code, it seems pretty straightforward. CAn you > > provide a character name, as well as items you are trying to apply? > > Might give a better clue as to what is going on. > > Actually, I discovered this in a discussion with another player. He > was level 19 and had equipped item power total of well over 19. Katia > was on the server at the time and may remember who it was. I can't > recall. My character, poof, is over level 50 so unless some items > exist that he can equip to go over the total for his level I won't > be able to test it personally without starting a new character. > Never trust on my bad memory for this things :) No i dont remember the name of the one who was talking, but it's something pretty simple to do again, and if you need a char mark, just look at my file "Katia" now she has 80 of 60 or so equipped right now, and i'll be playing my other char in the midtime so you can do what you need today. Or if you can take a copy and let it free that would be really nice :D BTW... i just remembered another bug (oh! my memory is working now! :D) Beeing a fireborn allows you to apply 2 amulets, and the problem is when you have 2 identical amulets (that would stack together) and leave the game and come back, when you come back your amulets will be in a strange status of applied while stacking, and i think it just counts like one of them beeing applied, but didnt check that further. Anyway, since this does not happen to rings, i dont think thats too hard to fix, i just have no clue of where to look for that in the code. Until next time! Katia. -- +-----------------------------+ | 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 Tue Feb 17 23:21:50 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:03 2005 Subject: [CF-Devel] Two things - item_power, Divine Shock In-Reply-To: <200402162355.20396.eracclists@bellsouth.net> References: <200402162012.20199.eracclists@bellsouth.net> <40318A3C.6020409@sonic.net> <200402162355.20396.eracclists@bellsouth.net> Message-ID: <4032F66E.7030606@sonic.net> ERACC wrote: > > Burning Hands is a level 1 spell yet it gets more powerful with the > level of the caster. Or at least it appears to. I double checked and > found that divine shock is a low level prayer, native grace of 50. I > still believe it has been castrated in the new code however. It also > seems to not be getting any more powerful with the increase in the > praying skill of my character. That doesn't follow the path of other > spells which *do* get more powerful with higher levels. Raise the > cost for it some if needed but please fix it where it is again useful > to have and use. IMO it should be at *least* as powerful as ball > lightning once the character reaches level 12 in praying. Get REAL, I > mean it is a *deity* granted spell for Sorig's sake. :-P Most all spells increase in power as the caster level gets higher. However, they don't all increase at the same rate. As said, I've made some changes to the divine shock prayer - just need to get those changes onto the server at some point. _______________________________________________ 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 Feb 17 23:33:04 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:03 2005 Subject: [CF-Devel] Two things - item_power, Divine Shock In-Reply-To: <20040217145946.25ff2b3f.kstenger@montevideo.com.uy> References: <200402162012.20199.eracclists@bellsouth.net> <40318A3C.6020409@sonic.net> <200402162355.20396.eracclists@bellsouth.net> <20040217145946.25ff2b3f.kstenger@montevideo.com.uy> Message-ID: <4032F910.30007@sonic.net> Karla Stenger wrote: > Never trust on my bad memory for this things :) No i dont remember the name of > the one who was talking, but it's something pretty simple to do again, and if > you need a char mark, just look at my file "Katia" now she has 80 of 60 or so > equipped right now, and i'll be playing my other char in the midtime so you can > do what you need today. Or if you can take a copy and let it free that would be > really nice :D Ok. That was easy to fix, once I see what the bug was. > > BTW... i just remembered another bug (oh! my memory is working now! :D) > Beeing a fireborn allows you to apply 2 amulets, and the problem is when you > have 2 identical amulets (that would stack together) and leave the game and come > back, when you come back your amulets will be in a strange status of applied > while stacking, and i think it just counts like one of them beeing applied, but > didnt check that further. Anyway, since this does not happen to rings, i dont > think thats too hard to fix, i just have no clue of where to look for that in > the code. This is also easy. And in fact, I believe can show up for other objects also (if we allowed ettin characters, and they wore two helmets, the same thing would happen). Rings right now are special cased in that the ring is applied, we don't try to merge it. I'm thinking removing that special case - in all cases, if an object is applied, it can't merge with another applied objects. I'm trying to think if there are any cases where that would cause problems - cases where you really want 5 of an item all grouped together and applied at the same time. I can't think of any such cases - if someone can think of some, let me know, otherwise, I'll put the change in that applied objects never merge with items of the same type. _______________________________________________ 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 Feb 18 12:19:02 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:03 2005 Subject: [CF-Devel] Unused fields in structures In-Reply-To: <402BF587.8020105@laposte.net> Message-ID: On 12-Feb-04 Nicolas Weeger wrote: > in object (include/object.h): > * thrownthaco > * tooltype is used only by command_build() (c_object.c), which is not used > afaik (and code is between #if 0) and loader.l/.c The code that is' if 0'd works fine. Nobody ever made objects for it however.. so it was never enabled. > in weathermap_t (include/maps.h): > * path (char [HUGE_BUF] !!) > * tmpname > * name Those are probably artifacts that don't need to be there anymore.. though I don't recall completely what they were originally for. --- 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 Thu Feb 19 14:12:26 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:03 2005 Subject: [CF-Devel] Suggestion: map flag for town portal Message-ID: <403518AA.7010100@laposte.net> Hello. Here's a suggestion for a map (or map square?) flag: non-permanent town portal. Basically, it would mean: you can cast town portal, and use said portal. But, if map resets, you can not get back to it even if you have memorized the location. The goal would be to prevent players, when reaching some places (top of wizard tower, last map of chaos lair, whatever) to make a portal from there, and come over & over to collect lore. But still allow players to go there as long as map doesn't reset. I also don't think that would be that hard to implement - if map is loaded when portal is reopened, check flag, if set fail portal & reset map. Comments? 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 Thu Feb 19 15:51:26 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:03 2005 Subject: [CF-Devel] Bug report: vitriol issues Message-ID: <40352FDE.203@laposte.net> Hello. On crossfire.metalforge.net, a player showed me the following concerning the spell vitriol. First, firing under himself would fire top left corner. This doesn't happen with other spells (like holy word, for instance). Could that be something like initial bullet has this direction? Second, firing towards a wall will make a vitriol thingy, which hits the wall... and that's all, no explosion afterwards. Maybe a broken archetype/other_arch field? 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 Thu Feb 19 16:04:40 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:03 2005 Subject: [CF-Devel] Future plans? Message-ID: <403532F8.8060702@laposte.net> Hello. I was wondering if anyone was doing any big thing on the server (or client) side. Any big feature planned? I'm out of ideas right now :) (ok, i could clean warnings, or write documentation, but it's funnier to do new things, sometimes). As a side note, bug #757920 (gcfclient Win32 port unproperly handling cached images) can be closed, it has been fixed in 1.6.0 release. 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 Thu Feb 19 18:53:05 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:03 2005 Subject: [CF-Devel] Future plans? In-Reply-To: <403532F8.8060702@laposte.net> Message-ID: On 19-Feb-04 Nicolas Weeger wrote: > I was wondering if anyone was doing any big thing on the server (or client) > side. Any big feature planned? > I'm out of ideas right now :) Long ago.. I wrote code for a job system, and a more advanced system of enchant armour. I gave the patches to Leaf. The job system probably needs a little twiddling to work with the new skills code, and the enchant armor stuff needed a few hacks. You're welcome to them. --- 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 Fri Feb 20 01:34:31 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:03 2005 Subject: [CF-Devel] Suggestion: map flag for town portal In-Reply-To: <403518AA.7010100@laposte.net> References: <403518AA.7010100@laposte.net> Message-ID: <200402200834.31246.tchize@myrealbox.com> Le Jeudi 19 F?vrier 2004 21:12, Nicolas Weeger a ?crit : > Hello. > > Here's a suggestion for a map (or map square?) flag: non-permanent town > portal. > > Basically, it would mean: you can cast town portal, and use said portal. > But, if map resets, you can not get back to it even if you have memorized > the location. > > The goal would be to prevent players, when reaching some places (top of > wizard tower, last map of chaos lair, whatever) to make a portal from > there, and come over & over to collect lore. But still allow players to go > there as long as map doesn't reset. > > I also don't think that would be that hard to implement - if map is loaded > when portal is reopened, check flag, if set fail portal & reset map. > > Comments? > > Nicolas > Yeah a comment. If map is reset at time portal is invoked, don't create the portal at all? (no need for a map flag, too difficult to change all treasure rooms to forbid portals....). Well basically, even if this prevent treasures stealing (which unbalance the game), this doesn't look natural being unable to get back to one place because it has 'reset' (in fact the idea of reseting a map doesn't seem natural but that's an other point). Perhaps a better idea would be to limit the time a player can remember where the portal must connect to. If it's something like 30 minutes (quite enough for portals from town to town, or from cleaned up dungeon's treasure room to shop), that would look close to the time of map resets. And it looks more natural to forget a location as time goes than to forget location because of a map reset. Tchize _______________________________________________ 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 Feb 20 03:11:52 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:03 2005 Subject: [CF-Devel] Suggestion: map flag for town portal In-Reply-To: <200402200834.31246.tchize@myrealbox.com> Message-ID: On 20-Feb-04 tchize wrote: > And it looks more natural to forget a location as time goes than to forget > location because of a map reset. So tell the player he forgot because too much time passed. What we do internally, and what we tell the player we do, don't necc. have to be the same thing. --- 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 Fri Feb 20 20:33:54 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:03 2005 Subject: [CF-Devel] Bug report: vitriol issues In-Reply-To: <40352FDE.203@laposte.net> References: <40352FDE.203@laposte.net> Message-ID: <20040220233354.7b1799db.kstenger@montevideo.com.uy> Hi, I add this to this topic since it seems related to what ryo says below. Just today i noticed my holy word strangely casted, i use a binding with fire 0, so it could have to do with that. The problem itself is when i cast it instead of beeing surrounded by holy word, there is a spot that is not covered and it's precisely the top left corner and all the top left corners of the squares around me... just to make it more clear: * floor O spell X me *OOOOOO O*OOOOO OO*OOOO OOOXOOO OOOOOOO OOOOOOO OOOOOOO Other cone spells seem to behave the same way. > First, firing under himself would fire top left corner. This doesn't happen > with other spells (like holy word, for instance). Could that be something like > initial bullet has this direction? Also would like to ask about the banishment spell, until 2 or 3 days ago it was a very powerful spell which as level 30 in praying allowed me to grow up to level 60 pretty fast beecause of the size of it when i casted it centered on me like holy word, it almost covered the whole place and so I advanced really fast. It's now been modified so the area covered by it, now i'm level 60 in praying, is about 4 or 5 sq of radius. So my point is, yes the spell was too powerful for beeing so big before, but now it's almost useless since it's too small and casting twice holy word (that is still big as it used to be) would be much worth than casting 5 or 6 times banishment. How are those radius calculated anyway? Until next time, Katia. -- +-----------------------------+ | 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 Feb 21 03:50:35 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:03 2005 Subject: [CF-Devel] Fire Resistance broken? In-Reply-To: <200402200834.31246.tchize@myrealbox.com> References: <403518AA.7010100@laposte.net> <200402200834.31246.tchize@myrealbox.com> Message-ID: <403729EB.4070401@cox.net> Fire resistance seems to be no longer effective as I was taking extreme damage with 44% resistance versus otherwise normal dragons and dreads. I just thought I would bring this to your 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 Sat Feb 21 09:18:11 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:03 2005 Subject: [CF-Devel] skills bug Message-ID: <1077376527.8829.2.camel@hawk> I started a new character, and I decided to be a dwarf with no class. This means I started out with smithery and no other skills. This in itself may be a bug (no combat skills at the start). However, what I also found is that when I failed to learn a new skill from a skill scroll, the 'skills command listed the skill, though I couldn't use it. However, I was able to use karate after failing to learn the skill (probably because it was in my skill list, even though it wasn't known). Now I'm gaining levels in a skill I don't have. --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 Feb 21 11:13:10 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:03 2005 Subject: [CF-Devel] About fire damage Message-ID: <403791A6.1070709@laposte.net> Hello. It seems something with either fire resistance or fire damage is weird on crossfire.metalforge.net A player, fireborn, was hit by fire. And it seems to me fire does much more damage. Or maybe it's just dragonbreath which has been upgraded - but dragons hurt a lot more :) 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 Sat Feb 21 12:26:43 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:03 2005 Subject: [CF-Devel] Suggestion: map flag for town portal In-Reply-To: References: Message-ID: <200402211926.50790.d.delbecq@laposte.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Le Vendredi 20 F?vrier 2004 10:11, Tim Rightnour a ?crit : > On 20-Feb-04 tchize wrote: > > And it looks more natural to forget a location as time goes than to > > forget location because of a map reset. > > So tell the player he forgot because too much time passed. What we do > internally, and what we tell the player we do, don't necc. have to be the > same thing. > Agree. But i don't like the idea of flagging because this mean you have to find all places where there are potential treasures and flag the corresponding map. Lots of work. Considering all maps as flagged is more easy to implement. Now, idead whe can tell the player it has forgotten wher to go when map to connected is is going to be reloaded from map path (and nont from cache) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAN6LoHHGOa1Q2wXwRAmaeAKC5cH+1XgxYmG/7M45M9G4VwWY3WgCgnfo7 9M5F8xVXzUQT4iQI/lZfvxM= =CYBi -----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 Feb 21 13:27:06 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:03 2005 Subject: [CF-Devel] Bug report: vitriol issues In-Reply-To: <20040220233354.7b1799db.kstenger@montevideo.com.uy> References: <40352FDE.203@laposte.net> <20040220233354.7b1799db.kstenger@montevideo.com.uy> Message-ID: <200402211327.06858.eracclists@bellsouth.net> On Friday 20 February 2004 20:33 Karla Stenger wrote: > Hi, > I add this to this topic since it seems related to what ryo says > below. Just today i noticed my holy word strangely casted, i use a > binding with fire 0, so it could have to do with that. The problem > itself is when i cast it instead of beeing surrounded by holy word, > there is a spot that is not covered and it's precisely the top left > corner and all the top left corners of the squares around me... > just to make it more clear: > > * floor > O spell > X me > > *OOOOOO > O*OOOOO > OO*OOOO > OOOXOOO > OOOOOOO > OOOOOOO > OOOOOOO > > Other cone spells seem to behave the same way. Nice diagram. :-) I've noticed the same with both icestorm and burning hands. > > First, firing under himself would fire top left corner. This > > doesn't happen with other spells (like holy word, for instance). > > Could that be something like initial bullet has this direction? > > Also would like to ask about the banishment spell, until 2 or 3 > days ago it was a very powerful spell which as level 30 in praying > allowed me to grow up to level 60 pretty fast beecause of the size > of it when i casted it centered on me like holy word, it almost > covered the whole place and so I advanced really fast. It's now > been modified so the area covered by it, now i'm level 60 in > praying, is about 4 or 5 sq of radius. [...] It seemed to me that icestorm was not firing as far. Perhaps it is related? FWIW, several things about the new spell code, and possible recent "tweaking", seem to make spells less effective. This is especially noticeable as one gains levels. Perhaps the excessive damage I have noticed from red dragons lately has been an attempt to fix the badly broken dragonbreath spell. The delay on it has made it a fairly unnecessary spell in my character's spell arsenal, it is never used now. Perhaps someone is trying to make it relevant once again(?). I would like it to be more relevant, yes, but not at the expense of no longer being able to fight red dragons with character fire resistance of +69 because my char takes so much damage from one fire hit with dragonbreath. Gene (aka poof, aka eracc) -- Linux era4.eracc.UUCP 2.4.22-26mdkenterprise i686 13:07:08 up 21 days, 15:02, 10 users, load average: 0.02, 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 Sat Feb 21 13:28:43 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:03 2005 Subject: [CF-Devel] About fire damage In-Reply-To: <403791A6.1070709@laposte.net> References: <403791A6.1070709@laposte.net> Message-ID: <200402211328.43850.eracclists@bellsouth.net> On Saturday 21 February 2004 11:13 Nicolas Weeger wrote: > Hello. > > It seems something with either fire resistance or fire damage is > weird on crossfire.metalforge.net > > A player, fireborn, was hit by fire. And it seems to me fire does > much more damage. Or maybe it's just dragonbreath which has been > upgraded - but dragons hurt a lot more :) I have noticed the same. It would be nice to see that particular tweak undone or better tuned. :-) Gene (aka poof, aka eracc) -- Linux era4.eracc.UUCP 2.4.22-26mdkenterprise i686 13:27:24 up 21 days, 15:23, 10 users, load average: 0.00, 0.00, 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 Feb 21 23:18:21 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:04 2005 Subject: [CF-Devel] Suggestion: map flag for town portal In-Reply-To: <200402211926.50790.d.delbecq@laposte.net> References: <200402211926.50790.d.delbecq@laposte.net> Message-ID: <40383B9D.2080402@sonic.net> David Delbecq wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Le Vendredi 20 F?vrier 2004 10:11, Tim Rightnour a ?crit : > >>On 20-Feb-04 tchize wrote: >> >>>And it looks more natural to forget a location as time goes than to >>>forget location because of a map reset. >> >>So tell the player he forgot because too much time passed. What we do >>internally, and what we tell the player we do, don't necc. have to be the >>same thing. >> > > Agree. But i don't like the idea of flagging because this mean you have to > find all places where there are potential treasures and flag the > corresponding map. Lots of work. Considering all maps as flagged is more easy > to implement. Now, idead whe can tell the player it has forgotten wher to go > when map to connected is is going to be reloaded from map path (and nont from > cache) I was about to say that I thought town portal already worked that way - that you couldn't go to a place if the destination has swapped out. But now I see that that is only the case when establishing the portal - eg, if the one you had cast previously to start the connection is gone, you can't link to it. I agree that there should be some marking, so that if the player casts town portal on a map that doesn't reset, they can't keep getting back to the same place. Perhaps that simplest way to do this would be to set up a subtype for the exit object - if the subtype matches, we then verify that on the target space, an object of the same general attributes still exists, and if so, let the player use it, otherwise, player can't use it. shouldn't be that hard to do. _______________________________________________ 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 Feb 21 23:45:12 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:04 2005 Subject: [CF-Devel] About fire damage In-Reply-To: <200402211328.43850.eracclists@bellsouth.net> References: <403791A6.1070709@laposte.net> <200402211328.43850.eracclists@bellsouth.net> Message-ID: <403841E8.5030806@sonic.net> ERACC wrote: > On Saturday 21 February 2004 11:13 > Nicolas Weeger wrote: > > >>Hello. >> >>It seems something with either fire resistance or fire damage is >>weird on crossfire.metalforge.net >> >>A player, fireborn, was hit by fire. And it seems to me fire does >>much more damage. Or maybe it's just dragonbreath which has been >>upgraded - but dragons hurt a lot more :) > > > I have noticed the same. It would be nice to see that particular > tweak undone or better tuned. :-) Dragonbreath was updated, because there were complaints that the spell wasn't powerful enough. I've split the monster dragonbreath and spell into two distinct archetypes, and put the ability (monster) one as it was before, with the spell one still a bit more beefed up. This change should show up on metalforge next time the server is restarted. _______________________________________________ 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 Feb 22 03:22:40 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:04 2005 Subject: [CF-Devel] About fire damage In-Reply-To: <403841E8.5030806@sonic.net> References: <403791A6.1070709@laposte.net> <200402211328.43850.eracclists@bellsouth.net> <403841E8.5030806@sonic.net> Message-ID: <403874E0.6090101@laposte.net> > Dragonbreath was updated, because there were complaints that the spell > wasn't powerful enough. > > I've split the monster dragonbreath and spell into two distinct > archetypes, and put the ability (monster) one as it was before, with the > spell one still a bit more beefed up. Note that it could be challenging to let red dragons use this upgraded dragonbreath :). But then cold & electric dragons should be upgraded too, else they are too unbalanced. > This change should show up on metalforge next time the server is > restarted. Many thanks for your quick tweaks ^_^ 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 Sun Feb 22 13:50:18 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:04 2005 Subject: [CF-Devel] Suggestion: map flag for town portal In-Reply-To: <40383B9D.2080402@sonic.net> References: <200402211926.50790.d.delbecq@laposte.net> <40383B9D.2080402@sonic.net> Message-ID: <200402222050.23880.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 Sun Feb 22 18:57:39 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:04 2005 Subject: [CF-Devel] Suggestion: map flag for town portal In-Reply-To: <200402222050.23880.tchize@myrealbox.com> References: <200402211926.50790.d.delbecq@laposte.net> <40383B9D.2080402@sonic.net> <200402222050.23880.tchize@myrealbox.com> Message-ID: <40395003.1020900@sonic.net> tchize wrote: > > I think you misunderstood problem. Already work that way (using the 2 way exit > subtype) Thanks for the explanation. snipping most of it. > Players using town portal to get access again and again to treasures rooms use > the following trick. > > 1 access the map in a 'classical way' > 2 make the first step of portal casting (the step memorizing location) > 3 get back to town by any mean (eg word of recall) when treasure room is > emptied > 4 wait for map reset > 5 cast second part of portal > 6 access treasure room using portal > 7 in treasure room , cast first part of portal > 8 get back to town with treasures and wait reset > 9 cast second part of portal to regains access to treasures > - and so on. > > So, as i see from discussions, ways to prevent this trickery may be one of the > followings (between brackets are the steps of trickery blocked) > - flag treasure map to prevent town portals spell(bad imo) [2,7] > - flag treasure map to prevent portals pair creation if map has been reset > (better, but lots of work to identify and flag all those maps)[5,9] Flagging maps is always difficult - just as you say, because it can be difficult to identify all those maps. In addition, that may not always solve the problem - a player may still be able to save themselves a lot of the work by doing the town portal on the map right before the treasure/final map. > - in any map, prevent portals pair creation if map has been reset (best imo) > [5,9] This is probably best. But does have some issues. IT is easy enough to add some code to portal creation to know if the map is being loaded into memory for the first time (Effectively, a reset) or if it has been swapped out. But do we care about the case of player is on treasure map, casts one side of the town portal, returns to town via other means (word of recall). Map then resets, but it is reloaded for some other reason (some other player visiting the map for example) - player could then town portal in. This could be very nasty if that person doing the town portal is just waiting for that event (watching the 'maps command for example). The town portal player could basically screw over another play by portaling in, and stealing the treasure before the other player gets a chance to do so. There are some thoughts to maybe prevent this - the most notably putting a real time limit on how long you can remember your previous portal location. One could express this simply in ticks (eg, the spell last 50,000 ticks, or roughly 1.5 hours, before it goes away). However, that doesn't help out the case where the player logs in, portals to the treasure, returns home, and logs out, and repeats the next day. So the better solution is then to actually store that in terms of real time (time() call) - this would actually be relatively simple - when player casts the first side of the spell, store in some value of the force field the current time + the reset time from the map. Then when the player casts again, compare that value against the current time - if that value is in the past, tell the player that they forgot the other location. That is foolproof and relatively simple. Now there could be cases where the map does not reset as soon as expected (if people keep visiting hte map, it might never reset), but that's a different matter. _______________________________________________ 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 Feb 22 19:03:29 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:04 2005 Subject: [CF-Devel] skills bug In-Reply-To: <1077376527.8829.2.camel@hawk> References: <1077376527.8829.2.camel@hawk> Message-ID: <40395161.2090106@sonic.net> Preston Crow wrote: > I started a new character, and I decided to be a dwarf with no class. > This means I started out with smithery and no other skills. This in > itself may be a bug (no combat skills at the start). It is a player induced bug, which I don't have a lot of sympathy for. Really, the ability to start a character with no class should be removed. At one point, there was a problem that for whatever reasons, player would end up back in the hall of selection, and thus could get multiple classes, so that was added as a way out. I don't think that has happened for a long time. But point remains, if a player chooses to start without a class, the deserve what they get. I'd consider this similar to a character playing a wizard type class and having a 4 int and 4 pow, and then complaining that with only 1 sp, they can't cast any spells. Answer to that is to have higher stats. > However, what I > also found is that when I failed to learn a new skill from a skill > scroll, the 'skills command listed the skill, though I couldn't use it. I've fixed this, but this is sort of normal. There are many skills which you can get exp in without natively knowing the skill. Any skill which uses skill tools is such a case (lockpicking, inscription). There are also some skills which you can know the skill natively or with a skill tool (the spell casting skills with talismans or holy symbols). IMO, we want to show the exp they have in those skills, even if they need a skill tool. But it is also problematic in some areas in that we just can't do something like not show skills with 0 exp, because I think there are still some skills out there where you just can't get any exp, but we still want to show you have the skill (mountaineering comes to mind here) > However, I was able to use karate after failing to learn the skill > (probably because it was in my skill list, even though it wasn't known). Yep - the code that tries to find a melee skill wasn't looking to see if you could use the skill without a skill tool. That is also fixed. _______________________________________________ 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 Feb 22 19:20:22 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:04 2005 Subject: [CF-Devel] Suggestion: map flag for town portal In-Reply-To: <200402222050.23880.tchize@myrealbox.com> References: <200402211926.50790.d.delbecq@laposte.net> <40383B9D.2080402@sonic.net> <200402222050.23880.tchize@myrealbox.com> Message-ID: On Sun, 22 Feb 2004, tchize wrote: > > prevent portals pair creation if map has been reset (best imo) > This is best imo too. I suggest: On first part of TP we do not only "memorize" location in player variables, we also create an (visible) object "playername's portal marker" on the map. Possible gfx: 1. TP with black center 2. smaller TP 3. transparent TP On casting the second TP, we can check if this marker still exists. It will vanish always on map reset. As a bonus, the player can see if the casting of TP was successful without reading log. Bernd Edler _______________________________________________ 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 Feb 22 19:24:10 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:04 2005 Subject: [CF-Devel] Future plans? In-Reply-To: <403532F8.8060702@laposte.net> References: <403532F8.8060702@laposte.net> Message-ID: <4039563A.7010505@sonic.net> Nicolas Weeger wrote: > Hello. > > I was wondering if anyone was doing any big thing on the server (or > client) side. Any big feature planned? > I'm out of ideas right now :) > (ok, i could clean warnings, or write documentation, but it's funnier to > do new things, sometimes). Well, in the near future, I'll probably make a new server release, which is one reason I've been more on top of bugs recently than big features. The TODO list is always an interesting place to look. Anyways, a short list of thoughts: 1) Refine blocking code (flying, walking, swimming, spells, etc). This should be discussed more before actually doing so, because there are many issues (like most projects, much rather it get done properly the first time, vs have to get hacked on multiple times). But quickly, the idea would be to add something like 'required_move_types', 'slowed_move_types' and 'can_move_type' to the objects. The naming here is a bit messy, because there is already a 'move_type' field in the object for pet move, or random moves, etc. Basically, if required move types is set, the player/monster must have one those move types to move through the space. If it is set to 0, then there are no restrictions. slowed_move_types indicates the terrain slows movements for those types. In that way, hills could slow movement for people walking, but not flying. The skills themselves could contain there own move types, to indicate that they help movement through that type of terrain. 2) Re do treasure lists as mentioned in mail a month or two back. 3) client/protocol improvements. One that comes immediately to mind, and not too difficult, is change the drawinfo stuff. Instead of hte server telling the client color informatin, the server should tell the client context information (level gain, killed creature, item description, listing, etc). Probably want to figure out maybe around a dozen of these - in that way, the client, and ideally the player through menus, can determine how to display it (color, different font, etc). 4) Re do character cretion - ideally, give player some number of stat points, and let the client do the work of letting the player set the stats, choose race, choose starting point, etc. I think that would make for a friendlier start than the current method. The server off coursse validates the results. probably others I'm forgetting. As for what I'm working on right now - I'm doing work on a gtk 2 compliant client, developed with glade. I really cared more about the glade part that hte gtk2 part, but glade will make other developement of client interfaces much easier in the future. > > As a side note, bug #757920 (gcfclient Win32 port unproperly handling > cached images) can be closed, it has been fixed in 1.6.0 release. You should have permissions now to update bugs on your own. _______________________________________________ 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 Feb 22 23:33:26 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:04 2005 Subject: [CF-Devel] Two things - item_power, Divine Shock In-Reply-To: <4032F910.30007@sonic.net> References: <200402162012.20199.eracclists@bellsouth.net> <40318A3C.6020409@sonic.net> <200402162355.20396.eracclists@bellsouth.net> <20040217145946.25ff2b3f.kstenger@montevideo.com.uy> <4032F910.30007@sonic.net> Message-ID: <403990A6.9070209@sonic.net> Mark Wedel wrote: > Karla Stenger wrote: > > This is also easy. And in fact, I believe can show up for other > objects also (if we allowed ettin characters, and they wore two helmets, > the same thing would happen). > > Rings right now are special cased in that the ring is applied, we don't > try to merge it. I'm thinking removing that special case - in all > cases, if an object is applied, it can't merge with another applied > objects. I'm trying to think if there are any cases where that would > cause problems - cases where you really want 5 of an item all grouped > together and applied at the same time. I can't think of any such cases > - if someone can think of some, let me know, otherwise, I'll put the > change in that applied objects never merge with items of the same type. Since no one mentioned anything, I'll make a change in the code so that applied objects never merge. Hopefully that won't break anything. _______________________________________________ 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 Feb 22 23:50:20 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:04 2005 Subject: [CF-Devel] Bug report: vitriol issues In-Reply-To: <20040220233354.7b1799db.kstenger@montevideo.com.uy> References: <40352FDE.203@laposte.net> <20040220233354.7b1799db.kstenger@montevideo.com.uy> Message-ID: <4039949C.1080808@sonic.net> Karla Stenger wrote: > *OOOOOO > O*OOOOO > OO*OOOO > OOOXOOO > OOOOOOO > OOOOOOO > OOOOOOO > > Other cone spells seem to behave the same way. yep - will commit change to CVS shortly. > Also would like to ask about the banishment spell, until 2 or 3 days ago it was > a very powerful spell which as level 30 in praying allowed me to grow up to > level 60 pretty fast beecause of the size of it when i casted it centered on me > like holy word, it almost covered the whole place and so I advanced really fast. > It's now been modified so the area covered by it, now i'm level 60 in praying, > is about 4 or 5 sq of radius. So my point is, yes the spell was too powerful for > beeing so big before, but now it's almost useless since it's too small and > casting twice holy word (that is still big as it used to be) would be much worth > than casting 5 or 6 times banishment. > How are those radius calculated anyway? The main change made a few days ago (related to the above change that broke that one angle) is that if you cast a cone spell in direction 0 (all directions) the range is not as far as if you specify a direction. The range is 1/4 in fact. This basically means that a cone spell will always cover roughly the same number of spaces. This is also how the code before the spell revamp worked. IT is arguably a more fair thing to do. The exact value could be tweaked (radius range to 1/3 or something). The range for all cone spell is specified in the spell object itself - thus there is no global 'how far will a cone spell go'. Range also slowly increases with level of the caster. Now because of rounding errors, casting in direction 0 could also hurt a bit more -eg, if the spell has direction range of 11, that means if you don't specify a range, it would only go 2 spaces (fractions are dropped). Note that a minimum range of 2 will occur in most all cases, even if the spell is cast in direction 0. _______________________________________________ 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 Feb 23 21:17:58 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:04 2005 Subject: [CF-Devel] skills bug In-Reply-To: <40395161.2090106@sonic.net> References: <1077376527.8829.2.camel@hawk> <40395161.2090106@sonic.net> Message-ID: <1077592677.16146.11.camel@hawk> Mark wrote: > Preston Crow wrote: > > I started a new character, and I decided to be a dwarf with no class. > > This means I started out with smithery and no other skills. This in > > itself may be a bug (no combat skills at the start). > > > It is a player induced bug, which I don't have a lot of sympathy for. > > Really, the ability to start a character with no class should be removed. At > one point, there was a problem that for whatever reasons, player would end up > back in the hall of selection, and thus could get multiple classes, so that was > added as a way out. > > I don't think that has happened for a long time. But point remains, if a > player chooses to start without a class, the deserve what they get. Well, I thought it would let me be a dwarf with a dwarf icon, but without any special starting skills. I was surprised not to have at least punching and the wand-use skill (or some way to acquire it). And on a related note: With the old system, using lockpicking would get you 20xp/door or so. I don't seem to get any experience now. Is that intentional? I was practicing singing and oratory, and I now have 15xp in missile weapons (a skill I don't have). I'm guessing an orc pet killed another orc with an arrow, and the xp was credited as if I had fired the arrow, not my pet. --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 Feb 23 21:50:31 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:04 2005 Subject: [CF-Devel] Lava floor vs. cone spells Message-ID: <20040224005031.75c57fb0.kstenger@montevideo.com.uy> Hi again, For some reason i dont understand the lava floor (as in training area for killing demons) does not allow cone spells to be casted more than one square farther than yourself, this applies to monsters and players, and is happening since some time ago, sorry for not telling before... but my empty head sometimes just forgets :/ I have no clue on why this is happening, but the only thing Ryo and i noticed is that the lava floor has lifesave 1... in the hope it makes things easier for you this is the dump of the lava floor: arch permanent_lava name lava name_pl lava face lava.114 animation permanent_lava hp 1 dam 3 wc -30 x 2 y 4 speed 0.200000 speed_left -0.500000 level 1 type 102 subtype 7 attacktype 4 state 3 smoothlevel 28 no_pick 1 walk_on 1 is_animated 1 is_floor 1 lifesave 1 end See you, Katia. -- +-----------------------------+ | 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 Mon Feb 23 23:59:58 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:04 2005 Subject: [CF-Devel] Lava floor vs. cone spells In-Reply-To: <20040224005031.75c57fb0.kstenger@montevideo.com.uy> References: <20040224005031.75c57fb0.kstenger@montevideo.com.uy> Message-ID: <403AE85E.60007@sonic.net> Karla Stenger wrote: > Hi again, > > For some reason i dont understand the lava floor (as in training area for > killing demons) does not allow cone spells to be casted more than one square > farther than yourself, this applies to monsters and players, and is happening > since some time ago, sorry for not telling before... but my empty head sometimes > just forgets :/ > > I have no clue on why this is happening, but the only thing Ryo and i noticed is > that the lava floor has lifesave 1... in the hope it makes things easier for you > this is the dump of the lava floor: Fixed in CVS. the lifesave had nothing to do with it. the problem actually was that the spell code uses the maxhp field to see if the smae spell is hitting the same space more than once, and if so, don't put any more on that space. That is sort of necessary based on how some spells move. The problem was that wasn't being set. And since lava is also a cone spell (believe it or not), when it encounter the lava, it thought the spell was already on the space. I also believe a bug was opened a while back on this (but don't see it, so maybe it was just a mention) that if you cast a cone spell at another cone spell, you effectively neutralized it. That shouldn't happen anymore either. Also, it does mean that cone spell should now do a bit more damage in the center (core) area, because that can still have up to 3 effects on the space instead of just one. _______________________________________________ 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 Feb 24 00:16:51 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:05 2005 Subject: [CF-Devel] skills bug In-Reply-To: <1077592677.16146.11.camel@hawk> References: <1077376527.8829.2.camel@hawk> <40395161.2090106@sonic.net> <1077592677.16146.11.camel@hawk> Message-ID: <403AEC53.6000904@sonic.net> Preston Crow wrote: > Mark wrote: > Well, I thought it would let me be a dwarf with a dwarf icon, but > without any special starting skills. I was surprised not to have at > least punching and the wand-use skill (or some way to acquire it). It's just the way the treasure lists are set up - those are basic class skills, and are in the skill treasurelists, not the racial treasurelists. That of course could be change. > > > And on a related note: > > With the old system, using lockpicking would get you 20xp/door or so. I > don't seem to get any experience now. Is that intentional? It should work - I just tried it now, and got some exp. Most likely, this was caused by a bug that caused the skill not to get properly linked in, which I just committed a fix for. > > I was practicing singing and oratory, and I now have 15xp in missile > weapons (a skill I don't have). I'm guessing an orc pet killed another > orc with an arrow, and the xp was credited as if I had fired the arrow, > not my pet. Most likely, correct. As mentioned before, it is entirely possible to have exp in skills you can't use. One change with the new skill code is that anything that gives exp records which skill the exp goes to. There used to be problems in the past, especially in party play, where players could funnel exp to most any skill they wanted (player A kilsl something with fireball, player b funnels it into praying). That should be next to impossible in the new code. But it does mean that if the orc pets kills something with missile weapons, you get the exp in missile weapons. _______________________________________________ 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 Feb 24 01:17:03 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:05 2005 Subject: [CF-Devel] skills bug In-Reply-To: <403AEC53.6000904@sonic.net> References: <1077376527.8829.2.camel@hawk> <1077592677.16146.11.camel@hawk> <403AEC53.6000904@sonic.net> Message-ID: <200402240117.03886.eracclists@bellsouth.net> On Tuesday 24 February 2004 00:16 Mark Wedel wrote: [...] > One change with the new skill code is that anything that gives > exp records which skill the exp goes to. There used to be problems > in the past, especially in party play, where players could funnel > exp to most any skill they wanted (player A kilsl something with > fireball, player b funnels it into praying). As far as I am concerned this did not need to be "fixed". Now it is broken. Placing exp in whatever skill *I* have selected when working in party makes perfect sense to me. Placing it in something I cannot use makes no sense whatsoever. > That should be next to impossible in the new code. But it does > mean that if the orc pets kills something with missile weapons, you > get the exp in missile weapons. Which makes working with a party pretty much useless for training skills that are useful to my character. A dragon with level 23 in two handed weapons is quite silly unless a dragon can now wield two handed weapons. Further, I tried to help another player, Omoikane on cf.mf.net, level up summoning, he DOES have that skill, and he never got any exp in summoning although MY summoning skill was clicking right up. Unless that is now fixed then why ever join a party, other than just because it is there, when I can level up what I *need* on my own? One other thing. Dragons have *fingers* (for rings) but not *hands* (for stealing)? You guys sure created some odd looking dragons. When I was chatting with Katia about it the other night in CF I was splitting my sides laughing at that picture in my head. :-) Seems that stealing would be linked to having *fingers* (does the US term "five finger discount" ring a bell? No? It is a term that refers to shoplifting aka stealing). Classic paintings of dragons clearly show hands. Though I suppose wielding weapons in CF is tied to hands and we don't want dragons doing that. So, fingers for stealing anyone? Gene (aka poof, aka eracc) -- Linux era4.eracc.UUCP 2.4.22-26mdkenterprise i686 00:54:52 up 24 days, 2:50, 11 users, load average: 0.00, 0.04, 0.07 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 Feb 24 01:46:27 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:05 2005 Subject: [CF-Devel] skills bug In-Reply-To: <200402240117.03886.eracclists@bellsouth.net> References: <1077376527.8829.2.camel@hawk> <1077592677.16146.11.camel@hawk> <403AEC53.6000904@sonic.net> <200402240117.03886.eracclists@bellsouth.net> Message-ID: <403B0153.6020209@sonic.net> ERACC wrote: > On Tuesday 24 February 2004 00:16 > Mark Wedel wrote: > > As far as I am concerned this did not need to be "fixed". Now it is > broken. Placing exp in whatever skill *I* have selected when working > in party makes perfect sense to me. Placing it in something I cannot > use makes no sense whatsoever. Matter of opinion I suppose. It doesn't make any sense ot me that if I have bargaining readied and a party friend blasts something with a fireball that my bargaining skill should go up. And most previous messages I have seen on the subject suggested just that was in fact a bug, cheat, or other non desirable feature. > Which makes working with a party pretty much useless for training > skills that are useful to my character. A dragon with level 23 in > two handed weapons is quite silly unless a dragon can now wield two > handed weapons. Further, I tried to help another player, Omoikane on > cf.mf.net, level up summoning, he DOES have that skill, and he never > got any exp in summoning although MY summoning skill was clicking > right up. Unless that is now fixed then why ever join a party, other > than just because it is there, when I can level up what I *need* on > my own? Well, that is the first I have heard of summoning exp not getting properly credited - it should, so that is a bug There may not be a bunch of good reasons to join a party - that is of course a player determination. But do note that even if you don't have the skill in question, your character still gains that for overall exp. So while it may not help in any particular skill, it may help their overall level if they are generally not able to kill things. > > One other thing. Dragons have *fingers* (for rings) but not *hands* > (for stealing)? You guys sure created some odd looking dragons. When > I was chatting with Katia about it the other night in CF I was > splitting my sides laughing at that picture in my head. :-) Seems > that stealing would be linked to having *fingers* (does the US term > "five finger discount" ring a bell? No? It is a term that refers to > shoplifting aka stealing). Classic paintings of dragons clearly show > hands. Though I suppose wielding weapons in CF is tied to hands and > we don't want dragons doing that. So, fingers for stealing anyone? I'll fix that in the code - it is relatively minor. What it basically comes down to is that you must have a free hand available to steal (not holding a shield or weapon). As part of that, it means you need to unequip such items - it would be odd to have to unequip rings to steal. I'll just put a check in that if the character in question doesn't have any hands, he doesn't need a free hand available. I'd imagine this should also let fireborns and perhaps other races steal, but I think that is perfectly fine (fireborns are somehow carrying lots of objects with no real body, so if they pick up objects, they should also be able to steal). _______________________________________________ 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 Feb 24 01:49:30 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:05 2005 Subject: [CF-Devel] skills bug In-Reply-To: <200402240117.03886.eracclists@bellsouth.net> Message-ID: On 24-Feb-04 ERACC wrote: >> There used to be problems >> in the past, especially in party play, where players could funnel >> exp to most any skill they wanted (player A kilsl something with >> fireball, player b funnels it into praying). > > As far as I am concerned this did not need to be "fixed". Now it is > broken. Placing exp in whatever skill *I* have selected when working > in party makes perfect sense to me. Placing it in something I cannot > use makes no sense whatsoever. I'll agree that this is broken.. but not in the same way eracc states. It doesn't necc. make a whole lot of sense that if a warrior and a mage are a duo, and the mage casts a fireball, that somehow, the warrior has gained experience in magic. He was just standing there. I'm not completely sure there is a logical place to put that experience, but putting it into magic doesn't make any sense either. The funnelling made slightly more sense.. but on a grander scale made a bigger mess. Just an off the cuff idea, but what if when a party member uses a skill you don't have, or you gain exp in that skill by some other means, such as a tamed orc, it instead goes into a generic bucket, at a reduced rate, say, 50%. Then, the player can issue a command, to empty that bucket, into the skill of his choice. >> That should be next to impossible in the new code. But it does >> mean that if the orc pets kills something with missile weapons, you >> get the exp in missile weapons. This makes me wonder how one is supposed to get EXP with oratory and singing, if all the exp from tame monsters goes into melee and archery. Is the same true for things like golems and avatars? Do they now transfer exp as melee? --- 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 Feb 24 02:29:35 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:05 2005 Subject: [CF-Devel] skills bug In-Reply-To: <403B0153.6020209@sonic.net> References: <1077376527.8829.2.camel@hawk> <200402240117.03886.eracclists@bellsouth.net> <403B0153.6020209@sonic.net> Message-ID: <200402240229.35478.eracclists@bellsouth.net> On Tuesday 24 February 2004 01:46 Mark Wedel wrote: > ERACC wrote: > > On Tuesday 24 February 2004 00:16 > > Mark Wedel wrote: > > > > > > As far as I am concerned this did not need to be "fixed". Now it > > is broken. Placing exp in whatever skill *I* have selected when > > working in party makes perfect sense to me. Placing it in > > something I cannot use makes no sense whatsoever. > > Matter of opinion I suppose. It is. > It doesn't make any sense ot me that if I have bargaining readied > and a party friend blasts something with a fireball that my > bargaining skill should go up. Then consider if I have ability to use a physical skill like karate, clawing and/or punching (my char poof knows and can use all three) then another player using a physical skill like two handed weapons will increase one of the physical skills I *can* use. For dragons make the default clawing *or* the readied physical skill if that will make it easier. If a monk is using karate in party with a paladin that knows one handed weapons and missile weapons then exp from monk's karate should go to one of paladin's usable physical paths. If the paladin is using prayers then the monk gains skill in praying and the paladin gains skill in a default physical path, let us say one handed weapons, from the monk's use of karate. Your point about bargaining props up my argument in this regard. If the other player uses a sorcery path spell then I *do* get exp in sorcery. If player does NOT have a physical path ability then exp only goes to overall and nothing else. There is no point in giving a player exp in a path s/he can NOT use. If this is the only way to do it and my suggestion is too hard to code or would cause too much CPU load on the server then I'll drop it. > And most previous messages I have seen on the subject suggested > just that was in fact a bug, cheat, or other non desirable feature. Ok, then please at least consider fine tuning it to better train what a player can use. The current model is just strange. :-P [...] > There may not be a bunch of good reasons to join a party - that > is of course a player determination. But do note that even if you > don't have the skill in question, your character still gains that > for overall exp. So while it may not help in any particular skill, > it may help their overall level if they are generally not able to > kill things. I usually only join a party to help another player train in a skill that s/he is finding troublesome (like summoning, too dang hard!) or to try to train my skills with another player that can assist me. I quit joining parties "just for fun" when my character kept dying due to the errors of thoughtless party members. In regard to overall exp I care more about spell paths and physical paths I can use than my overall score. As far as I am concerned overall score is just a number, that gives bragging rights of course, but the *real* meat and potatoes of CF is in raising exp in the skill paths. [...] Gene (aka poof, aka eracc) -- Linux era4.eracc.UUCP 2.4.22-26mdkenterprise i686 01:57:07 up 24 days, 3:53, 11 users, load average: 0.07, 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 Tue Feb 24 08:33:41 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:05 2005 Subject: =?iso-8859-1?Q?Re:_Re:_[CF-Devel]_skills_bug?= Message-ID: >Just an off the cuff idea, but what if when a party member >uses a skill you don't have, or you gain exp in that skill by >some other means, such as a tamed orc, it instead goes into a >generic bucket, at a reduced rate, say, 50%. Then, the player >can issue a command, to empty that bucket, into the skill of >his choice. Well I like half of Tim's idea, how about a player just gets 50% experience in their general XP bucket? Keep the skills out of it all together. And if overall xp is not fine enough in itself we could make some kinds of skills and abilities that ramp up based on general level rather than skill level. >I quit joining parties "just for fun" when my character kept >dying due to the errors of thoughtless party members. This should happen a lot less now with friendly fire code. Party play should really be mostly to allow a group of player to overcome situations where they would not be able to survive alone and secondly be a way for players to interact together. I would consider xp benefits a distant third in desirable party mechanics. Training up players is an abuse of the party system IMHO. -Todd _______________________________________________ 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 Feb 24 09:47:52 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:05 2005 Subject: [CF-Devel] skills bug In-Reply-To: References: Message-ID: <1077637672.15622.3.camel@d5110227.lss.emc.com> On Tue, 2004-02-24 at 09:33, Todd Mitchell wrote: > >Just an off the cuff idea, but what if when a party member > >uses a skill you don't have, or you gain exp in that skill by > >some other means, such as a tamed orc, it instead goes into a > >generic bucket, at a reduced rate, say, 50%. Then, the player > >can issue a command, to empty that bucket, into the skill of > >his choice. > > Well I like half of Tim's idea, how about a player just gets 50% experience in their general XP bucket? Keep the skills out of it all together. And if overall xp is not fine enough in itself we could make some kinds of skills and abilities that ramp up based on general level rather than skill level. The other option is to distribute the xp among the skills based on the current distribution of xp. This would probably be implemented using statistical odds--for each incoming point, select a random number between 1 and the total number of skill xp, then count down the list of skills, subtracting the xp until it goes negative, and assign the point to that skill. (There's probably a better way of implementing it, but you should get the idea.) Or we could have a "party" skill. (Hmmm, with a level 3 party skill, I can create booze. At level 10, I can create wine...) :) --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 Feb 24 13:16:49 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:05 2005 Subject: [CF-Devel] Suggestion: map flag for town portal In-Reply-To: References: <200402222050.23880.tchize@myrealbox.com> Message-ID: <200402242017.00832.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 Tue Feb 24 13:29:32 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:05 2005 Subject: [CF-Devel] Future plans? In-Reply-To: <4039563A.7010505@sonic.net> References: <403532F8.8060702@laposte.net> <4039563A.7010505@sonic.net> Message-ID: <200402242029.41191.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 Tue Feb 24 16:06:38 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:05 2005 Subject: [CF-Devel] Suggestion: map flag for town portal In-Reply-To: <200402242017.00832.tchize@myrealbox.com> References: <200402222050.23880.tchize@myrealbox.com> <200402242017.00832.tchize@myrealbox.com> Message-ID: <20040224190638.61e96a0b.kstenger@montevideo.com.uy> > Le Lundi 23 F?vrier 2004 02:20, Bernd Edler a ?crit : > > On Sun, 22 Feb 2004, tchize wrote: > > > prevent portals pair creation if map has been reset (best imo) > > > > This is best imo too. > > > > I suggest: > > On first part of TP we do not only "memorize" location in player > > variables, > > we also create an (visible) object "playername's portal marker" on the > > map. > > Possible gfx: > > 1. TP with black center > > 2. smaller TP > > 3. transparent TP > > > > On casting the second TP, we can check if this marker still exists. > > It will vanish always on map reset. > > > > As a bonus, the player can see if the casting of TP was successful > > without reading log. > > > > Bernd Edler > > > > > Though this mean creating a portal is like building 2 doors and then a tunnel, > while current behaviour is more to create a tunnel which end up having two > exits. I like this idea. Simple to implement. Can be used to chack map reset > easily. > So i agree with you way. > I like this too, looks like maps like guilds could still be reachable even if you casted the first part of the spell long time ago to "go back home" since the permanent tiles wouldnt reset the items on it, right? Katia. -- +-----------------------------+ | 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 Tue Feb 24 16:22:11 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:05 2005 Subject: [CF-Devel] Small patch: a few warnings :) Message-ID: <403BCE93.3040705@laposte.net> Hello. Here's just a small patch to fix a few warnings. Just type mistaches (map coordinates are sint16, not int, and stats are signed char, not int) Nicolas 'Ryo' -------------- next part -------------- Index: server/apply.c =================================================================== RCS file: /cvsroot/crossfire/crossfire/server/apply.c,v retrieving revision 1.98 diff -u -r1.98 apply.c --- server/apply.c 18 Feb 2004 05:28:54 -0000 1.98 +++ server/apply.c 24 Feb 2004 22:07:30 -0000 @@ -3165,7 +3165,7 @@ do { i=10; /* let's give it 10 tries */ while((tmp=generate_treasure(op->randomitems, - op->stats.exp?op->stats.exp:MAX(op->map->difficulty, 5)))==NULL&&--i); + op->stats.exp?(int)op->stats.exp:MAX(op->map->difficulty, 5)))==NULL&&--i); if(tmp==NULL) return 0; if(QUERY_FLAG(tmp, FLAG_CURSED) || QUERY_FLAG(tmp, FLAG_DAMNED)) { @@ -3186,7 +3186,7 @@ return 0; while ((op->stats.hp--)>0) create_treasure(op->randomitems, op, op->map?GT_ENVIRONMENT:0, - op->stats.exp ? op->stats.exp : + op->stats.exp ? (int)op->stats.exp : op->map == NULL ? 14: op->map->difficulty,0); /* If we generated on object and put it in this object inventory, @@ -3272,7 +3272,8 @@ void eat_special_food(object *who, object *food) { object *force; - int i, did_one=0, k; + int i, did_one=0; + signed char k; force = get_archetype(FORCE_NAME); @@ -3457,7 +3458,7 @@ */ int i,j; for(i=0;i<7;i++) { - int stat=get_attr_value(stats,i); + signed char stat=get_attr_value(stats,i); int race_bonus = get_attr_value(&(pl->arch->clone.stats),i); stat += get_attr_value(ns,i); if(stat > 20 + race_bonus) { Index: server/spell_attack.c =================================================================== RCS file: /cvsroot/crossfire/crossfire/server/spell_attack.c,v retrieving revision 1.6 diff -u -r1.6 spell_attack.c --- server/spell_attack.c 24 Feb 2004 05:43:58 -0000 1.6 +++ server/spell_attack.c 24 Feb 2004 22:07:34 -0000 @@ -275,7 +275,7 @@ if(op->range>0) { for(i=1;i<9;i++) { - int dx,dy; + sint16 dx,dy; dx=op->x+freearr_x[i]; dy=op->y+freearr_y[i]; @@ -700,7 +700,7 @@ } for(i= -1;i<2;i++) { - int x=op->x+freearr_x[absdir(op->stats.sp+i)], + sint16 x=op->x+freearr_x[absdir(op->stats.sp+i)], y=op->y+freearr_y[absdir(op->stats.sp+i)]; if(ok_to_put_more(op->map,x,y,op,op->attacktype)) { @@ -747,7 +747,7 @@ } for(i=range_min;i<=range_max;i++) { - int x,y, d; + sint16 x,y, d; /* We can't use absdir here, because it never returns * 0. If this is a rune, we want to hit the person on top @@ -909,7 +909,7 @@ object *tmp; - int dx=op->x+freearr_x[dir], dy=op->y+freearr_y[dir]; + sint16 dx=op->x+freearr_x[dir], dy=op->y+freearr_y[dir]; if(get_map_flags(op->map,NULL, dx,dy, NULL,NULL) & (P_OUT_OF_MAP | P_WALL)) { new_draw_info(NDI_UNIQUE, 0,op,"There is something in the way."); @@ -1458,7 +1458,8 @@ */ void move_ball_spell(object *op) { - int i,nx,ny,j,dam_save,dir, mflags; + int i,j,dam_save,dir, mflags; + sint16 nx,ny; object *owner; mapstruct *m; -------------- 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 Feb 24 16:33:41 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:06 2005 Subject: [CF-Devel] skills bug In-Reply-To: <200402240117.03886.eracclists@bellsouth.net> References: <1077376527.8829.2.camel@hawk> <1077592677.16146.11.camel@hawk> <403AEC53.6000904@sonic.net> <200402240117.03886.eracclists@bellsouth.net> Message-ID: On Tue, 24 Feb 2004, ERACC wrote: > Further, I tried to help another player, Omoikane on > cf.mf.net, level up summoning, he DOES have that skill, and he never > got any exp in summoning although MY summoning skill was clicking > right up. Just to make sure.. You both were in the same party? ('partywho) You both were in the same general area during the time you were gaining experience? > Unless that is now fixed then why ever join a party, other > than just because it is there, when I can level up what I *need* on > my own? As an example: while Player A is regenerating spell points, Player B is toasting monsters with burning hands until Player B runs out of Spell Points. Player B sits back, while Player A burns monsters. During this whole time, each player is gaining experience in the relevant skill. Sure, each player could work seperately on this - but it probably won't be as fast or efficient as working in a party. - Rick _______________________________________________ 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 Feb 24 18:24:46 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:06 2005 Subject: [CF-Devel] skills bug In-Reply-To: References: <1077376527.8829.2.camel@hawk> <200402240117.03886.eracclists@bellsouth.net> Message-ID: <200402241824.46424.eracclists@bellsouth.net> On Tuesday 24 February 2004 16:33 Rick Tanner wrote: > On Tue, 24 Feb 2004, ERACC wrote: > > Further, I tried to help another player, Omoikane on > > cf.mf.net, level up summoning, he DOES have that skill, and he > > never got any exp in summoning although MY summoning skill was > > clicking right up. > > Just to make sure.. > > You both were in the same party? ('partywho) Yes. I created the party and we both joined it. > You both were in the same general area during the time you were > gaining experience? Yes. One of the Scorn training areas. Don't recall which. We could talk to each other using 'say, so we were in the same area. [...] Gene (aka poof, aka eracc) -- Linux era4.eracc.UUCP 2.4.22-26mdkenterprise i686 18:21:45 up 24 days, 20:17, 11 users, load average: 0.31, 0.12, 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 Tue Feb 24 23:42:47 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:06 2005 Subject: [CF-Devel] skills bug In-Reply-To: References: Message-ID: <200402251542.47309.won_fang@yahoo.com.au> On Tue, 24 Feb 2004 05:49 pm, Tim Rightnour wrote: > doesn't necc. make a whole lot of sense that if a warrior and a mage are a > duo, and the mage casts a fireball, that somehow, the warrior has gained > experience in magic. He was just standing there. If the warrior was paying attention, then he has just seen how an expert casts a fireball. It can be very educational to watch an expert at work. Now the warrior nows a little more about how to cast fireballs, and how to cast magic in general. Sometime in the future, the warrior learns the fireball spell and remembers "I once saw a mage cast fireballs this way." he will find the casting of fireballs a little easier. If the warrior never learns magic, let alone the fireball spell, then he knows a little bit of trivia that may be usefull for winning bets at his local tavern B-). On the other hand, if the warrior was busy swinging his sword at something big and scary at the time, he would not have a chance to study an expert mage doing what mages do best. Also, the mage would only share mystical secrets with his party members. The same thing applies when a mage studies a friendly warrior waving a sword around in an expert manner. _______________________________________________ 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 Feb 25 01:14:19 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:06 2005 Subject: [CF-Devel] Small patch: a few warnings :) In-Reply-To: <403BCE93.3040705@laposte.net> References: <403BCE93.3040705@laposte.net> Message-ID: <403C4B4B.1070304@sonic.net> Nicolas Weeger wrote: > Hello. > > Here's just a small patch to fix a few warnings. > Just type mistaches (map coordinates are sint16, not int, and stats are > signed char, not int) Note that you should really use the 'sint8' type instead of declaring things signed character. Not likely to make much a difference, but better to be consistent in type declaration. _______________________________________________ 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 Feb 25 01:33:46 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:06 2005 Subject: [CF-Devel] Future plans? In-Reply-To: <200402242029.41191.d.delbecq@laposte.net> References: <403532F8.8060702@laposte.net> <4039563A.7010505@sonic.net> <200402242029.41191.d.delbecq@laposte.net> Message-ID: <403C4FDA.3010407@sonic.net> David Delbecq wrote: > > Although i like the idea to have one or several movement types > (flying/crawling/swimming/walking/horsing) associated with a player (and so > several base speeds). I'd like to had the following idea. Give a ground > clearance and a sky clearance to all wall - like blockings (at least at > outside of world, too many issue in the inside). Well, probably best to have the default values for wall to be completely impassable (Effectively infinitely high and infinitely low). In this way, walls that you want to allow people to fly over have to be specifically set. Setting the height of the wall makes a lot of sense. This could also be useful addition for the jump and climbing skill (eg, a 20' high wall can maybe be climbed over, a 5' high wall jumped over, etc). In terms of clearance - it seems there are two potential things being talked about - clearance, and for lack of better term, permiability. For clearance, the idea has some merit, but that certainly gets a little trickier. I'd need to see more concrete uses for it - presuming the all the players are the same size, may not be as useful. Otherwise, it may require a lot fo rework - eg, if a space is marked as 'blocked', then monsters won't see through, and thus won't really take advantage that they may in fact be able to get through it. For it to be in any way efficient, you need to be able to determine if a creature can get through the space without looking on the objects on the space, eg, you can store flags like 'small creature can get through, medium creature, etc'. Now the other point you seem to touch on is permiability - the holes in the wall. EG, a wall that has many small holes could let tiny creatures through, and a wall with a small hold could let small creatures (kobolds maybe) get through, but not humans. Unless a person is plasticman, they can't get through a hole smaller than they are. I'm personally much more concerned with movement types that player may use or may cause to use (fire spells, arrows, etc) - this is because players move about less often than other objects, and so we can 'afford' to extra cost of checking the player movement. Also, in terms of players, line of sight is less a concern - if a player doesn't know what is behind that wall, he is still free to scale it. OTOH, if a monster doesn't know what is beyond that wall, they won't even bother to try to climb it/get through it/whatever. Granted, monster logic could get greatly improved - I just haven't seen a lot of work in that area for quite a while. _______________________________________________ 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 Feb 25 01:56:15 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:06 2005 Subject: [CF-Devel] skills bug In-Reply-To: <200402241824.46424.eracclists@bellsouth.net> References: <1077376527.8829.2.camel@hawk> <200402240117.03886.eracclists@bellsouth.net> <200402241824.46424.eracclists@bellsouth.net> Message-ID: <403C551F.8050409@sonic.net> A few notes - It seems there may be a general misconception on how exp is rewarded. If say my share for being in a party is 50 melee weapon exp, I'll get 50 exp in melee weapons, and 50 exp against my total. The code can certainly get changed such that the character gets no exp in melee weapons, but the fact he is getting exp in melee weapons in now way reduces the amount of exp he is getting. Now what is overall exp useful for? Overall level of course, which several things are based off of (allowed item power, power of your custom weapon, maybe a few other things). Now it would certainly be possible to group some skills related - eg, group combat skills. So if someone kills something with one combat skill, and the other party memember has another combat skill ready, he gets exp in that ready skill. The problem here is now the issue of what if the second character does not have a combat skill readied? trying to find the one to shuffle it into that the player wants can be difficult? The one the player has the most exp in? May not be the one the player wants if they are building up some other skill. In terms of pets and summoned monsters, in those cases, the skill/owner for the pet is supposed to be set to the appropriate skill (eg, summoning) so if the monster kills something with its default means, exp goes to that skill (summoning). In most cases, monsters don't use skills. However, missile weapons is apparantly a special case, in that it does see that skill was used, and then credits the missle weapon skill back to the owner. Note that when the discussion of redoing skills first came up, the idea of being able to shuffle exp was brought up, and generally didn't seem that popular. It certainly wouldn't be that hard to add a generic container skill that just accumulates exp when the player doesn't have the skill itself. And some mechanism to redistribute that could be added. I do have some concerns - even with a penalty, a player could certainly accumulate and distribute a lot more exp to other skills that would normally be difficult to do so. As such, it'd probably still be necessarily to limit where the player can redistribute the exp to - basically, combat/spell related skills. Eg, you might not have pyromancy, but have sorcery, so you decide you want exp from that general bucket to go to sorcery. But you can't put it into disarm traps for example. _______________________________________________ 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 Feb 25 02:13:49 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:06 2005 Subject: [CF-Devel] Small patch: a few warnings :) In-Reply-To: <403C4B4B.1070304@sonic.net> References: <403BCE93.3040705@laposte.net> <403C4B4B.1070304@sonic.net> Message-ID: <403C593D.2040407@laposte.net> > Note that you should really use the 'sint8' type instead of declaring > things signed character. > > Not likely to make much a difference, but better to be consistent in > type declaration. Actually, the functions for which i fixed do use signed char. So maybe i should just change that to sint8? And it could make a difference, because sint8 = 8bits, whereas signed char could be more (multibyte chars?) 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 Wed Feb 25 12:24:33 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:06 2005 Subject: =?iso-8859-1?Q?Re:_Re:_[CF-Devel]_skills_bug?= Message-ID: If watching people do stuff gave you skills then everyone would be an expert actor, hockey or(insert your sport here) player, musician and public speaker from watching TV and other perfomers. A large part of skills is practice. I say shared party xp should be general XP only. This would save a lot of effort, is close enough to realistic to be fun instead of a pain, and is not nearly as prone to abuse. Again if there is not enought incentive/goodies linked to general XP already it is always possible to make more... > > doesn't necc. make a whole lot of sense that if a warrior and a mage are a > > duo, and the mage casts a fireball, that somehow, the warrior has gained > > experience in magic. He was just standing there. > > If the warrior was paying attention, then he has just seen how an expert casts > a fireball. It can be very educational to watch an expert at work. Now the > warrior nows a little more about how to cast fireballs, and how to cast magic > in general. Sometime in the future, the warrior learns the fireball spell > and remembers "I once saw a mage cast fireballs this way." he will find the > casting of fireballs a little easier. > > If the warrior never learns magic, let alone the fireball spell, then he knows > a little bit of trivia that may be usefull for winning bets at his local > tavern B-). > > On the other hand, if the warrior was busy swinging his sword at something big > and scary at the time, he would not have a chance to study an expert mage > doing what mages do best. Also, the mage would only share mystical secrets > with his party members. > > The same thing applies when a mage studies a friendly warrior waving a sword > around in an expert manner. > > > _______________________________________________ > 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 Wed Feb 25 12:50:47 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:06 2005 Subject: [CF-Devel] skills bug In-Reply-To: References: Message-ID: On Tue, 24 Feb 2004, Todd Mitchell wrote: > > This should happen a lot less now with friendly fire code. > Party play should really be mostly to allow a group of player to > overcome situations where they would not be able to survive alone and > secondly be a way for players to interact together. I would consider xp > benefits a distant third in desirable party mechanics. Training up > players is an abuse of the party system IMHO. > I think so too. Of course friendly fire has to be enabled for that. On my local server i shamelessly reduce the damage from ff to 0%. reasons: 1. All other MORPGs do that. (Yes, not he best argument, but still.) 2. For any good game, gameplay always comes before logic. A game is supposed to be fun. Dying from party spells is not. 3. Concerning logic, one can argue that the spells have a "friend-foe detection". If this seems like magic to you.. it is. :) 4. Crossfire has an especially large disproportion between monster hp and player hp. This causes a disproportion of the damage a player can deal/take. Thus PvP usually is death in a single tick. Apart from friendly fire, i furthermore suggest the "pump up" spells like "dexterity","protection from x","heal wounds" to include the whole party. Or one can create extra party spell variants "heal all". I consider funneling exp. into arbitrary skills abusive. And i have no problem getting useless exp. eg. clawing for non dragons. It might be useless, but it does not hurt either. Or does it? It does. When my overall level reaches the maximum, i can no longer gain any exp. at all. Thus if i have useless experience like "use magic item" it will limit my strength in the useful skills. Thus i suggest that reaching maximum overall should not prevent me from getting skill experience. Bernd Edler _______________________________________________ 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 Feb 25 15:56:54 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:06 2005 Subject: [CF-Devel] skills bug In-Reply-To: References: Message-ID: <403D1A26.9080503@sympatico.ca> Well 5% as a default is good to keep people awake... it's fine to change it however - you don't need an excuse since that is the purpose of having settings file anyway. :) > > Apart from friendly fire, i furthermore suggest the "pump up" spells > like "dexterity","protection from x","heal wounds" to include the whole > party. > Or one can create extra party spell variants "heal all". Party based versions of these sort of spells would be great. Some other suggestions could be a (at higher levels) teleport to or summon party member spell, or even some sort of wizard-eye spell that would show you another players view or at least remove the fog of war and let you share LOS anyway. A new 'encounter' type generator which could produce monsters from treasure lists based on the average level and number of players on a map would be nice too. Aside from this larger maps and larger map views as in the new clients would/will also help a lot for party play. _______________________________________________ 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 Feb 25 17:20:53 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:06 2005 Subject: [CF-Devel] skills bug In-Reply-To: References: Message-ID: <200402260920.53215.won_fang@yahoo.com.au> On Thu, 26 Feb 2004 04:24 am, Todd Mitchell wrote: > If watching people do stuff gave you skills then everyone would be an > expert actor, hockey or(insert your sport here) player, musician and public > speaker from watching TV and other perfomers. A large part of skills is > practice. A large part of skills is practice, but a part of skills is being shown how to do it in the first place. Watching experts is not as good as practicing it yourself, but you do learn something if you are watching carefully and the person you are watching is trying to teach you. In game terms, if you are in a party, you do nothing while a party member uses a skill, and the party member is better at the skill than you, then you get some small fraction of their experience in that skill. If you are busy doing something yourself, then you only get experience for what you are doing. Intelligence could probably have something to do with it. A really dumb warrior could never learn anything about magic, no matter how much you show him. On the other hand, I have not looked at the code, I have no idea how hard it is to figure out who in the party is doing nothing when xp is spread through the party. _______________________________________________ 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 Feb 26 01:39:08 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:06 2005 Subject: [CF-Devel] skills bug In-Reply-To: References: Message-ID: <403DA29C.7010706@sonic.net> Bernd Edler wrote: > > I consider funneling exp. into arbitrary skills abusive. > And i have no problem getting useless exp. eg. clawing > for non dragons. It might be useless, but it does not hurt > either. > Or does it? It does. > When my overall level reaches the maximum, i can no longer gain > any exp. at all. > Thus if i have useless experience like "use magic item" it will > limit my strength in the useful skills. > Thus i suggest that reaching maximum overall should not prevent me > from getting skill experience. This is no longer the case in the new exp system. A characters total exp is not coupled to the sum of exp in skills. For example, a character could have 3000 total exp, and 2000 melee weapon exp and 2000 more spell exp. This is not that likely to happen, but can when the charcter dies - for the max 20%/3 levels to work right, it is done on each skill as well as total exp. So each 'bucket' is now only limited by the max exp value allowed. So you could max out exp in every skill as well as overall exp under the new system. So in that regard, having exp go into a bucket you can't use does no harm. I'd also note that there could be odd cases where it could still be used: If playing on a permadeath server and a character is reincarnated, they may be able to use items that they couldn't before. Likewise, if polymorph is enabled, that could give them ability to use objects they couldn't before. In addition, now that 64 bit exp values are allowed, the likelihood of maxing out exp seems much more remote. _______________________________________________ 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 Feb 26 17:04:20 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:06 2005 Subject: [CF-Devel] skills bug In-Reply-To: <403DA29C.7010706@sonic.net> References: <403DA29C.7010706@sonic.net> Message-ID: On Wed, 25 Feb 2004, Mark Wedel wrote: > Bernd Edler wrote: > > Thus i suggest that reaching maximum overall should not prevent me > > from getting skill experience. > > This is no longer the case in the new exp system. > > A characters total exp is not coupled to the sum of exp in skills. > > So each 'bucket' is now only limited by the max exp value allowed. So you > could max out exp in every skill as well as overall exp under the new system. > Nope. I just now tested again with current cvs. As soon as one gets maxed out overall - one can get no more experience in any category. reason: common/living.c line 1637: /* Basically, you can never gain more experience in one shot * than half what you need to gain for next level. */ exp_to_add = exp; limit=(levels[op->level+1]-levels[op->level])/2; if (exp_to_add > limit) exp_to_add=limit; Bernd Edler _______________________________________________ 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 Feb 28 04:51:21 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:06 2005 Subject: [CF-Devel] Some warning cleaning Message-ID: <404072A9.5050705@laposte.net> Hello. I committed a few patches to clean some compilation warnings (mainly type matching, for map coordinates & stats). There are some left, because stuff like 'sint16 + sint16' yields (at least under Windows) an int, thus integral size mismatch in function call if it expects a sint16 (case of most map coordinates-related functions). But fixing those ones would require explicit casts around all (sint16+sint16), which sounds pretty ugly... Most of the other warnings I have left are signed/unsigned mismatch. I'd want to fix'em, but this is potentially easy to break things with those fixes. What do you think? Is it worth trying to fix signed/unsigned mismatches, or do we just let'em, hoping they won't be a bother later? Also, in common/porting.c, is there a compelling reason why strdup_local(), strncasecmp(), strcasecmp() and strcasestr_local() take char* and not const char* as arguments? Since strings are used only for comparison, and not changed. 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 Sun Feb 29 13:53:05 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:06 2005 Subject: [CF-Devel] artifact list error Message-ID: <1078084384.3227.6.camel@oberon.kameria> A recently added some items to the artifact file and now am seeing an error in the server when it loads the artifacts. I think that I am running out of space in a variable or somehting since the errors in question seem to be the ends of Allowed lists and the same number of characters I just added. for example I added rapier to this list Allowed dagger,light_sword,shortsword,shortsword_2,taifu_1,trident,axe,axe_2,axe_3,axe_4,axe_5,battle_axe,poleaxe,morningstar,large_morningstar,hammer,mace,mace_2,lspear,spear,sword,sword_2,sword_3,sabre,rapier,scimitar,katana_1,falchion,broadsword,broadsword_2 now I see "unknown input in artifact file: word_2" compiled on linux, CVS as of feb 29th. _______________________________________________ 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 Feb 29 22:28:26 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:07 2005 Subject: [CF-Devel] artifact list error In-Reply-To: <1078084384.3227.6.camel@oberon.kameria> References: <1078084384.3227.6.camel@oberon.kameria> Message-ID: On Sun, 29 Feb 2004, Todd Mitchell wrote: > A recently added some items to the artifact file and now am seeing an > error in the server when it loads the artifacts. I think that I am > running out of space in a variable or somehting since the errors in > question seem to be the ends of Allowed lists and the same number of > characters I just added. > for example I added rapier to this list > > Allowed > dagger,light_sword,shortsword,shortsword_2,taifu_1,trident,axe,axe_2,axe_3,axe_4,axe_5,battle_axe,poleaxe,morningstar,large_morningstar,hammer,mace,mace_2,lspear,spear,sword,sword_2,sword_3,sabre,rapier,scimitar,katana_1,falchion,broadsword,broadsword_2 > > now I see "unknown input in artifact file: word_2" > > compiled on linux, CVS as of feb 29th. > Well, as these lines are getting longer then 255, you need to change size of the buffer: RCS file: /cvsroot/crossfire/crossfire/common/treasure.c,v retrieving revision 1.45 diff -r1.45 treasure.c 1162c1162 < char filename[MAX_BUF], buf[MAX_BUF], *cp, *next; --- > char filename[MAX_BUF], buf[HUGE_BUF], *cp, *next; 1178c1178 < while (fgets(buf, MAX_BUF, fp)!=NULL) { --- > while (fgets(buf, HUGE_BUF, fp)!=NULL) { The parser also does not like leading whitespace in comment lines: RCS file: /cvsroot/crossfire/crossfire/lib/races,v retrieving revision 1.7 diff -r1.7 races 273c273 < # this is the summoning list for the goddess Ixalovh --- > # this is the summoning list for the goddess Ixalovh It also semms that you made the changes in the arch directory tree, but not in the files in crossfire/lib: Unable to find animation witch_water Couldn't find treasurelist Ixalovh Failed to link treasure to arch (Ixalovh): Ixalovh While after running collect: Couldn't find archetype ability_dragonbreath Treasure lacks archetype: ability_dragonbreath Couldn't find archetype ability_dragonbreath Treasure lacks archetype: ability_dragonbreath Treasurelist dragon has element with no name or archetype Treasurelist Cwyvern has element with no name or archetype Here the arch file seems to be missing. This can be fixed easily. Bernd Edler _______________________________________________ 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 Feb 29 18:30:36 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:07 2005 Subject: [CF-Devel] artifact list error In-Reply-To: References: <1078084384.3227.6.camel@oberon.kameria> Message-ID: <1078101036.3227.23.camel@oberon.kameria> On Mon, 2004-03-01 at 04:28, Bernd Edler wrote: > On Sun, 29 Feb 2004, Todd Mitchell wrote: > > > A recently added some items to the artifact file and now am seeing an > > error in the server when it loads the artifacts. I think that I am > > running out of space in a variable or somehting since the errors in > > question seem to be the ends of Allowed lists and the same number of > > characters I just added. > > for example I added rapier to this list > > > > Allowed > > dagger,light_sword,shortsword,shortsword_2,taifu_1,trident,axe,axe_2,axe_3,axe_4,axe_5,battle_axe,poleaxe,morningstar,large_morningstar,hammer,mace,mace_2,lspear,spear,sword,sword_2,sword_3,sabre,rapier,scimitar,katana_1,falchion,broadsword,broadsword_2 > > > > now I see "unknown input in artifact file: word_2" > > > > compiled on linux, CVS as of feb 29th. > > > > Well, as these lines are getting longer then 255, you need to change > size of the buffer: > > RCS file: /cvsroot/crossfire/crossfire/common/treasure.c,v > retrieving revision 1.45 > > diff -r1.45 treasure.c > 1162c1162 > < char filename[MAX_BUF], buf[MAX_BUF], *cp, *next; > --- > > char filename[MAX_BUF], buf[HUGE_BUF], *cp, *next; > 1178c1178 > < while (fgets(buf, MAX_BUF, fp)!=NULL) { > --- > > while (fgets(buf, HUGE_BUF, fp)!=NULL) { > That works, thanks. Is this going to be a problem to increase that - there are few places where it might be needed and arguably it isn't needed (just allow less items per artifact entry)? If not I can commit the change. > > The parser also does not like leading whitespace in comment lines: Fixed that. > > It also semms that you made the changes in the arch directory tree, > but not in the files in crossfire/lib: > > Unable to find animation witch_water > Couldn't find treasurelist Ixalovh > Failed to link treasure to arch (Ixalovh): Ixalovh Yes I have not committed a new collection in CVS because my arches are so marked up right now (still testing the animating and reintegrating on some multipart images). I had some more changes to the arches to commit before making a new collection. > > While after running collect: > > Couldn't find archetype ability_dragonbreath > Treasure lacks archetype: ability_dragonbreath > Couldn't find archetype ability_dragonbreath > Treasure lacks archetype: ability_dragonbreath > Treasurelist dragon has element with no name or archetype > Treasurelist Cwyvern has element with no name or archetype > > Here the arch file seems to be missing. > This can be fixed easily. > > Bernd Edler Actually I think this one isn't mine - I can't find that arch either. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel