From crossfire-devel-admin at archives.real-time.com Mon Sep 1 09:45:24 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:55:00 2005 Subject: [CF-Devel] Patch for runes not in CVS? In-Reply-To: <3F4CD1C7.7060606@laposte.net> References: <3F4CD1C7.7060606@laposte.net> Message-ID: <200309011645.29452.tchize@myrealbox.com> Le Mercredi 27 Ao?t 2003 17:44, Nicolas Weeger a ?crit : > Hello. > I submitted on 28 july a patch for rune.c, to display the name of the > rune the player fails to/successfully disarms. > > But it seems to not have been included in CVS. > Is it because no one committed it, or it's not enough interesting? > > Nicolas 'Ryo' > > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel done now. Thanks for reminding. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20030901/743ff17c/attachment.pgp From crossfire-devel-admin at archives.real-time.com Mon Sep 1 07:14:36 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:55:01 2005 Subject: [CF-Devel] Make fail Crossfire 1.5.0 In-Reply-To: <000001c36e26$d20b3bb0$b2b407d5@traitor> References: <000001c36e26$d20b3bb0$b2b407d5@traitor> Message-ID: <200309011414.42260.tchize@myrealbox.com> Le Vendredi 29 Ao?t 2003 14:12, Holger Erck a ?crit : > Hi > > I got a little bug for you > OpenBSD 3.3/I386(Duron750) > > Configure exited with error code 0 but make wasn't: > > > Making all in common > Making all in random_maps > Making all in socket > Making all in server > source='plugins.c' object='plugins.o' libtool=no > depfile='.deps/plugins.Po' tmpdepfile='.deps/plugins.TPo' depmode=gcc > /bin/sh ../utils/depcomp gcc -DHAVE_CONFIG_H -I. -I. -I../include > -I../include -DDATADIR=\"/usr/games/crossfire/share/crossfire\" > -DCONFDIR=\"/usr/games/crossfire/etc/crossfire\" > -DLIBDIR=\"/usr/games/crossfire/lib/crossfire\" > -DLOCALDIR=\"/usr/games/crossfire/var/crossfire\" > -DPLUGIN_SUFFIX=\".so\" -g -O2 -c `test -f 'plugins.c' || echo > './'`plugins.c > *** Error code 1 > > Stop in /usr/games/crossfire-1.5.0/server. > *** Error code 1 > > Stop in /usr/games/crossfire-1.5.0 (line 187 of Makefile). > > > plugins.c: In function 'initOnePlugin': > plugins.c:499 RTLD_NOW undeclared (first use of the function) > plugins.c:499 (Each undeclared identifier is reported only once > plugins.c:499 for each function it appears in.) > plugins.c:499 RTLD_GLOBAL undeclared (first use of the function) > > Greetings, Holger Erck a ld library problem? may be gros can fix it. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20030901/cd54284b/attachment.pgp From crossfire-devel-admin at archives.real-time.com Mon Sep 1 13:44:27 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:55:01 2005 Subject: [CF-Devel] Bigworldized Pupland [repost from -maps] Message-ID: <20030901184427.GD1546@laranja.org> (personally I think crossfire-maps is the proper place for this, but since there was no response there, someone on IRC suggested I tried -dev) I have a few maps that put Pupland into the Bigworld. I didn't want to warp existing Bigworld geography too much, so I ended up changing the layout a bit but I really, really like the results. I have "mainland" ready, the islands are edited but I need to fix the exits. I will post the entire thing as a diff once I'm done. In the meanwhile, if someone experienced wants to review it, I'd be very happy. (In case you're wondering, I solved the problem of people entering trough the east road without having been in Lone Town first, by the simple expedient of adding a second barrier station. So if you have a passport, it *is* reachable from land now.) []s, |alo +---- -- Those who trade freedom for security lose both and deserve neither. -- http://www.laranja.org/ mailto:lalo@laranja.org pgp key: http://www.laranja.org/pessoal/pgp Eu jogo RPG! (I play RPG) http://www.eujogorpg.com.br/ GNU: never give up freedom http://www.gnu.org/ _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Mon Sep 1 14:42:46 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:55:01 2005 Subject: [CF-Devel] Patch submission, round 2: item renaming. In-Reply-To: <3F4FCEFF.8020606@laposte.net> References: <3F4FCEFF.8020606@laposte.net> Message-ID: <3F53A136.9090608@sonic.net> Nicolas Weeger wrote: > Hello everyone. > > I fixed (at least I think :-) my item renaming patch to prevent buffer > overflows. > > Here's the patch. (sending as many small gzipped files, smack me if you > prefer one file...) smack smack. A single patch file is preferable - much easier to just do a patch .. once, vs a bunch of different patch commands. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Mon Sep 1 14:46:49 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:55:01 2005 Subject: [CF-Devel] client gizmos In-Reply-To: <1062281829.6996.9.camel@oberon.Kameria> References: <1062281829.6996.9.camel@oberon.Kameria> Message-ID: <3F53A229.7010104@sonic.net> Todd Mitchell wrote: > I think the gcfclient should have some indicators/toggle buttons(in the > stats window?) - specifically I have in mind one for braced and one for > peaceful. Aside from making the toggle buttons what would this require? A mechanism for the server to send the status back to the client (some form of protocol command). There are probably bits that should do this but don't right now - I'm thinking the newpickup stuff - the client tracks what it is doing on its own, but doesn't have any idea of it gets changed through player interaction, or if you load up a character, doesn't know those settings. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Mon Sep 1 15:28:01 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:55:01 2005 Subject: [CF-Devel] Make fail Crossfire 1.5.0 In-Reply-To: <000001c36e26$d20b3bb0$b2b407d5@traitor> References: <000001c36e26$d20b3bb0$b2b407d5@traitor> Message-ID: <3F53ABD1.307@sonic.net> Holger Erck wrote: > > plugins.c: In function ?initOnePlugin?: > > plugins.c:499 RTLD_NOW undeclared (first use of the function) > > plugins.c:499 (Each undeclared identifier is reported only once > > plugins.c:499 for each function it appears in.) > > plugins.c:499 RTLD_GLOBAL undeclared (first use of the function) Looking at the openbsd man page http://tinyurl.com/lvza, suggest that openbsd doesn't have those two values define in dlfcn.h (or anyplace else, but the dlopen manpage isn't very good). You could try changing that line to just not pass those values and see if it works - if so, then we at least know the 'fix', and can work on putting a change in the code. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Mon Sep 1 15:28:01 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:55:01 2005 Subject: [CF-Devel] Make fail Crossfire 1.5.0 In-Reply-To: <000001c36e26$d20b3bb0$b2b407d5@traitor> References: <000001c36e26$d20b3bb0$b2b407d5@traitor> Message-ID: <3F53ABD1.307@sonic.net> Holger Erck wrote: > > plugins.c: In function ?initOnePlugin?: > > plugins.c:499 RTLD_NOW undeclared (first use of the function) > > plugins.c:499 (Each undeclared identifier is reported only once > > plugins.c:499 for each function it appears in.) > > plugins.c:499 RTLD_GLOBAL undeclared (first use of the function) Looking at the openbsd man page http://tinyurl.com/lvza, suggest that openbsd doesn't have those two values define in dlfcn.h (or anyplace else, but the dlopen manpage isn't very good). You could try changing that line to just not pass those values and see if it works - if so, then we at least know the 'fix', and can work on putting a change in the code. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Mon Sep 1 15:51:45 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:55:01 2005 Subject: [CF-Devel] Patch submission, round 3: item renaming Message-ID: <3F53B161.1010804@laposte.net> As per Mark's request, here's my item renaming patch in one big file. The 'rename' file is simply the help file for the command itself, so i did NOT do a diff with the previous non-existant version.... Sorry if i'm polluting the list with those patches :-) Nicolas 'Ryo' -------------- next part -------------- Changes the custom name of an item. Syntax: rename to (Note: <> are mandatory) If '' is omitted, defaults to marked item. If 'to ' is omitted, clears the custom name. Note: maximum allowed name length is 127 characters. -------------- next part -------------- A non-text attachment was scrubbed... Name: rename.patch.gz Type: application/x-gzip Size: 3239 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20030901/fffcc659/rename.patch.bin From crossfire-devel-admin at archives.real-time.com Mon Sep 1 22:05:39 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:55:01 2005 Subject: [CF-Devel] trap patch Message-ID: <1062471938.557.35.camel@oberon.Kameria> I made a patch for RUNES and traps which make a finer distinction between the two and allows traps to have a connect field for triggering things (like fireballs or pits or magic mouths or whatever) I made a new type: TRAP 155 and added a simple check so if the trap is detonated and is a connected object it will trigger the connected object. In splitting traps from Runes more I also made traps (not Runes) not effected by dispel or counterspell and not more visible by detect magic. Basically this makes find and remove traps a bit more important. I wanted to make more seperation betwwen the magical and non magical traps so traps would be more mechanical and traplike (you trigger a bunch of lightning bolts or a monster cage opening) and Runes would be more magical (set spell and direction). There are some places where I copied out some case statements and stuff because these two objects may diverge even more in the future (If I can help it anyway...) I also made the appropriate changes to the java editor and the arches (changed the type for existing traps, made a trap.arc and a icon) so if this is acceptable I will update these. -------------- next part -------------- A non-text attachment was scrubbed... Name: trap.patch Type: text/x-patch Size: 8940 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20030901/bbcbcc2f/trap.bin From crossfire-devel-admin at archives.real-time.com Wed Sep 3 07:57:33 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:55:01 2005 Subject: [CF-Devel] new generator code Message-ID: <200309031457.40195.d.delbecq@laposte.net> I just added a modification to generator code in CVS. To be short, here is first a cut&paste from modified Objects file in Doc/ directory -- There are 2 types of generators in crossfire since september 2003. both are identified as generators by setting the flag "generate" to 1. For the first type (the classical one) use "other_arch" to specify archetype of object to be spawned. The second type allow more fine tuning on what to generate. To activate second type, set the flag "use_content_on_gen" to 1. Then each time something must be generated, it will be a copy of a randomly choosen item in the generator's inventory. -- Then here is additionnal informations before a bunch of questions comes to mailing list 1) For technical informations: At map load time, when a generator with use_content_on_gen flag set is found, all items in its inventory are recursively flaged with FLAG_IS_A_TEMPLATE (flag which is not saved in map). This flag is used cause even if a living creature is in the generator (a 'super kobold' or a 'worthless ant' or anything else) it has no reason to live yet. Also at some places, the randomitems part of monster is converted to a monster inventory. This is done early at map loading time. However if the FLAG_IS_A_TEMPLATE is set, it won't be converted early. When the monster is spawned as a copy of the template in generator's inventory, FLAG_IS_A_TEMPLATE is cleared recursively so the monster can start to live and randomitems is evaluated. So if a monster is in generator's inventory has randomitems, each generated monster can has different randomitems (according to classical randomitems evaluation rules). Also objects with FLAG_IS_A_TEMPLATE set are not dropped on floor when generator is destroyed. -- 2) The needed example. The following example extracted from a test map shows ho to create a generator (using the mouse hole generator as basis) which generate randomly a chicken, a sheep or a goose. The chicken, sheep and goose have been modified in map so the chicken will generate dragonpart (chicken steak, chicken wings, aso), the sheep will generate shheps parts and the goose will generate bear parts. This is stupid but is just an example. Also chickens generated have a higher speed and are called 'super chickens' (please note by default the arch generate_mouse already have "generator 1" so it's not re-written in map file) ... arch generate_mouse use_content_on_gen 1 x 9 y 4 arch chicken name super chicken randomitems dragon_parts speed 1.0 end arch goose randomitems bear_parts end arch sheep randomitems sheep end end ... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20030903/61ee0349/attachment.pgp From crossfire-devel-admin at archives.real-time.com Wed Sep 3 07:59:24 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:55:01 2005 Subject: [CF-Devel] new generator code Message-ID: <200309031457.40195.d.delbecq@laposte.net> Skipped content of type multipart/mixed-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20030903/61ee0349/attachment-0002.pgp From crossfire-devel-admin at archives.real-time.com Wed Sep 3 09:00:12 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:55:02 2005 Subject: [CF-Devel] Patch submission, round 3: item renaming In-Reply-To: <3F53B161.1010804@laposte.net> References: <3F53B161.1010804@laposte.net> Message-ID: <200309031600.25617.tchize@myrealbox.com> A non-text attachment was scrubbed... Name: not available Type: application/pgp-encrypted Size: 11 bytes Desc: version code Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20030903/badb04a9/attachment.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: msg.asc Type: application/octet-stream Size: 2094 bytes Desc: encrypted data Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20030903/badb04a9/msg.obj From crossfire-devel-admin at archives.real-time.com Wed Sep 3 09:07:38 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:55:02 2005 Subject: [CF-Devel] Patch submission, round 3: item renaming In-Reply-To: <3F53B161.1010804@laposte.net> References: <3F53B161.1010804@laposte.net> Message-ID: <200309031607.39185.tchize@myrealbox.com> Le Lundi 01 Septembre 2003 22:51, Nicolas Weeger a ?crit : > As per Mark's request, here's my item renaming patch in one big file. > The 'rename' file is simply the help file for the command itself, so i > did NOT do a diff with the previous non-existant version.... > > Sorry if i'm polluting the list with those patches :-) > > Nicolas 'Ryo' commited (sorry for other crypted mail, manipulation error) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20030903/ced6deb5/attachment.pgp From crossfire-devel-admin at archives.real-time.com Wed Sep 3 09:03:32 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:55:02 2005 Subject: [CF-Devel] Patch submission, round 3: item renaming In-Reply-To: <200309031607.39185.tchize@myrealbox.com> References: <3F53B161.1010804@laposte.net> <200309031607.39185.tchize@myrealbox.com> Message-ID: <3F55F4B4.7060809@laposte.net> tchize wrote: >commited > >(sorry for other crypted mail, manipulation error) > > Hum, I hope you at least tried to compile it under Linux ^.^;;;;; It does work under Windows, and I don't think I use any specific function, but still... BTW i realized after submitting that you can't use : in custom name... Anyone think that's a trouble? Thanks anyway Nicolas 'Ryo' _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Wed Sep 3 10:21:46 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:55:02 2005 Subject: [CF-Devel] Patch submission, round 3: item renaming In-Reply-To: <3F55F4B4.7060809@laposte.net> References: <3F53B161.1010804@laposte.net> <200309031607.39185.tchize@myrealbox.com> <3F55F4B4.7060809@laposte.net> Message-ID: <200309031721.49792.tchize@myrealbox.com> Le Mercredi 03 Septembre 2003 16:03, Nicolas Weeger a ?crit : > tchize wrote: > >commited > > > >(sorry for other crypted mail, manipulation error) > > Hum, I hope you at least tried to compile it under Linux ^.^;;;;; Yeah, and i even compiled and run it! > It does work under Windows, and I don't think I use any specific > function, but still... > > BTW i realized after submitting that you can't use : in custom name... > Anyone think that's a trouble? > Didn't help file say only alphanum and space allowed only? > Thanks anyway > Nicolas 'Ryo' > > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Wed Sep 3 10:33:30 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:55:02 2005 Subject: [CF-Devel] Patch submission, round 3: item renaming In-Reply-To: <200309031721.49792.tchize@myrealbox.com> References: <3F53B161.1010804@laposte.net> <200309031607.39185.tchize@myrealbox.com> <3F55F4B4.7060809@laposte.net> <200309031721.49792.tchize@myrealbox.com> Message-ID: <3F5609CA.7050804@laposte.net> tchize wrote: >Didn't help file say only alphanum and space allowed only? > Ha, maybe i didn't update the help file.... From memory, you can use: alphanumeric chars '-+_ space (heck, i don't have access to the source right now) would be easy to add more, though, just one test... Nicolas 'Ryo' _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Thu Sep 4 00:37:24 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:55:02 2005 Subject: [CF-Devel] new generator code In-Reply-To: <200309031457.40195.d.delbecq@laposte.net> References: <200309031457.40195.d.delbecq@laposte.net> Message-ID: <3F56CF94.3030104@sonic.net> David Delbecq wrote: As a note, I have no problem with the idea itself - generators being able to spawn inventory makes a lot of sense. But I have some minor nits. > -- > There are 2 types of generators in crossfire since september 2003. > both are identified as generators by setting the flag "generate" to 1. > For the first type (the classical one) use "other_arch" to specify > archetype of object to be spawned. > The second type allow more fine tuning on what to generate. To activate > second type, set the flag "use_content_on_gen" to 1. Then each > time something must be generated, it will be a copy of a randomly > choosen item in the generator's inventory. Why use such a flag at all? It'd be much better to just have code like 'if generator->inv, use generator->inv for object, otherwise use generator->other_arch'. I can't see any reason why that flag is needed. As an aside, this is a note to all developers, but things I definately saw in your last two checkins: 1) Please be careful about changing whitespace unecessary. Eg, don't change comments, }, or whatever else unecessarily. If you're changing the code in that area, fine, but there were several occasions in the last checking in which whitespace changed in code not anywhere close/related to other changes. This may not seem like a big issue, until you realize that other people working on the code with modified sources - it can cause unnecessarily need to resolve conflicts that needs to be resolved if they have modified the code. I suggest that you should always run a cvs diff on the stuff before you check in - make sure there are not unnecesarily changes. 2) Make sure the program compiles without warnings with some reasonable strict checking - -Wall with gcc for example. There was an error in the renaming code - was doing a cp==' ', when it should have been *cp - simple error gcc caught. Also catches unused variables and other behaviour. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Thu Sep 4 06:32:06 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:55:02 2005 Subject: [CF-Devel] new generator code In-Reply-To: <3F56CF94.3030104@sonic.net> References: <200309031457.40195.d.delbecq@laposte.net> <3F56CF94.3030104@sonic.net> Message-ID: <200309041332.09464.tchize@myrealbox.com> Le Jeudi 04 Septembre 2003 07:37, Mark Wedel a ?crit : > David Delbecq wrote: > > As a note, I have no problem with the idea itself - generators being able > to spawn inventory makes a lot of sense. But I have some minor nits. > > > -- > > There are 2 types of generators in crossfire since september 2003. > > both are identified as generators by setting the flag "generate" to 1. > > For the first type (the classical one) use "other_arch" to specify > > archetype of object to be spawned. > > The second type allow more fine tuning on what to generate. To activate > > second type, set the flag "use_content_on_gen" to 1. Then each > > time something must be generated, it will be a copy of a randomly > > choosen item in the generator's inventory. > > Why use such a flag at all? It'd be much better to just have code like > 'if generator->inv, use generator->inv for object, otherwise use > generator->other_arch'. Cause, simply, someone may already have created a mouse with pearls in it's inventory or a key but mice are generators. I don't want on such map people asking 'why does my mouse drop pearls now and don't duplicate itself?' I dunno if self-duplicating monster with randomitems in their inventory exists in arch or maps, but they would make sense, while stilling using the other_arch field (inventory way does not allow infinit list of generations unlike other_Arch way). So i implemented this the way which wouldn't have broke the existing. > > I can't see any reason why that flag is needed. > > As an aside, this is a note to all developers, but things I definately > saw in your last two checkins: > > 1) Please be careful about changing whitespace unecessary. Eg, don't > change comments, }, or whatever else unecessarily. If you're changing the > code in that area, fine, but there were several occasions in the last > checking in which whitespace changed in code not anywhere close/related to > other changes. This may not seem like a big issue, until you realize that > other people working on the code with modified sources - it can cause > unnecessarily need to resolve conflicts that needs to be resolved if they > have modified the code. sorry, simply seems all developpers are using differents characterisitcs for their 'tab' key, which most of time render code unreadable cause there is a mix of tabs and whitespace. Most of the time when modifying a function, i redo tab indentation with indentation. Sorry for convenience, won't do i again. > > I suggest that you should always run a cvs diff on the stuff before you > check in - make sure there are not unnecesarily changes. ok > > 2) Make sure the program compiles without warnings with some reasonable > strict checking - -Wall with gcc for example. There was an error in the > renaming code - was doing a cp==' ', when it should have been *cp - simple > error gcc caught. Also catches unused variables and other behaviour. > Did i fail to notice it? I always check for gcc warning. Seems this one was hidding somewhere between two compilation lines. > > > > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Thu Sep 4 06:42:04 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:55:02 2005 Subject: [CF-Devel] Alchemy experience question Message-ID: <3F57250C.7010308@laposte.net> Hello. Here's a weird thing with alchemy (or bowyery/and so on): let's say for instance i drop 20 arrows & one claw in the benchwork, and use the bowyer skill that makes 20 arrows of slay dragon, and gives 5000 xp now if i drop 40 arrows and 2 claws, it does make 40 arrows... And i still get 5000 xp ! this doesn't seem really right to me. either the recipe with 40/2 should fail plainly (wrong recipe) or give twice the xp... of course giving twice the xp would make leveling easier (drop 2000 arrows & 100 claws, though if you fail big loss), so that's something we may want to take into account... Nicolas 'Ryo' _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Thu Sep 4 09:26:10 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:55:02 2005 Subject: [CF-Devel] Alchemy experience question References: <3F57250C.7010308@laposte.net> Message-ID: <000601c372f0$7ddf2780$a19dacce@KAMERIA> On the other hand you are getting the xp for using the skill, not the amount of goodies you are making and that sort of makes sense. If you double the recipe does it make you a better skilled cook? > Hello. > > Here's a weird thing with alchemy (or bowyery/and so on): > let's say for instance i drop 20 arrows & one claw in the benchwork, and > use the bowyer skill > that makes 20 arrows of slay dragon, and gives 5000 xp > now if i drop 40 arrows and 2 claws, it does make 40 arrows... And i > still get 5000 xp ! > > this doesn't seem really right to me. either the recipe with 40/2 should > fail plainly (wrong recipe) or give twice the xp... > of course giving twice the xp would make leveling easier (drop 2000 > arrows & 100 claws, though if you fail big loss), so that's something we > may want to take into account... > > Nicolas 'Ryo' _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Thu Sep 4 23:52:59 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:55:02 2005 Subject: [CF-Devel] new generator code In-Reply-To: <200309041332.09464.tchize@myrealbox.com> References: <200309031457.40195.d.delbecq@laposte.net> <3F56CF94.3030104@sonic.net> <200309041332.09464.tchize@myrealbox.com> Message-ID: <3F5816AB.8090308@sonic.net> tchize wrote: > Cause, simply, someone may already have created a mouse with pearls in it's > inventory or a key but mice are generators. I don't want on such map people > asking 'why does my mouse drop pearls now and don't duplicate itself?' > I dunno if self-duplicating monster with randomitems in their inventory exists > in arch or maps, but they would make sense, while stilling using the > other_arch field (inventory way does not allow infinit list of generations > unlike other_Arch way). So i implemented this the way which wouldn't have > broke the existing. Ok. I had forgot about the monsters that are also generators. > sorry, simply seems all developpers are using differents characterisitcs for > their 'tab' key, which most of time render code unreadable cause there is a > mix of tabs and whitespace. > Most of the time when modifying a function, i redo tab indentation with > indentation. Sorry for convenience, won't do i again. I don't mind fixing tab in a function you are working on. I do it all the time. But there were several instances where whitespace changed in functions which you did not modify, and that creates unnecessary merge headaches, as the code sees some line different, and decides there is something in needs to update in that area. For functions you are working on, if it happens I've changed the same function, I'd almost certainly need to manually merge it also. So fixing whitespace in functions you modify is OK, fixing whitespace in areas you're not touching is a problem. > > Did i fail to notice it? I always check for gcc warning. Seems this one was > hidding somewhere between two compilation lines. I use 'makse -s' now days, simply because with the new automake stuff, the make lines are very verbose. But there are also some number of 'unused' variable warnings in some functions related to the smoothing code also I believe. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Fri Sep 5 03:23:07 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:55:02 2005 Subject: [CF-Devel] Alchemy experience question In-Reply-To: <000601c372f0$7ddf2780$a19dacce@KAMERIA> References: <3F57250C.7010308@laposte.net> <000601c372f0$7ddf2780$a19dacce@KAMERIA> Message-ID: <3F5847EB.3020303@laposte.net> >On the other hand you are getting the xp for using the skill, not the amount >of goodies you are making and that sort of makes sense. If you double the >recipe does it make you a better skilled cook? > > Hum......... Indeed, indeed.. If i were to split hair in four (as we say in french :-)), i'd say that when you use burning hands (or another spell) you mainly succeed in casting the spell, and thus killing monsters is a side effect which shouldn't give xp ^.^ If you cast a nice cone spell (as burning hands is), does it make you better at killing monsters? More seriously, the main drawback of having the same xp even if doubling (or tripling) the recipe is that it's pretty hard to level in mental. It does take time, much more than killing monsters... unless you party with someone & watch your xp go up. Ok right now having a high mental maybe isn't a big issue... But i find that regretful ! It's a skill, thereshould have uses & rewards for having a high level there... Nicolas 'Ryo' _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Fri Sep 5 03:30:25 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:55:02 2005 Subject: [CF-Devel] Any stuff i could help develop? Message-ID: <3F5849A1.1080108@laposte.net> After my rename patch, I don't have any idea right now of what to develop for CF. So i'm wondering what people are working on, and if they'd need help. I know some things related to ingame map making are being developed, that's something i'd like to see implemented, so if i can help... Any suggestion? Nicolas 'Ryo' _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Fri Sep 5 04:32:16 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:55:03 2005 Subject: [CF-Devel] Alchemy experience question In-Reply-To: <000601c372f0$7ddf2780$a19dacce@KAMERIA> References: <3F57250C.7010308@laposte.net> <000601c372f0$7ddf2780$a19dacce@KAMERIA> Message-ID: On the third hand you could see it as the character is actually making two batches and its just the player who is lasy and doesnt want to click twice. Thus the double xp could(should?) be valid. // Magnus Kronhamn email: mak@solace.mh.se On Thu, 4 Sep 2003, Todd Mitchell wrote: > On the other hand you are getting the xp for using the skill, not the amount > of goodies you are making and that sort of makes sense. If you double the > recipe does it make you a better skilled cook? > > > Hello. > > > > Here's a weird thing with alchemy (or bowyery/and so on): > > let's say for instance i drop 20 arrows & one claw in the benchwork, and > > use the bowyer skill > > that makes 20 arrows of slay dragon, and gives 5000 xp > > now if i drop 40 arrows and 2 claws, it does make 40 arrows... And i > > still get 5000 xp ! > > > > this doesn't seem really right to me. either the recipe with 40/2 should > > fail plainly (wrong recipe) or give twice the xp... > > of course giving twice the xp would make leveling easier (drop 2000 > > arrows & 100 claws, though if you fail big loss), so that's something we > > may want to take into account... > > > > Nicolas 'Ryo' > > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Fri Sep 5 04:56:47 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:55:03 2005 Subject: [CF-Devel] Alchemy experience question In-Reply-To: References: <3F57250C.7010308@laposte.net> <000601c372f0$7ddf2780$a19dacce@KAMERIA> Message-ID: <3F585DDF.10009@laposte.net> Magnus Kronhamn wrote: >On the third hand you could see it as the character is actually making >two batches and its just the player who is lasy and doesnt want to click >twice. Thus the double xp could(should?) be valid. > > > // Magnus Kronhamn > > email: mak@solace.mh.se > > But it would enable a player to drop 20000 arrows, 1000 claws & make a lot of xp in one shot Of course if you fail you lose many items, but isn't that big an issue usually :-) Nicolas 'Ryo' _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Fri Sep 5 06:56:38 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:55:03 2005 Subject: [CF-Devel] Alchemy experience question In-Reply-To: References: <3F57250C.7010308@laposte.net> <000601c372f0$7ddf2780$a19dacce@KAMERIA> Message-ID: <1062762997.12854.0.camel@debian> Fourth hand: if you make 4000 arrows, you might learn twice as if you make 2000 arrows... El vie, 05-09-2003 a las 11:32, Magnus Kronhamn escribi?: > On the third hand you could see it as the character is actually making > two batches and its just the player who is lasy and doesnt want to click > twice. Thus the double xp could(should?) be valid. > > > // Magnus Kronhamn > > email: mak@solace.mh.se > > On Thu, 4 Sep 2003, Todd Mitchell wrote: > > > On the other hand you are getting the xp for using the skill, not the amount > > of goodies you are making and that sort of makes sense. If you double the > > recipe does it make you a better skilled cook? > > > > > Hello. > > > > > > Here's a weird thing with alchemy (or bowyery/and so on): > > > let's say for instance i drop 20 arrows & one claw in the benchwork, and > > > use the bowyer skill > > > that makes 20 arrows of slay dragon, and gives 5000 xp > > > now if i drop 40 arrows and 2 claws, it does make 40 arrows... And i > > > still get 5000 xp ! > > > > > > this doesn't seem really right to me. either the recipe with 40/2 should > > > fail plainly (wrong recipe) or give twice the xp... > > > of course giving twice the xp would make leveling easier (drop 2000 > > > arrows & 100 claws, though if you fail big loss), so that's something we > > > may want to take into account... > > > > > > Nicolas 'Ryo' > > > > > > _______________________________________________ > > crossfire-devel mailing list > > crossfire-devel@lists.real-time.com > > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > > > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Fri Sep 5 22:24:26 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:55:03 2005 Subject: [CF-Devel] Alchemy experience question In-Reply-To: <1062762997.12854.0.camel@debian> References: <3F57250C.7010308@laposte.net> <000601c372f0$7ddf2780$a19dacce@KAMERIA> <1062762997.12854.0.camel@debian> Message-ID: <3F59536A.4070002@sonic.net> From a more narrow perspective, one could argue that once you have successfully made a recipe, how much do you learn by re-making it? But one has to ask if exp is really a measure of how much one learns, or more an abstract principle. However, a few notes: In the new skill system, which will probably get checked in sometime soon, there is no longer experience categories - instead, each skill has an exp total associated with it. Also, there is no longer any requirement that overall player exp is the sum of exp in all the skills. It is also possible to tune the amount of exp that goes to the characters overall exp from the skill. Thus, it is possible to set it so that 10% of the exp a character gets in alchemy goes to their total - this should make it more reasonable then give out larger rewards for such skills without messing up the balance quite as much, eg, a character could be level 50 in alchemy, but still only level 5 overall. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Tue Sep 9 19:58:17 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:55:03 2005 Subject: [CF-Devel] feature request - email player files Message-ID: The idea has been discussed on IRC and requested a number of times to me through private email and while logged in on the metalforge server.. People are very interested in the ability to have their player files emailed to them. The basic concept is, the player visits a web page and enters in their character's name and password. If this is correct, they then enter an email address and the player file is sent to that address. I'm pretty sure there more to it then this and that I've overlooked some basic security protocols. Is anyone up to the challenge of making this a possibility? =) Questions, comments or other ideas? - Rick Tanner leaf@real-time.com -- _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Wed Sep 10 00:22:27 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:55:03 2005 Subject: [CF-Devel] feature request - email player files In-Reply-To: References: Message-ID: <3F5EB513.3090900@sonic.net> Rick Tanner wrote: > The idea has been discussed on IRC and requested a number of times to me > through private email and while logged in on the metalforge server.. > > People are very interested in the ability to have their player files > emailed to them. > > The basic concept is, the player visits a web page and enters in their > character's name and password. If this is correct, they then enter an > email address and the player file is sent to that address. I'm pretty > sure there more to it then this and that I've overlooked some basic > security protocols. > > Is anyone up to the challenge of making this a possibility? =) > > Questions, comments or other ideas? Shouldn't be that hard. A few notes: 1) If possible, might be nice to verify that the player isn't currently logged into the server. 2) Giving players access to their file does give them some extra information. Eg, they can see what unidentified are (not that big a deal, given the easy), but there can be hidden forces in the object which they might otherwise not be aware of. 3) rather than sending e-mail, I'd just have the cgi-script send the data to the browser, just putting in the appropriate content-type flag so the browser deals with it appropriately. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Wed Sep 10 00:28:48 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:55:03 2005 Subject: [CF-Devel] Any stuff i could help develop? In-Reply-To: <3F5849A1.1080108@laposte.net> References: <3F5849A1.1080108@laposte.net> Message-ID: <3F5EB690.6090208@sonic.net> Nicolas Weeger wrote: > After my rename patch, I don't have any idea right now of what to > develop for CF. > > So i'm wondering what people are working on, and if they'd need help. > I know some things related to ingame map making are being developed, > that's something i'd like to see implemented, so if i can help... the TODO file lists some ideas. Some are fairly big projects, some are fairly modest. Whatever you decide to do, you should at least let everyone else know. You can also look at the bugs and see if there are any there you want to tackle. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Wed Sep 10 02:06:01 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:55:03 2005 Subject: [CF-Devel] feature request - email player files In-Reply-To: <3F5EB513.3090900@sonic.net> References: <3F5EB513.3090900@sonic.net> Message-ID: <3F5ECD59.6090002@laposte.net> > Shouldn't be that hard. A few notes: Actually someone on IRC channel wrote a script (perl?) to do just that... Don't remember her/his name, shouldn't be hard to find. > 1) If possible, might be nice to verify that the player isn't > currently logged into the server. > > 2) Giving players access to their file does give them some extra > information. Eg, they can see what unidentified are (not that big a > deal, given the easy), but there can be hidden forces in the object > which they might otherwise not be aware of. The script i mentioned removes the player file after downloading. Thus the extra information is non revelant, but the currently logged sure is :-) We could also imagine removing some things (forces, diseases) before sending to the client. On the other hand, downloading serves basically one purpose: use on another server, meaning uploading the file (or copying it if local server). In both cases the player does send/copy the file, so s/he can modify it any way s/he wants.... adding items, changing ones, and such. Nicolas 'Ryo' _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Wed Sep 10 02:07:16 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:55:03 2005 Subject: [CF-Devel] Any stuff i could help develop? In-Reply-To: <3F5EB690.6090208@sonic.net> References: <3F5849A1.1080108@laposte.net> <3F5EB690.6090208@sonic.net> Message-ID: <3F5ECDA4.2090308@laposte.net> > the TODO file lists some ideas. Some are fairly big projects, some > are fairly modest. Whatever you decide to do, you should at least let > everyone else know. > > You can also look at the bugs and see if there are any there you want > to tackle. Well, I've heard discussions about ingame map building, or at least apartment changing... That's something I'd sure love to see implemented, so if someone if working on that & needs help... I'll check the TODO list, never saw it ^.^ Thanks for the tips Nicolas 'Ryo' _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Wed Sep 10 08:54:39 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:55:03 2005 Subject: [CF-Devel] Player files download Web interface Message-ID: <200309101554.39439.yann.chachkoff@myrealbox.com> Philip Stolarczyk (Known as 'Somebdy') asked me to submit his work on the mailing list, as he currently cannot do it himself. His description of the thing: "This CGI script allows players to download their players files through a web interface. It does password checking and has some extra options." URL of the Perl Script: http://www.theperlguru.com/crossfire/pldl.pl.txt Comments (and possibly bug reports - if any) appreciated. -- Yann Chachkoff ----------------------- Garden Dwarf's Best Friend ----------------------- GPG Key : http://pgp.dtype.org:11371/pks/lookup?op=get&search=0x844D25E0 Fingerprint: 6616 2E02 BAD2 4AEF C90A F1EB 7E03 AAB9 844D 25E0 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20030910/b20185fe/attachment.pgp From crossfire-devel-admin at archives.real-time.com Wed Sep 10 08:52:45 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:55:03 2005 Subject: [CF-Devel] broken random map Message-ID: <20030910135245.5698.qmail@emc.com> It's been a while since I've seen a bad random map, but I ran into one on Metalforge last night: (null) (/random/pirateisland0479) xsize 17 ysize 21 wallstyle dungeon floorstyle lightdirt monsterstyle undead decorstyle creepy exitstyle sstair dungeon_level 26 dungeon_depth 50 orientation 1 origin_x 1 origin_y 1 random_seed 1063146276 I could see with x-ray vision where it should have been connected, but there were no doors or secret doors (I'm quite certain I checked every possible square). Oh, and there are still maps with keys that don't go to anything. I think it's a holdover from when there were locked chests, but that's just a guess. I'll try to remember to post the map information the next time I see one. --PC _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Wed Sep 10 09:09:41 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:55:03 2005 Subject: [CF-Devel] client code Message-ID: <20030910140941.5754.qmail@emc.com> I've been looking at the client code, and it looks like there's some old cruft in there, but I thought I should ask here before removing it, in case there's some reason for it. In common/client.h, the Player_Struct has several unused fields: name, password, and shoottype. In gtk/gx11.c (and in other client versions), there are two file descriptor sets defined, but tmp_exceptions is never used. In gtk/gx11.c at the end of set_window_pos(), there should be a fclose(fp). [Under Linux, you can look in /proc/{pid}/fd and see that the file is left open.] I'll check in all those changes unless someone says that I shouldn't. More complicated issues: Most commands are sent with the send_command() function. There are two exceptions: toggle_locked() and mark_obj() in item.c. I don't see a good way of changing this at this point (i.e., without tweaking the protocol), but it feels wrong. Any ideas? There seems to be redundant information on the run/fire state. This is in cpl.fire_on and cpl.run_on, as well as cpl.stats.flags. --PC _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Fri Sep 12 10:56:40 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:55:03 2005 Subject: [CF-Devel] 'maps' command update Message-ID: <20030912155640.22454.qmail@emc.com> I made a change to the maps command to accept an optional paramater. When going through the list, it uses strstr() to see if the parameter is a substring in the map path, and only displays it if it is. So issuing 'maps' works like it does now. Issuing 'maps itan' would list the Titan Quest maps if they are active. On servers like Metalforge where there may be hundreds of maps active, this makes it easy to check to see when a given quest will be ready. The changes are in server/c_misc.c (and a change in include/sproto.h to reflect the function change). Relevant excerpts from: cvs diff -u -r 1.34 -r 1.35 c_misc.c -void map_info(object *op) { +void map_info(object *op, char *search) { @@ -48,6 +48,7 @@ new_draw_info(NDI_UNIQUE, 0,op,"Path Pl PlM IM TO Dif Reset"); for(m=first_map;m!=NULL;m=m->next) { + if ( search && strstr(m->path,search)==NULL ) continue; /* Skip unwanted maps */ /* Print out the last 18 characters of the map name... */ if (strlen(m->path)<=18) strcpy(map_path, m->path); else strcpy(map_path, m->path + strlen(m->path) - 18); int command_maps (object *op, char *params) { - map_info(op); + map_info(op,params); return 1; } --PC _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Fri Sep 12 11:01:38 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:55:03 2005 Subject: [CF-Devel] client code Message-ID: <20030912160138.22476.qmail@emc.com> >In common/client.h, the Player_Struct has several unused fields: name, >password, and shoottype. Removing those seems to cause problems. Are we essentially doing a memcopy from the server into that struct, or is there some other reason for removal of those unused fields to cause problems? --PC _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Fri Sep 12 23:03:52 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:55:03 2005 Subject: [CF-Devel] client code In-Reply-To: <20030912160138.22476.qmail@emc.com> References: <20030912160138.22476.qmail@emc.com> Message-ID: <3F629728.10905@sonic.net> Preston Crow wrote: >>In common/client.h, the Player_Struct has several unused fields: name, >>password, and shoottype. > > > Removing those seems to cause problems. Are we essentially doing a memcopy > from the server into that struct, or is there some other reason for removal > of those unused fields to cause problems? > Can you be more specific on 'cause problems'? I can't see any reason for those fields to be accessed indirectly. Could be some buffer overflow issue with input_text, and being that these fields are after that, they extra bytes they provide mask the problem. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Sat Sep 13 00:08:02 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:55:04 2005 Subject: [CF-Devel] skill & spell object code check in. Message-ID: <3F62A632.8050504@sonic.net> I've checked in the new skill + spell code. I don't want to delve too in depth on details, as I think the docs I wrote up with them, and now in CVS, are pretty good, so I'll just give quick summary: skills: No longer are there experience categories. Each skill has its own exp and level total. The handling of exp for skills is greatly improved - should be impossible to funnel exp into a different skill - even in party mode. This is because for things like spells, we record the skill name the exp should be creditied to. It is possible to adjust the amount of exp you earn in a skill that goes to your overall exp. For example, it may be desirable to make it so that skills over all progress at near the same pace (level 10 one handed weapons, level 10 alchemist, level 10 literacy, etc). However, given literacy is a relative safe profession, don't want give the player as much exp for their overall level when using literacy as compared to soemthing dangerous. As an effect of these changes, the 'skills' tunable file is gone - now you tune skilsl by changing objects. Objects have been updated to note what skill you need to use - this is mostly relevant for weapons. spells: spells are now object. You learn a spell, and an object is added to your inventory. Things like spellbooks, wands, rods, etc, have the spell object they fire in their inventory. spells are now much more tunable - one can make an acid ball with no code changes at all - all that would be needed is a new arch. treasurelists now determine likelyhood of the spell showing up in wands, scrolls, etc. Magic is now split into 4 skills, evocation, pyromancy, summoning, and sorcery. Given spells are now objects, spell_params file is now gone - you tune spells by changing the archetypes. Several notes: I tagged the arch and server source with tag 'rel-1-5-0-patch' for the code just before this checkin, so if you want the code from before this checkin, just use that tag. While I have added some backward compatiblity to handle spell related objects on maps that might have values set (spellbook of X for example), I have not written any code that updates player files. This is possible to do, but given the numerous changes, I'm not sure what level of backward compatility should really be strived for here. I consider this checkin to be a major piece for a '2.0' release, so one might consider this pre-2.0 or the like. There are some areas that still need some work: Mosely's rare books in scorn need to be updated for the 4 spellbook types - this is relatively minor. Balance is probably in order. Currently, all the skills contribute on a 1:1 bases to overall exp. That may not be correctly. I tried to keep the spells at the same power as before, but some of the old code as 'odd', and in cleaning up the code, its probable balance is a little off from before in terms of damage or sp costs or the like. The CVS client will display all the skills, but it does tend to take up too much space in the stats pane, so I'll make a few tabs I think to cover that. One 'bug' is that it is pretty much impossible to know if a player has a skill until they use it, so you'll never see the pain lists skills with 0 exp. Personal notes: I've been playtesting the code for several weeks, finding bugs and fixing them. I think it is relative stable, but leave it to one person to use try something I didn't. OTOH, I personally think the spells are probably better tested than they have been in a long time, as I basically went through each spell type and gave it a try, and found several things that look like they may not have worked from before the changes I made. My one note is that it is harder on spellcasters, as you don't have quite the same number of choices to make. There is currently nothing in the code preventing a spellcaster from getting are four skills (other than cost). I have a feeling that as players play the different spellcasting skills, refinements (in terms of spells to fill gaps and the like) will be found and added. Have any questions, feel free to ask. As said, I think the documentation on this should be pretty good (in the doc/Developer directory in the server), so please read that first before asking too many questions. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Sat Sep 13 13:24:16 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:55:04 2005 Subject: [CF-Devel] autoconfig requirements Message-ID: <1063477456.542.57.camel@oberon.Kameria> One think I have brought up before and now again is that the requirements to make the server are now automake1.7 and autoconfig 2.54 or higher. These exceed the standard versions of these tool s in Debian stable and likely many other distros. Are these versions really requirements? I have managed to make the server by changing the aclocal.m4 entry for autoconfig 2.54 to 2.52 and it compiles fine as far as I can see (some automake warning but otherwise fine). This would represent a problem howver for folks not familiar with the server and with distros that do not have this version of automake. Should we really force people to update standard OS tools to install a game? My point is if it isn't really a requirement then can we change it so that people have less problems? I am not saying that progress is not wanted or that tools do not evolve, but arbitrary pseudo-requrements that cause barriers or confusion for people are not good. We cannot and do not want to be tracking OS distros, but if a *required* tool version is not in a major release such as Debian stable and is not *really* required I can't see the value here. I think it should be changed or someone explain the necessity. Personally I think it was likely slipped in by accident. On a related note I think the server config should also check for X libraries and if they are not there it should not attempt to make crossedit. Someone on this list should be educated enough in the build configure scripting to be able to make that work, no? Isn't it possible to do something like: if not x11LIBS: SUBDIRS = A B C else: SUBDIRS = A B C crossedit Ok, I'm done, back to checking out the new skill/spell stuff. -Todd _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Sun Sep 14 02:35:49 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:55:04 2005 Subject: [CF-Devel] autoconfig requirements In-Reply-To: <1063477456.542.57.camel@oberon.Kameria> References: <1063477456.542.57.camel@oberon.Kameria> Message-ID: <20030914073549.GB23515@nic.bnet.pl> On Sat, Sep 13, 2003 at 02:24:16PM -0400, Todd Mitchell wrote: > with distros that do not have this version of automake. Should we > really force people to update standard OS tools to install a game? Autoconf and automake are not needed to install the game. They are needed only for developers. Greets, Jacek _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Sun Sep 14 02:46:51 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:55:04 2005 Subject: [CF-Devel] Player files download Web interface In-Reply-To: <200309101554.39439.yann.chachkoff@myrealbox.com> References: <200309101554.39439.yann.chachkoff@myrealbox.com> Message-ID: <3F641CEB.8060109@sonic.net> Yann Chachkoff wrote: > Philip Stolarczyk (Known as 'Somebdy') asked me to submit his work on the > mailing list, as he currently cannot do it himself. > > His description of the thing: > > "This CGI script allows players to download their players files through a web > interface. It does password checking and has some extra options." > > URL of the Perl Script: http://www.theperlguru.com/crossfire/pldl.pl.txt > > Comments (and possibly bug reports - if any) appreciated. > Took a look. Nice bit of code. Few comments/questions: Is there a html page out there that uses this, just to toss in as a sample? I plan on putting this in the utils directory in the server code. That way autoconf can be used to fill in some of the fields so it just works with few changes. I note that there is a single file, stored in /tmp, that is used to track when players last downloaded. My personal thought is that it would be easier to just create/touch a file in the player directory, and one could just use the last modified time on that file. This does mean an extra file/inode used up in the filesystem, but I don't think that is that big a deal, and would seem to simplify the code. Related to this, it would be very easy for the server to create some other file to denote that the player is actually playing the game, and remove it when the player logs off. Thus, the script could check for the existance of that file, and if it finds it, note some error. Now there could be stale data in this case if the server crash. But I just envision the server creating that file unconditionally, so it wouldn't care. It would just mean that you could get cases where you can't download the character after hte server crashed (if you were playing at that time) until you logged in and logged out. the other thing I'd do is change the output of the tar to just dump the data directly down the the connection instead of writing it to a tmp file first. That seems like it'd be more efficiently. Also, potentially having a whole bunch of tar files in /tmp doesn't seem like a generally good idea. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Sun Sep 14 03:32:39 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:55:04 2005 Subject: [CF-Devel] autoconfig requirements In-Reply-To: <20030914073549.GB23515@nic.bnet.pl> References: <1063477456.542.57.camel@oberon.Kameria> <20030914073549.GB23515@nic.bnet.pl> Message-ID: <1063528359.542.70.camel@oberon.Kameria> On Sun, 2003-09-14 at 03:35, Jacek Konieczny wrote: > On Sat, Sep 13, 2003 at 02:24:16PM -0400, Todd Mitchell wrote: > > with distros that do not have this version of automake. Should we > > really force people to update standard OS tools to install a game? > > Autoconf and automake are not needed to install the game. They are > needed only for developers. > > Greets, > Jacek > You type in a make install on debian woody and see how far you get. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Sun Sep 14 03:24:08 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:55:04 2005 Subject: [CF-Devel] autoconfig requirements In-Reply-To: <1063528359.542.70.camel@oberon.Kameria> References: <1063477456.542.57.camel@oberon.Kameria> <20030914073549.GB23515@nic.bnet.pl> <1063528359.542.70.camel@oberon.Kameria> Message-ID: <20030914082408.GC23515@nic.bnet.pl> On Sun, Sep 14, 2003 at 04:32:39AM -0400, Todd Mitchell wrote: > You type in a make install on debian woody and see how far you get. Didn't you touch any file in crossfire sources? If not, then this must be a bug in crossfire build infrastructure or in Debian Woody. Try uninstalling autoconf and automake and run make install then. Greets, Jacek _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Sun Sep 14 05:19:26 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:55:04 2005 Subject: [CF-Devel] autoconfig requirements In-Reply-To: <20030914082408.GC23515@nic.bnet.pl> References: <1063477456.542.57.camel@oberon.Kameria> <20030914073549.GB23515@nic.bnet.pl> <1063528359.542.70.camel@oberon.Kameria> <20030914082408.GC23515@nic.bnet.pl> Message-ID: <1063534766.542.108.camel@oberon.Kameria> On Sun, 2003-09-14 at 04:24, Jacek Konieczny wrote: > On Sun, Sep 14, 2003 at 04:32:39AM -0400, Todd Mitchell wrote: > > You type in a make install on debian woody and see how far you get. > > Didn't you touch any file in crossfire sources? If not, then this must > be a bug in crossfire build infrastructure or in Debian Woody. > > Try uninstalling autoconf and automake and run make install then. > > Greets, > Jacek > I think you are missing my point, these products work ok on my system and I can make the server with a couple work arounds. The problem is that aclocal.m4 has an entry that has an entry that says AC_PREREQ([2.54]) - it will not even attempt to make the package unless I change that to AC_PREREQ([2.52]) and then it builds fine (with a warning about automake 1.7 not being installed). Now I have automake and autoconf installed (versions that come with woody) and they work ok. I can build crossfire all day long. At some point in the recent past someone updated the CVS and inserted these changes which are not really requiremernts but which cause problems for some people on standard distros because they act like requirements. Here is the change, notice that the tool used to build the file was newer (actually likely from Debian unstable distro). http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/crossfire/crossfire/aclocal.m4.diff?r1=1.9&r2=1.10 Now if there was a need to upgrade the autoconf version (new functionality, more performance...) then that would be one thing, but if it was just done because that's what was running on the developers system at the time then I would like to see it changed back. I am saying basically that if we didn't need to upgrade the tool used to do the configure script then we shouldn't have upgraded it. I cannot say what other distros this will impact, but I suspect that most people haven't come across it yet since it is in CVS or you would be hearing more about it. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Sun Sep 14 06:22:25 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:55:04 2005 Subject: [CF-Devel] autoconfig requirements In-Reply-To: <1063534766.542.108.camel@oberon.Kameria> References: <1063477456.542.57.camel@oberon.Kameria> <20030914073549.GB23515@nic.bnet.pl> <1063528359.542.70.camel@oberon.Kameria> <20030914082408.GC23515@nic.bnet.pl> <1063534766.542.108.camel@oberon.Kameria> Message-ID: <20030914112225.GA18024@nic.bnet.pl> On Sun, Sep 14, 2003 at 06:19:26AM -0400, Todd Mitchell wrote: > I think you are missing my point, these products work ok on my system > and I can make the server with a couple work arounds. > The problem is that aclocal.m4 has an entry that has an entry that > says AC_PREREQ([2.54]) - it will not even attempt to make the package > unless I change that to AC_PREREQ([2.52]) and then it builds fine (with > a warning about automake 1.7 not being installed). aclocal.m4 is autogenerated from other components. Those AC_PREREQ() are included from some other *.m4 file (maybe from libtool). Maybe you have to new libtool for your automake/autoconf or you didn't regenerated aclocal.m4 after changing other files. Try running "aclocal". > woody) and they work ok. I can build crossfire all day long. At some > point in the recent past someone updated the CVS and inserted these > changes which are not really requiremernts but which cause problems for > some people on standard distros because they act like requirements. I guess someone has newer libtool or something, rebuilded aclocal.m4 and commited it into CVS. aclocal.m4 should not be in CVS unless all other autogenerated files (including "configure" script) are up-to-date in the CVS. Greets, Jacek _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Sun Sep 14 14:41:04 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:55:04 2005 Subject: [CF-Devel] Client scripting interface Message-ID: <20030914194104.24126.qmail@emc.com> A number of players have wanted to be able to automate tasks that are too complicated for key bindings. I know several have made special-case modifications to their clients. Others have written special client programs for completely-automated characters. What I thought would be most useful in this area would be a general interface between the client and scripts, so that's what I wrote. My scripting interface works by adding a new client-side command: "script." A player will issue a command like "script unlock containers" which will cause the client to fork/exec a new process named "unlock" with the command-line parameter "containers." The stdin and stdout of the new process are a socket that is managed by the client. The script issues commands to the client by echoing them to stdout, and the client sends information to the script as lines of text on its stdin. Hence, scripts can be written in any language. The script can issue commands to request information from the client (like a copy of the inventory), to watch for selected commands from the server, to send a command to the server, or to monitor the commands being sent by the client. There are a few things not working yet (like having the client send map data), but it's working for me--I wrote a script to unlock all my containers, empty them, identify everything, then re-lock them. The patch can be downloaded from http://www.crowcastle.net/cf/ It can be applied with something like: cd ..../client gunzip client_scripting-1.0-patch.gz | patch --strip=1 Any comments on the idea/implementation? And the big question: Is this something that I should check in, or is something we don't want players using? (I could see it being abused to gain non-combat experience, automatically drink healing potions as needed, and things like that, as well as more mundane tasks such as inventory management.) --PC _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Sun Sep 14 15:36:28 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:55:04 2005 Subject: [CF-Devel] Client scripting interface In-Reply-To: <20030914194104.24126.qmail@emc.com> References: <20030914194104.24126.qmail@emc.com> Message-ID: <3F64D14C.9090507@laposte.net> Hello everyone. >And the big question: Is this something that I should check in, or is >something we don't want players using? (I could see it being abused to >gain non-combat experience, automatically drink healing potions as needed, >and things like that, as well as more mundane tasks such as inventory >management.) > >--PC > > > Well, as many things, I see this as double-edged sword :) I can see it being it used for things like: drink a potion of lava resistance if available, else a fire resistance one, and if none, invoke protection from fire Thus enhanced protection, easier for the player to manage (no need to bind 3 keys to those things, and no need to remember what potions player has in inventory). On the other hand, it could be used for things like: whenever a dragon appears on the map (detectable from image), or fire, or something like that, automatically drink a potion... thus helping the player, maybe too much... Or as you said automatic potions drinking (even though sometimes drinking doesn't help a lot :) For alchemy & such it could be used too, but you can already do much with a simple copy & paste....but it'll sure be easier if automated (write a zillion scrolls & gain much xp) Also it raises the issue of client playing automatically, like player making alchemy while user is chatting somewhere else...which, imo, is not something we'd want. (even though mental is such a pain to level without partying...) So maybe we should limit what information the script receives, and what it can do... The big question being 'what exactly' :) Just my 2 cents Nicolas 'Ryo' _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Mon Sep 15 00:38:48 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:55:04 2005 Subject: [CF-Devel] Client scripting interface In-Reply-To: <3F64D14C.9090507@laposte.net> References: <20030914194104.24126.qmail@emc.com> <3F64D14C.9090507@laposte.net> Message-ID: <3F655068.50906@sonic.net> I personally don't see adding scripting support as that big a deal. As said, some players have already hacked their clients to perform certain actions. So at best, all you can really do by not providing such a feature is to make it more difficult for players. Note that the client, and protocol, was intentionally designed to not give any information to the players that they should not know, eg, we don't trust the client. Thus, at best, scripts can only really provide aid, and not let them cheat (there are numerous games in which hacked clients could really cheat, but not crossfire). In some sense, having scripts that do the right thing could be really handy. Note that the script can't do anything that the player couldn't do. The command will still take the same amount of time on the server - all the script can really do is potentially respond faster (when drinking potions of healing for example), as well as automate tasks that are more tricky. In certainly won't be a cure all. For example, auto applying potions of healing may not always do what you want. If you want it to apply it soon enough so you don't get killed while standing in that lightning bolt, the threshold could be 40% of your hp. However, there could certainly be other times where being at 40% of your hp isn't that big a deal, if your fighting something that does pretty consistent damage. If someone can write a script that plays and gains exp for them, more power for them. One would have to ask at some level, what the point of such a script would be. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Mon Sep 15 00:57:44 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:55:04 2005 Subject: [CF-Devel] autoconfig requirements In-Reply-To: <20030914112225.GA18024@nic.bnet.pl> References: <1063477456.542.57.camel@oberon.Kameria> <20030914073549.GB23515@nic.bnet.pl> <1063528359.542.70.camel@oberon.Kameria> <20030914082408.GC23515@nic.bnet.pl> <1063534766.542.108.camel@oberon.Kameria> <20030914112225.GA18024@nic.bnet.pl> Message-ID: <3F6554D8.9000501@sonic.net> In general, all the files should be commited that are needed to build the server so that unless you actually modify the makefiles or configure.ac, that one shouldn't need automake or autoconf. The problem seems to be that whenever aclocal.m4 is rebuilt, it puts in whatever version of autoconf is onthe target system as the minimum required version. the other problem is that since crossfire went to automake, that the makefiles will detect if some file is out of data. When automake wasn't in use, never a problem as the process of running make would never run autoconf. This is compounded by the problem that since dependency checking is done, the order that files are checked in/checked out can matter. And I don't think a cvs checkin/checkout from the top level directory will necessarily be in the correct order for the datestamp of the files to be correct. The ideal thing, which I'm not sure if its possible, since I didn't do the automake stuff, would be so that the makefiles never try to run automake/autoconf on their own - only run those if developers specifically execute some command. Then the issue of checkin/checkout order is not important. As for crossedit, that problem is trickier - look at the Makefile.am - that is converted into the Makefile.in (automatically), which is converted into the Makefile. Removing crossedit in that process is very difficult. The simplest thing would be to just remove crossedit all together. Beyond that, not really sure what can easily be done, because the makefile.am's don't have a whole bunch of code in them, so I'm not really sure how easy one can control compile behaviour. However, crossedit is already listed as the last directory to build, so any errors it generates are purely cosmetic/obnoxious, and won't effect the building of any of the other bits. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Mon Sep 15 04:46:56 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:55:04 2005 Subject: [CF-Devel] Client scripting interface In-Reply-To: <3F655068.50906@sonic.net> References: <20030914194104.24126.qmail@emc.com> <3F64D14C.9090507@laposte.net> <3F655068.50906@sonic.net> Message-ID: <3F658A90.3050209@laposte.net> If server sends minimum information, then indeed all my objections are worthless :) Maybe some plugin interface, like for the server, could be designed for the client as well... Nicolas 'Ryo' _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Mon Sep 15 23:40:00 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:55:04 2005 Subject: [CF-Devel] Client scripting interface In-Reply-To: <3F658A90.3050209@laposte.net> References: <20030914194104.24126.qmail@emc.com> <3F64D14C.9090507@laposte.net> <3F655068.50906@sonic.net> <3F658A90.3050209@laposte.net> Message-ID: <3F669420.1090202@sonic.net> Nicolas Weeger wrote: > If server sends minimum information, then indeed all my objections are > worthless :) > > Maybe some plugin interface, like for the server, could be designed for > the client as well... it really depends on how much work someone wants to put in on this. It's obviously much easier to just run the script when the appropriate key is pressed or whatever than having scripts watching data all the time (and then controlling when those scripts should act/not act would need yet another interface). _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Mon Sep 15 23:38:18 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:55:05 2005 Subject: [CF-Devel] New comunication commands. 'me and 'set_reply Message-ID: <20030916013818.2bc8e9b4.kstenger@montevideo.com.uy> Hi all! I am sending 3 diff files today, here is a description of each of them. I would really apreciate if someone more experienced than me checks the code, and if you think it's stable enough commit them to the CVS. Despite gros' advice about doing the changes to the 1.5.0-patch i made it on the main branch (after i could understand what a branch was hehe). I hope i did it right. Any comments will be apreciated. cf_me.diff - this is a very simple file. Aparently the time the changes i made for the 'me command was commited to the CVS something weird happened and this simple row that is missing makes the command not to work. The rest of the needed code (command_me function and it's header) are already put in place. cf_set_reply.diff - well this is the new stuff :-) The 'set_reply command used without parameters, saves in a player field called reply_to the name of the last player that told you something until now. Then the reply command was modifies to use this value instead of the last_tell field if it was already set, if it was not set or was deletted this command will behave as always did. To remove the value of the reply_to field type 'set_reply -r To view who is stored into the reply_to field type 'set_reply -v This command will also work if the player to the one you are replying logs out and comes back again, the value will still be set to him/her if you didnt remove/reset it (i thought it's useful for crashing clients). But still if the player is logged off we wont be able to tell him anything. cf_set_reply&me.diff - just in case you wanted to commit both together since they are in my point of view very simple changes :-) Greetings, Katia. -- +-----------------------------+ | Karla M? Stenger S?bat | | Pando . Canelones . Uruguay | | kstenger@montevideo.com.uy | +-----------------------------+ -------------- next part -------------- ? .tm_project.cache ? Makefile ? autom4te.cache ? config.log ? config.status ? crossfire.prj ? crossfire.pws ? libtool ? common/.deps ? common/Makefile ? common/st6KFc92 ? crossedit/.deps ? crossedit/.libs ? crossedit/Makefile ? crossedit/crossedit ? crossedit/Cnv/.deps ? crossedit/Cnv/Makefile ? crossedit/bitmaps/Makefile ? crossedit/doc/Makefile ? crossedit/include/Makefile ? devel/.deps ? devel/.libs ? devel/Makefile ? devel/crossfire-config ? doc/Makefile ? doc/Developers/Makefile ? doc/playbook/Makefile ? doc/playbook-html/Makefile ? doc/scripts/Makefile ? doc/spell-docs/Makefile ? doc/spoiler/Makefile ? doc/spoiler-html/Makefile ? include/Makefile ? include/autoconf.h ? include/stamp-h1 ? lib/Makefile ? lib/checkarch.pl ? lib/collect.pl ? plugin/.deps ? plugin/Makefile ? random_maps/.deps ? random_maps/.libs ? random_maps/Makefile ? random_maps/random_map ? server/.deps ? server/.libs ? server/Makefile ? server/crossfire ? socket/.deps ? socket/Makefile ? utils/Makefile ? utils/add_throw.perl ? utils/crossloop ? utils/crossloop.pl ? utils/crossloop.pl.tmpl ? utils/crossloop.tmpl ? utils/crossloop.web ? utils/metaserver.pl ? utils/scores.pl Index: include/player.h =================================================================== RCS file: /cvsroot/crossfire/crossfire/include/player.h,v retrieving revision 1.33 diff -u -r1.33 player.h --- include/player.h 13 Sep 2003 05:01:34 -0000 1.33 +++ include/player.h 16 Sep 2003 03:31:31 -0000 @@ -161,6 +161,7 @@ char killer[BIG_NAME]; /* Who killed this player. */ char last_tell[MAX_NAME]; /* last player that told you something [mids 01/14/2002] */ + char reply_to[MAX_NAME]; /* player to the one we want to reply */ char write_buf[MAX_BUF]; /* Holds arbitrary input from client */ char input_buf[MAX_BUF]; /* Holds command to run */ Index: include/sproto.h =================================================================== RCS file: /cvsroot/crossfire/crossfire/include/sproto.h,v retrieving revision 1.96 diff -u -r1.96 sproto.h --- include/sproto.h 13 Sep 2003 05:01:34 -0000 1.96 +++ include/sproto.h 16 Sep 2003 03:31:32 -0000 @@ -73,6 +73,7 @@ int command_orcknuckle(object *op, char *params); int command_shout(object *op, char *params); int command_tell(object *op, char *params); +int command_sreply(object *op, char *params); int command_reply(object *op, char *params); int command_nod(object *op, char *params); int command_dance(object *op, char *params); Index: server/c_chat.c =================================================================== RCS file: /cvsroot/crossfire/crossfire/server/c_chat.c,v retrieving revision 1.15 diff -u -r1.15 c_chat.c --- server/c_chat.c 28 Jul 2003 05:19:35 -0000 1.15 +++ server/c_chat.c 16 Sep 2003 03:31:33 -0000 @@ -162,8 +162,62 @@ return 1; } -/* Reply to last person who told you something [mids 01/14/2002] */ -int command_reply (object *op, char *params) { +/* Sets the value of the reply_to field of a player */ +int command_sreply(object *op, char *params) { + player *pl; + + if (params==NULL) { + /* check if player is still connected */ + pl=find_player(op->contr->last_tell); + + if (pl==NULL){ + new_draw_info(NDI_UNIQUE, 0, op, + "Can't set reply_to value, this player left."); + return 1; + } + else { + /* Update reply_to value */ + strcpy(op->contr->reply_to, pl->ob->name); + new_draw_info_format(NDI_UNIQUE, 0, op, + "Reply_to value set to %s.", pl->ob->name); + return 1; + } + } + + while (*params==' ') params++; + + if (!strncmp(params,"-r",2)) { + /* Remove the reply_to value */ + op->contr->reply_to[0] = '\0'; + new_draw_info(NDI_UNIQUE, 0, op, + "Reply_to value was removed."); + } + else if (!strncmp(params,"-v",2)) { + /* View the reply_to value if it exists */ + if (op->contr->reply_to==NULL) { + new_draw_info(NDI_UNIQUE, 0, op, + "You will reply to the last person that tells you something."); + } + else { + /* NOTE: reply_to can be set to a player that is not logged any more * + * we make the control on if he's logged or not in the reply command.* + * So, if the player comes back online we can still reply to him/her. */ + new_draw_info_format(NDI_UNIQUE, 0, op, + "You will reply to %s.", op->contr->reply_to); + } + } + else { + /* Unknown parameter */ + new_draw_info(NDI_UNIQUE, 0, op, + "Usage: \n 'set_reply\n 'set_reply -r\n 'set_reply -v"); + } + return 1; +} + + +/* Reply to last person who told you something [mids 01/14/2002] * + * or to the player set in the reply_to player field if it exists */ +int command_reply(object *op, char *params) { player *pl; if (params == NULL) { @@ -171,13 +225,16 @@ return 1; } - if (op->contr->last_tell[0] == '\0') { + if (op->contr->last_tell[0] == '\0' && op->contr->reply_to[0] == '\0') { new_draw_info(NDI_UNIQUE, 0, op, "You can't reply to nobody."); return 1; } /* Find player object of player to reply to and check if player still exists */ - pl = find_player(op->contr->last_tell); + if (op->contr->reply_to[0] == '\0') + pl = find_player(op->contr->last_tell); + else + pl = find_player(op->contr->reply_to); if (pl == NULL) { new_draw_info(NDI_UNIQUE, 0, op, "You can't reply, this player left."); @@ -188,9 +245,9 @@ strcpy(pl->last_tell, op->name); new_draw_info_format(NDI_UNIQUE | NDI_ORANGE, 0, pl->ob, - "%s tells you: %s", op->name, params); + "%s tells you: %s", op->name, params); new_draw_info_format(NDI_UNIQUE | NDI_ORANGE, 0, op, - "You tell to %s: %s", pl->ob->name, params); + "You tell %s: %s", pl->ob->name, params); return 1; } Index: server/commands.c =================================================================== RCS file: /cvsroot/crossfire/crossfire/server/commands.c,v retrieving revision 1.39 diff -u -r1.39 commands.c --- server/commands.c 13 Sep 2003 05:02:09 -0000 1.39 +++ server/commands.c 16 Sep 2003 03:31:34 -0000 @@ -132,6 +132,7 @@ CommArray_s CommunicationCommands [] = { /* begin emotions */ {"tell", command_tell, 0.1}, + {"set_reply", command_sreply, 0.0}, {"reply", command_reply, 0.0}, {"say", command_say, 0.1}, {"shout", command_shout, 0.1}, -------------- next part -------------- ? .tm_project.cache ? Makefile ? autom4te.cache ? config.log ? config.status ? crossfire.prj ? crossfire.pws ? libtool ? common/.deps ? common/Makefile ? common/st6KFc92 ? crossedit/.deps ? crossedit/.libs ? crossedit/Makefile ? crossedit/crossedit ? crossedit/Cnv/.deps ? crossedit/Cnv/Makefile ? crossedit/bitmaps/Makefile ? crossedit/doc/Makefile ? crossedit/include/Makefile ? devel/.deps ? devel/.libs ? devel/Makefile ? devel/crossfire-config ? doc/Makefile ? doc/Developers/Makefile ? doc/playbook/Makefile ? doc/playbook-html/Makefile ? doc/scripts/Makefile ? doc/spell-docs/Makefile ? doc/spoiler/Makefile ? doc/spoiler-html/Makefile ? include/Makefile ? include/autoconf.h ? include/stamp-h1 ? lib/Makefile ? lib/checkarch.pl ? lib/collect.pl ? plugin/.deps ? plugin/Makefile ? random_maps/.deps ? random_maps/.libs ? random_maps/Makefile ? random_maps/random_map ? server/.deps ? server/.libs ? server/Makefile ? server/crossfire ? socket/.deps ? socket/Makefile ? utils/Makefile ? utils/add_throw.perl ? utils/crossloop ? utils/crossloop.pl ? utils/crossloop.pl.tmpl ? utils/crossloop.tmpl ? utils/crossloop.web ? utils/metaserver.pl ? utils/scores.pl Index: server/commands.c =================================================================== RCS file: /cvsroot/crossfire/crossfire/server/commands.c,v retrieving revision 1.39 diff -u -r1.39 commands.c --- server/commands.c 13 Sep 2003 05:02:09 -0000 1.39 +++ server/commands.c 16 Sep 2003 03:59:07 -0000 @@ -135,6 +135,7 @@ {"reply", command_reply, 0.0}, {"say", command_say, 0.1}, {"shout", command_shout, 0.1}, + {"me", command_me, 0.1}, {"nod", command_nod, 0.0}, {"dance", command_dance, 0.0}, {"kiss", command_kiss, 0.0}, -------------- next part -------------- ? .tm_project.cache ? Makefile ? autom4te.cache ? config.log ? config.status ? crossfire.prj ? crossfire.pws ? libtool ? common/.deps ? common/Makefile ? common/st6KFc92 ? crossedit/.deps ? crossedit/.libs ? crossedit/Makefile ? crossedit/crossedit ? crossedit/Cnv/.deps ? crossedit/Cnv/Makefile ? crossedit/bitmaps/Makefile ? crossedit/doc/Makefile ? crossedit/include/Makefile ? devel/.deps ? devel/.libs ? devel/Makefile ? devel/crossfire-config ? doc/Makefile ? doc/Developers/Makefile ? doc/playbook/Makefile ? doc/playbook-html/Makefile ? doc/scripts/Makefile ? doc/spell-docs/Makefile ? doc/spoiler/Makefile ? doc/spoiler-html/Makefile ? include/Makefile ? include/autoconf.h ? include/stamp-h1 ? lib/Makefile ? lib/checkarch.pl ? lib/collect.pl ? plugin/.deps ? plugin/Makefile ? random_maps/.deps ? random_maps/.libs ? random_maps/Makefile ? random_maps/random_map ? server/.deps ? server/.libs ? server/Makefile ? server/crossfire ? socket/.deps ? socket/Makefile ? utils/Makefile ? utils/add_throw.perl ? utils/crossloop ? utils/crossloop.pl ? utils/crossloop.pl.tmpl ? utils/crossloop.tmpl ? utils/crossloop.web ? utils/metaserver.pl ? utils/scores.pl Index: include/player.h =================================================================== RCS file: /cvsroot/crossfire/crossfire/include/player.h,v retrieving revision 1.33 diff -u -r1.33 player.h --- include/player.h 13 Sep 2003 05:01:34 -0000 1.33 +++ include/player.h 16 Sep 2003 03:49:47 -0000 @@ -161,6 +161,7 @@ char killer[BIG_NAME]; /* Who killed this player. */ char last_tell[MAX_NAME]; /* last player that told you something [mids 01/14/2002] */ + char reply_to[MAX_NAME]; /* player to the one we want to reply */ char write_buf[MAX_BUF]; /* Holds arbitrary input from client */ char input_buf[MAX_BUF]; /* Holds command to run */ Index: include/sproto.h =================================================================== RCS file: /cvsroot/crossfire/crossfire/include/sproto.h,v retrieving revision 1.96 diff -u -r1.96 sproto.h --- include/sproto.h 13 Sep 2003 05:01:34 -0000 1.96 +++ include/sproto.h 16 Sep 2003 03:49:49 -0000 @@ -73,6 +73,7 @@ int command_orcknuckle(object *op, char *params); int command_shout(object *op, char *params); int command_tell(object *op, char *params); +int command_sreply(object *op, char *params); int command_reply(object *op, char *params); int command_nod(object *op, char *params); int command_dance(object *op, char *params); Index: server/c_chat.c =================================================================== RCS file: /cvsroot/crossfire/crossfire/server/c_chat.c,v retrieving revision 1.15 diff -u -r1.15 c_chat.c --- server/c_chat.c 28 Jul 2003 05:19:35 -0000 1.15 +++ server/c_chat.c 16 Sep 2003 03:49:50 -0000 @@ -162,8 +162,62 @@ return 1; } -/* Reply to last person who told you something [mids 01/14/2002] */ -int command_reply (object *op, char *params) { +/* Sets the value of the reply_to field of a player */ +int command_sreply(object *op, char *params) { + player *pl; + + if (params==NULL) { + /* check if player is still connected */ + pl=find_player(op->contr->last_tell); + + if (pl==NULL){ + new_draw_info(NDI_UNIQUE, 0, op, + "Can't set reply_to value, this player left."); + return 1; + } + else { + /* Update reply_to value */ + strcpy(op->contr->reply_to, pl->ob->name); + new_draw_info_format(NDI_UNIQUE, 0, op, + "Reply_to value set to %s.", pl->ob->name); + return 1; + } + } + + while (*params==' ') params++; + + if (!strncmp(params,"-r",2)) { + /* Remove the reply_to value */ + op->contr->reply_to[0] = '\0'; + new_draw_info(NDI_UNIQUE, 0, op, + "Reply_to value was removed."); + } + else if (!strncmp(params,"-v",2)) { + /* View the reply_to value if it exists */ + if (op->contr->reply_to==NULL) { + new_draw_info(NDI_UNIQUE, 0, op, + "You will reply to the last person that tells you something."); + } + else { + /* NOTE: reply_to can be set to a player that is not logged any more * + * we make the control on if he's logged or not in the reply command.* + * So, if the player comes back online we can still reply to him/her. */ + new_draw_info_format(NDI_UNIQUE, 0, op, + "You will reply to %s.", op->contr->reply_to); + } + } + else { + /* Unknown parameter */ + new_draw_info(NDI_UNIQUE, 0, op, + "Usage: \n 'set_reply\n 'set_reply -r\n 'set_reply -v"); + } + return 1; +} + + +/* Reply to last person who told you something [mids 01/14/2002] * + * or to the player set in the reply_to player field if it exists */ +int command_reply(object *op, char *params) { player *pl; if (params == NULL) { @@ -171,13 +225,16 @@ return 1; } - if (op->contr->last_tell[0] == '\0') { + if (op->contr->last_tell[0] == '\0' && op->contr->reply_to[0] == '\0') { new_draw_info(NDI_UNIQUE, 0, op, "You can't reply to nobody."); return 1; } /* Find player object of player to reply to and check if player still exists */ - pl = find_player(op->contr->last_tell); + if (op->contr->reply_to[0] == '\0') + pl = find_player(op->contr->last_tell); + else + pl = find_player(op->contr->reply_to); if (pl == NULL) { new_draw_info(NDI_UNIQUE, 0, op, "You can't reply, this player left."); @@ -188,9 +245,9 @@ strcpy(pl->last_tell, op->name); new_draw_info_format(NDI_UNIQUE | NDI_ORANGE, 0, pl->ob, - "%s tells you: %s", op->name, params); + "%s tells you: %s", op->name, params); new_draw_info_format(NDI_UNIQUE | NDI_ORANGE, 0, op, - "You tell to %s: %s", pl->ob->name, params); + "You tell %s: %s", pl->ob->name, params); return 1; } Index: server/commands.c =================================================================== RCS file: /cvsroot/crossfire/crossfire/server/commands.c,v retrieving revision 1.39 diff -u -r1.39 commands.c --- server/commands.c 13 Sep 2003 05:02:09 -0000 1.39 +++ server/commands.c 16 Sep 2003 03:49:51 -0000 @@ -132,9 +132,11 @@ CommArray_s CommunicationCommands [] = { /* begin emotions */ {"tell", command_tell, 0.1}, + {"set_reply", command_sreply, 0.0}, {"reply", command_reply, 0.0}, {"say", command_say, 0.1}, {"shout", command_shout, 0.1}, + {"me", command_me, 0.1}, {"nod", command_nod, 0.0}, {"dance", command_dance, 0.0}, {"kiss", command_kiss, 0.0}, From crossfire-devel-admin at archives.real-time.com Mon Sep 15 23:48:03 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:55:05 2005 Subject: [CF-Devel] New comunication commands. 'me and 'set_reply In-Reply-To: <20030916013818.2bc8e9b4.kstenger@montevideo.com.uy> References: <20030916013818.2bc8e9b4.kstenger@montevideo.com.uy> Message-ID: <20030916014803.14863058.kstenger@montevideo.com.uy> Maybe i forgot to explain why this set_reply function :-) Well... many times happened to me and other people that using the reply command is not really secure, if a person tells you something, you begin replying to him/her and in the middle another person tells you something the message may go to the wrong person. But it wont hapen if you set_reply before using the reply command :D Hope you like it! Katia. -- +-----------------------------+ | Karla M? Stenger S?bat | | Pando . Canelones . Uruguay | | kstenger@montevideo.com.uy | +-----------------------------+ _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Tue Sep 16 11:58:19 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:55:05 2005 Subject: [CF-Devel] Server Crash on random maps Message-ID: <1063731498.1184.16.camel@d5110227.lss.emc.com> Playing on Metalforge with the recent update, there are frequent crashes. It appears to happen when someone applies an exit in a random map (to go to the next level). This only happens perhaps 5% of the time. Next time I play, I'll try to get the mapinfo on each level so that I can post the last one if I get a crash. In the meantime, hopefully the admin will find a stack trace. --PC _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Tue Sep 16 14:08:19 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:55:05 2005 Subject: [CF-Devel] client code Message-ID: <1063739299.1184.36.camel@d5110227.lss.emc.com> >>In common/client.h, the Player_Struct has several unused fields: name, >>password, and shoottype. > > > Removing those seems to cause problems. Are we essentially doing a memcopy > from the server into that struct, or is there some other reason for removal > of those unused fields to cause problems? > > Can you be more specific on 'cause problems'? I can't see any > reason for those fields to be accessed indirectly. Could be some > buffer overflow issue with input_text, and being that these fields > are after that, they extra bytes they provide mask the problem. It was behaving very strangely--all the statistics in the display were unexpected values. When I was logging in, my character name was hidden, and my password was displayed on the screen. I tried to recreate it, and now it works fine without those fields. --PC _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Thu Sep 18 10:42:43 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:55:05 2005 Subject: [CF-Devel] questions about new skill object Message-ID: <25464.1063899763@www22.gmx.net> Hi, This is all about the new skills. I like the new skill system very much. Great work. While I was trying to update the "types.xml" for the CFJavaEditor, some things about the SKILL object type (43) were unclear to me, so I'd like to ask... 1. "name" vs. "skill" attribute: According to the documentation, those two strings should or must be identical. They are used for skill matchings. I think having the two of them may simplify code, but it's quite irritating for arch-builders and mapmakers. Taking a glance at the code, it seems like most (/all?) of the matchings are applied to the "skill" attribute and not the object name. I think it would be worthwile to define only one attribute as responsible for matchings. For example "skill" is for matchings, and "name" doesn't matter. This can prevent errors too. 2. "subtype" attribute: This one seems to define the base functionality of the skill. It is the "link" between skill archtype and skill functions in the server, AFAIK. What I would have expected from this, is that I can define for example three different literacy skills - each with literacy subtype, but different stats. However, it turned out the server seems to require that each subtype appears only once in one skill archtype. That's no problem, but I would like to know: Why is this attribute in the arches at all? There seems to be no additional information contained in it. The skill names are already unique. The server code could just as well use the skill names to identify skills, couldn't it? Or the other way round: subtype could be used for all matchings, and we don't need skill names. (The JavaEditor can associate subtype numbers with names, so readability shouldn't be of concern.) 3. double meaning of "exp" and "level": When I understood the documentation correctly, the meaning of the "exp" and "level" attributes is different depending on wether the object is a default arch, or a map object. Is this true? When I take a default skill arch and put it into the inventory of a monster, does the meaning of exp and level suddenly change? Do I not even need to correct the values then? Or maybe the meaning won't change as long as I don't edit the values on the map... uh oh. If this is the case, I would strongly advise to split the different meanings into different variables. I wouln't even know how I can explain such a double-behaviour in the JavaEditor without really confusing people. AndreasV -- +++ GMX - die erste Adresse f?r Mail, Message, More! +++ Getestet von Stiftung Warentest: GMX FreeMail (GUT), GMX ProMail (GUT) (Heft 9/03 - 23 e-mail-Tarife: 6 gut, 12 befriedigend, 5 ausreichend) Jetzt selbst kostenlos testen: http://www.gmx.net _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Thu Sep 18 12:04:57 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:55:05 2005 Subject: [CF-Devel] Difference between a player file on 1.5.0 and player file on cvs-server-16 september 2003 Message-ID: An HTML attachment was scrubbed... URL: http://shadowknight.real-time.com/pipermail/crossfire/attachments/20030918/2bc5964b/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: Dalosein.tar.bz2 Type: application/octet-stream Size: 4575 bytes Desc: Dalosein.tar.bz2 Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20030918/2bc5964b/Dalosein.tar.obj From crossfire-devel-admin at archives.real-time.com Thu Sep 18 12:21:15 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:55:05 2005 Subject: [CF-Devel] Difference between a player file on 1.5.0 and player file on cvs-server-16 september 2003 In-Reply-To: References: Message-ID: <1063905675.7468.9.camel@d5110227.lss.emc.com> On Thu, 2003-09-18 at 13:04, Cross fire wrote: > Hopefully this will help convert the playerfile to the > new server so > players aren't lost on Metalforge. As one who plays there, thanks! On a related note, is there also a script to convert apartment exits for moving to the bigworld maps? --PC _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Thu Sep 18 12:25:28 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:55:05 2005 Subject: [CF-Devel] xp saving bug Message-ID: <1063905928.7468.14.camel@d5110227.lss.emc.com> There's a bug in saving experience points. The internal values are 64-bit, but when you log out, it saves it in ASCII using a routine that interprets it as a signed 32-bit value. It's also still sending the 32-bit version to the client. --PC _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Fri Sep 19 00:01:44 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:55:05 2005 Subject: [CF-Devel] questions about new skill object In-Reply-To: <25464.1063899763@www22.gmx.net> References: <25464.1063899763@www22.gmx.net> Message-ID: <3F6A8DB8.50906@sonic.net> Andreas Vogl wrote: > Hi, > > This is all about the new skills. > I like the new skill system very much. Great work. Thanks. > > While I was trying to update the "types.xml" for the CFJavaEditor, > some things about the SKILL object type (43) were unclear to me, > so I'd like to ask... > > 1. "name" vs. "skill" attribute: > According to the documentation, those two strings should or > must be identical. They are used for skill matchings. > > I think having the two of them may simplify code, but it's quite > irritating for arch-builders and mapmakers. > Taking a glance at the code, it seems like most (/all?) of the > matchings are applied to the "skill" attribute and not the object name. > I think it would be worthwile to define only one attribute as > responsible for matchings. For example "skill" is for matchings, > and "name" doesn't matter. This can prevent errors too. I agree. I'm actually not sure if there are any cases where there are any cases where we look at the skill name, other than when naming objects (eg, scroll of literacy). I'm trying to remember why I did it that way. In any case, if there are cases where op->skill is being against op->name, that is probably a bug that should be fixed. > > 2. "subtype" attribute: > This one seems to define the base functionality of the skill. > It is the "link" between skill archtype and skill functions in > the server, AFAIK. > > What I would have expected from this, is that I can define for example > three different literacy skills - each with literacy subtype, but > different stats. However, it turned out the server seems to > require that each subtype appears only once in one skill archtype. > > That's no problem, but I would like to know: > Why is this attribute in the arches at all? There seems to be no > additional information contained in it. The skill names are already > unique. The server code could just as well use the skill names > to identify skills, couldn't it? > Or the other way round: subtype could be used for all matchings, > and we don't need skill names. (The JavaEditor can associate subtype > numbers with names, so readability shouldn't be of concern.) Well, the idea of having multiple skills of the same subtype was something I wanted to allow for. Thus, you can have 'beginning literacy' for example, which doesn't give you a bunch of bonuses or something, and go on some quest and get 'expert literacy' which gives something extra. And I believe you can actually do this. The problem is having multiple varieties of the same skill in the archetype. The problem is that there are some cases in the code where we need to say 'hey, the player doesn't have skill lockpicking, and we need to give it to them. So it then finds the skill lockpicking and gives it to the player. Where this comes up is in the case of skill tools (lockpicks, talismans, might be some others I'm forgetting). Basically, the player is able to use and gain exp in the skill by getting that item, but isn't a skill they really have. Probably the right way to do this is put a flag or something in the archetype which says 'use this skill when we need to give them the skill in that case'. Thus, you could have multiple lock picking skills in the archetype. However, looking at the code, I notice the learn_skill just looks at the scroll->skill pointer - it should probably do something more like spells at look at the object inside the scroll and give that out. Also, there would be some trickery involved - I'd think that if you have different skills that do the same thing (eg, lockpicking and 'master lockpicking' for example), you'd have to know which is the one that is the better skill. Eg, if you have lockpicking, and learn master lockpicking, that should basically replace the other skill (copying over exp and other bits). If you have master lockpicking and try to learn lockpicking, it should say something like 'hey, you already know master lockpicking'. > > 3. double meaning of "exp" and "level": > When I understood the documentation correctly, the meaning of the > "exp" and "level" attributes is different depending on wether > the object is a default arch, or a map object. > Is this true? There is a difference in it being an arch and actual in use object. In retrospect, probably not a good idea for many reasons. Basically, the archetype is determined how the reward works out for using the skill. This unfortunately means that that if you want to make new varieties of skills, you would need an archetype, and see problem above. I really should have tossed those values into the object. > > When I take a default skill arch and put it into the inventory > of a monster, does the meaning of exp and level suddenly > change? Do I not even need to correct the values then? > Or maybe the meaning won't change as long as I don't > edit the values on the map... uh oh. > > If this is the case, I would strongly advise to split the > different meanings into different variables. > I wouln't even know how I can explain such a double-behaviour > in the JavaEditor without really confusing people. skills for monsters work a little bit differently - they don't always need skills. But yeah, it should work more sanely. I'll see about cleaning some of that up. Some was probably left behind since in some sense as it started out, it was to some extent a conversion of the older skill code, which didn't really have anything adjustable a an object level, so tossing it into the archetype didn't seem like a really bad idea at the time. I'd be interested in hearing on what plans people have for the skills, as it may make it easier to know what to design for. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Fri Sep 19 00:04:25 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:55:05 2005 Subject: [CF-Devel] Difference between a player file on 1.5.0 and player file on cvs-server-16 september 2003 In-Reply-To: <1063905675.7468.9.camel@d5110227.lss.emc.com> References: <1063905675.7468.9.camel@d5110227.lss.emc.com> Message-ID: <3F6A8E59.6000204@sonic.net> Preston Crow wrote: > On Thu, 2003-09-18 at 13:04, Cross fire wrote: > >> Hopefully this will help convert the playerfile to the >> new server so >> players aren't lost on Metalforge. > > > As one who plays there, thanks! > > On a related note, is there also a script to convert apartment exits for > moving to the bigworld maps? > The Info/update_apart script in the maps directory should do the job. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Fri Sep 19 00:10:42 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:55:05 2005 Subject: [CF-Devel] xp saving bug In-Reply-To: <1063905928.7468.14.camel@d5110227.lss.emc.com> References: <1063905928.7468.14.camel@d5110227.lss.emc.com> Message-ID: <3F6A8FD2.202@sonic.net> Preston Crow wrote: > There's a bug in saving experience points. The internal values are > 64-bit, but when you log out, it saves it in ASCII using a routine that > interprets it as a signed 32-bit value. The FASTCAT changes that were made broke this bit. > > It's also still sending the 32-bit version to the client. Not true. Up to date clients should get 64 bit values. Since this is a change in format of data, only new clients will request 64 bit values to be sent, so it still 'sort of' works on older clients (albeit, once the players exp goes beyond the 32 bit value, things get screwed up). _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Fri Sep 19 08:52:30 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:55:06 2005 Subject: [CF-Devel] Stove issue Message-ID: <3F6B0A1E.20905@laposte.net> Hello. I have some issues with making food on a stove. For some reason client crashes when i leave the container. What i usually do is: open container, drop things, use_skill woodsman, move one square left, one square right (to update container display), pick items. That combo works fine for bowyer. But for woodsman (stove), it crashes often when i leave the stove. The alchemy code used is common, so maybe that's an issue with the stove itself? or the medieval kitchen in Scorn? (where i do my experiments). I'm using GTK 1.5.0, version 0.7 for Windows 2000 (latest version i'm aware of). As soon as i compile the client, i'll look at that bug, but right now i still haven't succeeded.... Nicolas 'Ryo' _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Fri Sep 19 09:48:00 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:55:06 2005 Subject: [CF-Devel] Stove issue In-Reply-To: <3F6B0A1E.20905@laposte.net> References: <3F6B0A1E.20905@laposte.net> Message-ID: <3F6B1720.8050406@laposte.net> Correction, that bug appears with alchemy too..... I did a lot of boweyery (with commands like drop 1 claw; drop 20 arrow; use_skill bowyer; east; west; apply; get), and it didn't crash once... Weird, wonder what the bug is... Nicolas 'Ryo' _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Sat Sep 20 11:29:26 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:55:06 2005 Subject: [CF-Devel] shouting channels Message-ID: <1064075366.542.7.camel@oberon.Kameria> Here is a topic I posted to the CF forum of a functionality I would like to see in the game - Shouting Channels I am liking this idea more as I think more about it. I realize that people in a party can use gsay but a party also entails sharing Xp however - what about if you want to tune into a chat without being in a party? Well if there were channels that you could create and listen to that would be nice. Say I am new - I can sign up for the newbie channel, or if I am am in a guiild I can sign up for the guild channel. This would be great IMHO. I saw this on a few muds and think it is good way to have community and not have to listen to everything. A command to view the current list and start up or sign up for channels would be great IMHO. I am not sure passwords are a good idea here - this is not a private conversation sort of thing and there is still gsay and good old fashioned say and tell for more private conversation. Here is how I picture it working: The server will initialize an array of a defined size (set in etc/settings - maybe something like 99 or whatever is a useful number) and populate it with some channel names from a file called var/channels and fill the rest of the array with nulls.) There is an array added to player structure to hold the channel names players subscribe to. There is a command to add a new channel (temporary) like 'channel add ', to list all the channels like 'channel list', to subscribe to channels like 'channel join '. The channel list will show the channel name and the operator name. Maybe a command like channel hide that checks to see if you are the creator and takes it off the list of channels. Of course channel close which will remove the channel if you are the operator. There is a DM command to make a channel permanent (writes the channel name to the file in var) So when you want a new channel you add it and it is added with your name attached - if you leave the game the chanel is removed. If a Dm sets a channel or it is hardwritten into the channel file in var then it is not assigned to any player and is persistant. An entry is added into new_draw_info that checks if the message is a channel shout (by using the listen level for channel shouts - something we set up) and if so if you are subscribed to a particular channel - if you are you get the message. Maybe the command would be 'cshout' for "channel shout"? To shout you have to type 'cshout ', if you want to shout to all chanels you belong to you type 'cshout all" I guess channel messages would appear like and all channel messages should be the same colour to distinguish that this is where the message is coming from. So to recap - anyone can make a channel but only DM or admins can set up permanent chanels that stay around. If you leave your channel is closed. Then if you want to shout - it's still ok but really if you are shouting all the time the DM will shut you up. Sound reasonable? Any other thought on this? I guess finding out what are the different listening levels would have to be done but as far as I can tell 0 is system, 1 is shout and 5 is used for stuff like players joining or leaving the game so maybe 2 or 3 would be a good one to use since you will only get messages if you join a channel and I can see folks turning off other messaging but keeping this on for stuff they signed on for. - so any thoughts? _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Sat Sep 20 21:34:48 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:55:06 2005 Subject: [CF-Devel] random door styles Message-ID: <1064111688.1278.182.camel@oberon.Kameria> I made a change in random_styles/door.c to allow for some special random doors like rocks or shrubs spiderwebs you can chop away at. I did this for some sylvan maps I was playing with, but it could be useful otherwise as well I think. Rather than having weird doors showing up in old random maps I made it so that these have to be specified in the message field as 'doorstyle special/x' where x is the style. If 'special' is not specified the normal doors will be used. The next step I think is to do some things to doors to make them a bit more interesting - like have a flag for turning off the traps, a level for lockpicking attempts. I did notice a weird glitch when 'doorstyle special' is used (to get a random map from the special directory) it does correctly look for a random map in special (shows as loading a random map in the log anyway) but the doors arent actually put on the map all the time...? -------------- next part -------------- A non-text attachment was scrubbed... Name: random_door.patch Type: text/x-patch Size: 808 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20030920/26269693/random_door.bin From crossfire-devel-admin at archives.real-time.com Sun Sep 21 11:58:48 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:55:06 2005 Subject: [CF-Devel] Patch submission: item custom name partial match Message-ID: <3F6DD8C8.8040508@laposte.net> Hello. My rename patch made it to CVS, but I had missed partial name matching in item_matched_string So here's the patch for that. (for common/arch.c) Pretty straightforward, just added a strstr(op->custom_name,cp) Note that returned value is 3, meaning partial item name is almost the lowest priority taken into account. Nicolas 'Ryo' -------------- next part -------------- Index: arch.c =================================================================== RCS file: /cvsroot/crossfire/crossfire/common/arch.c,v retrieving revision 1.26 diff -c -3 -r1.26 arch.c *** arch.c 13 Sep 2003 05:01:26 -0000 1.26 --- arch.c 21 Sep 2003 16:55:40 -0000 *************** *** 248,253 **** --- 248,258 ---- else if (strstr(query_base_name(op,1), cp)) retval = 12; else if (strstr(query_base_name(op,0), cp)) retval = 12; else if (strstr(query_short_name(op), cp)) retval = 12; + /* Check for partial custom name, but give a real low priority */ + else if (op->custom_name && strstr(op->custom_name, cp)) { + pl->contr->count=count; /* May not do anything */ + retval = 3; + } if (retval) { if (pl->type == PLAYER) From crossfire-devel-admin at archives.real-time.com Sun Sep 21 12:05:43 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:55:06 2005 Subject: [CF-Devel] attach.h question Message-ID: <3F6DDA67.5030301@laposte.net> There's a weird thing in the code, in attack.h: #define num_resist_table 21 Except there are only 20 attack types as defined by resist_table... And that's an issue, at least under Windows, because in common/treasure.c there is resist=RANDOM() % num_resist_table; followed by while (op->resist[resist_table[resist]]!=0 && b<4) { So 'resist' can be 20, on the other hand resist_table (in attack.h) has only 20 elements. And that crashes (assertion failure you can ignore, but still) straight under Windows, randomly. Sounds to me there's a mistake here :) Nicolas 'Ryo' _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Mon Sep 22 23:25:58 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:55:06 2005 Subject: [CF-Devel] attach.h question In-Reply-To: <3F6DDA67.5030301@laposte.net> References: <3F6DDA67.5030301@laposte.net> Message-ID: <3F6FCB56.7060408@sonic.net> Nicolas Weeger wrote: > There's a weird thing in the code, in attack.h: > > #define num_resist_table 21 > > Except there are only 20 attack types as defined by resist_table... > And that's an issue, at least under Windows, because in > common/treasure.c there is > > resist=RANDOM() % num_resist_table; > > followed by > > while (op->resist[resist_table[resist]]!=0 && b<4) { > > So 'resist' can be 20, on the other hand resist_table (in attack.h) has > only 20 elements. > And that crashes (assertion failure you can ignore, but still) straight > under Windows, randomly. > > Sounds to me there's a mistake here :) Fixed in CVS. I broke this because I was originally adding two new attack types as part of the spell/skill stuff, but only added one and forgot to remove that entry. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Mon Sep 22 23:44:22 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:55:06 2005 Subject: [CF-Devel] Patch submission: item custom name partial match In-Reply-To: <3F6DD8C8.8040508@laposte.net> References: <3F6DD8C8.8040508@laposte.net> Message-ID: <3F6FCFA6.3060209@sonic.net> Nicolas Weeger wrote: > Hello. > > My rename patch made it to CVS, but I had missed partial name matching > in item_matched_string > So here's the patch for that. (for common/arch.c) Committed to CVS. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Tue Sep 23 00:24:31 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:55:06 2005 Subject: [CF-Devel] autoconfig requirements In-Reply-To: <1063477456.542.57.camel@oberon.Kameria> References: <1063477456.542.57.camel@oberon.Kameria> Message-ID: <3F6FD90F.10207@sonic.net> Todd Mitchell wrote: > One think I have brought up before and now again is that the > requirements to make the server are now automake1.7 and autoconfig 2.54 > or higher. These exceed the standard versions of these tool s in Debian > stable and likely many other distros. Are these versions really > requirements? I have managed to make the server by changing the > aclocal.m4 entry for autoconfig 2.54 to 2.52 and it compiles fine as far > as I can see (some automake warning but otherwise fine). This would > represent a problem howver for folks not familiar with the server and > with distros that do not have this version of automake. Should we > really force people to update standard OS tools to install a game? My > point is if it isn't really a requirement then can we change it so that > people have less problems? I am not saying that progress is not wanted > or that tools do not evolve, but arbitrary pseudo-requrements that cause > barriers or confusion for people are not good. We cannot and do not > want to be tracking OS distros, but if a *required* tool version is not > in a major release such as Debian stable and is not *really* required I > can't see the value here. I think it should be changed or someone > explain the necessity. Personally I think it was likely slipped in by > accident. Looking at that code a little tonight, it appears that if you use the 'autogen.sh' script in the top level directory, it then goes and runs aclocal and autoheader. aclocal then embeds the versions of the various tools in its own files. The real solution is probably for users who have older versions to re-run the aclocal/autoheader/automake themselves. The problem is that this re-generates all the makefiles. The better solution is probably to never use the autogen file. Unless your actually changing the some of the custom macros, you should never need to run aclocal. If all that is happening is that some makefile.am's are updated, all that should need to be done is run automake, which should hopefully not rev the required version information. > > On a related note I think the server config should also check for X > libraries and if they are not there it should not attempt to make > crossedit. Someone on this list should be educated enough in the build > configure scripting to be able to make that work, no? Isn't it possible > to do something like: > > if not x11LIBS: > SUBDIRS = A B C > > else: > SUBDIRS = A B C crossedit This should now be in place. Not that hard in fact - just had to read the automake manual. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Tue Sep 23 01:02:19 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:55:06 2005 Subject: [CF-Devel] random door styles In-Reply-To: <1064111688.1278.182.camel@oberon.Kameria> References: <1064111688.1278.182.camel@oberon.Kameria> Message-ID: <3F6FE1EB.1010506@sonic.net> Todd Mitchell wrote: > I made a change in random_styles/door.c to allow for some special random > doors like rocks or shrubs spiderwebs you can chop away at. > I did this for some sylvan maps I was playing with, but it could be > useful otherwise as well I think. Rather than having weird doors > showing up in old random maps I made it so that these have to be > specified in the message field as 'doorstyle special/x' where x is the > style. If 'special' is not specified the normal doors will be used. I'd think I'd like this code to be a little more flexible. Instead of looking for 'special', I'd rather that it does something more generic to see if there is a / in the style name. Or alternatively, have it just look for the stylename as set, and if it doesn't find it, then have it fall back to looking for hdoor/vdoor paths. > > The next step I think is to do some things to doors to make them a bit > more interesting - like have a flag for turning off the traps, a level > for lockpicking attempts. Looking at the code, it appears it basically just copies the object from the style map onto the map in question. Thus, you can disable traps by setting 'randomitems NONE' in that object. Note that currently, the lockpick code looks at just the difficulty of the map. It wouldn't be hard for it to look at the level of the door. And in that case, once again, just setting the level in the door object on the style map would be enough. > > I did notice a weird glitch when 'doorstyle special' is used (to get a > random map from the special directory) it does correctly look for a > random map in special (shows as loading a random map in the log anyway) > but the doors arent actually put on the map all the time...? I think that is the case - you could probably look at the parameters used to build the map and generate an ascii one. I think sometimes it decides to just leave empty spaces instead of doors. This may depend on the style of the map. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Tue Sep 23 01:41:49 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:55:06 2005 Subject: [CF-Devel] shouting channels In-Reply-To: <1064075366.542.7.camel@oberon.Kameria> References: <1064075366.542.7.camel@oberon.Kameria> Message-ID: <3F6FEB2D.6000303@sonic.net> Todd Mitchell wrote: > > So when you want a new channel you add it and it is added with your name > attached - if you leave the game the chanel is removed. If a Dm sets a > channel or it is hardwritten into the channel file in var then it is not > assigned to any player and is persistant. You'd probably want to have some functionality like 'reassign channel' which lets you give the channel to someone else. Eg, suppose there is a group of people talking (shouting), but the person that created the channel needs to leave. For convenience, it'd be nice to give someone else ownership of that channel so that it sticks around and people can continue to chat on the same channel. > > An entry is added into new_draw_info that checks if the message is a > channel shout (by using the listen level for channel shouts - something > we set up) and if so if you are subscribed to a particular channel - if > you are you get the message. That's not the right place to code it. Instead, it should be coded wherever the channel shout function is used (eg, have that code iterate through the players to see if the channel the player is shouting matches any each player is subscribed to). Trying to change new_draw_info is just making things much more complicated than it needs to be. I'd also put in code where the player can only shout at the channel if they are subscribed to it. > > So to recap - anyone can make a channel but only DM or admins can set up > permanent chanels that stay around. If you leave your channel is closed. > > Then if you want to shout - it's still ok but really if you are shouting > all the time the DM will shut you up. > > Sound reasonable? Any other thought on this? I guess finding out what > are the different listening levels would have to be done but as far as I > can tell 0 is system, 1 is shout and 5 is used for stuff like players > joining or leaving the game so maybe 2 or 3 would be a good one to use > since you will only get messages if you join a channel and I can see > folks turning off other messaging but keeping this on for stuff they > signed on for. > > - so any thoughts? Probably better to do it with dynamic sizing and not hardcoded sizes. this wouldn't be that much harder to do, and prevents the otherwise forseeable problem of running out of channel. You probably want to limit the number of channels any player can create. Eg, you don't want some abuser to log in and create 500 channels - even if the number of allowed channels is dynamic, a listing that long would just be unmanageable. For the player side of things, you could just easily have a pointer like 'char *subscribed_channels', and just have that be a comma seperated list of channnels the player is subscribed to, eg, 'newbie,town,dm'. Then for that string, it's just a matter of alloc, copy, etc. If you take that approach, things are much more interesting - I could do something like 'cshout asdf some random message', and it then just checks all the players to see if anyone has 'asdf' listed in that string, and if so, they get that message. By doing so, you no longer need a list of channels. Players can basically create their own channels by creating them, eg, 'subscribe blahblahblah', and if someone does a 'cshout blahblahblah ....', you get it. Official channel listing is only really needed then so players have an idea of what channels are available. Note that this method also means there is no worry about some player creating 500 channels. Sure, they can subscribe to 500 channels, but if no one else knows about them, who cares. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Wed Sep 24 01:04:27 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:55:06 2005 Subject: [CF-Devel] random door styles In-Reply-To: <3F6FE1EB.1010506@sonic.net> References: <1064111688.1278.182.camel@oberon.Kameria> <3F6FE1EB.1010506@sonic.net> Message-ID: <1064383467.543.31.camel@oberon.Kameria> On Tue, 2003-09-23 at 02:02, Mark Wedel wrote: > Todd Mitchell wrote: > > I made a change in random_styles/door.c to allow for some special random > > doors like rocks or shrubs spiderwebs you can chop away at. > > I did this for some sylvan maps I was playing with, but it could be > > useful otherwise as well I think. Rather than having weird doors > > showing up in old random maps I made it so that these have to be > > specified in the message field as 'doorstyle special/x' where x is the > > style. If 'special' is not specified the normal doors will be used. > > I'd think I'd like this code to be a little more flexible. Instead of looking > for 'special', I'd rather that it does something more generic to see if there is > a / in the style name. > > Or alternatively, have it just look for the stylename as set, and if it > doesn't find it, then have it fall back to looking for hdoor/vdoor paths. if(vdoors=find_style("/styles/doorstyles",doorstyle,-1)) hdoors=vdoors; else{ vdoors = find_style("/styles/doorstyles/vdoors",doorstyle,-1); if(!vdoors) return; sprintf(doorpath,"/styles/doorstyles/hdoors%s",strrchr(vdoors->path,'/')); hdoors = find_style(doorpath,0,-1); } - is this good then? Actually this is simpler yes and I see no need to have it pick a random style from the special folder (why I did it the other way first) as I can make a style map with all the different special types on it. > > > > > The next step I think is to do some things to doors to make them a bit > > more interesting - like have a flag for turning off the traps, a level > > for lockpicking attempts. > > Looking at the code, it appears it basically just copies the object from the > style map onto the map in question. > > Thus, you can disable traps by setting 'randomitems NONE' in that object. > oops silly me. I was wondering why the rocks had traps when obviously there were no randomitems in the mountain3 arch... but I'm not using the mountain3 arch - I'm using the door arch.... Doh. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Wed Sep 24 00:24:43 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:55:06 2005 Subject: [CF-Devel] random door styles In-Reply-To: <1064383467.543.31.camel@oberon.Kameria> References: <1064111688.1278.182.camel@oberon.Kameria> <3F6FE1EB.1010506@sonic.net> <1064383467.543.31.camel@oberon.Kameria> Message-ID: <3F712A9B.70503@sonic.net> Todd Mitchell wrote: > On Tue, 2003-09-23 at 02:02, Mark Wedel wrote: > > if(vdoors=find_style("/styles/doorstyles",doorstyle,-1)) > hdoors=vdoors; > else{ > vdoors = find_style("/styles/doorstyles/vdoors",doorstyle,-1); > if(!vdoors) return; > sprintf(doorpath,"/styles/doorstyles/hdoors%s",strrchr(vdoors->path,'/')); > hdoors = find_style(doorpath,0,-1); > } > > - is this good then? Actually this is simpler yes and I see no need to > have it pick a random style from the special folder (why I did it the > other way first) as I can make a style map with all the different > special types on it. Looks good. Should put an extra set of parens around the vdoors=find_style.., as it otherwise generates a compilation warning. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Wed Sep 24 01:07:30 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:55:06 2005 Subject: [CF-Devel] Stove issue In-Reply-To: <3F6B0A1E.20905@laposte.net> References: <3F6B0A1E.20905@laposte.net> Message-ID: <3F7134A2.7080206@sonic.net> Nicolas Weeger wrote: > Hello. > > I have some issues with making food on a stove. > For some reason client crashes when i leave the container. > What i usually do is: open container, drop things, use_skill woodsman, > move one square left, one square right (to update container display), > pick items. > That combo works fine for bowyer. > But for woodsman (stove), it crashes often when i leave the stove. > The alchemy code used is common, so maybe that's an issue with the stove > itself? or the medieval kitchen in Scorn? (where i do my experiments). > > I'm using GTK 1.5.0, version 0.7 for Windows 2000 (latest version i'm > aware of). > > As soon as i compile the client, i'll look at that bug, but right now i > still haven't succeeded.... I haven't been able to reproduce the bug with my unix version of the gtk client. However, I have fixed the bug in that the cauldron contents weren't getting updated as they should of. So the stop off/stop on shouldn't be required anymore. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Wed Sep 24 01:25:44 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:55:07 2005 Subject: [CF-Devel] New comunication commands. 'me and 'set_reply In-Reply-To: <20030916013818.2bc8e9b4.kstenger@montevideo.com.uy> References: <20030916013818.2bc8e9b4.kstenger@montevideo.com.uy> Message-ID: <3F7138E8.4070504@sonic.net> > diff -u -r1.15 c_chat.c > --- server/c_chat.c 28 Jul 2003 05:19:35 -0000 1.15 > +++ server/c_chat.c 16 Sep 2003 03:31:33 -0000 > @@ -162,8 +162,62 @@ > return 1; > } > + else if (!strncmp(params,"-v",2)) { > + /* View the reply_to value if it exists */ > + if (op->contr->reply_to==NULL) { That above if will never reveal true. That is because reply_to will always point to some string data. What you probably really want is 'if (op->contr->reply_to[0] == '\0') {' ... Check that the actual string is actually a null string. Otherwise, the patch seems OK. But I think at some level, I think improving the handling of this on the client would be a me relevant (a better chat interface). At some level, I don't want to re-invent irc within crossfire. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Wed Sep 24 02:07:46 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:55:07 2005 Subject: [CF-Devel] broken random map In-Reply-To: <20030910135245.5698.qmail@emc.com> References: <20030910135245.5698.qmail@emc.com> Message-ID: <3F7142C2.9020402@sonic.net> Preston Crow wrote: > It's been a while since I've seen a bad random map, but I ran into one on > Metalforge last night: > > (null) (/random/pirateisland0479) > xsize 17 > ysize 21 > wallstyle dungeon > floorstyle lightdirt > monsterstyle undead > decorstyle creepy > exitstyle sstair > dungeon_level 26 > dungeon_depth 50 > orientation 1 > origin_x 1 > origin_y 1 > random_seed 1063146276 > > I could see with x-ray vision where it should have been connected, but > there were no doors or secret doors (I'm quite certain I checked every > possible square). Yeah, I tracked down the problem to it trying to symmetrize rogue style layout maps. The symmetry code was originally meant for spirals. In that case, if you start in the center of the map and start making a passage in one direction, your bound to run into the spirals and thus connect things up. For rogue maps, this isn't the case as shown here - the passages miss the chambers by a space. My solution to this is to just disable the symmetrizing of roguelike maps. IMO, it probably doesn't add a whole bunch anyways. I cleaned up soem of the other code with this - I need to do a little more testing before I commit it. > > Oh, and there are still maps with keys that don't go to anything. I think > it's a holdover from when there were locked chests, but that's just a > guess. I'll try to remember to post the map information the next time I > see one. The random map code generates a whole bunch more keys than most people typically need, so you end up with a pile of keys at the end. It'd probably be nice for the keys to actually have some name, eg, instead of just 'special key', something like 'undead temple level 50 key' or something. Still not pretty, but at least then you know if the keys are basically useless and a key that is actually important (part of a quest or something) that also doesn't have a name. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Wed Sep 24 11:50:49 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:55:07 2005 Subject: [CF-Devel] Stove issue In-Reply-To: <3F7134A2.7080206@sonic.net> References: <3F6B0A1E.20905@laposte.net> <3F7134A2.7080206@sonic.net> Message-ID: <3F71CB69.8040803@laposte.net> > I haven't been able to reproduce the bug with my unix version of the > gtk client. > > However, I have fixed the bug in that the cauldron contents weren't > getting updated as they should of. So the stop off/stop on shouldn't > be required anymore. There are/were indeed inventory refresh issues. So maybe that's related to the crash... When the next Win GTK version is ready, i'll check :) *wants to make alchemy like crazy, but crashes too much for that...* Fun though, i've been doing much bowyery (2 ingredients recipes) without any trouble or crash... Nicolas 'Ryo' _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Wed Sep 24 12:20:26 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:55:07 2005 Subject: [CF-Devel] List archive causing spam Message-ID: <1064424026.10311.1.camel@d5110227.lss.emc.com> Would it be possible to remove or obscure the email addresses in the list archive? I've started receiving spam at my Crossfire address (I own my own domain, so I use different addresses in different places). --PC _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Wed Sep 24 12:31:50 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:55:07 2005 Subject: [CF-Devel] List archive causing spam In-Reply-To: <1064424026.10311.1.camel@d5110227.lss.emc.com> References: <1064424026.10311.1.camel@d5110227.lss.emc.com> Message-ID: Names and email addresses in the archive are obscured. Ex: http://archives.real-time.com/pipermail/crossfire-devel/2003-September/005104.html Or, am I not understanding the request? On Wed, 24 Sep 2003, Preston Crow wrote: > Would it be possible to remove or obscure the email addresses in the > list archive? I've started receiving spam at my Crossfire address (I > own my own domain, so I use different addresses in different places). _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Wed Sep 24 12:43:16 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:55:07 2005 Subject: [CF-Devel] List archive causing spam In-Reply-To: References: <1064424026.10311.1.camel@d5110227.lss.emc.com> Message-ID: <1064425396.10311.8.camel@d5110227.lss.emc.com> On Wed, 2003-09-24 at 13:31, Rick Tanner wrote: > Names and email addresses in the archive are obscured. > > Ex: > http://archives.real-time.com/pipermail/crossfire-devel/2003-September/005104.html > > Or, am I not understanding the request? I did a Google search on my Crossfire email address, and it shows up in the archive. Now I see that it is on older messages, so I'm surprised I haven't had spam on this address before. Example: http://archives.real-time.com/pipermail/crossfire-devel/2001-May/002256.html I guess it's time to kill this address and move to a new one. --PC > On Wed, 24 Sep 2003, Preston Crow wrote: > > > Would it be possible to remove or obscure the email addresses in the > > list archive? I've started receiving spam at my Crossfire address (I > > own my own domain, so I use different addresses in different places). _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Thu Sep 25 10:15:19 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:55:07 2005 Subject: [CF-Devel] New comunication commands. 'me and 'set_reply In-Reply-To: <3F7138E8.4070504@sonic.net> References: <20030916013818.2bc8e9b4.kstenger@montevideo.com.uy> <3F7138E8.4070504@sonic.net> Message-ID: <20030925121519.3a5b0680.kstenger@montevideo.com.uy> [...] > What you probably really want is 'if (op->contr->reply_to[0] == '\0') {' ... > Check that the actual string is actually a null string. > Ops... missed it, i'll fix that today i hope. > Otherwise, the patch seems OK. But I think at some level, I think improving > > the handling of this on the client would be a me relevant (a better chat > interface). > > At some level, I don't want to re-invent irc within crossfire. What are your ideas about it? and how to do it on the client? I still didn't look too much the client code since i thought comunication commands were meant to be on the c_chat.c file. I really think the comunication needs to be improved, but i'm a bit short of ideas and i would prefer to be guided on what and maybe how to do it. If i can help, i'm all ears :) -- +-----------------------------+ | Karla M? Stenger S?bat | | Pando . Canelones . Uruguay | | kstenger@montevideo.com.uy | +-----------------------------+ _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Thu Sep 25 10:18:31 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:55:07 2005 Subject: [CF-Devel] New comunication commands. 'me and 'set_reply In-Reply-To: <20030925121519.3a5b0680.kstenger@montevideo.com.uy> References: <20030916013818.2bc8e9b4.kstenger@montevideo.com.uy> <3F7138E8.4070504@sonic.net> <20030925121519.3a5b0680.kstenger@montevideo.com.uy> Message-ID: <3F730747.9060900@laposte.net> >What are your ideas about it? and how to do it on the client? I still didn't >look too much the client code since i thought comunication commands were meant >to be on the c_chat.c file. I really think the comunication needs to be >improved, but i'm a bit short of ideas and i would prefer to be guided on what >and maybe how to do it. If i can help, i'm all ears :) > > > There were some discussions about that on the mailing list, or on the forum... If i remember correctly, something like channels was planned... Personally i'd like to have one tab per user i'm chatting with, and maybe chat rooms, that is something like IRC :) With one channel for general messages (leaves/enters/...) Nicolas 'Ryo' _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Thu Sep 25 10:26:24 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:55:07 2005 Subject: [CF-Devel] GTK client errors Message-ID: <1064503584.14554.6.camel@d5110227.lss.emc.com> When I start up the gtk client with split windows, it tells me: Gtk-WARNING **: invalid cast from (NULL) pointer to `GtkCList' Gtk-CRITICAL **: file gtkclist.c: line 1714 (gtk_clist_set_column_width): assertion `clist != NULL' failed. Gtk-WARNING **: invalid cast from (NULL) pointer to `GtkCList' Gtk-CRITICAL **: file gtkclist.c: line 1714 (gtk_clist_set_column_width): assertion `clist != NULL' failed. Gtk-WARNING **: invalid cast from (NULL) pointer to `GtkCList' Gtk-CRITICAL **: file gtkclist.c: line 1714 (gtk_clist_set_column_width): assertion `clist != NULL' failed. All of that is coming from the call to gtk_widget_show(gtkwin_inv) in gx11.c:create_windows(). I see the same call for other windows with no errors. Everything still seems to work right, but I'm guessing we're doing something wrong here. Does someone here know enough about GTK to correct this? --PC _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Thu Sep 25 10:44:06 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:55:07 2005 Subject: [CF-Devel] gtk client memory leak Message-ID: <1064504646.14554.15.camel@d5110227.lss.emc.com> I just noticed some horrible problems with memory consumption using the gtk client. As mentioned before, the process that is actually consuming the memory is X, not gcfclient. When I kill the client, X releases the memory. What I find particularly interesting is that this happens on my Gentoo system, but not on my Red Hat system when running with the same client binary. This supports the idea that it's a problem with a library. Does anyone know how to debug this sort of thing? To start with, I would like to find out what resources X is keeping for the client. Has anyone spent much time looking into this? --PC _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Thu Sep 25 13:10:10 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:55:07 2005 Subject: [CF-Devel] Patch submission: weather.c for Windows32 Message-ID: <3F732F82.70406@laposte.net> Hello. Compiling the server under Windows, i had to fix some things in weather.c Here's the patch. It changes long long to sint64 (that's what the typedef is for :)) And instead of int64 * 1.5, it does int64 * 3 / 2 (since windows can't figure how to do *1.5.....) I believe it'll work under Linux too... Nicolas 'Ryo' -------------- next part -------------- Index: weather.c =================================================================== RCS file: /cvsroot/crossfire/crossfire/server/weather.c,v retrieving revision 1.34 diff -r1.34 weather.c 2886,2887c2886,2887 < long long total_rainfall = 0; < long long total_wind = 0; --- > sint64 total_rainfall = 0; > sint64 total_wind = 0; 2927c2927 < avgwind = (total_wind / (WEATHERMAPTILESX * WEATHERMAPTILESY) * 1.5); --- > avgwind = (total_wind / ((WEATHERMAPTILESX * WEATHERMAPTILESY) * 3 / 2)); From crossfire-devel-admin at archives.real-time.com Thu Sep 25 13:17:45 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:55:07 2005 Subject: [CF-Devel] Living.c / experience question Message-ID: <3F733149.5090206@laposte.net> Browsing living.c, and trying to erase warnings during compilation under Windows, i have a question regarding those 2 functions: int check_exp_loss(object *op, int exp) int check_exp_adjust(object *op, int exp) Sometimes exp is given as an int64 (since experience) Like loss = check_exp_loss(tmp, MIN(loss_3l, loss_20p)); (line 1796) with loss_3l & loss_20p being sint64 So shouldn't be those function more like sint64(object*, sint64) ? Also in living.c, we have (line 1442) (*dragon_gain_func)(who, abil->stats.exp, (int)((1+abil->resist[abil->stats.exp])/5.)); except the function prototype expects int as 2nd parameter... Just my 2 cents Nicolas 'Ryo' _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Thu Sep 25 23:10:53 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:55:07 2005 Subject: [CF-Devel] New comunication commands. 'me and 'set_reply In-Reply-To: <3F730747.9060900@laposte.net> References: <20030916013818.2bc8e9b4.kstenger@montevideo.com.uy> <3F7138E8.4070504@sonic.net> <20030925121519.3a5b0680.kstenger@montevideo.com.uy> <3F730747.9060900@laposte.net> Message-ID: <1064549453.560.8.camel@oberon.Kameria> > > > There were some discussions about that on the mailing list, or on the > forum... > If i remember correctly, something like channels was planned... > not planned, proposed... > Personally i'd like to have one tab per user i'm chatting with, and > maybe chat rooms, that is something like IRC :) > With one channel for general messages (leaves/enters/...) > > Nicolas 'Ryo' I thought it would be ok to have a few channels for shouting type communications but not anything really fancy - I can see the need for being able to tune in and out of global conversations which you cnnot do with shout, but if it starts getting into of rooms and tabs and all that it starts taking away from the game. Gsay and tell/reply are pretty good tools. Channels would be like gsay without the xp shareing. But crossfire does have a location factor so if you want to get a room and converse (and use all those emotes) you can *actually* get a room and sit down and have a conversation. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Fri Sep 26 00:28:47 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:55:07 2005 Subject: [CF-Devel] CFPython.SetQuantity() Message-ID: <1064554126.560.24.camel@oberon.Kameria> I am working on making the IPO banking scripts more fun and have noticed a little glitch. CFPython.SetQuantity() does not seem to change the displayed number of items in a stack until the stack is clicked or moved or some such change. It is doing the right hting, just not refreshing the amount right away. I actually noticed this before with the realestate stuff some time ago but assumed it was my mistake but now I think it is in the function. I suppose I could destroy and create the stack of objects but SetQuantity should be updating the number right away no? _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Fri Sep 26 00:04:20 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:55:07 2005 Subject: [CF-Devel] Living.c / experience question In-Reply-To: <3F733149.5090206@laposte.net> References: <3F733149.5090206@laposte.net> Message-ID: <3F73C8D4.3020605@sonic.net> Nicolas Weeger wrote: > Browsing living.c, and trying to erase warnings during compilation under > Windows, i have a question regarding those 2 functions: > > int check_exp_loss(object *op, int exp) > int check_exp_adjust(object *op, int exp) > > Sometimes exp is given as an int64 (since experience) > Like loss = check_exp_loss(tmp, MIN(loss_3l, loss_20p)); (line 1796) > with loss_3l & loss_20p being sint64 > > So shouldn't be those function more like sint64(object*, sint64) ? Yep - I'll fix that. > > Also in living.c, we have (line 1442) > (*dragon_gain_func)(who, abil->stats.exp, > (int)((1+abil->resist[abil->stats.exp])/5.)); > > except the function prototype expects int as 2nd parameter... that one is a bit odder. Looking at the code, abil->stats.exp doesn't contain an actual exp value, but instead points to the ability/resistance to increase. Thus, there is no worry about the value being truncated, overflowed, etc. I'll toss a cast in there which should clean up any warnings. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Fri Sep 26 01:07:54 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:55:07 2005 Subject: [CF-Devel] CFPython.SetQuantity() In-Reply-To: <1064554126.560.24.camel@oberon.Kameria> References: <1064554126.560.24.camel@oberon.Kameria> Message-ID: <3F73D7BA.2040905@sonic.net> Todd Mitchell wrote: > I am working on making the IPO banking scripts more fun and have noticed > a little glitch. > CFPython.SetQuantity() does not seem to change the displayed number of > items in a stack until the stack is clicked or moved or some such > change. It is doing the right hting, just not refreshing the amount > right away. I actually noticed this before with the realestate stuff > some time ago but assumed it was my mistake but now I think it is in the > function. I suppose I could destroy and create the stack of objects but > SetQuantity should be updating the number right away no? Yeah, it looks like the code that increases the nrof should also make a call to (PlugHooks[HOOK_ESRVSENDITEM]) (). It's actually a little trickier - if the object in question is in a players inventory, that hook works fine. However, if the object is on the ground where the player is standing, then we update_look tag for the object probably needs to be updated. I also notice that the existing CFSetQuantity is a bit odd - it calls PlugHooks[HOOK_UPDATEOBJECT](), which doesn't make a lot of sense - the updateobject changes how the map looks (eg, face), but changing the nrof of objects is not likely to actually change the face. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Fri Sep 26 01:09:26 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:55:07 2005 Subject: [CF-Devel] Patch submission: weather.c for Windows32 In-Reply-To: <3F732F82.70406@laposte.net> References: <3F732F82.70406@laposte.net> Message-ID: <3F73D816.7030502@sonic.net> Nicolas Weeger wrote: > Hello. > > Compiling the server under Windows, i had to fix some things in weather.c > > Here's the patch. > > It changes long long to sint64 (that's what the typedef is for :)) > And instead of int64 * 1.5, it does int64 * 3 / 2 > (since windows can't figure how to do *1.5.....) > > I believe it'll work under Linux too... Applied to CVS. > > Nicolas 'Ryo' > > > ------------------------------------------------------------------------ > > Index: weather.c > =================================================================== > RCS file: /cvsroot/crossfire/crossfire/server/weather.c,v > retrieving revision 1.34 > diff -r1.34 weather.c > 2886,2887c2886,2887 > < long long total_rainfall = 0; > < long long total_wind = 0; > --- > >> sint64 total_rainfall = 0; >> sint64 total_wind = 0; > > 2927c2927 > < avgwind = (total_wind / (WEATHERMAPTILESX * WEATHERMAPTILESY) * 1.5); > --- > >> avgwind = (total_wind / ((WEATHERMAPTILESX * WEATHERMAPTILESY) * 3 / 2)); > > _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Fri Sep 26 01:12:49 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:55:08 2005 Subject: [CF-Devel] gtk client memory leak In-Reply-To: <1064504646.14554.15.camel@d5110227.lss.emc.com> References: <1064504646.14554.15.camel@d5110227.lss.emc.com> Message-ID: <3F73D8E1.9040405@sonic.net> Preston Crow wrote: > I just noticed some horrible problems with memory consumption using the > gtk client. As mentioned before, the process that is actually consuming > the memory is X, not gcfclient. When I kill the client, X releases the > memory. > > What I find particularly interesting is that this happens on my Gentoo > system, but not on my Red Hat system when running with the same client > binary. This supports the idea that it's a problem with a library. > Does anyone know how to debug this sort of thing? To start with, I > would like to find out what resources X is keeping for the client. > > Has anyone spent much time looking into this? I tend not to investigate bugs in gtk, even though there are many. I'd first take a look at the gtk/glib versions on each of those two systems. If the system where hte bug does not occur has later versions of the library, I'd just assume that gtk people found and fixed the problem. X keeps a bunch of hte resources, the images being the main one. I could certainly see a case where gtk is not freeing the old icon information for thinsgs like the inventory/look window as the client animates/changes the the image repeatedly. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Fri Sep 26 01:37:37 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:55:08 2005 Subject: [CF-Devel] New comunication commands. 'me and 'set_reply In-Reply-To: <20030925121519.3a5b0680.kstenger@montevideo.com.uy> References: <20030916013818.2bc8e9b4.kstenger@montevideo.com.uy> <3F7138E8.4070504@sonic.net> <20030925121519.3a5b0680.kstenger@montevideo.com.uy> Message-ID: <3F73DEB1.7010109@sonic.net> Karla Stenger wrote: > What are your ideas about it? and how to do it on the client? I still didn't > look too much the client code since i thought comunication commands were meant > to be on the c_chat.c file. I really think the comunication needs to be > improved, but i'm a bit short of ideas and i would prefer to be guided on what > and maybe how to do it. If i can help, i'm all ears :) Well, I don't propose that the client will talk to other clients directly. The communication will still go through the server. However, at some level, I'd prefer more of the logic to be in the client than in the server. For example, 'tell' already takes the character name of the target of the tell. So from a starting point, you could see that the client watches the messages that come by, and stores its own copy of the last person to tell that client something. Thus, when the player replies, 'reply' is handled completely on the client - it just does a 'tell %s ...', and fills in %s with the last person that did the tell. Likewise, the player could do some client command which sets who the replies should go to. One could go further with this - highlight (or maybe just put the mouse) over the name in the last tell, and right click and get the option to tell them something. You could also do the actual filtering of messages on the clients (eg, ignore all shouts, or only listen to shouts/tells from Xyz, etc). With just a little work, one could even see the idea of hte shout channels on the client, eg, mesages are like 'Mark shouts on Newbie: this is the newbie channel'. Client parts that, sees who shouted (Mark), and channel (Newbie) and sees if this is a message that should be displayed to the player. If someone wnats to make the client with tabbed windows, up to them. Some of this could be easier - one of the things on the TODO list is to change the draw_info formatting a bit. Right now, the server tells the client the color, and really nothing else. The idea is that instead, the server tells the client the type of content (level gain, monster killed, etc) and the client can then figure out how to display it (color, font, which window/tab, etc). Extending that idea just a little bit, one could see some message formats as abbreviations, eg, if the client doesn't know the format, the text message is still humanly readable, but a smart client could clean it up, eg, for shout messages, you could have a format like 'name:channel:message'. Clients could clean that up to 'name shouts on channel message', but even if the client didn't clean it up, it is still perfectly readable with the colons. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Fri Sep 26 02:53:18 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:55:08 2005 Subject: [CF-Devel] =?iso-8859-1?Q?Re:_[CF-Devel]_New_comunication_commands._'me_and_'set=5Freply?= Message-ID: Here's what I propose for channels & such, based on what has been said previously. And if everyone agree, i'll implement that :) * ability to create channels, with or without password * persistent ones, at DM's discretion (newbie, admin, ...) * channel list, but without password protected ones * players can join any channel, provided they know the password if there is one * new command like csay (channel say) taking channel name argument * messages are sent to client in the form 'channel: says something' Maybe player will remember what channels they are in between sessions, as to not have to rejoin all the time when connecting. This way, current clients can use the new features right away, and read messages plainly. And future versions will parse the text to know which channel is concerned. As right know you could parse the ' tells you' message to see who asys what. Of course, that means the server manages channels... Maybe not that great an option? Nicolas 'Ryo' Acc?dez au courrier ?lectronique de La Poste : www.laposte.net ; 3615 LAPOSTENET (0,34?/mn) ; t?l : 08 92 68 13 50 (0,34?/mn) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://shadowknight.real-time.com/pipermail/crossfire/attachments/20030926/738a543b/attachment.htm From crossfire-devel-admin at archives.real-time.com Fri Sep 26 10:32:39 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:55:08 2005 Subject: [CF-Devel] Re: [CF-Devel] New comunication commands. 'me and 'set_reply In-Reply-To: References: Message-ID: <3F745C17.6090809@sympatico.ca> nicolas.weeger@laposte.net wrote: > Here's what I propose for channels & such, based on what has been said > previously. And if everyone agree, i'll implement that :) > * ability to create channels, with or without password > * persistent ones, at DM's discretion (newbie, admin, ...) > * channel list, but without password protected ones > * players can join any channel, provided they know the password if there > is one > * new command like csay (channel say) taking channel name argument > * messages are sent to client in the form 'channel: says something' > I would prefer it be cshout since it is not local like say or personal like tell/reply. I would like it also if the channels had a consistent format (currently a just a colour but in the future a style for the client to render) and used a message priority of say 3 (so you can use listen to block these messages but still recieve shouts). > Maybe player will remember what channels they are in between sessions, > as to not have to rejoin all the time when connecting. Sure, but only persistant channels > > This way, current clients can use the new features right away, and read > messages plainly. > And future versions will parse the text to know which channel is concerned. > As right know you could parse the ' tells you' message to see who > asys what. > > Of course, that means the server manages channels... Maybe not that > great an option? I don't think that is bad - The server should be the dispatcher and currently I would just use something like: "... NDI_UNIQUE | , 3, , ... " to actually send the messages. Future changes to NDI to offload more message formatting to the client would automatically apply to the channel stuff then. - as an aside, anyone have real objection if I change the priority of tell and reply to 1? You should be able to block this with listen and putting it to the same level as shout (lower - maybe a 2?) makes sense, no? _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Sun Sep 28 06:56:33 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:55:08 2005 Subject: [CF-Devel] Floors / walls and archetypes Message-ID: <3F76CC71.40006@laposte.net> Hi. For some new functions I wanna add to CF, I need to be able to detect, at a certain position, which object is a floor and which one is a wall. I don't mean 'blocking pass or view' item, but the real floor or wall item. Currently I plan on using a combination of GET_MAP_OB (hopefully the floor), and FLAG_NO_PASS to check if something is a wall, also checking things like slaying to avoid doors. But looking in the code, there's in define.h #define WALL 77 #define FLOOR 71 (as item type definition) It seems those values aren't in archetypes anywhere, even in walls archetypes. Is there a simple way to find floor / wall? Should I use an item's type, defining it manually in the editor, for floors / walls? Should I change archetypes to add type 77 / type 71 to walls / floors? Or am I missing an easy & obvious solution? Thanks in advance Nicolas 'Ryo' _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Sun Sep 28 10:36:36 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:55:08 2005 Subject: [CF-Devel] Floors / walls and archetypes In-Reply-To: <3F76CC71.40006@laposte.net> Message-ID: On 28-Sep-03 Nicolas Weeger wrote: > Is there a simple way to find floor / wall? Take a look at how the weather system finds floors in the routines where it snows and rains. I don't do anything with walls there.. but it shouldn't be hard to fiddle with to find walls too. --- Tim Rightnour NetBSD: Free multi-architecture OS http://www.netbsd.org/ NetBSD supported hardware database: http://mail-index.netbsd.org/cgi-bin/hw.cgi _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Sun Sep 28 23:23:21 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:55:08 2005 Subject: [CF-Devel] Floors / walls and archetypes In-Reply-To: <3F76CC71.40006@laposte.net> References: <3F76CC71.40006@laposte.net> Message-ID: <3F77B3B9.2040607@sonic.net> Nicolas Weeger wrote: > Hi. > > For some new functions I wanna add to CF, I need to be able to detect, > at a certain position, which object is a floor and which one is a wall. > I don't mean 'blocking pass or view' item, but the real floor or wall item. > > Currently I plan on using a combination of GET_MAP_OB (hopefully the > floor), and FLAG_NO_PASS to check if something is a wall, also checking > things like slaying to avoid doors. > > But looking in the code, there's in define.h > #define WALL 77 > #define FLOOR 71 > (as item type definition) > It seems those values aren't in archetypes anywhere, even in walls > archetypes. > > Is there a simple way to find floor / wall? Should I use an item's type, > defining it manually in the editor, for floors / walls? Should I change > archetypes to add type 77 / type 71 to walls / floors? > Or am I missing an easy & obvious solution? My question I guess would be 'what are you trying to do?' For floors, thing to always check for is FLAG_IS_FLOOR. For walls, no_pass is the right thing to check. As you note, there are some things that have no_pass set which aren't really walls (eg doors), but the question is then what are you really trying to do/check for? Those type defines aren't really good - certainly for floors, where something could be marked 'flag_is_floor', but already has another type (floor is simply defined as something you can't see beneath, so any number of objects could be so defined). You could perhaps say those aren't really floors, but then you get into a messy discussion of 'just what is a floor?' Those defines should actually be removed, since they aren't used for anything. You could update are the arch's, but there are sure to be things that might still not have the correct type set (eg, a map that takes another object, sets no_pass on it. Is that a wall? sure looks like it). My general philosophy is that types should only be defined if there is code in apply.c or time.c (or maybe a few other places) that needs to know the type. For something like walls and floors, which are passive, there really isn't any reason to define a type, because the attributes of the object itself dictate the no pass/can't see below behaviour. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Sun Sep 28 23:42:45 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:55:08 2005 Subject: [CF-Devel] Re: [CF-Devel] New comunication commands. 'me and 'set_reply In-Reply-To: <3F745C17.6090809@sympatico.ca> References: <3F745C17.6090809@sympatico.ca> Message-ID: <3F77B845.2090801@sonic.net> > Here's what I propose for channels & such, based on what has been said previously. And if everyone agree, i'll implement that :) > * ability to create channels, with or without password > * persistent ones, at DM's discretion (newbie, admin, ...) > * channel list, but without password protected ones > * players can join any channel, provided they know the password if there is one > * new command like csay (channel say) taking channel name argument > * messages are sent to client in the form 'channel: says something' Seems reasonable. My only concern is players being able to create channels. There are two real considerations: 1) If the number of channels is static, all channels could get used up - all it takes is one abusive player. 2) if dynamic, you could get a huge list of channels, making it unwieldy. Perhaps the solution is to allow one player to only create/have one active channel at a time. If the player wants to create another one, they get a message saying they have to close the one they currently have. Thus, unlikely to ever get a large number of channels, simply because there is a typical limit of number of players that would log in. This also presumes that channelsthe player creates go away when they log out/connection dies. That could be annoying if the party is using the channel, and the person who created it has their client crash (hence, logout). One thought might be to have some time delay when player connection terminates, and the connection actually dies. Eg, each channel normally has a expiration time of 0, denoting that it never goes away. When the owner of the channel goes away, the expiration time is now set to time() + some number of seconds (300 - 5 minutes perhaps?) At the same time, a message to all players on the channel goes out saying something like 'owner of channel is gone, type adopt to take over this channel'. It also means that if the player who created it comes back soon enough, they could re-adopt the channel they had previous created. Players can't adopt a channel if they already have one, as once someone adopt is, the expiration time goes back to zero. At some check in check_specials() that checks to see if there are any channels that should be terminated because the expiration time has been reached. > > Maybe player will remember what channels they are in between sessions, as to not have to rejoin all the time when connecting. > > This way, current clients can use the new features right away, and read messages plainly. > And future versions will parse the text to know which channel is concerned. > As right know you could parse the ' tells you' message to see who asys what. > > Of course, that means the server manages channels... Maybe not that great an option? If done in a simple enough fashion, perhaps not terrible. I'd just really don't want to see it become a huge mess of code to implement communication in crossfire. Of course, one could argue from a realism standpoint (the R word again) that this isn't especially realistic, eg, how can someone on a map far away tell the player next to you something and you not be able to hear it. But we'll ignore that point. Perhaps combine/clean up the current gsay type commands, and just implement them as a channel also? Eg, you create a party, and it creates a channel for that party where people likewise use the same commands to communicate. The biggest issue on this is how to deal with it on the client. at some level, typing 'cshout channelname blah blah blah' would get tiring, but at the same time, using bindings for 'cshout channelname' seem non ideal, simply on the basis of how do you know the channelname will always be that? Also, storing channels in the saved player file, while doable, has to be considered. Should you share private channels that are password protected (if so, how do we know the player has the correct password next time they join? Perhaps someone else is using the same channel name with different passwrod). I'd personally expect most channel names to be relative short (just to reduce typing), so chance of collision/reuse would probably be fairly high. You could certainly save all the permanent channels. Todd Mitchell wrote: >> > I would prefer it be cshout since it is not local like say or personal > like tell/reply. > I would like it also if the channels had a consistent format (currently > a just a colour but in the future a style for the client to render) and > used a message priority of say 3 (so you can use listen to block these > messages but still recieve shouts). It seems odd to set a listen level for these. You've subscibed to the channel - that suggests you want to hear them. If you don't want to hear them, unsubscribe from the channel. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Mon Sep 29 02:50:10 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:55:08 2005 Subject: [CF-Devel] Re: [CF-Devel] New comunication commands. 'me and 'set_reply In-Reply-To: <3F77B845.2090801@sonic.net> References: <3F745C17.6090809@sympatico.ca> <3F77B845.2090801@sonic.net> Message-ID: <3F77E432.6000801@laposte.net> > Perhaps the solution is to allow one player to only create/have one > active channel at a time. If the player wants to create another one, > they get a message saying they have to close the one they currently have. Hum, so one player creates only one channel, but can be on multiple ones... sounds fair to me. > This also presumes that channelsthe player creates go away when they > log out/connection dies. That could be annoying if the party is using > the channel, and the person who created it has their client crash > (hence, logout). One thought might be to have some time delay when > player connection terminates, and the connection actually dies. > > Eg, each channel normally has a expiration time of 0, denoting that > it never goes away. When the owner of the channel goes away, the > expiration time is now set to time() + some number of seconds (300 - 5 > minutes perhaps?) At the same time, a message to all players on the > channel goes out saying something like 'owner of channel is gone, type > adopt to take over this channel'. > > It also means that if the player who created it comes back soon > enough, they could re-adopt the channel they had previous created. > Players can't adopt a channel if they already have one, as once > someone adopt is, the expiration time goes back to zero. At some > check in check_specials() that checks to see if there are any channels > that should be terminated because the expiration time has been reached. Sounds fair to me, again. But I'd add an option for DMs to make channels permanent. Like 'newbie' channel, that could exist even without an owner... Also possibility to transfer ownership to another player, provided s/he didn't create a channel either. And of course channel disband :) > If done in a simple enough fashion, perhaps not terrible. I'd just > really don't want to see it become a huge mess of code to implement > communication in crossfire. Of course, one could argue from a realism > standpoint (the R word again) that this isn't especially realistic, > eg, how can someone on a map far away tell the player next to you > something and you not be able to hear it. But we'll ignore that point. > > Perhaps combine/clean up the current gsay type commands, and just > implement them as a channel also? Eg, you create a party, and it > creates a channel for that party where people likewise use the same > commands to communicate. In this case, maybe we could reimplement the 'shout' like a general channel everyone is subscribed to? This way, even if shout still exists, it's still managed the same way as other channels. > The biggest issue on this is how to deal with it on the client. at > some level, typing 'cshout channelname blah blah blah' would get > tiring, but at the same time, using bindings for 'cshout channelname' > seem non ideal, simply on the basis of how do you know the channelname > will always be that? For current clients, indeed, it'll soon become a real pain. But if channels names are short, as you mention, it's faster. Also the client can be improved for channel handling. Shouldn't be hard to parse message string, recognize 'channel: player says bla bla' and put it in a separate floating window for instance (one window per channel -> no need to use 'csay' or 'cshout' when typing in this window). The aim would be to provide compatibility with current clients and letting the chat interface be improved in the future. > Also, storing channels in the saved player file, while doable, has to > be considered. Should you share private channels that are password > protected (if so, how do we know the player has the correct password > next time they join? Perhaps someone else is using the same channel > name with different passwrod). > > I'd personally expect most channel names to be relative short (just > to reduce typing), so chance of collision/reuse would probably be > fairly high. You could certainly save all the permanent channels. Storing channels on server exit (btw, how do you close the server properly? Only way i know, under Windows, is good old ctrl+c) could be done. Though closing server isn't something that happens often, so savings channels is maybe _not_ that big a priority. Joining channels a player was in, maybe that could also be delayed. What I see coming (is someone working on that? Or should i tackle that myself?) is client-side improvements like macros or plugins. So we could imagine when the player logs out client stores chanels s/he is in, and auto-join on reconnect (like IRC clients do sometimes). Or possibility for players to add commands to execute at game entry, so obviously channel join. I think the first step is implementing, server-side, the basic channel logic. Then improve with permanent / saved channels, auto-rejoin, and such. > It seems odd to set a listen level for these. You've subscibed to > the channel - that suggests you want to hear them. If you don't want > to hear them, unsubscribe from the channel. Agreed here. I think it's been mentioned too, but we could do message types (like: player joins/leaves game, player death, monster kill, ...). So listen could be changed to something ressembling new pickup, ie listen join/leave + death but not monster kill. Nicolas 'Ryo' _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Mon Sep 29 03:03:58 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:55:08 2005 Subject: [CF-Devel] Floors / walls and archetypes In-Reply-To: <3F77B3B9.2040607@sonic.net> References: <3F76CC71.40006@laposte.net> <3F77B3B9.2040607@sonic.net> Message-ID: <3F77E76E.2060505@laposte.net> > My question I guess would be 'what are you trying to do?' Something that I think has been discussed earlier: ingame map building. I added some archetypes for building walls, floors, doors. They work fine for now (only in unique maps, because I'm not sure on how other maps are stored... But the code should work anywhere). The issue I'm running into is to correctly remove a wall, or check that there is indeed a floor on a square. Currently my code uses things like no_pass or is_floor. But in some cases I think that may not be enough. For instance, into your apartment, on the east wall (with extender). Just behind the wall is a 'blocking view'. It does have the 'no_pass' flag. So my code, if you remove an east wall & put a floor, will consider that blocking view to be a wall. Which, in a way, it is. Thus it'll leave that blocking view, which isn't really nice (black square, i'd rather have walls). Small drawing to illustrate: FWB FWB FWB (F = floor, W = wall, B = blocking view) Adding a floor on the middle square results in: FWB FFB FWB (correct gameplay-wise, player can't move outside the floor area) but i'd rather have FWW FFW FWW to have nice walls :) So I need to find a 'real' wall, not a blocking view... Also if you build near the grates an apartment's entrance, I had to do some tweaking to correctly see that the grate, even if it has 'no_pass', is not a wall... Note: i'll send a patch with my current code in a few days if someone wants to have a look :) > For floors, thing to always check for is FLAG_IS_FLOOR. Seems that flag is always set, yes... So easy to find. > For walls, no_pass is the right thing to check. As you note, there > are some things that have no_pass set which aren't really walls (eg > doors), but the question is then what are you really trying to > do/check for? I think i answered that, tell me if that's not enough :) > My general philosophy is that types should only be defined if there > is code in apply.c or time.c (or maybe a few other places) that needs > to know the type. For something like walls and floors, which are > passive, there really isn't any reason to define a type, because the > attributes of the object itself dictate the no pass/can't see below > behaviour. Well for 'correct' map building some tweaking will be required. Because you don't want to have a square with no floor and only a wall, it isn't nice :) Note: i don't say we should be able to build on all maps, probably on some special maps which could be tweaked with some special types or values on floors or walls. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Mon Sep 29 09:33:11 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:55:08 2005 Subject: [CF-Devel] Floors / walls and archetypes References: <3F77E76E.2060505@laposte.net> Message-ID: <8218.1064845991@www23.gmx.net> Nicolas Weeger wrote: > > My question I guess would be 'what are you trying to do?' > > Something that I think has been discussed earlier: > ingame map building. Yeah, this has been discussed earlier. I still don't understand what's so facinating about it. Crossfire mapmaking is immensely complex. What interfaces are you going to provide for in-game map building? - Command line syntax? Have you ever tried to create a 30x30 map by typing down the ascii-text? There are good reasons why we have map editors. AndreasV -- NEU F?R ALLE - GMX MediaCenter - f?r Fotos, Musik, Dateien... Fotoalbum, File Sharing, MMS, Multimedia-Gru?, GMX FotoService Jetzt kostenlos anmelden unter http://www.gmx.net +++ GMX - die erste Adresse f?r Mail, Message, More! +++ _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Mon Sep 29 09:29:37 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:55:08 2005 Subject: [CF-Devel] Re: [CF-Devel] New comunication commands. 'me and 'set_reply In-Reply-To: <3F77B845.2090801@sonic.net> References: <3F745C17.6090809@sympatico.ca> <3F77B845.2090801@sonic.net> Message-ID: <3F7841D1.6070409@sympatico.ca> > It seems odd to set a listen level for these. You've subscibed to the > channel - that suggests you want to hear them. If you don't want to > hear them, unsubscribe from the channel. > I could see being subscribed to a few different channels (your guild, friends channel,... then deciding for a while to not get any channel messages (busy in a tricky place). If you could do listen 2 and for a time just ignore those channels then do listen 3 when you are done so you can continue on with them without having to subscribe or unsubscribe it would be handy, no? _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Mon Sep 29 10:02:55 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:55:08 2005 Subject: [CF-Devel] Re: [CF-Devel] New comunication commands. 'me and 'set_reply In-Reply-To: <3F77E432.6000801@laposte.net> References: <3F745C17.6090809@sympatico.ca> <3F77B845.2090801@sonic.net> <3F77E432.6000801@laposte.net> Message-ID: <3F78499F.3060703@sympatico.ca> Nicolas Weeger wrote: > > >> Perhaps the solution is to allow one player to only create/have one >> active channel at a time. If the player wants to create another one, >> they get a message saying they have to close the one they currently have. > sure or even don't allow players to create channels at all... If it is too much of a pain. Even just having a couple dozen or so DM or admin setup channels to use would be a great feature. > Sounds fair to me, again. But I'd add an option for DMs to make channels > permanent. Like 'newbie' channel, that could exist even without an owner... > Also possibility to transfer ownership to another player, provided s/he > didn't create a channel either. And of course channel disband :) > >> If done in a simple enough fashion, perhaps not terrible. I'd just >> really don't want to see it become a huge mess of code to implement >> communication in crossfire. Of course, one could argue from a realism >> standpoint (the R word again) that this isn't especially realistic, >> eg, how can someone on a map far away tell the player next to you >> something and you not be able to hear it. But we'll ignore that point. > Ya it shouldn't need a manual to run channels - they should be prettyy simple. There are already a lot of good communication commands available, but channel shouting would be nice to allow people to use shout in a responsi9ble manner since it is the most popular form of messaging it appears. As I mentioned above - even if only DMs or admins could create a number of regular channels on a server it would be good enough in my books. Maybe players making channels is too much of a pain. This way you can have a channel file with say 10 or so channels (newbie, chat1, chat2, chat3, DMs, one for each guild...) you can subscribe to and then remind people to use thes rather than abusing the shout command. >> Perhaps combine/clean up the current gsay type commands, and just >> implement them as a channel also? Eg, you create a party, and it >> creates a channel for that party where people likewise use the same >> commands to communicate. > That would be ok. Gsay type channels should be a higer listen level than normal channels however. > > In this case, maybe we could reimplement the 'shout' like a general > channel everyone is subscribed to? > This way, even if shout still exists, it's still managed the same way as > other channels. > I thought about that but didn't want to do it that way - shout is listen level 1 and should be a higher priority than these channels. How I see the priorities are game messages 0, shout 1, tell/reply/gsay 2, channels 3, player joins and stuff 5... This lets you control at any time the amount of crap you are seeing in messages so when you are busy then you do listen 2 or listen 1 or in rare cases when the shout command is being overused and the DM isn't muzzling shouters listen 0. The reason is that shout should be rare, you should be able to ignore tell if someone is bothering you but still hear shouts and you should be able to ignore subscribed chitchat when you are busy but still hear party communication. We have listen levels and it is real easy to use them when sending messages so why not use them? _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Mon Sep 29 10:06:16 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:55:09 2005 Subject: [CF-Devel] Floors / walls and archetypes In-Reply-To: <8218.1064845991@www23.gmx.net> References: <3F77E76E.2060505@laposte.net> <8218.1064845991@www23.gmx.net> Message-ID: <3F784A68.2090907@laposte.net> > Yeah, this has been discussed earlier. > I still don't understand what's so facinating about it. Hum... totaly customize your apartment? Change your guild? Make a new map? The aim is to extend to game to be able to do more things than hack-slash-get money... Same thing with alchemy, what's fascinating with that, he? > Crossfire mapmaking is immensely complex. > What interfaces are you going to provide for in-game map > building? - Command line syntax? > Have you ever tried to create a 30x30 map by typing down the > ascii-text? There are good reasons why we have map editors. I agree those features are pretty complex. I don't plan on doing everything possible ingame. But right now you can already put walls, floors, doors with my code... And I could expand it for more items. FYI I'm using special archetypes with a specific item type (in define.h), with changes to manual_apply to handle those new types... So you just have to look at a wall, 'apply Floor builder => you remove the wall & put a floor instead :) Or 'apply Door builder (button) => you get a door & 2 buttons to open / close it. Nicolas 'Ryo' _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Mon Sep 29 10:55:19 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:55:09 2005 Subject: AW: [CF-Devel] Floors / walls and archetypes In-Reply-To: <3F784A68.2090907@laposte.net> Message-ID: > FYI I'm using special archetypes with a specific item type (in > define.h), with changes to manual_apply to handle those new types... > So you just have to look at a wall, 'apply Floor builder => you remove > the wall & put a floor instead :) Thats exactly was never should happens or possible. Even cf is not that vulnerable in this area, changing floor arch (which defines "bottom" of a tile stack) to a wall type (which should be top and having different flags) is really bad from technical or design points. The point is, that there is a big difference between "map making" and "ingame map customizing". They are from a technical view absolutly different. The first is a technical process outside the game - the 2nd is part of game play. Never mix it. Customizing needs a special interface which defines whats allowed or not and control what can be changed or not - like color of wall or droping a "non_pick" table here or there in a player house (and ONLY there). Btw, this is a somewhat complex & big coding part which needs alot of brainstorming before it should included. Commercial mmorpg has it too but they need usally years after release to complete integrate it. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Mon Sep 29 13:11:33 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:55:09 2005 Subject: [CF-Devel] Map making patch Message-ID: <3F7875D5.2000505@laposte.net> As mentioned in previous posts, I've been playing with ingame map modification. Here's my current code (diff with current cvs, as anonymous access sees it). This is not intented to be committed to cvs, but just to show the code & have opinions on it :) Quick & dirty modifications to test it, after applying & building: * using an editor, open your appartment (or any unique map which gives map->unique == 1, actually) * increase its size, leave undefined squares around * save, close, launch game, enter that map * you'll need to switch to dm to create items, no way to get'em currently Here are the archetypes i defined, how to use'em and what they do: (those archetypes are items in inventory, apply one to build) * builder_floor face a wall, apply the Floor builder. Will remove the wall, put a floor, make sure there are floors and/or walls around affected square, and ensure walls are correctly connected. Uses floor you are standing on for archetype, destroyed wall for walls you add * builder_wall face a square where you can go, which must be adjacent to an existing wall. Will put a wall of same archetype as first found wall around affected square, and ensure walls are correctly connected * builder_door_detector face a 'free' (where you can go) square, with the next in line free too. You must look either horizontally or vertically, diagonals NOT authorized. Will make a door and 2 pedestals to activate it. Uses a random connection number (range 0-19999, should be ok) * builder_door_button same as previous, but makes buttons instead of detectors Feel free to test it, or not :) Nicolas 'Ryo' -------------- next part -------------- A non-text attachment was scrubbed... Name: build_stuff.patch.bz2 Type: application/x-bzip2 Size: 4094 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20030929/188d6a43/build_stuff.patch.bin From crossfire-devel-admin at archives.real-time.com Tue Sep 30 00:42:30 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:55:09 2005 Subject: [CF-Devel] Re: [CF-Devel] New comunication commands. 'me and 'set_reply In-Reply-To: <3F7841D1.6070409@sympatico.ca> References: <3F745C17.6090809@sympatico.ca> <3F77B845.2090801@sonic.net> <3F7841D1.6070409@sympatico.ca> Message-ID: <3F7917C6.9090905@sonic.net> Todd Mitchell wrote: > >> It seems odd to set a listen level for these. You've subscibed to >> the channel - that suggests you want to hear them. If you don't want >> to hear them, unsubscribe from the channel. >> > I could see being subscribed to a few different channels (your guild, > friends channel,... then deciding for a while to not get any channel > messages (busy in a tricky place). If you could do listen 2 and for a > time just ignore those channels then do listen 3 when you are done so > you can continue on with them without having to subscribe or unsubscribe > it would be handy, no? Perhaps, but this seems more like an client issue. Depending on how the channel messages are displayed (eg, different tab), then all you really do is not look at that tab. I'd rather see the ignore logic handled on the client. Probably just as easy to do, but more so, one could add pretty complicated logic (regexp expression matching for messages or something). _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Tue Sep 30 00:51:29 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:55:09 2005 Subject: [CF-Devel] Re: [CF-Devel] New comunication commands. 'me and 'set_reply In-Reply-To: <3F77E432.6000801@laposte.net> References: <3F745C17.6090809@sympatico.ca> <3F77B845.2090801@sonic.net> <3F77E432.6000801@laposte.net> Message-ID: <3F7919E1.2050701@sonic.net> Nicolas Weeger wrote: > In this case, maybe we could reimplement the 'shout' like a general > channel everyone is subscribed to? > This way, even if shout still exists, it's still managed the same way as > other channels. Yeah, perhaps. OTOH, the current shout code is probably pretty simple codewise, so may not really save much be rolling that logic in. > > Storing channels on server exit (btw, how do you close the server > properly? Only way i know, under Windows, is good old ctrl+c) could be > done. Though closing server isn't something that happens often, so > savings channels is maybe _not_ that big a priority. Well, there are dm commands, and sighup is the best way. But really, if you allow persistant channels to be created by DM's, that file should be the instant the appropriate command to create the channel is done. Because most server shutdowns are unexpected (crashes), can't hope that a clean shutdown would be done. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Tue Sep 30 01:06:45 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:55:09 2005 Subject: [CF-Devel] Floors / walls and archetypes In-Reply-To: <3F77E76E.2060505@laposte.net> References: <3F76CC71.40006@laposte.net> <3F77B3B9.2040607@sonic.net> <3F77E76E.2060505@laposte.net> Message-ID: <3F791D75.4060506@sonic.net> I see your point about walls. And as of now, there isn't any really good solution. However, in your specific case, one should argue that they should never be able to mess with that row of blocked spaces. And the followup to this thought would be - the player is presumably starting with some map to make his apartment on. It would seem reasonable to me that such a map has some sane defaults (boundry walls of known type/flags or whatever). IMO, if in game map building is allowed, it has to be allowed in controlled situations, eg, you can modify this space, but not that space. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Tue Sep 30 02:28:56 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:55:09 2005 Subject: [CF-Devel] Floors / walls and archetypes In-Reply-To: <3F791D75.4060506@sonic.net> References: <3F76CC71.40006@laposte.net> <3F77B3B9.2040607@sonic.net> <3F77E76E.2060505@laposte.net> <3F791D75.4060506@sonic.net> Message-ID: <3F7930B8.4090104@laposte.net> > I see your point about walls. And as of now, there isn't any really > good solution. > > However, in your specific case, one should argue that they should never > be able to mess with that row of blocked spaces. > > And the followup to this thought would be - the player is presumably > starting with some map to make his apartment on. It would seem > reasonable to me that such a map has some sane defaults (boundry walls > of known type/flags or whatever). IMO, if in game map building is > allowed, it has to be allowed in controlled situations, eg, you can > modify this space, but not that space. I agree there: map building is allowed in specific places only. I was asking about detecting floors/walls in general. If the map is specific, then specific flags can, and probably must, be used on walls/floors to indicate where you can build. Maybe using the FLAG or WALL tags in define.h? About 'blocked' view, I don't know if they are required or not around walls (so xray has something to see behind the wall). That's something I can't tell, don't know the code enough right now. But if they are required, then for building you should be able to mess with them... Actually you can figure building maps in two ways: start from big empty map, and can't remove outter walls, thus messing with blocking view isn't required. Or the opposite, start with small room and dig walls to make room. That is, either build on an outside map, or dig in a hole :) Nicolas 'Ryo' _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Tue Sep 30 03:23:13 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:55:09 2005 Subject: [CF-Devel] Crossfire CVS and GCC 3.3 Message-ID: <200309301023.17863.yann.chachkoff@myrealbox.com> Problems have recently been spotted when attempting to run the CVS server. The main symptom is the map parsing getting stuck into an endless loop. After quite some investigations, it appears that using GCC 3.3.1 or 3.3.2 to build the server code causes that loop. Compiling the same code under the same conditions with an older GCC version (2.95,3.1 or 3.2) doesn't produce the bug. The exact source of the problem is unclear, but it could be a GCC bug. So if you get that problem, try to use an older version of GCC instead of 3.3. -- Yann Chachkoff ----------------------- Garden Dwarf's Best Friend ----------------------- GPG Key : http://pgp.dtype.org:11371/pks/lookup?op=get&search=0x844D25E0 Fingerprint: 6616 2E02 BAD2 4AEF C90A F1EB 7E03 AAB9 844D 25E0 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20030930/14fc1ad0/attachment.pgp From crossfire-devel-admin at archives.real-time.com Tue Sep 30 23:19:44 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:55:09 2005 Subject: [CF-Devel] Floors / walls and archetypes In-Reply-To: <3F7930B8.4090104@laposte.net> References: <3F76CC71.40006@laposte.net> <3F77B3B9.2040607@sonic.net> <3F77E76E.2060505@laposte.net> <3F791D75.4060506@sonic.net> <3F7930B8.4090104@laposte.net> Message-ID: <3F7A55E0.8080206@sonic.net> Nicolas Weeger wrote: > I agree there: map building is allowed in specific places only. > I was asking about detecting floors/walls in general. If the map is > specific, then specific flags can, and probably must, be used on > walls/floors to indicate where you can build. Maybe using the FLAG or > WALL tags in define.h? Or appropriate floor building objects or whatever (eg, imagine a map you start out with special floor builder objects. You buy 'tokens', and when you drop them on a space, different things show up (wall token, marble floor token, etc). You could also have a 'this space is finished token'.) > > About 'blocked' view, I don't know if they are required or not around > walls (so xray has something to see behind the wall). That's something I > can't tell, don't know the code enough right now. > But if they are required, then for building you should be able to mess > with them... This is a bit trickier. Because you have some objects, like the 'swall' archetypes, which are the jail type walls. These block passage, but don't block the view. However, once again, they should probably be considered walls. The simple definition of a wall is something that you can't pass through, and line of sight isn't important. But that will also get blurred that if in the future, more refinement on movement types are added (Eg, no walk, no fly, no spell, etc through spaces). Something like the swall, while blocking fly/walk, should perhaps allow spells, eg, burning hands through it would make sense. > > Actually you can figure building maps in two ways: start from big empty > map, and can't remove outter walls, thus messing with blocking view > isn't required. Or the opposite, start with small room and dig walls to > make room. > That is, either build on an outside map, or dig in a hole :) Well, I'd think the former is easier. Because the idea of adding new walls is probably a bit more palatable then trying to figure out what walls to remove. Just from a movement standpoint, you can't stand on top of a wall, so you need to deal with directions and so forth to remove walls. However, you can stand on top of an empty space. But also it means you can start out with 'mostly' empty maps, with perhaps some special section walled off (say special teleporter or something). If you can only add walls, you then can't get access to that teleporter until you pay whatever some of money. But if you can remove them, then you need to put in special indicators of 'don't remove these walls'. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Tue Sep 30 23:30:15 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:55:09 2005 Subject: [CF-Devel] Idea: Resting Message-ID: <3F7A5857.2000108@sonic.net> While driving home from work the other night, the thought that all the furniture in the game is basically useless, and that is a bit of a shame. I also thought that characters never actually sleep. Must be a lot of caffeine in the water. So my thought was to add a 'rest' command. When resting, you are blind (eyes closed after all). Your hp/sp/grace regen goes up, for food consumption goes down. I thought the hp/sp/grace regen would just be nice for those cases where you have a whole bunch to regen - getting it back faster would be nice. If you take any damage while resting, or you enter any command, you stop resting. The extension I had is that you then have modifiers for resting (basically, meaning how much hp/sp/grace regen bonus you get). If you try to rest in the street while it is raining, you gain nothing for example. However, if you have a nice comfy bed in the inn, you'd get a whole bunch of bonuses while resting. Resting in a chair gives some bonuses, but not quite so many. I could even see some additional objects, eg, mats/bedrolls characters carry around to rest on. OR it might be simpler to just remove things like chairs/tables/beds from being weapons, and instead make them 'rest enabling objects'. So if you apply the object, that starts your resting. This might also be nice, because then the food/sp/grace/hp fields from those objects could be used to denote rest benefits without having to worry about their meaning for them being weapons. Thoughts? It wouldn't seem like this should be that hard to code in. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel