From tanner at real-time.com Mon Feb 25 01:10:18 2002 From: tanner at real-time.com (Bob Tanner) Date: Thu Jan 13 17:53:03 2005 Subject: [cf-admin] DM mode Message-ID: <20020225011018.N24279@real-time.com> I would like to have people help me put together crossfire DM HOWTO. As metalforge has become more popular, so have the newbies. Which is a good thing! :-) But I'm a terrible DM. I know the basic DM commands, but I'm at a loss for the more advanced commands. For instance, newbies seem to like cursed items. I send to let them suffer for a little so they can learn a lesson about identifing things before equipping, but after awhile they get fustrated. So I'd like to give them a scroll of remove curse, but I don't know how to create one! (ok, mids told me, but there is nothing documented on it). I do not know how to create "complex" items, like book of cure posion. I can create a book, but not a book of cure posion. I read this the mailing list and there are suggestions about using a quill, paper, and writing this stuff, but come on! I'm the DM, I should be able to create things out of thin air! :-) It would be nice to be able to tweak the times maps reset. When you have lots of newbies, the newbie areas get cleared out quickly. Yes, I can reset /map/map, but I'm not online 24x7. Is there a way to change the reset timeout on certain maps? Just stuff like this. Anyone willing to help me? -- Bob Tanner | Phone : (952)943-8700 http://www.mn-linux.org, Minnesota, Linux | Fax : (952)943-8500 Key fingerprint = 6C E9 51 4F D5 3E 4C 66 62 A9 10 E5 35 85 39 D9 From mwedel at sonic.net Fri Feb 1 02:16:30 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:04 2005 Subject: [CF-Devel] death attack, AT_DEATH References: <200201312041.g0VKf9E00539@tonks.EECS.Berkeley.EDU> Message-ID: <3C5A4EDE.1D947A66@sonic.net> Peter Mardahl wrote: > > > In reply to Henric Karlsson: > > > > > Now why can't I use the attack type death on a weapon with slay set? > > > This sounds like a bug to me, but maybe I missed something in > > > the code. > > Well, > > I originally coded a lot of this stuff, and what I had in mind was this: > > 1) If a weapon had a "slaying" and AT_DEATH, it used AT_DEATH on the > monsters listed in "slaying" and the other attacktypes on anything else. > > 2) If it didn't have a slaying field, it used AT_DEATH on everything. That scheme is probably non intuitive for most people - you would generally think that the addition of slaying should make an item better, not worse. Now since your god could improve your weapon, it is certainly possible your weapon could be worse. I would guess that the death attack would use the players level (either overall or in the melee weapon skill) as the comparison. I would take Andreas's proposal and modify it slightly: 1) Death attack only work if the weapon has a slaying field set. 2) Death attack always works, but if the weapon has slaying, it is more effective (maybe make death attack less effective on all weapons if slaying is not set). That at least means that a weapon that gets slaying added to it becomes a better weapon. From root at garbled.net Fri Feb 1 09:43:24 2002 From: root at garbled.net (Tim Rightnour) Date: Thu Jan 13 18:02:04 2005 Subject: [CF-Devel] death attack, AT_DEATH In-Reply-To: <3C5A4EDE.1D947A66@sonic.net> Message-ID: On 01-Feb-02 Mark Wedel wrote: > I would take Andreas's proposal and modify it slightly: > > 1) Death attack only work if the weapon has a slaying field set. > 2) Death attack always works, but if the weapon has slaying, it is more > effective (maybe make death attack less effective on all weapons if slaying > is > not set). In which case I'd vote #2. And an additional yes for the parentheses. --- Tim Rightnour NetBSD: Free multi-architecture OS http://www.netbsd.org/ NetBSD supported hardware database: http://mail-index.netbsd.org/cgi-bin/hw.cgi From bugs at real-time.com Fri Feb 1 02:10:02 2002 From: bugs at real-time.com (bugs@real-time.com) Date: Thu Jan 13 18:02:04 2005 Subject: [CF-Devel] Your Bugzilla buglist needs attention. Message-ID: <200202010810.g118A2420251@crusader.real-time.com> [This e-mail has been automatically generated.] You have one or more bugs assigned to you in the Bugzilla bugsystem (http://bugzilla.real-time.com/) that require attention. All of these bugs are in the NEW state, and have not been touched in 7 days or more. You need to take a look at them, and decide on an initial action. Generally, this means one of three things: (1) You decide this bug is really quick to deal with (like, it's INVALID), and so you get rid of it immediately. (2) You decide the bug doesn't belong to you, and you reassign it to someone else. (Hint: if you don't know who to reassign it to, make sure that the Component field seems reasonable, and then use the "Reassign bug to owner of selected component" option.) (3) You decide the bug belongs to you, but you can't solve it this moment. Just use the "Accept bug" command. To get a list of all NEW bugs, you can use this URL (bookmark it if you like!): http://bugzilla.real-time.com/buglist.cgi?bug_status=NEW&assigned_to=crossfire-devel@lists.real-time.com Or, you can use the general query page, at http://bugzilla.real-time.com/query.cgi. Appended below are the individual URLs to get to all of your NEW bugs that haven't been touched for a week or more. You will get this message once a day until you've dealt with these bugs! http://bugzilla.real-time.com/show_bug.cgi?id=368 http://bugzilla.real-time.com/show_bug.cgi?id=374 http://bugzilla.real-time.com/show_bug.cgi?id=379 http://bugzilla.real-time.com/show_bug.cgi?id=381 http://bugzilla.real-time.com/show_bug.cgi?id=382 http://bugzilla.real-time.com/show_bug.cgi?id=384 http://bugzilla.real-time.com/show_bug.cgi?id=385 http://bugzilla.real-time.com/show_bug.cgi?id=386 http://bugzilla.real-time.com/show_bug.cgi?id=388 http://bugzilla.real-time.com/show_bug.cgi?id=389 http://bugzilla.real-time.com/show_bug.cgi?id=390 From kevin at ank.com Sat Feb 2 00:26:00 2002 From: kevin at ank.com (kevin@ank.com) Date: Thu Jan 13 18:02:04 2005 Subject: [7] [CF-Devel] CFJavaEditor update In-Reply-To: <000001c1aad1$a4ced630$c86ebb81@gizmo> References: <000001c1aad1$a4ced630$c86ebb81@gizmo> Message-ID: <20020201222600.A18095@balrog.ank.com> Ah, wonderful addition. Especially considering that I never managed to get any updates to you for the guide (still have them on my drive, but haven't had time to finish them.) This sounds much better anyway. Cheers, -kls On Fri, Feb 01, 2002 at 04:36:27AM +0100, Andreas Vogl wrote: > I happily announce that there is a new feature for the CFJavaEditor > available, which is going to make mapmaking significantly easier. > > The biggest problem with Crossfire maps is the terrible > mess of the arch syntax. Arch attributes like "sp", "wc", "last_heal" > etc. are confusing on their own - and they get used in so many > different ways. Even the most passionate Crossfire-developer > needs a long time to understand half of it. > > I tried to improve the situation by writing my map-guide. > Docu is a fine thing - but not good enough. It's way too annoying > to read all that, and look things up repeatedly. > > So now I have integrated a Graphical User Interface in the editor, > providing a convenient input-mask for all kinds of crossfire-objects. > The GUI is very flexible, the data is parsed from a definitions- > file called "types.txt". As you can imagine, this file has a > non-trivial syntax, but it's quite easy to understand. > It already contains a lot more information than my map-guide. > > The whole thing is available for now at > > (I can easily put it on cvs later, the new code is > pretty much stand-alone) > Look for the red "Attributes"-button... > > > Of course the whole thing isn't complete yet. > And the "types.txt" still lacks a bunch of information, > but it's already extremely helpful. I started to work > on this feature long time ago and decided it's time > for a first release. > > > Andreas V. > > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel -- // .--=, .....::://::::::::::::::::::::::::::::.. (o O & kevin@ank.com :::::::://:::://://://:/:://::||_// / V K :::::://:::://:/:|//'/' // _,|' r , 'qk :'''/____ // / // |_// // || .'~. .~`, kls \_/-=\_/ From dnh at hawthorn.csse.monash.edu.au Fri Feb 1 20:12:32 2002 From: dnh at hawthorn.csse.monash.edu.au (David Hurst) Date: Thu Jan 13 18:02:04 2005 Subject: [CF-Devel] death attack, AT_DEATH In-Reply-To: References: <3C5A4EDE.1D947A66@sonic.net> Message-ID: <20020202021232.GB6839@hawthorn.csse.monash.edu.au> > > 1) Death attack only work if the weapon has a slaying field set. > > 2) Death attack always works, but if the weapon has slaying, it is more > > effective (maybe make death attack less effective on all weapons if slaying > > is > > not set). > > In which case I'd vote #2. And an additional yes for the parentheses. Certainly death attack is the most powerful out there for everyday use at high levels. At low levels it isn't quite so useful, but is still very helpful when it comes to running through a room full of low level very high health monsters. Currently, as letalis and I were discussing, CF in general becomes very unbalanced (and easy) at high levels. I think this problem probably extends quite abit past intuitive to players, I think CF is in general rather counter intuitive to new players, and very easy for experienced players. Perhaps we should try and make CF head in the opposite direction abit? anyway, for the purpose of this discussion I would go with option 2) as it seems most logical to me. Darth_bob From kevin at ank.com Thu Feb 7 12:22:16 2002 From: kevin at ank.com (kevin@ank.com) Date: Thu Jan 13 18:02:04 2005 Subject: [CF-Devel] Rebuilding the arch database Message-ID: <20020207102216.A29874@balrog.ank.com> Hi all, I've kind of figured out how to run collect.pl after a make install; just point it at the share/crossfire directory, then copy all of its output files to their proper locations. Unfortunately that doesn't seem to rebuild the crossfire.0 and crossfire.1 databases. Anyone have pointers to how that is supposed to be done? -- // .--=, .....::://::::::::::::::::::::::::::::.. (o O & kevin@ank.com :::::::://:::://://://:/:://::||_// / V K :::::://:::://:/:|//'/' // _,|' r , 'qk :'''/____ // / // |_// // || .'~. .~`, kls \_/-=\_/ From mwedel at sonic.net Thu Feb 7 23:45:47 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:04 2005 Subject: [CF-Devel] Rebuilding the arch database References: <20020207102216.A29874@balrog.ank.com> Message-ID: <3C63660B.E85BAB9B@sonic.net> kevin@ank.com wrote: > > Hi all, > > I've kind of figured out how to run collect.pl after a make install; > just point it at the share/crossfire directory, then copy all of its > output files to their proper locations. Unfortunately that doesn't > seem to rebuild the crossfire.0 and crossfire.1 databases. Anyone > have pointers to how that is supposed to be done? You should use the makefile in the lib directory to rebuild the files - it knows how to rebuild the files. Easy way to do this is to remove the archetypes file then type 'make'. From jorahood at indiana.edu Fri Feb 8 09:46:46 2002 From: jorahood at indiana.edu (Orahood, J. Andrew) Date: Thu Jan 13 18:02:05 2005 Subject: [CF-Devel] crossfire compilation errors Message-ID: <875F4BFEEB4CD21192D300805F65BBC00D7F7851@pennsylvania.exchange.indiana.edu> Crossfire version: 1.0.0 computer: Intel PIII OS: Red Hat 7.1 2.96-85 Windowing system: XFree86 Compiler: gcc 2.96 20000731 flags: --prefix=/usr/local/ making all in common... make[1]: Entering directory `/usr/local/src/crossfire-1.0.0/common' gcc -g -O2 -I../include -I./../include -c anim.c In file included from ../include/includes.h:100, from ../include/global.h:36, from anim.c:31: ../include/config.h:114: parse error before `ALCHEMY' In file included from ../include/includes.h:101, from ../include/global.h:36, from anim.c:31: ../include/define.h:620: `maxlen' undeclared here (not in a function) ../include/define.h:620: size of array `dest' has non-integer type ../include/define.h:620: invalid initializer ../include/define.h:620: warning: data definition has no type or storage class ../include/define.h:621: parse error before `+=' make[1]: *** [anim.o] Error 1 make[1]: Leaving directory `/usr/local/src/crossfire-1.0.0/common' making all in random_maps... make[1]: Entering directory `/usr/local/src/crossfire-1.0.0/random_maps' gcc -g -O2 -I../include -I. -c random_map.c In file included from ../include/includes.h:100, from ../include/global.h:36, from random_map.c:31: ../include/config.h:114: parse error before `ALCHEMY' In file included from ../include/includes.h:101, from ../include/global.h:36, from random_map.c:31: ../include/define.h:620: `maxlen' undeclared here (not in a function) ../include/define.h:620: size of array `dest' has non-integer type ../include/define.h:620: invalid initializer ../include/define.h:620: warning: data definition has no type or storage class ../include/define.h:621: parse error before `+=' make[1]: *** [random_map.o] Error 1 make[1]: Leaving directory `/usr/local/src/crossfire-1.0.0/random_maps' making all in socket... make[1]: Entering directory `/usr/local/src/crossfire-1.0.0/socket' gcc -g -O2 -I../include -I./../include -c info.c In file included from ../include/includes.h:100, from ../include/global.h:36, from info.c:10: ../include/config.h:114: parse error before `ALCHEMY' In file included from ../include/includes.h:101, from ../include/global.h:36, from info.c:10: ../include/define.h:620: `maxlen' undeclared here (not in a function) ../include/define.h:620: size of array `dest' has non-integer type ../include/define.h:620: invalid initializer ../include/define.h:620: warning: data definition has no type or storage class ../include/define.h:621: parse error before `+=' make[1]: *** [info.o] Error 1 make[1]: Leaving directory `/usr/local/src/crossfire-1.0.0/socket' making all in server... make[1]: Entering directory `/usr/local/src/crossfire-1.0.0/server' gcc -g -O2 -I../include -I./../include -c alchemy.c In file included from ../include/includes.h:100, from ../include/global.h:36, from alchemy.c:4: ../include/config.h:114: parse error before `ALCHEMY' In file included from ../include/includes.h:101, from ../include/global.h:36, from alchemy.c:4: ../include/define.h:620: `maxlen' undeclared here (not in a function) ../include/define.h:620: size of array `dest' has non-integer type ../include/define.h:620: invalid initializer ../include/define.h:620: warning: data definition has no type or storage class ../include/define.h:621: parse error before `+=' make[1]: *** [alchemy.o] Error 1 make[1]: Leaving directory `/usr/local/src/crossfire-1.0.0/server' making all in include... make[1]: Entering directory `/usr/local/src/crossfire-1.0.0/include' make[1]: Nothing to be done for `all'. make[1]: Leaving directory `/usr/local/src/crossfire-1.0.0/include' making all in lib... make[1]: Entering directory `/usr/local/src/crossfire-1.0.0/lib' make[1]: Nothing to be done for `all'. make[1]: Leaving directory `/usr/local/src/crossfire-1.0.0/lib' making all in utils... make[1]: Entering directory `/usr/local/src/crossfire-1.0.0/utils' make[1]: Nothing to be done for `all'. make[1]: Leaving directory `/usr/local/src/crossfire-1.0.0/utils' making all in doc... make[1]: Entering directory `/usr/local/src/crossfire-1.0.0/doc' make[1]: Nothing to be done for `all'. make[1]: Leaving directory `/usr/local/src/crossfire-1.0.0/doc' making all in crossedit... make[1]: Entering directory `/usr/local/src/crossfire-1.0.0/crossedit' gcc -g -O2 -I/usr/X11R6/include/ -I../include -I. -Iinclude -I./../include -I. -I./include -ICnv -I./Cnv -I../include -I. -Iinclude -ICnv -c crossedit.c In file included from ../include/includes.h:100, from ../include/global.h:36, from Defines.h:7, from App.h:28, from crossedit.c:23: ../include/config.h:114: parse error before `ALCHEMY' In file included from ../include/includes.h:101, from ../include/global.h:36, from Defines.h:7, from App.h:28, from crossedit.c:23: ../include/define.h:620: `maxlen' undeclared here (not in a function) ../include/define.h:620: size of array `dest' has non-integer type ../include/define.h:620: invalid initializer ../include/define.h:620: warning: data definition has no type or storage class ../include/define.h:621: parse error before `+=' In file included from Cnv/Cnv.h:28, from Edit.h:5, from App.h:29, from crossedit.c:23: ../include/config.h:114: parse error before `ALCHEMY' In file included from Edit.h:5, from App.h:29, from crossedit.c:23: Cnv/Cnv.h:43: parse error before `}' Cnv/Cnv.h:43: warning: data definition has no type or storage class Cnv/Cnv.h:44: parse error before `CnvMenuRec' make[1]: *** [crossedit.o] Error 1 make[1]: Leaving directory `/usr/local/src/crossfire-1.0.0/crossedit' make: *** [all] Error 2 [root@globbo crossfire-1.0.0]# make install making install in common... make[1]: Entering directory `/usr/local/src/crossfire-1.0.0/common' make[1]: Nothing to be done for `install'. make[1]: Leaving directory `/usr/local/src/crossfire-1.0.0/common' making install in random_maps... make[1]: Entering directory `/usr/local/src/crossfire-1.0.0/random_maps' gcc -g -O2 -I../include -I. -c random_map.c In file included from ../include/includes.h:100, from ../include/global.h:36, from random_map.c:31: ../include/config.h:114: parse error before `ALCHEMY' In file included from ../include/includes.h:101, from ../include/global.h:36, from random_map.c:31: ../include/define.h:620: `maxlen' undeclared here (not in a function) ../include/define.h:620: size of array `dest' has non-integer type ../include/define.h:620: invalid initializer ../include/define.h:620: warning: data definition has no type or storage class ../include/define.h:621: parse error before `+=' make[1]: *** [random_map.o] Error 1 make[1]: Leaving directory `/usr/local/src/crossfire-1.0.0/random_maps' making install in socket... make[1]: Entering directory `/usr/local/src/crossfire-1.0.0/socket' make[1]: Nothing to be done for `install'. make[1]: Leaving directory `/usr/local/src/crossfire-1.0.0/socket' making install in server... make[1]: Entering directory `/usr/local/src/crossfire-1.0.0/server' gcc -g -O2 -I../include -I./../include -c alchemy.c In file included from ../include/includes.h:100, from ../include/global.h:36, from alchemy.c:4: ../include/config.h:114: parse error before `ALCHEMY' In file included from ../include/includes.h:101, from ../include/global.h:36, from alchemy.c:4: ../include/define.h:620: `maxlen' undeclared here (not in a function) ../include/define.h:620: size of array `dest' has non-integer type ../include/define.h:620: invalid initializer ../include/define.h:620: warning: data definition has no type or storage class ../include/define.h:621: parse error before `+=' make[1]: *** [alchemy.o] Error 1 make[1]: Leaving directory `/usr/local/src/crossfire-1.0.0/server' making install in include... make[1]: Entering directory `/usr/local/src/crossfire-1.0.0/include' make[1]: Nothing to be done for `install'. make[1]: Leaving directory `/usr/local/src/crossfire-1.0.0/include' making install in lib... make[1]: Entering directory `/usr/local/src/crossfire-1.0.0/lib' if [ ! -d /usr/local/crossfire/share/crossfire/help ]; then \ echo "Creating directory /usr/local/crossfire/share/crossfire/help"; \ /bin/mkdir -p /usr/local/crossfire/share/crossfire/help; \ fi; Creating directory /usr/local/crossfire/share/crossfire/help Installing ./help/apply Installing ./help/bind Installing ./help/cast Installing ./help/golem Installing ./help/invoke Installing ./help/keys Installing ./help/mark Installing ./help/melee Installing ./help/mouse Installing ./help/move Installing ./help/name Installing ./help/output Installing ./help/output-count Installing ./help/output-sync Installing ./help/party Installing ./help/pickup Installing ./help/quit Installing ./help/range Installing ./help/save Installing ./help/sort_inventory Installing ./help/spells Installing ./help/statistics Installing ./help/take Installing ./help/traps Installing ./help/unbind Installing ./help/usekeys Installing ./artifacts Installing ./ban_file Installing ./def_help Installing ./dm_file Installing ./forbid Installing ./formulae Installing ./messages Installing ./motd Installing ./races Installing ./skill_params Installing ./spell_params Installing ./treasures Installing ./animations Installing ./archetypes Installing ./bmaps Installing ./bmaps.paths Installing ./crossfire.xpm Installing ./faces Installing ./crossfire.xbm Installing ./crossfire.png Installing ./xpmtopix.pl Installing ./collect.pl Installing ./util.pl touch /usr/local/crossfire/var/crossfire/highscore touch /usr/local/crossfire/var/crossfire/bookarch touch /usr/local/crossfire/var/crossfire/temp.maps Creating directory /usr/local/crossfire/var/crossfire/players Creating directory /usr/local/crossfire/var/crossfire/unique-items make[1]: Leaving directory `/usr/local/src/crossfire-1.0.0/lib' making install in utils... make[1]: Entering directory `/usr/local/src/crossfire-1.0.0/utils' /bin/mkdir: `/usr/local/crossfire/bin' exists but is not a directory make[1]: *** [install] Error 1 make[1]: Leaving directory `/usr/local/src/crossfire-1.0.0/utils' making install in doc... make[1]: Entering directory `/usr/local/src/crossfire-1.0.0/doc' /usr/bin/install -c ./crossedit.man /usr/local/crossfire/man/man6/crossedit.6 /usr/bin/install -c ./crossfire.man /usr/local/crossfire/man/man6/crossfire.6 make[1]: Leaving directory `/usr/local/src/crossfire-1.0.0/doc' making install in crossedit... make[1]: Entering directory `/usr/local/src/crossfire-1.0.0/crossedit' gcc -g -O2 -I/usr/X11R6/include/ -I../include -I. -Iinclude -I./../include -I. -I./include -ICnv -I./Cnv -I../include -I. -Iinclude -ICnv -c crossedit.c In file included from ../include/includes.h:100, from ../include/global.h:36, from Defines.h:7, from App.h:28, from crossedit.c:23: ../include/config.h:114: parse error before `ALCHEMY' In file included from ../include/includes.h:101, from ../include/global.h:36, from Defines.h:7, from App.h:28, from crossedit.c:23: ../include/define.h:620: `maxlen' undeclared here (not in a function) ../include/define.h:620: size of array `dest' has non-integer type ../include/define.h:620: invalid initializer ../include/define.h:620: warning: data definition has no type or storage class ../include/define.h:621: parse error before `+=' In file included from Cnv/Cnv.h:28, from Edit.h:5, from App.h:29, from crossedit.c:23: ../include/config.h:114: parse error before `ALCHEMY' In file included from Edit.h:5, from App.h:29, from crossedit.c:23: Cnv/Cnv.h:43: parse error before `}' Cnv/Cnv.h:43: warning: data definition has no type or storage class Cnv/Cnv.h:44: parse error before `CnvMenuRec' make[1]: *** [crossedit.o] Error 1 make[1]: Leaving directory `/usr/local/src/crossfire-1.0.0/crossedit' make: *** [install] Error 2 Thanks, Andy From tchize at MailAndNews.com Sun Feb 10 05:09:46 2002 From: tchize at MailAndNews.com (david delbecq) Date: Thu Jan 13 18:02:05 2005 Subject: [CF-Devel] patch for spell system Message-ID: <3C67D495@MailAndNews.com> I wrote a big modification on the way spells are used in the code. This is only internal change and does not affect the gameplay. The chages include: * The spells internals have been separated from the rest of the code and are only accessed using functions in a file called spell_library.c. There should be no more access to the spells[] table or the spellarch[] table * The spells are now saved in a list and not in a table. This allow to have, for example, spells numbers from 0 to 203 then spells from 500 to 504, then 600 to 602 and so on. There may be holes in the list. This should help creating new spells since you get a set of number, keep them even if someone else is creating newspells at the same time. This also open the door for people wanting to allow players creating spells (get a free number and keep it) * All spells have their internals saved in a file called spellbook. This file may be tuned by system administrator, the same way the old file spell_params did, but in a larger and more human readable way. At the bottom of this mail, there is some example line from the file * The spells are casted using a callback in the new structure. This allow plugins to reference spells in the server. However the hooks for referencing a spell from a plugin has not been written yet :( * The file spellbook in the shared crossfire dir is created automagically by the server if not available. This is done using thed old spells[] structure and the old spell_param file. * The new structure also opens the door for a new kind of spell: the localised spells. This will be done using a command fire_at instead of fire so we could create spells that aim a position and not a direction I plan to cvs the code next week. But since it is a big change, i send a patch for the moment. -- A part of the spellbook file -- spell magic bullet ################################ # Core server Spell N?0 # a level 1 wizard spell # id= 0 level= 1 sp= 1 charges= 99 time= 2.000000 scrolls= 0 scroll_chance= 0 book_chance= 10 range?= 1 defensive?= 0 cleric?= 0 onself?= 0 targeting?= 0 path= 0x0010 archname= bullet bdam= 10 bdur= 0 ldam= 1 ldur= 0 spl= 6 casting_plugin= SERVER casting_function= sp_cast_bullet -------------- next part -------------- A non-text attachment was scrubbed... Name: patch.newspell.gz Type: application/x-gzip Size: 71419 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20020210/ad76508f/patch.newspell.bin From jshelley at surf.ictransnet.com Sun Feb 10 06:13:05 2002 From: jshelley at surf.ictransnet.com (johnny shelley) Date: Thu Jan 13 18:02:05 2005 Subject: [CF-Devel] pet summoning server crash Message-ID: <3C6663D1.764FF290@ictransnet.com> To reproduce, summon a pet mosnter,invoke face of death, immediately summon another monster while face of death is still in progress. -- johnny PGP Public Key available from: http://www.keyserver.net:11371/pks/lookup?op=get&search=0x17BF1DD3 From kevin at ank.com Sun Feb 10 18:13:03 2002 From: kevin at ank.com (kevin@ank.com) Date: Thu Jan 13 18:02:05 2005 Subject: [CF-Devel] Question: Re overlays Message-ID: <20020210161303.A4118@balrog.ank.com> In common/map.c the load_overlay_map() gets called if the MAP_OVERLAY flag is not set. Is this correct? I would think you would call load_overlay_map() if the MAP_OVERLAY flag is set? All of my maps have the flag cleared, so I'm getting lots of errors in my output log about missing overlays, and this I suspect is the culprit. Thanks, -kls -- // .--=, .....::://::::::::::::::::::::::::::::.. (o O & kevin@ank.com :::::::://:::://://://:/:://::||_// / V K :::::://:::://:/:|//'/' // _,|' r , 'qk :'''/____ // / // |_// // || .'~. .~`, kls \_/-=\_/ From dnh at hawthorn.csse.monash.edu.au Sun Feb 10 18:11:21 2002 From: dnh at hawthorn.csse.monash.edu.au (David Hurst) Date: Thu Jan 13 18:02:05 2005 Subject: [CF-Devel] patch for spell system In-Reply-To: <3C67D495@MailAndNews.com> References: <3C67D495@MailAndNews.com> Message-ID: <20020211001121.GA1916@hawthorn.csse.monash.edu.au> > * The new structure also opens the door for a new kind of spell: the > localised spells. This will be done > using a command fire_at instead of fire so we > could create spells that aim > a position and not a direction Hey this sounds really cool! =) dnh From mwedel at sonic.net Sun Feb 10 19:49:12 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:05 2005 Subject: [CF-Devel] pet summoning server crash References: <3C6663D1.764FF290@ictransnet.com> Message-ID: <3C672318.68507688@sonic.net> johnny shelley wrote: > > To reproduce, summon a pet mosnter,invoke face of death, immediately > summon another monster while face of death is still in progress. Just a note, I tried this and was unable to reproduce the crash. In some cases, the just summoned pet monster was killed my the face of death currently in progress. I don't know if this is a matter of server version, using invoke vs cast/fire, skills known by the character, etc. The fact that the relative timing is important suggests that the problem is that the skills are getting confused some how. From mwedel at sonic.net Sun Feb 10 21:00:25 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:05 2005 Subject: [CF-Devel] patch for spell system References: <3C67D495@MailAndNews.com> Message-ID: <3C6733C9.7B16CF65@sonic.net> david delbecq wrote: > > I wrote a big modification on the way spells are used in the code. This is > only internal change and does > not affect the gameplay. The chages include: I'd be nice if this was brought up before the code was done. It seems like this comes up often. The reason I say that is this entry from the TODO list: - IDEA: Make spells be objects. One object for each spell you know. Same system for the monsters. For now let the objects be invisible. Then later create a spellbook into which the spells can be "put". Thus knowing a spell consists of having the spell-object in some spellbook. With this, more properties of the spell (level, cost, etc) from the current array to the spell object. Alternatively, spellbooks have the spell objects that are then put in the players inventory when the spell is learnt. scrolls, wands, potions would just be objects with some spell object as an inventory. As a further extension, make general spell casting code, which can look at the spell object and come up with effects. For example, right now the cones could be pretty generalized - all that is really different is the attack form (could be determined by attack type), area of effect (some other value in the object), damage, spell cast, level, etc. In other words, the spell objects could pretty much provide all the information needed for some of the more general functions (cast cone, fire_bolt, etc.) That above change is not completely orthagonal to your code, but certainly your code did a lot of work that isn't really necessary. In the above example, since all spells are just archetypes, tuning them is just a matter of changing the archetype, not a configuration file. If the code is abstract enough, it means that new spells are just a matter of modifying the arch on the map. Eg, if different paramaters control damage, attacktype, size of spell (length of code, expansion of fireball, etc), making a 'mongo fireball' spell just means taking the large fireball and increase the area of effect value. This approach means you don't even have spell numbers. Given your code below, these archetypes would just have the function that should be called in one of their fields. This also simplifies some areas of the code - since knowing a spell is having that spell object in your inventory, it means the loading and storing of the spells for the player file are no longer need - just the normal object loading code is used. This also meaks some things easier to examine - rather than needing to look up a spell number to see what spell that spellbook may contain, you just look at the object inside the spellbook. I think this may make it easier for mapmakers. Given that is the eventual goal, may comments below: > > * The spells internals have been separated from the rest of the code and are > only accessed using > functions in a file called spell_library.c. There should be no more access to > the spells[] table or the > spellarch[] table > * The spells are now saved in a list and not in a table. This allow to have, > for example, spells numbers > from 0 to 203 then spells from 500 to 504, then 600 to 602 and so on. There > may be holes in the list. > This should help creating new spells since you get a set of number, keep them > even if someone else is > creating newspells at the same time. This also open the door for people > wanting to allow players > creating spells (get a free number and keep it) > * All spells have their internals saved in a file called spellbook. This > file may be tuned by system > administrator, the same way the old file spell_params did, but in a larger and > more human readable way. > At the bottom of this mail, there is some example line from the file Those three points would be non issues if spells are objects. > * The spells are casted using a callback in the new structure. This allow > plugins to reference spells in > the server. However the hooks for referencing a spell from a plugin has not > been written yet :( I think a similar mechanism if spells are objects in place, eg, the spell would have a callback field that is used when the spell is cast. > * The file spellbook in the shared crossfire dir is created automagically > by the server if not available. > This is done using thed old spells[] structure and the old spell_param file. Reasonable. I'm not sure how many people actually modify the spells. The spell_params file was really put in place so that spells could be tweaked without needing to recompile the server. IF spells are objects, that is not relevant, but I will certainly admit that going to a spell object system will result in some legacy code (eg, need to support the old spell number system for some amount of time for things like wands and scrolls, but that could be made easier by the spell archetypes having a spell number that is used for that purpose). Likewise, player loading would need to convert the known_spell .. values into spell objects. > * The new structure also opens the door for a new kind of spell: the > localised spells. This will be done > using a command fire_at instead of fire so we > could create spells that aim > a position and not a direction The support for this mainly seems to be in the need to say that this is an aimed spell vs directional - that of course could have been done in the old system just by adding another value to the spell field. While I think this change is a good idea, I think the bigger problem is the actual implementation of this (eg, the player need some way to say fire at x,y). I think that is the bigger thing to do - some spells should probably be in both categories, eg, directional and aimed at some specific spot. I say that because for almost all spells combat spells, you want to be able to fire it off quickly in some direction. However, if your with a party or other considerations, being able to aim some spell at a specific point would be nice. Given that, I think the callback should have something like 'direction, offset_x, offset_y' parameter. If the offsets are set, and the spell is aimable, those are used. Otherwise, direction is used. Thus, for example, if I fire a spell north, direction would be 1, the offsets 0, so it is a normal spell. If the player tries to aim a spell that is not aimable, he gets some error message. I say that because I think to add such functionality is to some extent a client issue to issue something like a 'fireat ' command. How the player does that in the client is certainly a client issue, but I would guess it would probably involve clicking on some space with the mouse, which is certainly something slower to do. Note that the fireat command could also be used for the bow attacks, and monsters should also be able to used the aimed spells (which would make a group of spellcasting monsters much nastier, as the ones in back could cast spells at the player). The aimed fire code does need to do some sanity checking of course - you can't fire through walls or otherwise blocked terrain. > I plan to cvs the code next week. But since it is a big change, i send a patch > for the moment. It would be nice if people actually discussed what they were working on before writing the code. A few comments: I dislike code/functions like: + /* callback name: int sp_cast_raise_dead + * used by: raise dead, resurrection + */ + int sp_cast_raise_dead (object *op,object *caster,int dir,spell_data *sp,int ability,SpellTypeFrom item,char *stringarg) + { + return cast_raise_dead_spell(op,dir,sp->type, NULL); I'd much rather that the target function (cast_raise_dead_spell) get modified to use the same parameters - This extra function generally makes code more confusing. Using such wrappers is generally easy to do, but if done enough, results in a complete mess of code. > -- A part of the spellbook file -- > > spell magic bullet > ################################ > # Core server Spell N?0 > # a level 1 wizard spell > # > id= 0 > level= 1 > sp= 1 > charges= 99 > time= 2.000000 > scrolls= 0 > scroll_chance= 0 > book_chance= 10 > range?= 1 > defensive?= 0 > cleric?= 0 > onself?= 0 > targeting?= 0 > path= 0x0010 I'd also much rather have values stored in such config files to be text when appropriate, eg, have PATH_HEALING or PATH_.. instead of someone needing to go through the docs to find the right value. Yes, I know that this isn't done in lots of places right now, but we need to start somewhere. From mwedel at sonic.net Sun Feb 10 22:24:03 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:05 2005 Subject: [CF-Devel] pet summoning server crash References: <3C6663D1.764FF290@ictransnet.com> <3C672318.68507688@sonic.net> Message-ID: <3C674763.E45E671C@sonic.net> Bug is now fixed in CVS. From phil at micronetix.com Mon Feb 11 06:21:08 2002 From: phil at micronetix.com (phil) Date: Thu Jan 13 18:02:05 2005 Subject: [CF-Devel] Compiling GTK client under Cygwin Message-ID: <200202110621.AA1988887028@micronetix.com> I recently compiled the GTK version of the crossfire client for Cygwin and had to do a minor modifications to make it compile. In the file "client/gtk/gx11.c", add the following three lines where appropriate. Somewhere along with the system file includes, I think. #ifdef __CYGWIN__ #include #endif -- Please CC: any replies to me personally, as I don't read the list. From jbontje at suespammers.org Tue Feb 12 10:27:50 2002 From: jbontje at suespammers.org (Joris Bontje) Date: Thu Jan 13 18:02:05 2005 Subject: [CF-Devel] exits broken Message-ID: <20020212172750.A17383@freebsd.localdomain> On my server (latest CVS), exits with walk_on 1 fly_on 1 don't work. I did not compile my damned exits patch on it, so it must be some recent patch that broke it. Joris Bontje / mids -- Gpg Key: Id=0xF19326A9 / http://mids.student.utwente.nl/~mids/jbontje.pub Key fingerprint = 730D 9B3A F406 F28A 957D 6397 31E8 6D4C F193 26A9 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 238 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20020212/6a618e50/attachment.pgp From phil at micronetix.com Tue Feb 12 02:19:56 2002 From: phil at micronetix.com (phil) Date: Thu Jan 13 18:02:05 2005 Subject: [CF-Devel] Bug in connected items with walk_on & fly_on Message-ID: <200202120219.AA3881239114@micronetix.com> Another bug. walk_on & fly_on don't trigger the proper connections. For one example, if you try walking onto an invisible exit, it won't work. -- I don't read the list, so please CC: any replies to me personally. From mwedel at sonic.net Wed Feb 13 00:54:04 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:05 2005 Subject: [CF-Devel] exits broken References: <20020212172750.A17383@freebsd.localdomain> Message-ID: <3C6A0D8C.59C242B2@sonic.net> Joris Bontje wrote: > > On my server (latest CVS), exits with > walk_on 1 > fly_on 1 > don't work. > > I did not compile my damned exits patch on it, so it must be some recent > patch that broke it. I tried it on my local server, latest CVS, and had no problems. So its hard for me to know what the cause might happen to me. From jbontje at suespammers.org Wed Feb 13 06:05:13 2002 From: jbontje at suespammers.org (Joris Bontje) Date: Thu Jan 13 18:02:06 2005 Subject: [CF-Devel] exits broken In-Reply-To: <3C6A0D8C.59C242B2@sonic.net>; from mwedel@sonic.net on Tue, Feb 12, 2002 at 10:54:04PM -0800 References: <20020212172750.A17383@freebsd.localdomain> <3C6A0D8C.59C242B2@sonic.net> Message-ID: <20020213130512.A40148@freebsd.localdomain> On Tue, Feb 12, 2002 at 10:54:04PM -0800, Mark Wedel wrote: > Joris Bontje wrote: > > On my server (latest CVS), exits with > > walk_on 1 > > fly_on 1 > > don't work. > > I tried it on my local server, latest CVS, and had no problems. So its hard > for me to know what the cause might happen to me. It works correctly on my FreeBSD server. I tried running crossfire on the problematic linux box under ddd and then it worked! I did not know that debuggers automatically fix problems. Only now I have no idea how to debug it.. Can it be a leak? Joris Bontje / mids -- Gpg Key: Id=0xF19326A9 / http://mids.student.utwente.nl/~mids/jbontje.pub Key fingerprint = 730D 9B3A F406 F28A 957D 6397 31E8 6D4C F193 26A9 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 238 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20020213/abdbd58b/attachment.pgp From jbontje at suespammers.org Wed Feb 13 15:32:52 2002 From: jbontje at suespammers.org (Joris Bontje) Date: Thu Jan 13 18:02:06 2005 Subject: [CF-Devel] exits bug fixed Message-ID: <20020213223252.A62120@freebsd.localdomain> I have fixed the exits bug, it is in CVS now. My damned exits code is now also in CVS, I changed maps/peterm/Nethack_in_crossfire_entrance as example. I don't know why the diff for crossfire/server/main.c isnt mailed to crossfire-cvs... it certainly is commited (according to cvs and viewcvs) Joris Bontje / mids -- Gpg Key: Id=0xF19326A9 / http://mids.student.utwente.nl/~mids/jbontje.pub Key fingerprint = 730D 9B3A F406 F28A 957D 6397 31E8 6D4C F193 26A9 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 238 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20020213/28863ca8/attachment.pgp From tanner at real-time.com Thu Feb 14 18:59:57 2002 From: tanner at real-time.com (Bob Tanner) Date: Thu Jan 13 18:02:06 2005 Subject: [CF-Devel] arch directory location? Message-ID: <20020214185957.S20180@real-time.com> What is the official arch directory location suppose to be? I have mine in crossfire/arch But the lib/adm/collect_images.pl looks like it wants arch here crossfire/lib/arch I'm doing a clean cvs check and build for the first time in over a year and lib/adm/collect_images.pl fails to run properly. -- Bob Tanner | Phone : (952)943-8700 http://www.mn-linux.org, Minnesota, Linux | Fax : (952)943-8500 Key fingerprint = 6C E9 51 4F D5 3E 4C 66 62 A9 10 E5 35 85 39 D9 From tanner at real-time.com Thu Feb 14 20:27:10 2002 From: tanner at real-time.com (Bob Tanner) Date: Thu Jan 13 18:02:06 2005 Subject: [CF-Devel] Official location of maps? Message-ID: <20020214202710.X20180@real-time.com> More issues with locations. A clean check out from cvs and I get this in my logs: Trying to load map /usr/games/crossfire/share/crossfire/maps/HallOfSelection. Can't open /usr/games/crossfire/var/crossfire/maps/HallOfSelection Can't open overlay /usr/games/crossfire/var/crossfire/maps/HallOfSelection Where are the maps support to be located? ./crossfire -o Reading bmaps from /usr/games/crossfire/share/crossfire/bmaps...done (got 3811/3812/3812) Reading faces from /usr/games/crossfire/share/crossfire/faces...done Reading animations from /usr/games/crossfire/share/crossfire/animations...done. got (767) Reading archetypes from /usr/games/crossfire/share/crossfire/archetypes... arch-pass 1... Unable to find animation mithril_ar Adding friendly object Evil Master, Bonehead. done Setting up archetable...done loading treasure... done arch-pass 2... done done Reading attack messages from /usr/games/crossfire/share/crossfire/attackmess...got 227 messages in 19 categories. Reading clockdata from /usr/games/crossfire/var/crossfire/clockdata...todtick=28Welcome to CrossFire, v1.0.0-07-30 Copyright (C) 1994 Mark Wedel. Copyright (C) 1992 Frank Tore Johansen. Can't open /usr/games/crossfire/share/crossfire/shutdown Non-standard include files: Secure: Datadir: /usr/games/crossfire/share/crossfire Localdir: /usr/games/crossfire/var/crossfire Perm file: /forbid Shutdown file: /shutdown Save player: Save mode: 0660 Playerdir: /players Itemsdir: /unique-items Use checksum: Tmpdir: /tmp Map max timeout: 1000 Map reset: Max objects: 25000 Use_calloc: Use_swap_stats: Explore mode: Shop listings: Max_time: 120000 Linux warlock 2.2.18pre24 #1 Mon Feb 19 13:18:39 CST 2001 sparc64 unknown -- Bob Tanner | Phone : (952)943-8700 http://www.mn-linux.org, Minnesota, Linux | Fax : (952)943-8500 Key fingerprint = 6C E9 51 4F D5 3E 4C 66 62 A9 10 E5 35 85 39 D9 From mwedel at sonic.net Thu Feb 14 22:52:30 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:06 2005 Subject: [CF-Devel] arch directory location? References: <20020214185957.S20180@real-time.com> Message-ID: <3C6C940E.95EE944E@sonic.net> Bob Tanner wrote: > > What is the official arch directory location suppose to be? > > I have mine in > > crossfire/arch > > But the lib/adm/collect_images.pl looks like it wants arch here > > crossfire/lib/arch > > I'm doing a clean cvs check and build for the first time in over a year and > lib/adm/collect_images.pl fails to run properly. The proper location is the later (eg, in the lib directory). This can be a symlink to the real location. This has been the way it has been historically, probably mostly because the lib directory is where the collected results go. From mwedel at sonic.net Thu Feb 14 22:56:49 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:06 2005 Subject: [CF-Devel] Official location of maps? References: <20020214202710.X20180@real-time.com> Message-ID: <3C6C9511.42169E16@sonic.net> Bob Tanner wrote: > > More issues with locations. > > A clean check out from cvs and I get this in my logs: > > Trying to load map /usr/games/crossfire/share/crossfire/maps/HallOfSelection. > > Can't open /usr/games/crossfire/var/crossfire/maps/HallOfSelection > Can't open overlay /usr/games/crossfire/var/crossfire/maps/HallOfSelection > > Where are the maps support to be located? The share directory is the proper location. the var is used for the overlay. The messages about 'can't open' should really be removed, because it is not an error (or even worth debugging) if your not able to load an overlay map. I need to talk to Tim about this sometime, but as I've thought about it, if the overlay maps are used, the general purpose unique item maps should go away (they duplicate purpose). The per play unique maps would need to be handled the same way as they are now, but for those maps, an overlay should never be used. From andi.vogl at gmx.net Sat Feb 16 12:03:05 2002 From: andi.vogl at gmx.net (Andreas Vogl) Date: Thu Jan 13 18:02:06 2005 Subject: [CF-Devel] The Java Client Message-ID: <10625.1013882585@www60.gmx.net> Hi Isak Styf, I am very happy about your effort to revive the Java Client. The Windows client is currently kinda lacking support, so maybe a Java Client might become handy for Win- (and of course Mac-) users. I'm pretty sure Phil is going to like your work. Maybe you could join up somehow and roll out a new "official" Java Client release... What I noticed from your screenshot is that you seem to have problems with some pngs not being displayed correctly. I have coded a lot for the Crossfire Java Editor and this problem is very familiar to me. I assume you did use the default Java methods to load pngs? While using these, I had the same problems with the editor. Applying an "external" png library fixed the problem for me. I use the sixlegs png library . It's the only png lib I found which is free, GPLed and working. Java rules, ;o) Andreas V. PS.: Another small question: Where did you get a Java2 SDK for MacOS? I know someone here who is searching for that... -- GMX - Die Kommunikationsplattform im Internet. http://www.gmx.net From andi.vogl at gmx.net Sun Feb 17 19:41:53 2002 From: andi.vogl at gmx.net (Andreas Vogl) Date: Thu Jan 13 18:02:06 2005 Subject: [CF-Devel] patch for spell system In-Reply-To: <3C6733C9.7B16CF65@sonic.net> Message-ID: <000001c1b81d$7468c470$c86ebb81@gizmo> Mark W. wrote: > > - IDEA: Make spells be objects. One object for each spell > you know. [...] > In the above example, since all spells are just archetypes, > tuning them is just a matter of changing the archetype, not > a configuration file. > > If the code is abstract enough, it means that new spells are > just a matter of modifying the arch on the map. [...] Spells being objects sounds cool, but I don't think it really is the big hit. o Above all, it's a big amount of work and it's gonna blow up and complexify the spell code. o Spell-objects won't make life any more simple for mapmakers. Okay, the "sp"-values will be gone - but I bet the spell-objects will again have a hundred attributes that no one ever truely understands. o With spell-objects, spells can be modiefied in the maps. Maybe that's just me, but I think spells should be standards. There should be a finite amount of spells, so that players can learn how they work and what to expect of them. That keeps the game more simple and a lot more intuitive. Is it really good to have hundred different versions of the fireball spell? I think not. Now if spells are standards (instead of objects), they should still be fine-tuned and balanced. The perfect combination of damage, speed and duration is often hard to find. Therefore, the "spellbook"-approach by David Delbecq seems like a useful thing to me. Certainly, I do agree that he should have asked on cf-devel before doing all the work. But at least, he asked before doing a cvs commit. That's already quite good, isn't it? ;-) Andreas V. From andi.vogl at gmx.net Mon Feb 18 21:26:44 2002 From: andi.vogl at gmx.net (Andreas Vogl) Date: Thu Jan 13 18:02:06 2005 Subject: [CF-Devel] CFJavaEditor and spellnumbers Message-ID: <000201c1b8f5$45138510$c86ebb81@gizmo> I've extended the CFJavaEditor to handle Crossfire spellnumbers internally. In the attribute-window mapmakers can now select spells by name conveniently, choosing from a list. No longer does anyone need to look up cranky spellnumbers. :-) The spells are stored in a file, and they can be imported from 'spellist.h' directly anytime (menu "Collect->Collect Spells"). Now just in case this "spellbook-file"-approach would be realized for the CF server, I could write an additional parser to import spells from the spellbook-file with little effort. Andreas V. From mwedel at sonic.net Mon Feb 18 23:18:13 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:07 2005 Subject: [CF-Devel] patch for spell system References: <000001c1b81d$7468c470$c86ebb81@gizmo> Message-ID: <3C71E015.5B186A05@sonic.net> Andreas Vogl wrote: > > Mark W. wrote: > > > > - IDEA: Make spells be objects. One object for each spell > > you know. [...] > > In the above example, since all spells are just archetypes, > > tuning them is just a matter of changing the archetype, not > > a configuration file. > > > > If the code is abstract enough, it means that new spells are > > just a matter of modifying the arch on the map. [...] > > Spells being objects sounds cool, but I don't think it > really is the big hit. > > o Above all, it's a big amount of work and it's gonna blow up > and complexify the spell code. I don't think it really makes it any more complicated - instead of looking in a spell params table (or list), you just look at the object attributes. No doubt that this is a bit of work, but a lot of it is fairly mundane work (eg, changing references of xxx to yyy). > o Spell-objects won't make life any more simple for mapmakers. > Okay, the "sp"-values will be gone - but I bet the spell-objects > will again have a hundred attributes that no one ever truely > understands. Map makers only need to worry about this if they customize spells. Of course, good documentation is needed. However, if you take the above argument to excess (allow map makers to modify attributes makes life difficult), the end result would be to let map makers modify nothing. IMO, allowing the map makers to modify as many things as possible is I think the right approach. It is up to the map makers to know whaty they are doing, and certainly custom dialogues or whatever can be done to make life easier. > > o With spell-objects, spells can be modiefied in the maps. > Maybe that's just me, but I think spells should be standards. > There should be a finite amount of spells, so that players > can learn how they work and what to expect of them. > That keeps the game more simple and a lot more intuitive. > Is it really good to have hundred different versions of > the fireball spell? I think not. I agree to that to an extent - every map maker should not go and put custom spells on their maps. I would consider custom spells to be similar to artifacts - put them in for appropriate rewards, but they still need to be balanced. And of course the standard spells would still exist to be generated for spellbooks that are not customized. > Now if spells are standards (instead of objects), they should > still be fine-tuned and balanced. The perfect combination > of damage, speed and duration is often hard to find. > Therefore, the "spellbook"-approach by David Delbecq seems > like a useful thing to me. You could have the standardized approach with spell object. That still results in a bit of work for less potential gain (if your going to have spells be objects, why not let mapmakers modify them) IMO, spell being objects should happen at some time - it would standardize things, and I expect make things easier for other pieces of the code (perhaps things like scripts - it can now look at an object for the spell). Certainly, David's code would make this easier (as the spell object would have a string like spell_callback that is used). From oxygen at ludd.luth.se Tue Feb 19 10:55:28 2002 From: oxygen at ludd.luth.se (Isak Styf) Date: Thu Jan 13 18:02:07 2005 Subject: [CF-Devel] The Java Client In-Reply-To: <10625.1013882585@www60.gmx.net> Message-ID: <79E65BE9-2559-11D6-A949-003065478D5A@ludd.luth.se> l?rdagen den 16 februari 2002 kl 19.03 skrev Andreas Vogl: > Hi Isak Styf, > > I am very happy about your effort to revive the Java Client. > The Windows client is currently kinda lacking support, so maybe > a Java Client might become handy for Win- (and of course Mac-) users. That was why i started to work on it from the beginning. I believe that a Java client has the potential to please an even larger audience than that. > I'm pretty sure Phil is going to like your work. Maybe you could join > up somehow and roll out a new "official" Java Client release... I guess what would be best would be to put the sources in the CVS so more people can work with it. I dont think i can do that all by my self though since the code is not in the public domain (to the best of my knowledge) and i dont know what Phil would think about that. I sent my mail about the modifications over two months ago, and since that day i havent done that very much coding on it. Most of my time is spent doing commercial programming and finishing up my studies, so unfortunately i havent been able to work as much on the client as i have wanted. I planned to do a complete rewrite using interfaces and inheritances to cope with the Swing/NOSWING audience seamlessly. I havent started that work yet though. > What I noticed from your screenshot is that you seem to have > problems with some pngs not being displayed correctly. Yes. Quite a few pictures get a gray "cloud" on top of them. > I have coded a lot for the Crossfire Java Editor and this problem > is very familiar to me. I assume you did use the default Java methods > to load pngs? While using these, I had the same problems with the > editor. > Applying an "external" png library fixed the problem for me. I use the > sixlegs png library . > It's the only png lib I found which is free, GPLed and working. I will check that out. The png bug is annoying. > Java rules, ;o) > > Andreas V. > > PS.: Another small question: Where did you get a Java2 SDK for MacOS? > I know someone here who is searching for that... For Classic MacOS there is no Java2 SDK because there is no Java2 support for Classic MacOS. I have done my development work with Project Builder under MacOS X which has 1.3.1 under the hood. Bye for now. /// Isak Styf From andi.vogl at gmx.net Thu Feb 21 20:50:11 2002 From: andi.vogl at gmx.net (Andreas Vogl) Date: Thu Jan 13 18:02:07 2005 Subject: [CF-Devel] bug in arch collect Message-ID: <000001c1bb4b$a6150020$c86ebb81@gizmo> The new image-system doesn't work yet, due to a bug: When I add png-images (to the base set) without adding xpm & xbm versions at the same time, the arch collect script complains about "missing faces". That's a bit annoying. Even worse, when the new image is supposed to appear on my screen, the client crashes! And of course this happens with both server and client from latest CVS. So, I think it would be very nice to have following stuff fixed: - Collect script shouldn't complain about missing xpm/xbm. In fact, it shouldn't even look at those IMO. - Client shouldn't crash due to missing xpm/xbm (this might be connected with a bug in the collect script). - Client shouldn't crash due to missing image at all. Displaying some default icon instead would be a lot better. Andreas V. From root at garbled.net Fri Feb 22 02:50:27 2002 From: root at garbled.net (Tim Rightnour) Date: Thu Jan 13 18:02:07 2005 Subject: [CF-Devel] RE: [Crossfire-cvs] CVS commit: arch In-Reply-To: Message-ID: On 22-Feb-02 crossfire-cvs-admin@lists.sourceforge.net wrote: > Added Files: > arch/magic: windstorm.111 windstorm.111.xpm windstorm.112 Do we still need to create/add xpm and xbm files? --- Tim Rightnour NetBSD: Free multi-architecture OS http://www.netbsd.org/ NetBSD supported hardware database: http://mail-index.netbsd.org/cgi-bin/hw.cgi From bugs at mail.real-time.com Sat Feb 23 05:07:38 2002 From: bugs at mail.real-time.com (bugs@mail.real-time.com) Date: Thu Jan 13 18:02:07 2005 Subject: [CF-Devel] [Bug 391] New - gtk-client causes memory leak Message-ID: <200202231107.g1NB7c614157@crusader.real-time.com> http://bugzilla.real-time.com/show_bug.cgi?id=391 *** shadow/391 Sat Feb 23 05:07:37 2002 --- shadow/391.tmp.14154 Sat Feb 23 05:07:37 2002 *************** *** 0 **** --- 1,27 ---- + +============================================================================+ + | gtk-client causes memory leak | + +----------------------------------------------------------------------------+ + | Bug #: 391 Product: Crossfire | + | Status: NEW Version: 0.95.6 | + | Resolution: Platform: PC | + | Severity: blocker OS/Version: Linux | + | Priority: P2 Component: GTK client | + +----------------------------------------------------------------------------+ + | Assigned To: crossfire-devel@lists.real-time.com | + | Reported By: jukkaho@mail.student.oulu.fi | + | CC list: Cc: | + +----------------------------------------------------------------------------+ + | URL: | + +============================================================================+ + | DESCRIPTION | + When fighting with monsters in gtk-client, size of X -process rises 1 to many + megabytes per monster. When playing long enough, X doesn't have any more free + virtual memory space and it crashes. + + Simply moving around in the same screen with monsters does not cause any + leaking, but even hitting them does. Killing them also (I think). + + cfclient does not leak memory afaik. + + Client was the one which can be downloaded from the front page of + crossfire.real-time.com - version 1.1.0 \ No newline at end of file From bugs at mail.real-time.com Sat Feb 23 05:20:05 2002 From: bugs at mail.real-time.com (bugs@mail.real-time.com) Date: Thu Jan 13 18:02:07 2005 Subject: [CF-Devel] [Bug 392] New - gtk-client dies when pressing the 'wrong button' Message-ID: <200202231120.g1NBK5E14238@crusader.real-time.com> http://bugzilla.real-time.com/show_bug.cgi?id=392 *** shadow/392 Sat Feb 23 05:20:05 2002 --- shadow/392.tmp.14235 Sat Feb 23 05:20:05 2002 *************** *** 0 **** --- 1,68 ---- + +============================================================================+ + | gtk-client dies when pressing the 'wrong button' | + +----------------------------------------------------------------------------+ + | Bug #: 392 Product: Crossfire | + | Status: NEW Version: 0.95.6 | + | Resolution: Platform: PC | + | Severity: major OS/Version: Linux | + | Priority: P2 Component: GTK client | + +----------------------------------------------------------------------------+ + | Assigned To: crossfire-devel@lists.real-time.com | + | Reported By: jukkaho@mail.student.oulu.fi | + | CC list: Cc: | + +----------------------------------------------------------------------------+ + | URL: | + +============================================================================+ + | DESCRIPTION | + Gdk-ERROR **: file gdkfont.c: line 504 (gdk_char_width_wc): assertion failed: + (wctomb(&c,character) == 1) + aborting... + Abort (core dumped) + + gdb tells the following: + #0 0x4034c801 in __kill () from /lib/i686/libc.so.6 + (gdb) bt + #0 0x4034c801 in __kill () from /lib/i686/libc.so.6 + #1 0x4034c5da in raise (sig=6) at ../sysdeps/posix/raise.c:27 + #2 0x4034dd82 in abort () at ../sysdeps/generic/abort.c:88 + #3 0x4021415c in g_logv () at eval.c:41 + #4 0x40214207 in g_log () at eval.c:41 + #5 0x401dedf3 in gdk_char_width_wc () at eval.c:41 + #6 0x400fbffe in gtk_entry_insert_text () at eval.c:41 + #7 0x401273e0 in gtk_marshal_NONE__POINTER_INT_POINTER () at eval.c:41 + #8 0x40159c7d in gtk_signal_real_emit () at eval.c:41 + #9 0x401579f5 in gtk_signal_emit () at eval.c:41 + #10 0x400f73b8 in gtk_editable_insert_text () at eval.c:41 + #11 0x400fabff in gtk_entry_key_press () at eval.c:41 + #12 0x40126fbc in gtk_marshal_BOOL__POINTER () at eval.c:41 + #13 0x40159c7d in gtk_signal_real_emit () at eval.c:41 + #14 0x401579f5 in gtk_signal_emit () at eval.c:41 + #15 0x401920e9 in gtk_widget_event () at eval.c:41 + #16 0x4019a6df in gtk_window_key_press_event () at eval.c:41 + #17 0x40126fbc in gtk_marshal_BOOL__POINTER () at eval.c:41 + #18 0x40159c7d in gtk_signal_real_emit () at eval.c:41 + #19 0x401579f5 in gtk_signal_emit () at eval.c:41 + #20 0x401920e9 in gtk_widget_event () at eval.c:41 + #21 0x40126e98 in gtk_propagate_event () at eval.c:41 + #22 0x40125f3f in gtk_main_do_event () at eval.c:41 + #23 0x401dde4f in gdk_event_dispatch () at eval.c:41 + #24 0x402117f3 in g_main_dispatch () at eval.c:41 + #25 0x40211dd9 in g_main_iterate () at eval.c:41 + #26 0x40211f8c in g_main_run () at eval.c:41 + #27 0x40125803 in gtk_main () at eval.c:41 + #28 0x0805ec61 in get_metaserver () at gx11.c:6014 + #29 0x0805f9a5 in main (argc=1, argv=0xbffff9f4) at gx11.c:6306 + #30 0x4033b177 in __libc_start_main (main=0x805f8c0
, argc=1, + ubp_av=0xbffff9f4, init=0x804e5b4 <_init>, fini=0x80692f0 <_fini>, + rtld_fini=0x4000e184 <_dl_fini>, stack_end=0xbffff9ec) at + ../sysdeps/generic/libc-start.c:129 + + Perhaps this is just a gtk-problem. But it is annoying as hell. When pressing + any of the keys: ö,ä,å which are located right from p and l in Finnish keyboard + layout, crossfire client dies a horrible death. Ö and ä characters are also very + commonly used in Finnish language. + + Client is 1.1.0 + + $ gtk-config --version + 1.2.9 \ No newline at end of file From bugs at mail.real-time.com Sat Feb 23 05:41:16 2002 From: bugs at mail.real-time.com (bugs@mail.real-time.com) Date: Thu Jan 13 18:02:07 2005 Subject: [CF-Devel] [Bug 391] Changed - gtk-client causes memory leak Message-ID: <200202231141.g1NBfGO14323@crusader.real-time.com> http://bugzilla.real-time.com/show_bug.cgi?id=391 *** shadow/391 Sat Feb 23 05:07:37 2002 --- shadow/391.tmp.14320 Sat Feb 23 05:41:16 2002 *************** *** 25,27 **** --- 25,36 ---- Client was the one which can be downloaded from the front page of crossfire.real-time.com - version 1.1.0 + + ------- Additional Comments From jukkaho@mail.student.oulu.fi 2002-02-23 05:41 ------- + Hmm.. after I changed my imlib settings to 'no cache', almost no increase in + X-processes size can be seen after I quit the gtk-client. + + Only about 3 megs / short crossfire session and not 300 like before. + + Size of X still is several hundred megabytes during the actual game. Are there + other caching settings that can cause this silly behaviour? \ No newline at end of file From bugs at mail.real-time.com Sat Feb 23 11:15:23 2002 From: bugs at mail.real-time.com (bugs@mail.real-time.com) Date: Thu Jan 13 18:02:07 2005 Subject: [CF-Devel] [Bug 391] Changed - gtk-client causes memory leak Message-ID: <200202231715.g1NHFNY17170@crusader.real-time.com> http://bugzilla.real-time.com/show_bug.cgi?id=391 *** shadow/391 Sat Feb 23 05:41:16 2002 --- shadow/391.tmp.17167 Sat Feb 23 11:15:23 2002 *************** *** 4,10 **** | Bug #: 391 Product: Crossfire | | Status: NEW Version: 0.95.6 | | Resolution: Platform: PC | ! | Severity: blocker OS/Version: Linux | | Priority: P2 Component: GTK client | +----------------------------------------------------------------------------+ | Assigned To: crossfire-devel@lists.real-time.com | --- 4,10 ---- | Bug #: 391 Product: Crossfire | | Status: NEW Version: 0.95.6 | | Resolution: Platform: PC | ! | Severity: normal OS/Version: Linux | | Priority: P2 Component: GTK client | +----------------------------------------------------------------------------+ | Assigned To: crossfire-devel@lists.real-time.com | *************** *** 34,36 **** --- 34,40 ---- Size of X still is several hundred megabytes during the actual game. Are there other caching settings that can cause this silly behaviour? + + ------- Additional Comments From jukkaho@mail.student.oulu.fi 2002-02-23 11:15 ------- + Changed severity to normal since imlib was the main cause of problem after + program was terminated. \ No newline at end of file From dnh at hawthorn.csse.monash.edu.au Sat Feb 23 23:07:26 2002 From: dnh at hawthorn.csse.monash.edu.au (David Hurst) Date: Thu Jan 13 18:02:07 2005 Subject: [CF-Devel] The Java Client In-Reply-To: <200111010138.CAA28382@mother.ludd.luth.se> References: <200111010138.CAA28382@mother.ludd.luth.se> Message-ID: <20020224050726.GA25129@hawthorn.csse.monash.edu.au> > The host OS is MacOSX so beware if Mac makes your skin itch. ;) OMG, totally the opposite dude ;), I have been waiting for someone to get a client working on MacOS X for ages =). Please come into the irc chatroom more so we can chat =), verra cool! dnh > Comments and questions are very welcome. Bye for now. > > /// Isak Styf, oxygen@ludd.luth.se > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel From dnh at hawthorn.csse.monash.edu.au Sun Feb 24 17:19:39 2002 From: dnh at hawthorn.csse.monash.edu.au (David Hurst) Date: Thu Jan 13 18:02:07 2005 Subject: [CF-Devel] Re: [Crossfire-cvs] CVS commit: maps/city/misc In-Reply-To: References: Message-ID: <20020224231939.GA3423@hawthorn.csse.monash.edu.au> > Module Name: maps > Committed By: avogl > Date: Sun Feb 24 23:11:47 UTC 2002 > Log Message: > in scorn PowerHouse: inserted altar to buy > full mana restore (in case runes get sold > out - altar works infinitly) I am just wondering if we should make the scorn powerhouse a no magic zone. You can create a town portal in the powerhouse, then portal to some nasty strong monster, shoot off all your mana, then run into the townportal, heal and fill mana, and do it again. dnh From andi.vogl at gmx.net Mon Feb 25 05:06:09 2002 From: andi.vogl at gmx.net (Andreas Vogl) Date: Thu Jan 13 18:02:07 2005 Subject: [CF-Devel] town portal (RE: CVS commit: maps/city/misc) In-Reply-To: <20020224231939.GA3423@hawthorn.csse.monash.edu.au> Message-ID: <000001c1bdec$71a22db0$c86ebb81@gizmo> in reply to Darth Bob: > I am just wondering if we should make the scorn powerhouse a > no magic zone. > You can create a town portal in the powerhouse, then portal > to some nasty strong monster, shoot off all your mana, then > run into the townportal, heal and fill mana, and do it again. I agree, no_magic zone in the powerhouse is a good idea. I want to add that I generally dislike the town portal spell. What darth bob describes above can always be done in some way: make a portal to safe place and wait/restore yourself. Many maps have been explicitly designed *not* to allow players a break from fighting a particular monster. Town portal ruins the tension in these maps. Spells like town portal and WoR are the reason why so many maps have no_magic/no_spell zones. This again hurts the wizard- type players, because they can't fight efficiently without spells. Some day I would like to create a "spellblocker"-object that can block use of a particular spell (like TownPortal and WoR). I would then like to insert "town_portal_blockers" on several boss-monster maps, and a few other places. Does anyone see objections to doing that? If so, please speak up now before I realize my plan. =) Andreas V. From dnh at hawthorn.csse.monash.edu.au Mon Feb 25 07:06:53 2002 From: dnh at hawthorn.csse.monash.edu.au (David Hurst) Date: Thu Jan 13 18:02:07 2005 Subject: [CF-Devel] town portal (RE: CVS commit: maps/city/misc) In-Reply-To: <000001c1bdec$71a22db0$c86ebb81@gizmo> References: <20020224231939.GA3423@hawthorn.csse.monash.edu.au> <000001c1bdec$71a22db0$c86ebb81@gizmo> Message-ID: <20020225130653.GA22672@hawthorn.csse.monash.edu.au> > Does anyone see objections to doing that? > If so, please speak up now before I realize my plan. =) Nope =). I agree with you, WoR, Restore, Holy Word, Bomb and Town Portal are really the only spells the average player uses unless in a specific situation that there is clearly a better solution (dragons.. ) I don't like the idea that all the other hundreds of spells aren't useful perhaps more thought could be put into a way of fixing this problem, certainly what AV suggests is a step in the right direction. Darth dnh From mwedel at sonic.net Mon Feb 25 22:41:20 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:07 2005 Subject: [CF-Devel] town portal (RE: CVS commit: maps/city/misc) References: <000001c1bdec$71a22db0$c86ebb81@gizmo> Message-ID: <3C7B11F0.FE045AE6@sonic.net> Andreas Vogl wrote: > I want to add that I generally dislike the town portal spell. > What darth bob describes above can always be done in some way: > make a portal to safe place and wait/restore yourself. > Many maps have been explicitly designed *not* to allow players > a break from fighting a particular monster. Town portal ruins > the tension in these maps. Yep - instead of the town portal going to the mana shop, you put it to the inn or other nearby building. IT does mean a few more steps for the player. IMO, some potions should be in near infinite supply, like magic power potions, healing potions, etc. This doesn't fix the problem, but does reduce the need somewhat - if you can carry those 10 magic power potions, popping back to the mana shop isn't quite as important. > Some day I would like to create a "spellblocker"-object that > can block use of a particular spell (like TownPortal and WoR). > I would then like to insert "town_portal_blockers" on several > boss-monster maps, and a few other places. Yeah - similarly, many maps have no spells also for things like dimension door (so you can't pop into the treasure room). An abstract 'no transportation spell' abstract could cover all of those. It might also be handy to have that as a global in the map header, so that you don't need to put them on every space of a map you want to fully protect. From root at garbled.net Mon Feb 25 23:15:32 2002 From: root at garbled.net (Tim Rightnour) Date: Thu Jan 13 18:02:07 2005 Subject: [CF-Devel] town portal (RE: CVS commit: maps/city/misc) In-Reply-To: <20020225130653.GA22672@hawthorn.csse.monash.edu.au> Message-ID: On 25-Feb-02 David Hurst wrote: > I agree with you, WoR, Restore, Holy Word, Bomb and Town Portal are really > the > only spells the > average player uses unless in a specific situation that there is clearly a > better solution > (dragons.. ) > > I don't like the idea that all the other hundreds of spells aren't useful > perhaps more thought > could be put into a way of fixing this problem, certainly what AV suggests is > a > step in the right > direction. On our mud, we had the problem that portals became abused, much like they seem to be becoming here. We had a unique solution. We called it the void. When you stepped into the portal, there was a percentage change (like 5) that you would get dumped into the void. The void, was a no-magic, silent room (cant shout or speak). In there lived a particularly nasty creature, who was horribly aggressive, and incredibly dangerous to even top-level players. What this caused, was that players used portals more gingerly. Only when they absolutely needed to. They didn't use them willy-nilly, knowing that a very bad thing could happen if they did hit the void. --- Tim Rightnour NetBSD: Free multi-architecture OS http://www.netbsd.org/ NetBSD supported hardware database: http://mail-index.netbsd.org/cgi-bin/hw.cgi From andi.vogl at gmx.net Mon Feb 25 23:27:00 2002 From: andi.vogl at gmx.net (Andreas Vogl) Date: Thu Jan 13 18:02:07 2005 Subject: [CF-Devel] new quetzal (dragon) race Message-ID: <000001c1be86$37bf8d00$c86ebb81@gizmo> I would like to realize an idea now that I had in mind for a long time: Modifying the quetzal to be a special "dragon race", which works different from all other races. The major clou is that these dragon-players won't wear any equipment, but "evolve" instead by eating flesh-items from slain monsters. This adds a completely new way to play the game without changing or complexifying existing stuff. I'm already halfway done with the coding and would like to ask if my idea is generally accepted. ------------------------- Here's what I want to do: The new quetzal cannot wear armour, nor weapons, nor will it start with fire immunity. But it makes up for it by "evolving": Being dragons, they have a dragon skin which can evolve to provide resistances. The quetzals must eat flesh-items to gain resistance. The higher the resistance goes, the higher must be both the player's level and the level of the flesh-items to improve it further. The upper limit is 95% resistance, which is of course hard to achieve. At any time, the quetzal is specialized in one certain attacktype (fire, cold, etc). Gaining levels, the player advances in this speciality. He can achieve higher stages of evolution where he gains new abilities or spells. However, new ability levels can only be achieved by surpassing the maximum level. If the player falls back due to dying, he must catch up before gaining additional stuff. In this way, the quetzal must plan it's character development, as there are "only" 110 levels to go. The attacktype-focus can be changed by eating special flesh items ("ancient elemental residues"). These will be available in shops. Special attacktypes (paralyze, confuse, drain, etc) are not included in the dragon-skin feature, as they are close to useless at less than 100% resistance. I plan to eventually hand out such special immunities for Q's in form of flesh-artifacts. Old quetzal players will not be affected by the changes. ------------------------- Andreas From mwedel at sonic.net Mon Feb 25 23:50:18 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:07 2005 Subject: [CF-Devel] new quetzal (dragon) race References: <000001c1be86$37bf8d00$c86ebb81@gizmo> Message-ID: <3C7B221A.B7E61E09@sonic.net> As a general note, it sounds like a cool idea. Having similar things more races/classes in the future would add interest - eg, monks who start to gain special powers or whatever. Not really related to this, but a better way to perhaps do such focus in the future (for the more general case) would be to have training halls in the various cities. When you go to a training hall, through some mechanism (ideally, server asking the player/client), the player chooses their focus for the level(s) they have gained but not put any focus on. The idea of eating food below works, but seems more a solution because its an easy way to do it. > The new quetzal cannot wear armour, nor weapons, > nor will it start with fire immunity. > But it makes up for it by "evolving": > Being dragons, they have a dragon skin which can evolve > to provide resistances. The quetzals must eat flesh-items > to gain resistance. The higher the resistance goes, > the higher must be both the player's level and the level > of the flesh-items to improve it further. The upper limit > is 95% resistance, which is of course hard to achieve. Tuning of this is a key, but seems reasonable. Items with relatively low resistance values may mean very little gain (or don't work at all). You could easily enough do an inverse resistance of skin * resistance of food = chance of resistance improving (eg, you are 60% resistant to fire and eat a 20% resistant item - your chance of improvement is 40% * 20%, or .8%). That may be extremely, but such a system means you need to eat highly resistant food if you are already highly resistant. > Special attacktypes (paralyze, confuse, drain, etc) are not > included in the dragon-skin feature, as they are close to useless > at less than 100% resistance. > I plan to eventually hand out such special immunities for Q's in > form of flesh-artifacts. The other problem of giving confuse/drain/whatever resistant is that I don't think any foods with those resistances ever show up - since the idea behind resistances on food was apparantly to increase the odd of the fleshes survival when monsters of similar type were around, that was never an issue for drain/confusion/whatever, since those attacktypes don't destroy items. A minor nit - drain resistance isn't completely useless - your resistance to drain reduces the amount you are drained by that amount. So if your 80% resistance, you only lose 20% of what you would if you had no resistant. Such a drain is still very painful of course, which is why the 100% drain rings are about. From bugs at mail.real-time.com Mon Feb 25 23:08:57 2002 From: bugs at mail.real-time.com (bugs@mail.real-time.com) Date: Thu Jan 13 18:02:07 2005 Subject: [CF-Devel] [Bug 392] Changed - gtk-client dies when pressing the 'wrong button' Message-ID: <200202260508.g1Q58vh30369@crusader.real-time.com> http://bugzilla.real-time.com/show_bug.cgi?id=392 *** shadow/392 Sat Feb 23 05:20:05 2002 --- shadow/392.tmp.30362 Mon Feb 25 23:08:57 2002 *************** *** 2,9 **** | gtk-client dies when pressing the 'wrong button' | +----------------------------------------------------------------------------+ | Bug #: 392 Product: Crossfire | ! | Status: NEW Version: 0.95.6 | ! | Resolution: Platform: PC | | Severity: major OS/Version: Linux | | Priority: P2 Component: GTK client | +----------------------------------------------------------------------------+ --- 2,9 ---- | gtk-client dies when pressing the 'wrong button' | +----------------------------------------------------------------------------+ | Bug #: 392 Product: Crossfire | ! | Status: RESOLVED Version: 0.95.6 | ! | Resolution: WONTFIX Platform: PC | | Severity: major OS/Version: Linux | | Priority: P2 Component: GTK client | +----------------------------------------------------------------------------+ *************** *** 66,68 **** --- 66,78 ---- $ gtk-config --version 1.2.9 + + ------- Additional Comments From mwedel@scruz.net 2002-02-25 23:08 ------- + From the stack trace, this certainly looks like a gtk bug. + + I was unable to reproduce it on my system (latest client, gtk 1.2.10). + However, it could just be that the font you are using does not have those + characters defined. + + In any case, this is not a crossfire bug, unless crossfire should not honor the + extended characters, but that seems liek a bit of a hack. From mwedel at sonic.net Tue Feb 26 01:44:13 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:08 2005 Subject: [CF-Devel] arch: xbm, xpm, and dev Message-ID: <3C7B3CCD.B724D3A5@sonic.net> I've removed all the xbm and xpm images from the arch distribution. those of you on the mailing list should see those messages shortly. However, what is left is a bunch of misc images in the dev directory. Some of them (Britan, Gloarn, Kanji) are more or less alternate fonts for some characters. These are obviously not being used - they in theory could be used for runes, or large scale signs, or whatever else. Others may just be old versions of some images, and some may be actual different images. Also, there are the follow .arc files in the dev directory: ./xpm_pref/Mountain/mountain_2.arc ./xpm_pref/Mountain/moun_cave1.arc ./xpm_pref/Mountain/moun_cave2.arc ./xpm_pref/Mountain/mountain1.arc ./xpm_pref/Mountain/mountain2.arc ./unused/0.91.1/crystal_bl.arc ./unused/0.91.1/mountain_1.arc ./unused/0.91.1/Store/store_book.arc ./unused/0.91.1/Store/store_food.arc ./unused/0.91.1/shop.arc ./unused/0.91.1/Monolith/monolith.arc ./unused/0.91.1/Undead/shadow.arc ./unused/0.91.1/Undead/werewolf.arc ./unused/0.91.1/Flyingnote/flyingnote.arc ./unused/0.91.1/dopplegang.arc ./unused/0.91.1/centaur.arc ./unused/0.91.1/lwoodhouse.arc ./unused/0.91.1/grave.arc ./unused/0.91.1/Lg_bungalow/lbungalow.arc ./unused/0.91.1/grateTrg1.arc ./unused/0.91.1/grateTrg2.arc ./unused/0.91.1/dark_uni.arc ./unused/0.91.6/potionrstr.arc ./unused/0.91.7/Town/beggar.arc ./unused/0.91.7/Town/child.arc ./unused/0.91.7/Town/sailor.arc ./unused/0.91.7/Town/fatman.arc ./unused/0.91.7/Town/fatwoman.arc ./unused/0.91.7/Town/merchant.arc ./unused/0.91.7/Town/courier.arc ./unused/0.91.7/chaos/c_knight.arc ./unused/0.91.7/chaos/broo.arc ./unused/0.91.7/newfood/s_weasel.arc ./unused/0.91.7/newfood/bag_popcorn.arc ./unused/0.91.7/newfood/orange.arc ./unused/0.91.7/newfood/pear.arc ./unused/0.91.7/newfood/onion.arc ./unused/0.91.7/newtown/r_house1.arc ./unused/0.91.7/newtown/r_house2.arc ./unused/0.91.7/newtown/university.arc ./unused/0.91.7/newtown/s_shop1.arc ./unused/0.91.7/newtown/s_shop2.arc ./unused/0.91.7/newtown/t_house1.arc ./unused/0.91.7/newtown/t_house2.arc ./unused/0.91.7/newtown/market1.arc ./unused/0.91.7/newtown/market2.arc ./unused/0.91.7/newtown/market3.arc ./unused/0.91.7/newtown/s_tower1.arc ./unused/0.91.7/newtown/s_tower2.arc ./unused/0.91.7/newtown/slum1.arc ./unused/0.91.7/newtown/slum2.arc ./unused/0.91.7/newtown/slum3.arc ./unused/0.91.7/newtown/temple/temple1.arc ./unused/0.91.7/newtown/collesium.arc ./unused/0.91.7/mood_floors/furious_floor.arc ./unused/0.91.7/mood_floors/sleep_floor.arc ./unused/0.91.7/mood_floors/calm_floor.arc ./unused/0.91.7/mood_floors/charm_floor.arc ./obsolete/randomCont.arc With the addition of the alternate image support in the server, there really isn't much point have a dev directory - either the image is good enough that it should perhaps be in some set, the image is bad enough it should be removed, or it is a duplicate of something else. The above arc files should likewise be resolved - if they are useful, they should get moved back into the main distribution, if they are not, they should get removed. That said, I think in a month or two, we should go and remove the dev directory. I would suggest that people interessted in the arch's/images look through the stuff in the dev directory and move the stuff worth keeping someplace more appropriate in the arch directory. From yann.chachkoff at MailAndNews.com Tue Feb 26 06:34:47 2002 From: yann.chachkoff at MailAndNews.com (Yann Chachkoff) Date: Thu Jan 13 18:02:08 2005 Subject: [CF-Devel] town portal (RE: CVS commit: maps/city/misc) Message-ID: <3C98EC6E@MailAndNews.com> > >On our mud, we had the problem that portals became abused, much like they seem >to be becoming here. We had a unique solution. > >We called it the void. The current problem with spellcasting is that it is too "piece-of-cake" - you do not risk anything when failing to cast a spell. IMO, we should try to: 1 - Rise the difficulty level for spells known to be too powerful (there should always be a small chance of failing the higher level spells); 2 - Make high-level spellcasting more unpredictable and dangerous. If I remember well, there was a crossfire compile-time option to activate "backfire effects" for failed spellcasting, but I've never seen it on a public server. We could reactivate and modify it a little to allow more "dangerous" effects (like The Void) not only for the Town Portal, but also for all other "high level" spells. ------------------------------------------------ Visit http://www.chachkoff.pronym.org for a journey into a fantastic world ! (But don't expect too much...) GPG: http://www.chachkoff.pronym.org/gros.pub ------------------------------------------------ From jbontje at suespammers.org Tue Feb 26 06:48:04 2002 From: jbontje at suespammers.org (Joris Bontje) Date: Thu Jan 13 18:02:08 2005 Subject: [CF-Devel] memory leak Message-ID: <20020226124804.GA32578@mids.student.utwente.nl> Latest CVS version of crossfire seems to have a big memory leak Regards, Joris Bontje / mids -- Gpg Key: Id=0xF19326A9 / http://mids.student.utwente.nl/~mids/jbontje.pub Key fingerprint = 730D 9B3A F406 F28A 957D 6397 31E8 6D4C F193 26A9 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 240 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20020226/b8a3bfcb/attachment.pgp From andi.vogl at gmx.net Tue Feb 26 07:29:51 2002 From: andi.vogl at gmx.net (Andreas Vogl) Date: Thu Jan 13 18:02:08 2005 Subject: [CF-Devel] town portal (RE: CVS commit: maps/city/misc) In-Reply-To: <3C98EC6E@MailAndNews.com> Message-ID: <000201c1bec9$aed58fa0$c86ebb81@gizmo> in reply to gros and garbled: > > > > On our mud, we had the problem that portals became abused, > > much like they seem to be becoming here. > > We had a unique solution. > > > > We called it the void. > > > The current problem with spellcasting is that it is too > "piece-of-cake" - you do not risk anything when failing to cast > a spell. IMO, we should try to: > 1 - Rise the difficulty level for spells known to be too > powerful (there should always be a small chance of failing > the higher level spells); > 2 - Make high-level spellcasting more unpredictable and dangerous. I think this would be a very good thing to do. And I *love* the idea about the "void". :-) Andreas From crossfire at Suckfuell.net Tue Feb 26 07:48:55 2002 From: crossfire at Suckfuell.net (Jochen Suckfuell) Date: Thu Jan 13 18:02:08 2005 Subject: [CF-Devel] town portal (RE: CVS commit: maps/city/misc) In-Reply-To: <000201c1bec9$aed58fa0$c86ebb81@gizmo>; from andi.vogl@gmx.net on Tue, Feb 26, 2002 at 02:29:51PM +0100 References: <3C98EC6E@MailAndNews.com> <000201c1bec9$aed58fa0$c86ebb81@gizmo> Message-ID: <20020226144855.A26325@ds217-115-141-141.dedicated.hosteurope.de> Hi! > > 2 - Make high-level spellcasting more unpredictable and dangerous. That's okay if high level means minimum required caster level. But it should not mean "cast at high level". There is no sense in making a simple spell fail just because the caster has a high level (and cannot cast at a lower level by any means). Bye Jochen -- Jochen Suckfuell From andi.vogl at gmx.net Tue Feb 26 08:18:18 2002 From: andi.vogl at gmx.net (Andreas Vogl) Date: Thu Jan 13 18:02:08 2005 Subject: [CF-Devel] new quetzal (dragon) race In-Reply-To: <3C7B221A.B7E61E09@sonic.net> Message-ID: <000c01c1bed0$71695cd0$c86ebb81@gizmo> in reply to Mark: > > As a general note, it sounds like a cool idea. [...] Thanks. Nice to hear that. :-) > Not really related to this, but a better way to perhaps do > such focus in thefuture (for the more general case) would be > to have training halls in the various cities. [...] > The idea of eating food below works, but seems more a solution > because its an easy way to do it. Absolutely true. I just want to keep it simple to start with. Later - if traininghalls are implemented - this could be changed easily. > > The higher the resistance goes, the higher must be both the > > player's level and the level of the flesh-items to improve it > > further. The upper limit is 95% resistance, which is of course > > hard to achieve. > > Tuning of this is a key, but seems reasonable. Items with > relatively low resistance values may mean very little gain > (or don't work at all). [...] Yes, it is tricky to tune and balance. I have given the mathematical aspect a LOT of thought (You should see my design- paper crammed full of formulaes and level-graphs =) ...) In the meantime I've got an implementation that makes a good impression to me and looked good in the testing so far. It goes like this (calculated with double precision): (note that flesh level is inherited from the killed monster) = level bonus for lower levels (at low/medium levels the resistances can be boosted to a decent basic level ~30%) chance = MIN( , ) + - if (chance >= 0) chance += 1; // if chance>0, the chance increases linear else chance = 2^chance // if chance<0, the chance decreases exponentially // the chance is proportional to the amount of resistance // on the flesh (50% is maximum on flesh) chance = chance * /50; // for resistance of ability focus, chance is doubled if (resist = ability focus) chance *= 2; add +1 resistance if: RANDOM%100 < chance > > Special attacktypes (paralyze, confuse, drain, etc) are not > > included in the dragon-skin feature [...] > > The other problem of giving confuse/drain/whatever resistance > is that I don't think any foods with those resistances ever show > up - since the idea behind resistances on food was apparantly to > increase the odd of the fleshes survival [...] In fact, all attacktypes are inherited to the flesh. But gaining +1 really isn't worth anything, so I want to spare players from this kinda dissappointment. Since humanoid players can get an amulet of free action/shielded mind, I think it is most fair and balancing to allow "flesh-artifacts" for dragons with similar effect. But I'll care about this later when I have finished, tested and committed the basic code. Andreas From reeve at ductape.net Tue Feb 26 10:28:10 2002 From: reeve at ductape.net (Scott Barnes) Date: Thu Jan 13 18:02:08 2005 Subject: [CF-Devel] town portal (RE: CVS commit: maps/city/misc) In-Reply-To: References: Message-ID: <1014740970.8398.7.camel@terra.localnet> On Tue, 2002-02-26 at 00:15, Tim Rightnour wrote: > > On 25-Feb-02 David Hurst wrote: > > I agree with you, WoR, Restore, Holy Word, Bomb and Town Portal are really > > the > > only spells the > > average player uses unless in a specific situation that there is clearly a > > better solution > > (dragons.. ) > > > > I don't like the idea that all the other hundreds of spells aren't useful > > perhaps more thought > > could be put into a way of fixing this problem, certainly what AV suggests is > > a > > step in the right > > direction. > > On our mud, we had the problem that portals became abused, much like they seem > to be becoming here. We had a unique solution. > > We called it the void. When you stepped into the portal, there was a > percentage change (like 5) that you would get dumped into the void. The void, > was a no-magic, silent room (cant shout or speak). In there lived a > particularly nasty creature, who was horribly aggressive, and incredibly > dangerous to even top-level players. > > What this caused, was that players used portals more gingerly. Only when they > absolutely needed to. They didn't use them willy-nilly, knowing that a very > bad thing could happen if they did hit the void. Wow! I just wanted to say I REALLY like this idea! Although, I had an idea like this that I wanted to discuss too. My idea was the same principle as the "void" idea, except that instead of a void with a monster of unspeakable evil in it, I was thinking it could transport the player to one of the gods special little "worlds". Like the dark world of Gorokh or the end of the universe (The Devourers world). Then they would have to fight their way through it and defeat the avatar of the god that rules it to get back. (or die of course :)) -- -- -- Reeve the cat ----BEGIN FORTUNE---- You had mail. Paul read it, so ask him what it said. ----END FORTUNE---- -----BEGIN GEEK CODE BLOCK----- Version: 3.12 GCS d? s: a? C++++ UL++++ P+ L++++ E- W++ N o K- w--- O M-- V-- PS+++ PE Y PGP t+++ 5 X+ R+++ tv+ b+++ DI++ D+ G e* h-- r+++ y** ------END GEEK CODE BLOCK------ From root at garbled.net Tue Feb 26 12:46:27 2002 From: root at garbled.net (Tim Rightnour) Date: Thu Jan 13 18:02:08 2005 Subject: [CF-Devel] town portal (RE: CVS commit: maps/city/misc) In-Reply-To: <3C98EC6E@MailAndNews.com> Message-ID: On 26-Feb-02 Yann Chachkoff wrote: > If I remember well, there was a crossfire compile-time option to activate > "backfire effects" for failed spellcasting, but I've never seen it on a > public > server. We could reactivate and modify it a little to allow more "dangerous" > effects (like The Void) not only for the Town Portal, but also for all other > "high level" spells. Well.. I actually disagree with that. Again, using the mud as my base of reference, we found that generally, the backfires, even though they were pretty cool, and seemed relatively balanced, really pissed off the players. Basically, here is the problem: Player A fights monster A: Monster A can fire lightning at the player all day long, with no fear. if the monster dies, it doesn't care, it repops. Player A however, has limited mana, and if it dies, it's a very upsetting thing. The player has a spell which he painstakingly learned, and now attempts to use against the monster trying to kill him. Oh look, he rolled 00, he just blew his arm off. This is just like critical hits/misses. It's very upsetting to the players. It throws millions of balance problems into the equasion. Players absolutely hated the spells, and stopped using them entirely until we took it out. I suggested the void, because it's a specific solution to a specific problem, one which was being abused on our mud, and looks to be abused on CF. If you think about it, the portal is a kind of "cheat" for the player. He can avoid things that he would normally have to encounter. The player is willing to risk the void, in order to cheat past the rest of the maze. However, a normal spell, like say meteor storm, is not a form of cheating, it's just a high level mage causing lots of fire. The void is designed to balance the cheat out. I don't mind if you take a certain spell, and find a logical and just backfire for it, on an individual basis. Think of the void as "a rift in space time caused by the portal". But I think each spell should be evaluated one at a time, and determined if it needs a backfire or not. I do not agree that we should penalize spellcasters in general. As yourself, why is it that nobody runs the backfire code. :) --- Tim Rightnour NetBSD: Free multi-architecture OS http://www.netbsd.org/ NetBSD supported hardware database: http://mail-index.netbsd.org/cgi-bin/hw.cgi From peterm at tonks.EECS.Berkeley.EDU Tue Feb 26 12:45:06 2002 From: peterm at tonks.EECS.Berkeley.EDU (Peter Mardahl) Date: Thu Jan 13 18:02:08 2005 Subject: [CF-Devel] new quetzal (dragon) race In-Reply-To: Message from "Andreas Vogl" of "Tue, 26 Feb 2002 06:27:00 +0100." <000001c1be86$37bf8d00$c86ebb81@gizmo> Message-ID: <200202261845.g1QIj6s19038@tonks.EECS.Berkeley.EDU> Hello, I don't see a compelling reason to modify the Quetzalcoatl instead of creating another dragon player-race. This is reverse-compatible and extends the game rather than mutating it, and possibly breaking someone's treasured characters. In terms of how to do it, I'd rather not see a lot of hard-wired special purpose code having to do with dragons only implemented, eg, when a DRAGON eats part of a FIRE ELEMENTAL'S RESIDUE, he gains 5 points of fire immunity. How about: when a DRAGON sacrifices a FIRE ELEMENTAL'S RESIDUE on a special altar of Ruggilli, the god (via a player-changer) adds 5% to his intrinsic fire resistance. The downside of this is that maps are required for a player's development. The upside is that DRAGONs won't be a slew of special purpose code written into the server. You can keep the "eating" flavor by saying this: the body parts have to be prepared specially in order to confer any properties, and so have to be brought in and dropped on an altar. You can actually take the sacrifice and produce an unliftable 'prepared' body part which is actually a potion which grants the desired intrinsic, and which must be eaten or destroyed on the spot in order for the player to leave. All the code you create to do it these ways could be reused in similar ways for wraiths, or even advancement in priest levels, e.g., a priest of Gaea being required to bring back an apple from the Tree of Life, only to be told to eat it after it'd been "blessed", and gaining some poison immunity that way, or some such. PM > I would like to realize an idea now that I had in mind for a > long time: Modifying the quetzal to be a special "dragon race", > which works different from all other races. > The major clou is that these dragon-players won't wear any > equipment, but "evolve" instead by eating flesh-items from > slain monsters. This adds a completely new way to play the game > without changing or complexifying existing stuff. > > I'm already halfway done with the coding and would like > to ask if my idea is generally accepted. > > ------------------------- > Here's what I want to do: > > The new quetzal cannot wear armour, nor weapons, > nor will it start with fire immunity. > But it makes up for it by "evolving": > Being dragons, they have a dragon skin which can evolve > to provide resistances. The quetzals must eat flesh-items > to gain resistance. The higher the resistance goes, > the higher must be both the player's level and the level > of the flesh-items to improve it further. The upper limit > is 95% resistance, which is of course hard to achieve. > > At any time, the quetzal is specialized in one certain > attacktype (fire, cold, etc). Gaining levels, the player advances > in this speciality. He can achieve higher stages of evolution > where he gains new abilities or spells. > However, new ability levels can only be achieved by surpassing > the maximum level. If the player falls back due to dying, > he must catch up before gaining additional stuff. > In this way, the quetzal must plan it's character development, > as there are "only" 110 levels to go. > The attacktype-focus can be changed by eating special > flesh items ("ancient elemental residues"). These will be > available in shops. > > Special attacktypes (paralyze, confuse, drain, etc) are not > included in the dragon-skin feature, as they are close to useless > at less than 100% resistance. > I plan to eventually hand out such special immunities for Q's in > form of flesh-artifacts. > > Old quetzal players will not be affected by the changes. > ------------------------- > > Andreas > > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel From root at garbled.net Tue Feb 26 12:56:16 2002 From: root at garbled.net (Tim Rightnour) Date: Thu Jan 13 18:02:08 2005 Subject: [CF-Devel] new quetzal (dragon) race In-Reply-To: <000001c1be86$37bf8d00$c86ebb81@gizmo> Message-ID: On 26-Feb-02 Andreas Vogl wrote: > The new quetzal cannot wear armour, nor weapons, > nor will it start with fire immunity. > But it makes up for it by "evolving": > Being dragons, they have a dragon skin which can evolve > to provide resistances. The quetzals must eat flesh-items > to gain resistance. The higher the resistance goes, > the higher must be both the player's level and the level > of the flesh-items to improve it further. The upper limit > is 95% resistance, which is of course hard to achieve. So.. if I get this right, you are taking away the ability to wear rings, amulets, and weapons, and giving the ability to very slowly gain resistances? As a player.. that doesn't seem very fun to me. I can run around at level 20, and buy a bunch of rings, and get some decent protection. I can grab a sword and get a little more. Chances are, with a slow moving resistance chart, you will be much less resistant by eating things than you would be just collecting objects and money. Why not make a better prize at the end? Like this: You "are" what you eat. If you eat lots of humanoids, you might become a draconian, gaining the ability to wield and wear some armor, but your max natural resistance maxes out at around 40. If you eat a cold resistance thing, you gain cold, but lose fire. If you get really high in something like fire, as you progress, you gain innate abilities, like dragon breath, or other dragon-like abilities. You essentially become more dragon-like. My idea is, that the Q starts out as a lowly snake, and has the ability to shape his destiny, coming up with all sorts of variations of what he could become in the end. This gives the player a reason to play the race. Gaining resistances is neat, but it sounds a little boring. If this is what you intended.. then I didn't get that from your original message. Either way.. making it not suck for the player is going to be difficult. --- Tim Rightnour NetBSD: Free multi-architecture OS http://www.netbsd.org/ NetBSD supported hardware database: http://mail-index.netbsd.org/cgi-bin/hw.cgi From andi.vogl at gmx.net Tue Feb 26 14:54:53 2002 From: andi.vogl at gmx.net (Andreas Vogl) Date: Thu Jan 13 18:02:08 2005 Subject: [CF-Devel] new quetzal (dragon) race In-Reply-To: <200202261845.g1QIj6s19038@tonks.EECS.Berkeley.EDU> Message-ID: <000001c1bf07$da5d52f0$c86ebb81@gizmo> in reply to Peter M.: > I don't see a compelling reason to modify the Quetzalcoatl instead > of creating another dragon player-race. Sorry but I really would like to use the Quetzal-race for this. My scheme ("dragon skin" and all that) is designed for dragons. And I don't want two dragon races that work *completely* different. May I suggest to move the old Quetzal-scheme to a different race instead? What about the ever-unuseable fireborn for example? Grant weapons to fireborns and that's it. Or why not create a completely new race with fire immu and no_armour (like the old Qetzal). Though, I want to note that the old Quetzal-scheme has serious problems because it cannot get a total level of resistances that other players can get. And the fire immu is often used for abusive purposes. I thought replacing it would be an improvement - but I have not problem with leaving it in the game in some way (just not as Quetzal/dragon - please). > This is reverse-compatible and extends the game rather than > mutating it, and possibly breaking someone's treasured characters. I guarantee you that my work is 100% reverse-compatible. Existing Q's of the old kind can continue to lead a happy life with my code checked in. > In terms of how to do it, I'd rather not see a lot of hard-wired > special purpose code having to do with dragons only implemented, > eg, when a DRAGON eats part of a FIRE ELEMENTAL'S RESIDUE, he > gains 5 points of fire immunity. The way I have planned and coded it, it is a unique race and therefore needs unique code. The dragon skin- and abilities work together and it doesn't make sense to reuse this for other races/classes. If I want to make general reusable code, I would need to do it completely different. I don't want to re-invent the skill system or rewrite file parsers. Doing it as I planned is already an immense load of work. I've coded it as general and expandable as I could so far. However, creating a feature like this without special code is an impossible task for me. Andreas From andi.vogl at gmx.net Tue Feb 26 15:32:01 2002 From: andi.vogl at gmx.net (Andreas Vogl) Date: Thu Jan 13 18:02:08 2005 Subject: [CF-Devel] new quetzal (dragon) race In-Reply-To: Message-ID: <000101c1bf0d$0a570640$c86ebb81@gizmo> in reply to garbled: > So.. if I get this right, you are taking away the ability to > wear rings, amulets, and weapons, and giving the ability to > very slowly gain resistances? Yes, indeed. But unlike the old quetzal, you have the chance to get real high resistances in the end. A Quetzal will no longer have a desire for weapons or armour, it would hunt monsters for their flesh. > As a player.. that doesn't seem very fun to me. I can run > around at level 20, and buy a bunch of rings, and get some > decent protection. I can grab a sword and get a little more. > Chances are, with a slow moving resistance chart, you > will be much less resistant by eating things than you would > be just collecting objects and money. In an ideal CF-world, hunting flesh would be as hard as hunting artifacts - with similar reward. Of course that's not easy to achieve, but I'll try. > Why not make a better prize at the end? Like this: > > You "are" what you eat. [...] This is pretty much how it works. You can control your character development by choosing your meals. > If you eat a cold resistance thing, you gain cold, but lose fire. Yes, it works just like that. Except you don't loose anything, because that proved frustrating and a lot more difficult to balance. > If you get really high in something like fire, as you > progress, you gain innate abilities, like dragon breath, > or other dragon-like abilities. You essentially become > more dragon-like. Yes, you will get lots of special abilities by focusing on a certain attacktype. If you focus on fire for a while, you will indeed get dragonbreath, added fire attack on your claws, and more. The longer you specialize, the more powerful stuff you can expect. Switching around bears other advantages, like getting more different attacktypes for example. (I've got all of this already working btw!) > My idea is, that the Q starts out as a lowly snake, and has > the ability to shape his destiny, coming up with all sorts of > variations of what he could become in the end. This gives the > player a reason to play the race. Yes, I've also planned face and title changes as the quetzal evolves and gains levels. You could start as "fire hatchling", become a "fire wyrm" later, and finally reach the state of an "ancient fire dragon". You could also switch to become an acid dragon or whatever. > Gaining resistances is neat, but it sounds a little boring. IMO, having 11 races which all act identical - *that* is *REALLY* boring! :-) If someone doesn't want to play dragon - fine, there are still going to be 10 other races to choose. > If this is what you intended.. then I didn't get that from > your original message. Either way.. making it not suck for > the player is going to be difficult. I can't and don't want to make a race which is better than anything ever seen. I just want to make a true alternative which is at least as much fun to play. Andreas From peterm at tonks.EECS.Berkeley.EDU Tue Feb 26 15:57:29 2002 From: peterm at tonks.EECS.Berkeley.EDU (Peter Mardahl) Date: Thu Jan 13 18:02:08 2005 Subject: [CF-Devel] new quetzal (dragon) race In-Reply-To: Your message of "Tue, 26 Feb 2002 21:54:53 +0100." <000001c1bf07$da5d52f0$c86ebb81@gizmo> Message-ID: <200202262157.g1QLvTS19411@tonks.EECS.Berkeley.EDU> > in reply to Peter M.: > > > I don't see a compelling reason to modify the Quetzalcoatl instead > > of creating another dragon player-race. > > Sorry but I really would like to use the Quetzal-race for this. > My scheme ("dragon skin" and all that) is designed for dragons. > And I don't want two dragon races that work *completely* different. Well, how about if you change the Quetzalcoatl image? It really ought to be a bird-snake image anyway. Just changing the image won't seriously affect anyone's gameplay. I really don't understand your objection to doing it this way, which lets you do what you want and preserves compatibility for the existing player base (such as it is.) > Though, I want to note that the old Quetzal-scheme has serious > problems because it cannot get a total level of resistances > that other players can get. Not every race has to be equal in potentiality to every other. It's perfectly fine to create races with handicaps, such as fireborn, Q's and Wraiths. It might piss some people off after they find out the ultimate price they paid for their early advantages, but that's the game. > I guarantee you that my work is 100% reverse-compatible. > Existing Q's of the old kind can continue to lead a happy > life with my code checked in. Well, OK, but I suggest creating a new race and perhaps changing the Q's bitmap, to avoid confusion. > The way I have planned and coded it, it is a unique race > and therefore needs unique code. The dragon skin- and abilities > work together and it doesn't make sense to reuse this for other > races/classes. > > If I want to make general reusable code, I would need to do it > completely different. I don't want to re-invent the skill system > or rewrite file parsers. Doing it as I planned is already > an immense load of work. Mmm, I was proposing extending the player-changer or perhaps the potions, and using map features to limit these to the target race(s). You're doing the coding, of course, so I won't speak too strongly about how it should be done. I have a strong preference for having a distinct Q and dragno race though, one which is the same as previously except perhaps the image, and one which is your new thing. A Quetzalcoatl really is *not* a dragon, I just liked that image, and it was sort of close, so I used it. PeterM From andi.vogl at gmx.net Tue Feb 26 17:23:22 2002 From: andi.vogl at gmx.net (Andreas Vogl) Date: Thu Jan 13 18:02:08 2005 Subject: [CF-Devel] new quetzal (dragon) race In-Reply-To: <200202262157.g1QLvTS19411@tonks.EECS.Berkeley.EDU> Message-ID: <000201c1bf1c$98a64eb0$c86ebb81@gizmo> in reply to Peter M.: > > Sorry but I really would like to use the Quetzal-race for this. > > My scheme ("dragon skin" and all that) is designed for dragons. > > And I don't want two dragon races that work *completely* different. > > Well, how about if you change the Quetzalcoatl image? It really > ought to be a bird-snake image anyway. Just changing the image > won't seriously affect anyone's gameplay. Hm okay, I can change the quetzal's image and the race (to animal, or reptile). Then call the new thing "dragon" directly and the old thing remains being called quetzal. Only problem: I need a new quetzal-image to do that. I would draw it if I could, but I'm afraid a birdlike snake is way byond my skills. > Not every race has to be equal in potentiality to > every other. It's perfectly fine to create races with handicaps, > such as fireborn, Q's and Wraiths. It might piss some people > off after they find out the ultimate price they paid for their > early advantages, but that's the game. What you say is true and I agree. But the bad thing about the old Quetzal is that players used it to run through certain fire-maps and grab a few artifacts for their other, "real" character. But okay, I admit it's not that critical. If I had an image for it, I'd do what you asked for. Andreas From dnh at hawthorn.csse.monash.edu.au Tue Feb 26 19:10:59 2002 From: dnh at hawthorn.csse.monash.edu.au (David Hurst) Date: Thu Jan 13 18:02:08 2005 Subject: [CF-Devel] town portal (RE: CVS commit: maps/city/misc) In-Reply-To: References: <3C98EC6E@MailAndNews.com> Message-ID: <20020227011059.GA29755@hawthorn.csse.monash.edu.au> > I suggested the void, because it's a specific solution to a specific problem, > one which was being abused on our mud, and looks to be abused on CF. If you > think about it, the portal is a kind of "cheat" for the player. He can avoid > things that he would normally have to encounter. The player is willing to risk > the void, in order to cheat past the rest of the maze. However, a normal > spell, like say meteor storm, is not a form of cheating, it's just a high level > mage causing lots of fire. The void is designed to balance the cheat out. I am guessing you don't get experience in the void? other wise ill be casting portals all day =) Also, is it just townportal? or word of recall too? I am just thinking perhaps the god can send some punishment. > I don't mind if you take a certain spell, and find a logical and just backfire > for it, on an individual basis. yeah this is true, it would get very tiresome if everyspell backfires etc at you. I'm sure alot of you have experienced low level casting of say fireball at monsters. It is extremely annoying to fail the spells, even if it only takes half your mana so much so that I sacrafice all my defense just to cast it properly. I also feel that right now Wizards are slightly underpowered compared to warriors (and usually priests). Because of the high rate of immunity in monsters the only spells which will generally kill a room are things like bomb, the rest just don't do any damage unless the monsters are vunerable. Either bomb is overpowered, or all other spells are underpowered it is food for thought. Think of the void as "a rift in space time > caused by the portal". But I think each spell should be evaluated one at a > time, and determined if it needs a backfire or not. I do not agree that we > should penalize spellcasters in general. indeed, I think we should make any spell cast by a player with the name 'red_blaze' to backfire and kill him. dnh> > As yourself, why is it that nobody runs the backfire code. :) > > --- > 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 yann.chachkoff at MailAndNews.com Wed Feb 27 02:00:27 2002 From: yann.chachkoff at MailAndNews.com (Yann Chachkoff) Date: Thu Jan 13 18:02:09 2005 Subject: [CF-Devel] town portal (RE: CVS commit: maps/city/misc) Message-ID: <3C9F3B7E@MailAndNews.com> >===== Original Message From Tim Rightnour ===== >On 26-Feb-02 Yann Chachkoff wrote: >> If I remember well, there was a crossfire compile-time option to activate >> "backfire effects" for failed spellcasting >Basically, here is the problem: > >Player A fights monster A: > >Monster A can fire lightning at the player all day long, with no fear. if the >monster dies, it doesn't care, it repops. > I suppose you imply that monsters got an infinite amount of mana. Did I ever said they should ? (Unless, of course, the spells are "natural abilities", like the dragon breath) >Player A however, has limited mana, and if it dies, it's a very upsetting >thing. The player has a spell which he painstakingly learned, and now >attempts to use against the monster trying to kill him. Oh look, he rolled >00, he just blew his arm off. > The backfire effect should of course be a function of the player and spell levels. I simply can't imagine why a player should be killed when missing a level 1 spell. Now, if the "painstakingly learned spell" is a difficult one (Very powerful spells like "Meteor Shower", "Resurrect" or "Chained Lightning"), I think it should be somewhat dangerous to cast. Note that I'm not the only one to think so - in many commercial RPGs, high level spellcasting is quite risky, and it does not seem to upset players at all. >This is just like critical hits/misses. Not really, as the critical hit/misses usually do not take the levels of the player and the attempt into account. Critical hits are usually triggered when you roll a special value on the dice (like 00 or 99). >I suggested the void, because it's a specific solution to a specific problem, >one which was being abused on our mud, and looks to be abused on CF. If you >think about it, the portal is a kind of "cheat" for the player. He can avoid >things that he would normally have to encounter. The player is willing to risk >the void, in order to cheat past the rest of the maze. However, a normal >spell, like say meteor storm, is not a form of cheating, it's just a high level >mage causing lots of fire. The void is designed to balance the cheat out. > I do not understand how Town Portal could be used as a cheat to pass over a whole maze, since the player needs to reach the end of it to cast the Portal. Now I admit that the Town Portal offers the opportunity of a "convenient escape" - but that's also the case for Word of Recall and, to a lesser extend, for Dimension Door and Amulets of LifeSaving. Should we consider them as "cheats" also ? >I don't mind if you take a certain spell, and find a logical and just backfire >for it, on an individual basis. Think of the void as "a rift in space time >caused by the portal". But I think each spell should be evaluated one at a >time, and determined if it needs a backfire or not. I do not agree that we >should penalize spellcasters in general. > I am not opposed to the idea of binding specific effects to specific spells. However, I think the problem is more general than just an unbalanced spell. What about spells like Word of Recall, Holy Word, Burning Hands, Create Bomb, Summon Avatar, Sanctuary, Restoration for example ? Should we also apply a specific solution to each of those ? >As yourself, why is it that nobody runs the backfire code. :) > Maybe that's because the option is disabled by default and most people never change anything in the configure file ? And, as I said, I do not think we should retake the current system as it is - but using it as a workbasis for a more general and flexible system. ------------------------------------------------ Visit http://www.chachkoff.pronym.org for a journey into a fantastic world ! (But don't expect too much...) GPG: http://www.chachkoff.pronym.org/gros.pub ------------------------------------------------ From root at garbled.net Wed Feb 27 02:57:05 2002 From: root at garbled.net (Tim Rightnour) Date: Thu Jan 13 18:02:09 2005 Subject: [CF-Devel] town portal (RE: CVS commit: maps/city/misc) In-Reply-To: <3C9F3B7E@MailAndNews.com> Message-ID: On 27-Feb-02 Yann Chachkoff wrote: > I suppose you imply that monsters got an infinite amount of mana. Did I ever > said they should ? (Unless, of course, the spells are "natural abilities", > like the dragon breath) No. I imply that monsters are infinite, and don't care if you kill them. Players however, have feelings, and frustration, and tend to react poorly when they think you've made something un-fun for them. Making all the cool spells backfire, does indeed accomplish what you might desire. The spells become uncool. Nobody likes to use them anymore. Look at scrolls and wands. Nobody uses them, they are neat, and they are there, but they have no advantage to players. When I said that each spell should be considered and tuned for specifically.. what I meant is, we should decide if the spell is really that bad after all, and if we will make the game less fun by removing it, because thats what you essentially do when you add a drawback. The players learn quick. "Don't cast that spell, it will blow your arm off", turns into "don't bother learning that, it's useless" and "it's too bad they ruined that spell". I realize everyone has thier balance issues, and it's a very complex thing to wrap your head around completely. But if I learned one thing from running a mud for so long, it's that players hate balance. And far far more than they hate balance, they hate it when you change the way something they've done for years works. All these things that we are encountering now... I encountered on the mud. And I implemented systems very similar to the one you are proposing.. and I regretted it, sourly. I'm just trying to pass what I learned along. It's just MHO, so, take it for what it's worth. --- Tim Rightnour NetBSD: Free multi-architecture OS http://www.netbsd.org/ NetBSD supported hardware database: http://mail-index.netbsd.org/cgi-bin/hw.cgi From dnh at hawthorn.csse.monash.edu.au Wed Feb 27 08:32:01 2002 From: dnh at hawthorn.csse.monash.edu.au (David Hurst) Date: Thu Jan 13 18:02:09 2005 Subject: [CF-Devel] town portal (RE: CVS commit: maps/city/misc) In-Reply-To: <3C9F3B7E@MailAndNews.com> References: <3C9F3B7E@MailAndNews.com> Message-ID: <20020227143201.GA26769@hawthorn.csse.monash.edu.au> > I do not understand how Town Portal could be used as a cheat to pass over a > whole maze, since the player needs to reach the end of it to cast the Portal. > Now I admit that the Town Portal offers the opportunity of a "convenient > escape" - but that's also the case for Word of Recall and, to a lesser extend, > for Dimension Door and Amulets of LifeSaving. Should we consider them as > "cheats" also ? The problem is, after going through a town portal, you can then go straight back throught it again. This mean.. you can go into the portal, fire a whole heap of spells, go back out it again.. cast healing spells, use a mana crystal in the powerhouse, and cast spells again. Basically like a portable set of stairs that you can create which have a healing and recharge centre just threw it. No other spell allows this. Word of recall does pose a problem, that is why there are so many no cast spell zones, because you can save inside a treasure chamber and get double the treasure. This isn't an issue for town portal because you need to place the end, but it does allow players to go into a treasure chamber, town portal, WoR out, completel town portal, go do other maps, go back through portal and finally save. Next reset collect treasure and repeat. I'm sure you get the picture, the reason this whole debate started was because people are abusing the powerhouse with town portals. The simple solution to this would be to make the powerhouse no magic zone. Mark pointed out that a portal could be made anywhere near by and this would still be a problem (all those less of one), feel free to come up with a solution =). dnh From andi.vogl at gmx.net Wed Feb 27 09:00:10 2002 From: andi.vogl at gmx.net (Andreas Vogl) Date: Thu Jan 13 18:02:09 2005 Subject: [CF-Devel] new quetzal (dragon) race In-Reply-To: <200202262338.g1QNcoD19653@tonks.EECS.Berkeley.EDU> Message-ID: <000001c1bf9f$7458b380$c86ebb81@gizmo> in reply to Peter M.: > > An easy way is to just color the image differently. Even > a poor artist (such as myself) can do that much. What I'll do is take the quetzal-image from alternate set. It's a bit flat but will do till someone cares to draw a better image. The dragon player will now start out titled "fire hatchling". The quetzal remains, only with different image, race reptile and slightly modified description message. Okay, I hope with this I've got the general blessing for commiting. :-) I've got the basic code done and tested (as far as I can). I'd like to wait to have the current memory leak issue resolved before my commit. But on the other hand I don't wanna wait too long, as with every cvs change it becomes harder for me to merge in my patch. So please expect me to commit my patch somewhere during the next days. If anyone still has objections, please don't wait and tell me now. Andreas From leaf at real-time.com Wed Feb 27 12:58:06 2002 From: leaf at real-time.com (Rick Tanner) Date: Thu Jan 13 18:02:09 2005 Subject: Void idea, was Re: [CF-Devel] town portal (RE: CVS commit: maps/city/misc) In-Reply-To: Message-ID: Using this post and the discussion (on IRC) on what kind of monster and room layout the void should consist of (if this idea is implemented..) What about the a map similar to the final gate in the Gates of Hell quest (the Palace in Britany/Brest) ? You have the Balrog (Jessy?) demon in a room blasting you with spells and you have to either kill the demon or out maneuver it to pull the levers to get the key and then get out. - Rick Tanner On Mon, 25 Feb 2002, Tim Rightnour wrote: > We called it the void. When you stepped into the portal, there was a > percentage change (like 5) that you would get dumped into the void. The void, > was a no-magic, silent room (cant shout or speak). In there lived a > particularly nasty creature, who was horribly aggressive, and incredibly > dangerous to even top-level players. > > What this caused, was that players used portals more gingerly. Only when they > absolutely needed to. They didn't use them willy-nilly, knowing that a very > bad thing could happen if they did hit the void. From dnh at hawthorn.csse.monash.edu.au Wed Feb 27 14:38:35 2002 From: dnh at hawthorn.csse.monash.edu.au (David Hurst) Date: Thu Jan 13 18:02:09 2005 Subject: [CF-Devel] new quetzal (dragon) race In-Reply-To: <000001c1bf9f$7458b380$c86ebb81@gizmo> References: <200202262338.g1QNcoD19653@tonks.EECS.Berkeley.EDU> <000001c1bf9f$7458b380$c86ebb81@gizmo> Message-ID: <20020227203835.GA19384@hawthorn.csse.monash.edu.au> > What I'll do is take the quetzal-image from alternate set. > It's a bit flat but will do till someone cares to draw > a better image. I mentioned to AV I might be able to help here, so probably there will at least be a new image for both sets. > The dragon player will now start out titled "fire hatchling". > The quetzal remains, only with different image, race reptile > and slightly modified description message. I am confused with naming, which is the new race? the fire hatchling.. something which you would expect starts with 100 fire resistance etc etc. Or the Q? Which IMHO is an even better plan for the Q than the old one simply because a Q is a very strange creature, and AV's idea sorta fits better =). My feelings. dnh > Okay, I hope with this I've got the general blessing for > commiting. :-) > > I've got the basic code done and tested (as far as I can). > I'd like to wait to have the current memory leak issue > resolved before my commit. But on the other hand I don't wanna > wait too long, as with every cvs change it becomes harder for > me to merge in my patch. > > So please expect me to commit my patch somewhere during the > next days. If anyone still has objections, please don't wait > and tell me now. > > > Andreas > > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > From mwedel at sonic.net Thu Feb 28 00:24:28 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:09 2005 Subject: [CF-Devel] town portal (RE: CVS commit: maps/city/misc) References: Message-ID: <3C7DCD1C.2EB38B5D@sonic.net> As said, town portal is the worst abuse because it allows you to return to just where you were. Word of recall isn't quite so bad - there is some delay factor before you get out (so you can't reliably use it if your about to die). Plus, it puts you back at your savebed (I should note this used to be the city map - now that it is the savebed, it becomes a little more of an abuse (Because you can arrange that savebed closer to where your actually adventuring). Actually doing backfiring depends on the chances of it happening and the effects. If the failure just happens to be that it uses the standard amount of mana and doesn't do anything, that doesn't do anything. If it does something that may kill the character, then I agree with garbled that that won't be something very popular (would you use something that has a 1% chance to kill you? Probably only in an emergency). One of the problems with the spell failure as currently done just isn't that good - I seem to recall that it basically takes spell level vs caster level - thus, low level characters fail much more often, high level characters can cast the lower level spells quite easily. I think the approach of balancing the spells that are overpowering is the way to go. For town portal, that may become something like the void theory (there isn't that many alternative). For spells that due damage, it may be tuning the damage or upping the mana cost. Its unclear to me if some spells are greatly suprerior, or it is more that some spells just work really well against some monsters due to those monsters resistances. If thats the case, I'm not really sure if thats much a bug - it sounds more like people have just identified the right spells for the job. It should be noted that some spells will always be better than other, so fixing the most powerful spell all the time probably isn't the right approach. What is a problem is if there are spells that are universally the best to use (eg, learn this spell and you don't need anything else). The right thing is that 'use this spell against zyx, this spell against abc, etc'. From henric at lysator.liu.se Thu Feb 28 06:01:53 2002 From: henric at lysator.liu.se (Henric Karlsson) Date: Thu Jan 13 18:02:09 2005 Subject: [CF-Devel] memory leak In-Reply-To: <20020226124804.GA32578@mids.student.utwente.nl> Message-ID: I ran purify on the latest cvs server but couldn't find any big leaks. purifylog can be found at www.lysator.liu.se/~henric/crossfire/crossfire.plog This is what I tested: ------------------- started server. loged in killed trolls + dread in raffle2 summoned monster (got belzebub) killed demons + dragon in well in dragonmountains.. saved and exited. ------------------- Do you have any more specific hints on what to test? I compiled the server on solaris 2.7 with only default options. /Henric (Gambold) On Tue, 26 Feb 2002, Joris Bontje wrote: > Latest CVS version of crossfire seems to have a big memory leak > > Regards, > Joris Bontje / mids > -- > Gpg Key: Id=0xF19326A9 / http://mids.student.utwente.nl/~mids/jbontje.pub > Key fingerprint = 730D 9B3A F406 F28A 957D 6397 31E8 6D4C F193 26A9 > From jbontje at suespammers.org Thu Feb 28 06:38:05 2002 From: jbontje at suespammers.org (Joris Bontje) Date: Thu Jan 13 18:02:09 2005 Subject: [CF-Devel] memory leak In-Reply-To: References: <20020226124804.GA32578@mids.student.utwente.nl> Message-ID: <20020228123805.GA12430@mids.student.utwente.nl> On Thu, Feb 28, 2002 at 01:01:53PM +0100, Henric Karlsson wrote: > > I ran purify on the latest cvs server but couldn't find any big leaks. > purifylog can be found at > www.lysator.liu.se/~henric/crossfire/crossfire.plog > > [cut] > > Do you have any more specific hints on what to test? > I compiled the server on solaris 2.7 with only default options. It seemed that the leak was cause because the archfiles werent collected in a right way. gros fixed that, so the problem is solved Regards, Joris Bontje / mids -- Gpg Key: Id=0xF19326A9 / http://mids.student.utwente.nl/~mids/jbontje.pub Key fingerprint = 730D 9B3A F406 F28A 957D 6397 31E8 6D4C F193 26A9 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 240 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20020228/da64e54f/attachment.pgp From andi.vogl at gmx.net Thu Feb 28 08:11:57 2002 From: andi.vogl at gmx.net (Andreas Vogl) Date: Thu Jan 13 18:02:09 2005 Subject: [CF-Devel] town portal (RE: CVS commit: maps/city/misc) In-Reply-To: <3C7DCD1C.2EB38B5D@sonic.net> Message-ID: <001601c1c061$e549bc20$c86ebb81@gizmo> in reply to Mark W.: > As said, town portal is the worst abuse because it allows > you to return to just where you were. Yes, I think the void idea is really a good solution (and eventually a spellblocker thing on some maps later). > Word of recall isn't quite so bad - there is some delay > factor before you get out (so you can't reliably use it > if your about to die). WoR is quite okay. It effectively means quitting your dungeon-quest and often it is hard to get back in. Besides, we shouldn't forget that there are quite a few badly-designed maps which trap players frequently. The abuse-potential of Town Portal is a lot bigger than from WoR. In fact, the two have little in common IMO. > Actually doing backfiring depends on the chances of it > happening and the effects. [...] Somehow I agree to what Mark (and others) said here. Adjusting spell damage and monster resistance is probably a better approach than backfires for attack spells. Andreas From root at garbled.net Thu Feb 28 09:41:10 2002 From: root at garbled.net (Tim Rightnour) Date: Thu Jan 13 18:02:09 2005 Subject: [CF-Devel] town portal (RE: CVS commit: maps/city/misc) In-Reply-To: <001601c1c061$e549bc20$c86ebb81@gizmo> Message-ID: On 28-Feb-02 Andreas Vogl wrote: > Somehow I agree to what Mark (and others) said here. > Adjusting spell damage and monster resistance is probably > a better approach than backfires for attack spells. However, worth noting, I don't object to "cute" backfires on spell failure. Like a 5% chance of a failure causing a cute side effect to occur might be fun. When I say cute though, I mean silly things, like summoning a chicken, or turning wine into water. Nothing that affects the player adversly. The idea being not to deter using spells, but make them a little more colorful. It should only happen on normal failure though, not increase the chances for failure. If there are spells people feel are too powerful, we should get a list going, identify what makes them so powerful, and tune them down. As for WOR, there are potential abuses for it, but more importantly, it's a very vital spell. When I start playing, and explore maps, I allways take a scroll with me, so if I get myself in too deep, or end up trapped, I can bail in a hurry. Any newbie who has played a mud/moria knows that a WOR can save your hide. I would go as far to say, we should give one as starting equipment to every new player. --- Tim Rightnour NetBSD: Free multi-architecture OS http://www.netbsd.org/ NetBSD supported hardware database: http://mail-index.netbsd.org/cgi-bin/hw.cgi From henric at lysator.liu.se Thu Feb 28 10:55:53 2002 From: henric at lysator.liu.se (Henric Karlsson) Date: Thu Jan 13 18:02:09 2005 Subject: [CF-Devel] town portal (RE: CVS commit: maps/city/misc) In-Reply-To: Message-ID: A few thougts on the subject. Mostle tweaks of already presented ideas. * town portal abuse This spell is indeed being abused and the void idea sounds like a good solution *IF* void does not mean an instant death. The void should be some place where it's possible to take coverage (at least when you enter the map), and spells and prayers should be allowed, how should a priest or mage survive otherwise? This probably means that WoR alone has to be blocked (so you can't make an easy escape) To make void a challenge even to high lvl players, there should probably be several instances of void with different difficulties depending on the level of the player using the portal. (easy way is to make different monsters I guess. Protector of Void?) * spell backfire When I think of a spell backfire, some kind of random side effect comes to mind, like wand of wonder. One idea would be to replace the normal spell effect with a random spell. This could be both good or bad depending on what actually happens. Maybe use some extra spell points as well. In most cases however changing the effect of the spell usually makes it worse than the original spell (otherwise the player would have chosen this new spell in the first place, right) /Henric (Gambold) From reeve at ductape.net Thu Feb 28 12:23:54 2002 From: reeve at ductape.net (Scott Barnes) Date: Thu Jan 13 18:02:09 2005 Subject: [CF-Devel] town portal (RE: CVS commit: maps/city/misc) In-Reply-To: References: Message-ID: <1014920636.8091.3.camel@terra.localnet> On Thu, 2002-02-28 at 11:55, Henric Karlsson wrote: > > A few thougts on the subject. > Mostle tweaks of already presented ideas. > > > * town portal abuse > This spell is indeed being abused and the void idea sounds like a good > solution *IF* void does not mean an instant death. The void should be some > place where it's possible to take coverage (at least when you enter the > map), and spells and prayers should be allowed, how should a priest or > mage survive otherwise? This probably means that WoR alone has to be > blocked (so you can't make an easy escape) > > To make void a challenge even to high lvl players, there should probably > be several instances of void with different difficulties depending on the > level of the player using the portal. (easy way is to make different > monsters I guess. Protector of Void?) I still think it should bring them to the "alternate reality" of one of the gods, and they could have a quest to accomplish before the god will release them. > > > * spell backfire > When I think of a spell backfire, some kind of random side effect comes to > mind, like wand of wonder. One idea would be to replace the normal spell > effect with a random spell. This could be both good or bad depending on > what actually happens. Maybe use some extra spell points as well. > In most cases however changing the effect of the spell usually makes it > worse than the original spell (otherwise the player would have chosen this > new spell in the first place, right) I definately agree on this one. Just make the backfire effect completely random for attack spells. > > > /Henric (Gambold) > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel -- -- -- Reeve the cat ----BEGIN FORTUNE---- You had mail. Paul read it, so ask him what it said. ----END FORTUNE---- -----BEGIN GEEK CODE BLOCK----- Version: 3.12 GCS d? s: a? C++++ UL++++ P+ L++++ E- W++ N o K- w--- O M-- V-- PS+++ PE Y PGP t+++ 5 X+ R+++ tv+ b+++ DI++ D+ G e* h-- r+++ y** ------END GEEK CODE BLOCK------ From andi.vogl at gmx.net Thu Feb 28 17:47:27 2002 From: andi.vogl at gmx.net (Andreas Vogl) Date: Thu Jan 13 18:02:09 2005 Subject: [CF-Devel] start equipment (RE: town portal) In-Reply-To: Message-ID: <000001c1c0b2$4aa84d20$c86ebb81@gizmo> garbled wrote: > As for WOR, [...] it's a very vital spell. [...] I would > go as far to say, we should give one as starting equipment > to every new player. Funny, while meddling with dragon race, I also had the feeling it might be good to extend the starting equipment a bit. I guess most of us will agree that newbies have a bit too much of a hard start. My proposion for additional start equipment (for all races): - An "apple of life", being a potion of life in fact. (Description message contains hint about potions of life and what they do.) - A balm of travelling (WoR, balms never fail - that's important for newbies). - A decent bunch of lightweight food. Removing the infinit food auto-generation on HallOfSelection map (it gets heavily abused for earning money). All of these will have "startequip 1" set, hence vanish when dropped. I believe these items would not only help newbies directly, they also help them understand how WoR and death-restoration works. And all this would be very simple to realize. Andreas From dnh at hawthorn.csse.monash.edu.au Thu Feb 28 18:02:17 2002 From: dnh at hawthorn.csse.monash.edu.au (David Hurst) Date: Thu Jan 13 18:02:09 2005 Subject: [CF-Devel] town portal (RE: CVS commit: maps/city/misc) In-Reply-To: References: Message-ID: <20020301000217.GA16860@hawthorn.csse.monash.edu.au> Is it just me.. or does the name 'Protector of void' sound particularly silly? I thought the Void was nothingness, why would you bother protecting it, and if you did, it wouldn't be a void anymore would it? come to think of it, if you got sent to the void.. well that's a contradiction because when you get there, it isn't the void anymore ;) dnh From leaf at real-time.com Wed Feb 20 17:37:04 2002 From: leaf at real-time.com (Rick Tanner) Date: Thu Jan 13 18:04:09 2005 Subject: [CF List] metalforge server - scheduled downtime Message-ID: The Metalforge server (metalforge.real-time.com, 65.193.17.234) will be offline on Thursday (21-Feb-2002) starting at 4pm GMT until sometime around 10pm GMT for server upgrades Why so long? It's not exactly the "fastest" box ;) - Rick Tanner leaf@real-time.com --