From crossfire-devel-admin at archives.real-time.com Fri Sep 27 17:00:02 2002 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:53:12 2005 Subject: [CF-Devel] 4 crossfire-devel admin request(s) waiting Message-ID: <200209272200.g8RM02d29158@sprite.real-time.com> The crossfire-devel@lists.real-time.com mailing list has 4 request(s) waiting for your consideration at: https://mailman.real-time.com/mailman/admindb/crossfire-devel Please attend to this at your earliest convenience. This notice of pending requests, if any, will be sent out daily. Pending posts: From: wwc1@freeuk.com on Mon Sep 23 06:23:02 2002 Cause: Post by non-member to a members-only list From: resourcetoday@postino.ch on Tue Sep 24 01:50:17 2002 Cause: Post by non-member to a members-only list From: onacct65@terra.es on Tue Sep 24 21:08:12 2002 Cause: Post by non-member to a members-only list From: kbulgrien@att.net on Thu Sep 26 08:34:53 2002 Cause: Post by non-member to a members-only list From crossfire-devel-admin at archives.real-time.com Mon Sep 30 17:00:31 2002 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:53:18 2005 Subject: [CF-Devel] 1 crossfire-devel admin request(s) waiting Message-ID: <200209302200.g8UM0LK13317@sprite.real-time.com> The crossfire-devel@lists.real-time.com mailing list has 1 request(s) waiting for your consideration at: https://mailman.real-time.com/mailman/admindb/crossfire-devel Please attend to this at your earliest convenience. This notice of pending requests, if any, will be sent out daily. Pending posts: From: growthstockalerts@yahoo.com on Sun Sep 29 23:29:12 2002 Cause: Post by non-member to a members-only list From crossfire-devel-admin at archives.real-time.com Thu Sep 26 17:00:31 2002 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:53:28 2005 Subject: [CF-Devel] 4 crossfire-devel admin request(s) waiting Message-ID: <200209262200.g8QM0Td09454@sprite.real-time.com> The crossfire-devel@lists.real-time.com mailing list has 4 request(s) waiting for your consideration at: https://mailman.real-time.com/mailman/admindb/crossfire-devel Please attend to this at your earliest convenience. This notice of pending requests, if any, will be sent out daily. Pending posts: From: wwc1@freeuk.com on Mon Sep 23 06:23:02 2002 Cause: Post by non-member to a members-only list From: resourcetoday@postino.ch on Tue Sep 24 01:50:17 2002 Cause: Post by non-member to a members-only list From: onacct65@terra.es on Tue Sep 24 21:08:12 2002 Cause: Post by non-member to a members-only list From: kbulgrien@att.net on Thu Sep 26 08:34:53 2002 Cause: Post by non-member to a members-only list From crossfire-devel-admin at archives.real-time.com Fri Sep 27 17:00:02 2002 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:53:36 2005 Subject: [CF-Devel] 4 crossfire-devel admin request(s) waiting Message-ID: <200209272200.g8RM02d29158@sprite.real-time.com> The crossfire-devel@lists.real-time.com mailing list has 4 request(s) waiting for your consideration at: https://mailman.real-time.com/mailman/admindb/crossfire-devel Please attend to this at your earliest convenience. This notice of pending requests, if any, will be sent out daily. Pending posts: From: wwc1@freeuk.com on Mon Sep 23 06:23:02 2002 Cause: Post by non-member to a members-only list From: resourcetoday@postino.ch on Tue Sep 24 01:50:17 2002 Cause: Post by non-member to a members-only list From: onacct65@terra.es on Tue Sep 24 21:08:12 2002 Cause: Post by non-member to a members-only list From: kbulgrien@att.net on Thu Sep 26 08:34:53 2002 Cause: Post by non-member to a members-only list From crossfire-devel-admin at archives.real-time.com Mon Sep 30 17:00:31 2002 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:53:39 2005 Subject: [CF-Devel] 1 crossfire-devel admin request(s) waiting Message-ID: <200209302200.g8UM0LK13317@sprite.real-time.com> The crossfire-devel@lists.real-time.com mailing list has 1 request(s) waiting for your consideration at: https://mailman.real-time.com/mailman/admindb/crossfire-devel Please attend to this at your earliest convenience. This notice of pending requests, if any, will be sent out daily. Pending posts: From: growthstockalerts@yahoo.com on Sun Sep 29 23:29:12 2002 Cause: Post by non-member to a members-only list From crossfire-devel-admin at archives.real-time.com Thu Sep 26 17:00:31 2002 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:53:41 2005 Subject: [CF-Devel] 4 crossfire-devel admin request(s) waiting Message-ID: <200209262200.g8QM0Td09454@sprite.real-time.com> The crossfire-devel@lists.real-time.com mailing list has 4 request(s) waiting for your consideration at: https://mailman.real-time.com/mailman/admindb/crossfire-devel Please attend to this at your earliest convenience. This notice of pending requests, if any, will be sent out daily. Pending posts: From: wwc1@freeuk.com on Mon Sep 23 06:23:02 2002 Cause: Post by non-member to a members-only list From: resourcetoday@postino.ch on Tue Sep 24 01:50:17 2002 Cause: Post by non-member to a members-only list From: onacct65@terra.es on Tue Sep 24 21:08:12 2002 Cause: Post by non-member to a members-only list From: kbulgrien@att.net on Thu Sep 26 08:34:53 2002 Cause: Post by non-member to a members-only list From mwedel at sonic.net Sun Sep 1 01:10:32 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:45 2005 Subject: [CF-Devel] Protocol Questions (Server to Client) References: <3D700384.2030704@xanathos.de> <3D70503A.3070402@sonic.net> <7cb2nuo7ldelgust1rq754rkkvmdrobgbq@flonk> <3D714717.9060108@sonic.net> Message-ID: <3D71AF58.8060809@sonic.net> pstolarc@theperlguru.com wrote: > On Sat, 31 Aug 2002, Mark Wedel wrote: > Yes. Windows has it's own DATADIR defined somewhere that does something > else. I don't know what it does. It's in some standard library. It > didn't appear to be worth the time it would take to work around. Fair enough. >>ifdef else endif >>>ifdef else endif >> >> etc, such that it became really hard to read through the function to see what >>it was doing, because not only did you have to try to parse the code, but you >>also had to parse the ifdefs. So I tended to prefer longer ifdef/else/endif, >>even if they included some common code. > > > I don't think I did that to the server source. It's probably some other > Win32 guy. We all look alike. Actually, I was thinking that this predated the win32 changes - there was code like that in for some of the different config options. It doesn't really make too much difference what the code is ifdeffing - it was mostly just a readability issue. > I would guess MacOS would build from the Unix source, as there is no GUI > code in the common files, but that's just a guess. Yeah - I notice there are a few 'getenv()' calls in the common/init.c and image.c files. I'm not sure how they would get handled on macos. From michael.toennies at nord-com.net Sun Sep 1 10:29:42 2002 From: michael.toennies at nord-com.net (Michael Toennies) Date: Thu Jan 13 18:02:45 2005 Subject: [CF-Devel] Protocol Questions (Server to Client) In-Reply-To: <7cb2nuo7ldelgust1rq754rkkvmdrobgbq@flonk> Message-ID: All should please note, that the SDL client in CVS is a full working, full ported win32 application. This included the whole non graphical core, cmd part and socket. The SDL client use the unix client core, so all the talking about porting and changing is unneeded work - exactly the same is done by me a year ago and full working included in the CVS. You has just add the new cmd stuff to it, thats all. And a small question: Why doing a win32 only client again? And not SDL or if you don't like it a different multi cross library? The SDL client in CVS really needs not much work to be 100% workable with all features. From jajcus at bnet.pl Sun Sep 1 12:08:23 2002 From: jajcus at bnet.pl (Jacek Konieczny) Date: Thu Jan 13 18:02:46 2005 Subject: [CF-Devel] Automake patch available, please test it In-Reply-To: <3D5B3186.5050106@sonic.net> References: <20020811105642.GA28190@nic.nigdzie> <3D5B3186.5050106@sonic.net> Message-ID: <20020901170823.GB29162@nic.nigdzie> On Wed, Aug 14, 2002 at 09:43:50PM -0700, Mark Wedel wrote: > >The "make distcheck" builds a dsitribution tarball and checks if it > >works. > > How does distcheck determine what to pack in the archive? It appears that > it just takes everything in the current directory? No it doesn't do that. It archives only files described in Makefile.am and some well-known files (like README or Makefile.{in,am}. > Distcheck failed on my > system because there was a gmon.out. It is strange... Could you send me the full output of `make distcheck`? > I'm much more worried about say the doc directories, where there may be > some left over files from the build process. They should be not included. And automake will not archive them unless there is some error in some Makefile.am or configure.ac > I suppose the right approach for making archives with this system would be > to have a completely cvs checkout (done after whatever checkins) to run > this in. This is slightly more inconvenient than the current archive > method, which knows to only archive files specifically mentioned. automake is supposed to archive even some of autogenerated files which doesn't need to be kept in CVS (as CVS is intended for developers, who can rebuild those files). > > instead of autoconf.h header. This is done according to > > automake documentation ("datadir","libdir","localstatedir" > > should be used only in Makefile) > > I personally find this new format annoying. From jajcus at bnet.pl Sun Sep 1 12:14:33 2002 From: jajcus at bnet.pl (Jacek Konieczny) Date: Thu Jan 13 18:02:46 2005 Subject: [CF-Devel] Automake patch available, please test it In-Reply-To: <3D6B2CE3.3010004@sonic.net> References: <20020811105642.GA28190@nic.nigdzie> <3D5B3186.5050106@sonic.net> <3D6B2CE3.3010004@sonic.net> Message-ID: <20020901171433.GC29162@nic.nigdzie> On Tue, Aug 27, 2002 at 12:40:19AM -0700, Mark Wedel wrote: > However, even with that, the compile output is still very cluttered with > the depfile/depmod stuff. You can turn dependency checking off by 'configue --disable-dependency-tracking' > Real solution may be to just include our own .c.o directive which doesn't > echo the command it is running (put a - in front of the directive) and > instead just does something like an echo 'compiling XYZ' before that. This would be a-very-bad-thing. Automake tries hard to make compilation as portable as generic as possible. With overiding .c.o directive we will probably loss a lot of these. And probably automake would not allow this anyway. > In that case, I wouldn't really care how much stuff is passed via command > line. But as it is now, the output is so verbose that non critical errors > will probably not get noticed. So the build process should be done in such way, that non-critical errors may be mand critical. For C files -Werror flag should be enough. And one is looking for errors when something goes wrong, and he will probably use his editor to find errors in makefile log. IMHO it is much easier to examine errors with all these verbose lines (including full command line), that without them Greets, Jacek From kf_bulk at excelcia.org Sun Sep 1 12:29:55 2002 From: kf_bulk at excelcia.org (Kurt Fitzner) Date: Thu Jan 13 18:02:46 2005 Subject: [CF-Devel] Re: libtool with plugins In-Reply-To: <3D713430.3040902@sonic.net> Message-ID: On 31-Aug-2002 Mark Wedel wrote: > Kurt Fitzner wrote: > As for libcross.a - why should it care - that is a static library, that is > linked in statically. Same is true for libsocket.a for that matter. There > is really no reason to make those shared libraries, because the versions are > tied very closely to crossfire, and it is not like there will be more than > one process running on the system that may use those shared objects and thus > have some benefit of reduced memory. You may want to make it into a shared library for the benefit of the plugins. The issue is that plugins are using the same code in libcross.a. Since they -are- shared libraries, at the very least, the libcross.a component object files will have to be built using -fPIC. You can put position-independant code object files in a static library. You just can't put non-position-independant code in a shared. It may be that relative jumps are large enough by default on the x86 that the compiler doesn't happen to use any absolute jumps in Linux. On my HP, though, gcc is putting in absolute jumps in libcross.a and the linking of python_plugin barfs since libcross.a has non position-independant code in it. My guess is that at some point even on Linux, some function will grow to be longer than a page and your plugin linking will suddenly break. Your object files in a static library can be compiled with -fPIC with very little performance hit. After all, in Linux if the linker isn't complaining now, then it's already PI code, and adding the flag won't make a difference. You can keep track of different object files with libtool, if you like. Compile the code without -fPIC for your static library, and then use libtool with -fPIC to make it into .lo PIC object files for the plugins. Some projects do it this way. However, that somewhat defeats the purpose of a plugin. Plugins should be able to be fairly independant of the main program. If you do the above, then every time you change code in common, you will have to recompile every plugin. If you switch libcross.a to a shared object, this will most of the time be avoided. Unless, of course, there are interface changes in the common code. It also has the added benefit of being able to distribute plugins independantly of the main program. All you need are the libcross.a headers somewhere, and you can compile plugins outside the main source. I'd suggest moving to shared code as much as possible. It will add nothing to the size, and ease problems down the road. Incidentally, the python config library for HP wasn't compiled with -fPIC either, so I have to recompile it too. I haven't got a clue why the distro for HP doesn't have shared libraries. Bah. Kurt. From pstolarc at theperlguru.com Sun Sep 1 18:24:52 2002 From: pstolarc at theperlguru.com (pstolarc@theperlguru.com) Date: Thu Jan 13 18:02:46 2005 Subject: [CF-Devel] Infinite Wand bug Message-ID: That is wands of burning hands (lvl 6) (readied) It has -3753 charges left. It is made of: wood It goes in your range slot It weighs 2.300 kg. You would get nothing for the it. Had the wand on autofire for a bit, just watching the pretty lights. The wand goes poof, but it still fires. First noticed on metalforge with a "treasure" wand. That is wands of burning hands (lvl 4) (readied) It has -12900 charges left. It is made of: wood It goes in your range slot It weighs 2.300 kg. You would get nothing for the it. Bought this wand in a store. Bug is reproducible. Didn't check wands with other spells. -Philip From pstolarc at theperlguru.com Sun Sep 1 19:02:20 2002 From: pstolarc at theperlguru.com (pstolarc@theperlguru.com) Date: Thu Jan 13 18:02:46 2005 Subject: [CF-Devel] Protocol Questions (Server to Client) In-Reply-To: References: <7cb2nuo7ldelgust1rq754rkkvmdrobgbq@flonk> Message-ID: On Sun, 1 Sep 2002 17:29:42 +0200, you wrote: >All should please note, that the SDL client in CVS is a full working, >full ported win32 application. > >This included the whole non graphical core, cmd part and socket. > >The SDL client use the unix client core, so all the talking about porting >and changing is unneeded work - exactly the same is done by me a year ago >and full working included in the CVS. > >You has just add the new cmd stuff to it, thats all. > >And a small question: > >Why doing a win32 only client again? >And not SDL or if you don't like it a different multi cross library? Someone else is planning on doing a win32 only, closed source client. I'm not directly involved in that project. I'm going to continue work on the SDL client. I was experiencing some bugs in the network code, and rather than debug the problems as they were, (and that I probably introduced), I decided it would be more fruitful to use the common code. So, I started merging the SDL client I have with the common files from cfclient &c. It wasn't too hard, but I realized that the common files weren't directly portable to win32. So, I started working on getting them compiled on win32. I'm starting with the easy stuff, and if I encounter anything that gives me pause, I'm going to go to the SDL source for inspiration. Also, I figured that doing this would beneficial for future work on porting to GTK 2.0 on win32, if that ever happens. Or any other choices of graphics libraries anyone may make. And I do have plans in mind, in case the SDL client doesn't merge well with the common code, but that's beyond the scope of this email. >The SDL client in CVS really needs not much work to be 100% workable with >all features. I've gotten quite a few different versions of the SDL client, for various reasons. I started with what's in CVS, and got it working, then I got another version, merged in most of the changes I had made to the first version, then I got another version, and started merging in the changes from the first two versions. This kinda put me off development for a bit, until I found a way to interest myself in it again. If anyone wants to see the mess that is my SDL client project directory, I'll zip it up, but it's really messy. I want to get something clean before publicly distributing it. -Philip From pstolarc at theperlguru.com Sun Sep 1 20:15:16 2002 From: pstolarc at theperlguru.com (pstolarc@theperlguru.com) Date: Thu Jan 13 18:02:46 2005 Subject: [CF-Devel] Item Damage idea In-Reply-To: <000601c24ea0$0df21ce0$0a02a8c0@kameria> References: <000001c24e79$515c0670$c86ebb81@gizmo> <000601c24ea0$0df21ce0$0a02a8c0@kameria> Message-ID: <1fb5nu8mg96s8ehmorbsiklbeil878maq7@flonk> On Wed, 28 Aug 2002, Todd Mitchell wrote: >would you limit damage to weapons and armour? I don't see much need/sense >for amulets and rings getting damaged. I personally don't like the idea of anything being damaged. I think that crossfire isn't a "real RPG". I don't want critical hit location tables, where if your left arm has 13HP (80% for the arm) damage, you can't use it to hold anything more than 8kg (4% of max for the arm). I don't want damaged equipment. Mostly for the same reasons. It adds unnecessary complexity. I don't really see what the benefits are. Siphon money from high level chars: They have enough money that they won't even notice it. This is better solved by having some really expensive items. Something like in-game dungeon design, where real estate costs lots of money, and so do tiles that the player can place. Gift Equipment : Players will then "gift repair" equipment. And with the ideas I've seen floated around, these gift repairs don't have to be all that common. High level equipment on a low level character will last a long time. Anyway, this is my opinion. I don't know how other players feel about this. Gros was asking around at some point. mids, maybe you could have a poll on your website? -Philip (I'd better go write some code. I've been writing way too much on the list today.) From pstolarc at theperlguru.com Sun Sep 1 20:25:04 2002 From: pstolarc at theperlguru.com (pstolarc@theperlguru.com) Date: Thu Jan 13 18:02:46 2005 Subject: [CF-Devel] Building the Server on Win32 In-Reply-To: <3D6EFBF3.2040800@sonic.net> References: <3D6E2C24.1030308@xanathos.de> <3D6EFBF3.2040800@sonic.net> Message-ID: On Thu, 29 Aug 2002 22:00:35 -0700, you wrote: >Bjoern Becker wrote: >> Hi. >> >> I just checked out crossfire and tried to compile the server >> following the instructions in make_win32. After compiling for >> some time MVC6 reports unresolved symbols : > > My guess is that the build environment isn't compiling the socket/images.c >file. I know nothing about windows development, but if you add that file in >wherever it should be, that might fix it up. > > Probably also needed to add the server/weather.c file. I compiled it today. I hope this patch helps. (VC++ modified a lot more stuff automatically, mostly changing various computer generated comments to English in the project file, but I trimmed it down to just the relevant bits.) -Philip -------------- next part -------------- Index: crossfire/make_win32/crossfire32.dsp =================================================================== RCS file: /cvsroot/crossfire/crossfire/make_win32/crossfire32.dsp,v retrieving revision 1.9 diff -c -r1.9 crossfire32.dsp *** crossfire/make_win32/crossfire32.dsp 26 Nov 2001 17:52:26 -0000 1.9 --- crossfire/make_win32/crossfire32.dsp 1 Sep 2002 15:58:56 -0000 *************** *** 134,139 **** --- 134,143 ---- # PROP Default_Filter "" # Begin Source File + SOURCE=..\socket\image.c + # End Source File + # Begin Source File + SOURCE=..\socket\info.c !IF "$(CFG)" == "crossfire32 - Win32 FullDebug" *************** *** 1144,1149 **** --- 1148,1157 ---- !ENDIF + # End Source File + # Begin Source File + + SOURCE=..\server\weather.c # End Source File # Begin Source File Index: crossfire/server/main.c =================================================================== RCS file: /cvsroot/crossfire/crossfire/server/main.c,v retrieving revision 1.63 diff -c -r1.63 main.c *** crossfire/server/main.c 15 Jul 2002 04:57:13 -0000 1.63 --- crossfire/server/main.c 1 Sep 2002 15:58:56 -0000 *************** *** 172,180 **** # ifdef HAVE_LIBDES return (char*)des_crypt(str,s); # endif #endif - /* Default case - just use crypt */ - return (char*)crypt(str,s); } int check_password(char *typed,char *crypted) { --- 172,180 ---- # ifdef HAVE_LIBDES return (char*)des_crypt(str,s); # endif + /* Default case - just use crypt */ + return (char*)crypt(str,s); #endif } int check_password(char *typed,char *crypted) { From mwedel at sonic.net Mon Sep 2 02:01:47 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:46 2005 Subject: [CF-Devel] Building the Server on Win32 References: <3D6E2C24.1030308@xanathos.de> <3D6EFBF3.2040800@sonic.net> Message-ID: <3D730CDB.6000006@sonic.net> pstolarc@theperlguru.com wrote: > On Thu, 29 Aug 2002 22:00:35 -0700, you wrote: > > >>Bjoern Becker wrote: >> >>>Hi. >>> >>>I just checked out crossfire and tried to compile the server >>>following the instructions in make_win32. After compiling for >>>some time MVC6 reports unresolved symbols : >> >> My guess is that the build environment isn't compiling the socket/images.c >>file. I know nothing about windows development, but if you add that file in >>wherever it should be, that might fix it up. >> >> Probably also needed to add the server/weather.c file. > > > I compiled it today. I hope this patch helps. (VC++ modified a lot more > stuff automatically, mostly changing various computer generated comments to > English in the project file, but I trimmed it down to just the relevant > bits.) Does VC++ care about the whatspace/newline terminator on the .dsp file? I have no problem just putting that patch in, but I noticed that the ^M got stripped, where as the rest of that file does have ^M, so I'm not sure if it would be useful as is. From mwedel at sonic.net Mon Sep 2 02:03:32 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:46 2005 Subject: [CF-Devel] Infinite Wand bug References: Message-ID: <3D730D44.2080908@sonic.net> Bug is for all wands - code was missing a 'return' - this is now fixed in CVS. pstolarc@theperlguru.com wrote: > That is wands of burning hands (lvl 6) (readied) > It has -3753 charges left. > It is made of: wood > It goes in your range slot > It weighs 2.300 kg. > You would get nothing for the it. > > Had the wand on autofire for a bit, just watching the pretty lights. The > wand goes poof, but it still fires. First noticed on metalforge with a > "treasure" wand. > > That is wands of burning hands (lvl 4) (readied) > It has -12900 charges left. > It is made of: wood > It goes in your range slot > It weighs 2.300 kg. > You would get nothing for the it. > > Bought this wand in a store. Bug is reproducible. Didn't check wands with > other spells. > > -Philip > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel From kbulgrien at worldnet.att.net Mon Sep 2 02:26:42 2002 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Thu Jan 13 18:02:46 2005 Subject: [CF-Devel] Occidental Mages Sword +2 crashes server... In-Reply-To: References: Message-ID: <20020902072413.YOZL2447.mtiwmhc22.worldnet.att.net@there> I have a sword of Occidental Mages +2 that I wanted to try out to see what it does... Every single time I kill things with it, the server crashes. (I am using a recent cvs version, Mandrake 8.2, Python 2.0.) Some background: I had to tweak the compile to get it to work with Python 2.0 since the detect didn't pick it up in lib/python. I have Python 2.2 on the machine since I upgraded from Mandrake 8.0 to 8.2. I guess I'll try compiling with that first. Not having done hardly any development on Linux/Unix, I am not very sure what the best way to track down things like this. I am willing to spend some time trying to get data... Any suggestions about how one might gather information? Nothing is printed in the log file that seems relevant. From mwedel at sonic.net Mon Sep 2 02:27:31 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:47 2005 Subject: [CF-Devel] Re: libtool with plugins References: Message-ID: <3D7312E3.6070606@sonic.net> Kurt Fitzner wrote: > On 31-Aug-2002 Mark Wedel wrote: > > You may want to make it into a shared library for the benefit of the plugins. > The issue is that plugins are using the same code in libcross.a. Since they > -are- shared libraries, at the very least, the libcross.a component object > files will have to be built using -fPIC. You can put position-independant code > object files in a static library. You just can't put non-position-independant > code in a shared. I'd have to look at the plugin code, but I'm not 100% positive that it confines it calls to only the stuff in libcross. Hypothetically, if it made a callback to a function that is located in in the server directory, what may happen down the road? My impression of the static libraries was that they were really just a convenient way to gather a bunch of .o files together, and linkin in a static library really isn't any different than if you had just passed all the .o files directly to the linker. > However, that somewhat defeats the purpose of a plugin. Plugins should be > able to be fairly independant of the main program. If you do the above, then > every time you change code in common, you will have to recompile every plugin. > If you switch libcross.a to a shared object, this will most of the time be > avoided. Unless, of course, there are interface changes in the common code. > It also has the added benefit of being able to distribute plugins > independantly of the main program. All you need are the libcross.a headers > somewhere, and you can compile plugins outside the main source. As of now, the plugins are _very_ dependent on the code. The plugins access some areas of the object structure directly - if the object layout changes, the plugin must be recompiled. There was actually a bug here for a while in that the plugin wasn't getting the dependencies done, so something would change some area like the object, the plugin wasn't getting recompiled, and then doing bad things. I know the idea is/was originally that there could be multiple plugins, and shared objects was the most reasonable way to do that (as the dynamic loader could look and see what features the plugin is providing). > > I'd suggest moving to shared code as much as possible. It will add nothing to > the size, and ease problems down the road. I'll take a look at this. From mwedel at sonic.net Mon Sep 2 02:42:01 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:47 2005 Subject: [CF-Devel] Item Damage idea References: <000001c24e79$515c0670$c86ebb81@gizmo> <000601c24ea0$0df21ce0$0a02a8c0@kameria> <1fb5nu8mg96s8ehmorbsiklbeil878maq7@flonk> Message-ID: <3D731649.1080403@sonic.net> pstolarc@theperlguru.com wrote: > On Wed, 28 Aug 2002, Todd Mitchell wrote: >>would you limit damage to weapons and armour? I don't see much need/sense >>for amulets and rings getting damaged. I was personally thinking to cover all items that are equipped. Now, the damage could should probably try to be clever and weigh the likelihoods of different items - if you got hit by a lightning bolt, certainly can be argued that anything you were could get damaged to some extent. > Siphon money from high level chars: They have enough money that they won't > even notice it. This is better solved by having some really expensive > items. Something like in-game dungeon design, where real estate costs lots > of money, and so do tiles that the player can place. The real-estate has of course been talked about. That is really the only other way to get rid of money - other high valued items don't do anything, because no one ever buys them. > > Gift Equipment : Players will then "gift repair" equipment. And with the > ideas I've seen floated around, these gift repairs don't have to be all > that common. High level equipment on a low level character will last a > long time. Gift equipment should last a bit longer on lower level characters, but hard to really say how much longer - low level characters would have their stuff damaged at a slower rate, but not necessarily a lot slower. The main difference is that low level players won't have to spend nearly as much for repairs. but yeah, I think the gift item is not solvable except by getting the item_power stuff properly tuned, such that low level characters wouldn't be able to use high level stuff (or they would have to use it to the exclusivity of any other magical equipment, which may not be worth while if the item is highly specialized). > > Anyway, this is my opinion. I don't know how other players feel about > this. Gros was asking around at some point. > > mids, maybe you could have a poll on your website? May not be a bad idea - no reason to do something if no one wants to use of. Poles can of course be tricky - some number of players seem to think that gift equipment is in fact a good thing, but I doubt there are many server admins that would agree with that. From jajcus at bnet.pl Mon Sep 2 02:55:37 2002 From: jajcus at bnet.pl (Jacek Konieczny) Date: Thu Jan 13 18:02:47 2005 Subject: [CF-Devel] Apartment in Scorn not really missing... In-Reply-To: <5.1.0.14.0.20020828143321.00a186d0@postoffice.worldnet.att.net> References: <3D6C7059.2080204@sonic.net> <5.1.0.14.0.20020828143321.00a186d0@postoffice.worldnet.att.net> Message-ID: <20020902075536.GM20235@serwus.bnet.pl> On Wed, Aug 28, 2002 at 02:38:14PM -0500, Kevin R. Bulgrien wrote: > The disappearing apartment turned out to be a change in > world permissions... > > The maps/city/apartments directory has to be world > writeable... Since I am running the maps straight out > of my cvs directory, I need to tweak some permissions. > > Is this normal though? I would have thought that the > server saved things to a different place than to the > master copies of the maps? > > In general, does the server need the maps directories > and/or files to be writeable? No. No files/directories in $datadir should be written by server. Files which are modified are stored in other directory (under $localstatedir). Usually $datadir is /usr/local/share (and maps are in /usr/local/share/crossfire/maps) and $localstatedir is /var (and files are written in /var/lib/crossfire/). It seems it works OK for me. Maybe the "old layout" if used (as configure option) may break things. Or something has been broken in sources recently. Greets, Jacek From kbulgrien at worldnet.att.net Mon Sep 2 04:00:21 2002 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Thu Jan 13 18:02:47 2005 Subject: [CF-Devel] Item Damage idea In-Reply-To: <3D731649.1080403@sonic.net> References: <000001c24e79$515c0670$c86ebb81@gizmo> <1fb5nu8mg96s8ehmorbsiklbeil878maq7@flonk> <3D731649.1080403@sonic.net> Message-ID: <20020902085740.YVIU2447.mtiwmhc22.worldnet.att.net@there> On Monday 02 September 2002 02:42, you wrote: > pstolarc@theperlguru.com wrote: > > On Wed, 28 Aug 2002, Todd Mitchell wrote: > >>would you limit damage to weapons and armour? I don't see much > >> need/sense for amulets and rings getting damaged. > > I was personally thinking to cover all items that are equipped. Now, the > damage could should probably try to be clever and weigh the likelihoods of > different items - if you got hit by a lightning bolt, certainly can be > argued that anything you were could get damaged to some extent. Well, not to criticize the creativity, because it is cool to see new ideas being formed, but here is something that occurs to me... (I have to say that at the moment, the sentiment expressed against equipment damage struck a chord.) All this sounds like an awful lot of work if it is being done to drain money. I suspect, instead, that it is feature creep... We started out talking about weapons, armor dragged in, and now "everything"... The game modelling being described here is very complex. Complexity is not always a good thing... Sometimes its nice for the player to actually be able to intuitively understand what is going on. If an idea has merit, I'd suggest starting with a simple implementation instead of going all out. This may be a bad example, but take a simple item like "bracers". I don't know how many games I've played where the docs have to do some verbal dance around why bracers sometimes seem to help AC and sometimes not. The explanation, I understand, has to do with a complex D&D rule that is kept around for whatever reasons. I'm not a rabid D&D type person who wants to know all the rules, and that's why I play games like Crossfire... If I was a complexity freak, I'd probably not do games like Crossfire. So, back to the point... bracers bug the crap out of me. I don't always want to take the time to research how things work. I'd like it to basically make sense and be somewhat obvious what is going on... Bracer complexity is nothing compared to zone damage rules and other ideas being discussed here. I see a scenario developing that results in a game I may not want to play... a reality simulation and not a fantasy. I would rather trust my ability to decide whether my cool magical stuff will give me reasonable odds for surviving a challenging fight as-is, and not realize that all my protection will rot away under my feet according to some rocket-science that will be hard to simulate in the heat of gaming. > > Siphon money from high level chars: They have enough money that they > > won't even notice it. This is better solved by having some really > > expensive items. Something like in-game dungeon design, where real > > estate costs lots of money, and so do tiles that the player can place. > > The real-estate has of course been talked about. That is really the only > other way to get rid of money - other high valued items don't do anything, > because no one ever buys them. I say this is bologna... but then I don't have any characters over level thirty something... I buy cool stuff whether I use it regularly or not, just because it is something special/unique. For me the game is experiencing a lot of variety. It's not all about cranking up levels for leveling's sake. I save the money so that I can buy whatever I have an opportunity to buy. > > Gift Equipment : Players will then "gift repair" equipment. And with the > > ideas I've seen floated around, these gift repairs don't have to be all > > that common. High level equipment on a low level character will last a > > long time. > > Gift equipment should last a bit longer on lower level characters, but > hard to really say how much longer - low level characters would have their > stuff damaged at a slower rate, but not necessarily a lot slower. The main > difference is that low level players won't have to spend nearly as much for > repairs. > but yeah, I think the gift item is not solvable except by getting the > item_power stuff properly tuned, such that low level characters wouldn't be > able to use high level stuff (or they would have to use it to the > exclusivity of any other magical equipment, which may not be worth while if > the item is highly specialized). Folks, this isn't a deathmatch... If a group of players like gifting, what is the real problem with that? People are going to bend the reality to suit their particular mood... Ok, I like both. On my own server, I appreciate doing stuff myself, but on metalforge, you won't see me not using things that somebody I know gave me... but I don't go around asking either. Some people "give" things that aren't affected by damage... the password to some quest or another... Are you going to control that too? That happened to me with the Tower of Stars. I chose to find the password myself before playing the levels beyond the passworded gate. I like that ability to choose. In fact, it is very believable that some true hero would be going for the common good of battling evil - and thus shares equipment and knowledge to people he trusts will use it for the goal he seeks of destroying evil. So there, you can model a legitimate reason to leave things the way they are... Are rules being made to force people to conform to a particular version of gaming that may reduce the ability of the player to customize his play to his mood? This isn't to say that I have not found merit in the discussion, but the longer it goes on, the more skeptical I get since there seems to be snowball effect going on... > > Anyway, this is my opinion. I don't know how other players feel about > > this. Gros was asking around at some point. > > > > mids, maybe you could have a poll on your website? > > May not be a bad idea - no reason to do something if no one wants to use > of. > > Poles can of course be tricky - some number of players seem to think that > gift equipment is in fact a good thing, but I doubt there are many server > admins that would agree with that. So what does it matter what a server admin thinks anyway. Is a game not supposed to be what players enjoy the most? I don't get it... Why not make damaging items a configurable option... like some of the other things that are configurable. From kbulgrien at worldnet.att.net Mon Sep 2 11:53:27 2002 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Thu Jan 13 18:02:47 2005 Subject: [CF-Devel] Item Damage idea In-Reply-To: <20020902085740.YVIU2447.mtiwmhc22.worldnet.att.net@there> References: <000001c24e79$515c0670$c86ebb81@gizmo> <3D731649.1080403@sonic.net> <20020902085740.YVIU2447.mtiwmhc22.worldnet.att.net@there> Message-ID: <20020902165037.ZEKX23721.mtiwmhc21.worldnet.att.net@there> On Monday 02 September 2002 04:00, I wrote: > The game modelling being described here is very complex. Complexity is > not always a good thing... Sometimes its nice for the player to actually > be able to intuitively understand what is going on. If an idea has merit, > I'd suggest starting with a simple implementation instead of going all out. > > This may be a bad example, but take a simple item like "bracers". I don't > know how many games I've played where the docs have to do some > verbal dance around why bracers sometimes seem to help AC and > sometimes not. The explanation, I understand, has to do with a complex > D&D rule that is kept around for whatever reasons. I'm not a rabid D&D > type person who wants to know all the rules, and that's why I play games > like Crossfire... If I was a complexity freak, I'd probably not do games > like Crossfire. So, back to the point... bracers bug the crap out of me. > I don't always want to take the time to research how things work. I'd like > it to basically make sense and be somewhat obvious what is going on... > > Bracer complexity is nothing compared to zone damage rules and other > ideas being discussed here. I see a scenario developing that results in > a game I may not want to play... a reality simulation and not a fantasy. > > I would rather trust my ability to decide whether my cool magical stuff > will give me reasonable odds for surviving a challenging fight as-is, > and not realize that all my protection will rot away under my feet > according to some rocket-science that will be hard to simulate > in the heat of gaming. To try to counter a possibility for misunderstanding... I recognize that some of he Crossfire battle modelling is pretty complex... The formulae for damage, etc. are hairy - to say the least... Nevertheless, one does not have to grasp the complexity of the formula in order to have a vague idea about what is going to happen if I use an identified dagger, poleaxe, or what-have-you... Sometimes complexity is necessarily good... but I think that it might be said that this kind is often hidden from the player, and made to model something that is quite obviously intuitive to a human player. Apparant randomness can be frustrating. Take acid damage... It can be said that maybe the best reason to wear bracers is that they are help "mute the annoying randomness" by taking acid damage first... I think muting of randomness by adding a particular piece of armor makes the game more pleasant (though it pains me tremendously when accumulated acid damage takes my bracers of magical power +5 down to -5... 8-O ). I accentuated my example of bracers to make a point... At some level, one must be able to accept things like this, and just play the game to see if it is really a significant issue when you consider the whole model. For bracers, its not that big of a deal. Wear the best ones you have - trust that the developer of the D&D rules knew what he was doing from experiences during gaming. If the game play feels ok, then you choose to keep playing the game and not shelve it. From mwedel at sonic.net Mon Sep 2 14:51:44 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:47 2005 Subject: [CF-Devel] Occidental Mages Sword +2 crashes server... References: <20020902072413.YOZL2447.mtiwmhc22.worldnet.att.net@there> Message-ID: <3D73C150.3050307@sonic.net> Kevin R. Bulgrien wrote: > I have a sword of Occidental Mages +2 that I wanted to try out to see what > it does... > > Every single time I kill things with it, the server crashes. (I am using a > recent cvs version, Mandrake 8.2, Python 2.0.) > > Some background: I had to tweak the compile to get it to work with Python > 2.0 since the detect didn't pick it up in lib/python. I have Python 2.2 on > the machine since I upgraded from Mandrake 8.0 to 8.2. I guess I'll try > compiling with that first. > > Not having done hardly any development on Linux/Unix, I am not very sure > what the best way to track down things like this. > > I am willing to spend some time trying to get data... Any suggestions about > how one might gather information? Nothing is printed in the log file that > seems relevant. Run the server under the debugger, eg: gdb crossfire (gdb) run When it crashes, do a (gdb) where (gdb) is the prompt gdb provides - you don't enter that part. This at least will show you what function it is crashing in. There could certainly odd issues if you are using the library of one version of python with the include file from another. From mwedel at sonic.net Mon Sep 2 18:21:04 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:47 2005 Subject: [CF-Devel] Automake patch available, please test it References: <20020811105642.GA28190@nic.nigdzie> <3D5B3186.5050106@sonic.net> <20020901170823.GB29162@nic.nigdzie> Message-ID: <3D73F260.8050302@sonic.net> Jacek Konieczny wrote: >>Distcheck failed on my >>system because there was a gmon.out. > > It is strange... Could you send me the full output of `make distcheck`? I figured out the cause - I have CFLAGS set to '-ggdb -pg -Wall' in my environment - thus the sub make it does as part of the configuration/testing picked that up, and when it did the test run of the program, it produced the gmon.out file. >> In addition to all the passed >>compile options, each compiled file now takes numerous lines, eg: > > [...] > This is very usefull for many developers. And lack of those messages > would be esspeccialy anoying to developers used to autoconf/automake > projects (there are more and more of them). I think the solution for me at least is to run make with the -s option. However, I need to try this out with non gnu tools and see what it looks like. From pstolarc at theperlguru.com Mon Sep 2 18:50:26 2002 From: pstolarc at theperlguru.com (pstolarc@theperlguru.com) Date: Thu Jan 13 18:02:47 2005 Subject: [CF-Devel] High level money drainage ideas In-Reply-To: <3D731649.1080403@sonic.net> References: <000001c24e79$515c0670$c86ebb81@gizmo> <000601c24ea0$0df21ce0$0a02a8c0@kameria> <1fb5nu8mg96s8ehmorbsiklbeil878maq7@flonk> <3D731649.1080403@sonic.net> Message-ID: <9976nu0to5hnj86ers48ft7mselbs68nh7@flonk> On Mon, 02 Sep 2002, Mark Wedel wrote: >> Siphon money from high level chars: They have enough money that they won't >> even notice it. This is better solved by having some really expensive >> items. Something like in-game dungeon design, where real estate costs lots >> of money, and so do tiles that the player can place. > > The real-estate has of course been talked about. That is really the only >other way to get rid of money - other high valued items don't do anything, >because no one ever buys them. It's not the *only* other way of getting rid of money. The "Lost Wages" mapset that I was workiing on, on mids, was another way of draining money. Gambling, pet fights, a pet shop (mostly for sending to the pet arena). (These ideas are from off the top of my head.) Maybe some really expensive to buy alchemical ingredients, for some weird, but highly useful alchemical formulae that can only be obtained through alchemy. BTW, here's how I would implement the real-estate idea. A special entrance for the pseudoDM. They enter a map that is a Platonic ideal of the real map. The monster gens don't work. Monsters are frozen. The pseudo-DM player is able to walk through walls, pick up *anything*, and drop *anything*. Monster gens and treasure gens only respawn on the "for players" map a limited number of times, but can be stacked to increase the total. When a player enters the map, through the for-players entrance, then everything gets spawned. counts are decreased, etc. I'm sure the people who played with the idea will have something to say about it. Next idea,; this can only be done a few times before it gets old, but dungeons with an entrance fee. It should be something fairly high, and have a decent reward at the end. Maybe some kind of health club map, with different levels of membership. Not really anything useful, but a new map to explore and play around with. A bar with expensive wine and beer. I know that I, as a high level char, spend a lot of time idle, just sitting around. Recently, I've started hanging around in bars instead of in bed. I would "invoke create food w_glass" on the table in front of me, but I wouldn't be adverse to spending some money for some good wine. It wouldn't be a huge drain, but it would be a use for some of all that money. Monsters that instead of causing damage, remove (steal) cash. You need to get a certain amount of money past the monsters to finish the quest segment. Difficult to fine tune against spell manipulation. (Some of the following ideas aren't mine. They're from my idea file.) I had a quest idea for the castle in Lost Wages. You have to run around paying bribes to every little official, working up the chain. "To see the prince, you need a pass from the grand viceroy" "You need a pass from the clerk to see the viceroy" Clerk sells pass, and "You need to get this stamped by the secretary to the prince" and so on. And you're only allowed in to the castle if you're nobility, (working in the nobility quests from Scorn). Custom Tombstones, either change the appearance/description of tombstones based on level, or allow the player to buy more expensive tombstones. ie. "Wooden cross nailed to the ground" "small tombstone" "large tombstone" "small, gem encrusted tombstone" And so on. Anyway, I hope this counters the "only other way to get rid of money" argument. And maybe someone will see some ideas here that they like, or be inspired with some ideas of their own. -Philip From pstolarc at theperlguru.com Mon Sep 2 19:15:43 2002 From: pstolarc at theperlguru.com (pstolarc@theperlguru.com) Date: Thu Jan 13 18:02:47 2005 Subject: [CF-Devel] Building the Server on Win32 In-Reply-To: <3D730CDB.6000006@sonic.net> References: <3D6E2C24.1030308@xanathos.de> <3D6EFBF3.2040800@sonic.net> <3D730CDB.6000006@sonic.net> Message-ID: On Mon, 02 Sep 2002, Mark Wedel wrote: > Does VC++ care about the whatspace/newline terminator on the .dsp file? I >have no problem just putting that patch in, but I noticed that the ^M got >stripped, where as the rest of that file does have ^M, so I'm not sure if it >would be useful as is. I tested it, and VC++ does indeed care about newline terminators. I stripped the CRLFs to LFs in one .dsp file, and had to restore from the backup (that I'd just made). I put my project file up at http://theperlguru.com/crossfire/crossfire32.dsp It's 66k, so I didn't want to post it to the list. And it has all sorts of VC++ goodness, like automatic changing of the text to English. It also has a different directory for python. "C:\Python22" instead of "D:\Python21". "C:\Python22" was the default install path for Python when I installed it. If adding CRLFs is really painful, then I can merge the diff with what's in CVS on my system. (I've got this great ASM CRLF utility I wrote, ...) Anyway, your choice as to what to do. -Philip From kf_bulk at excelcia.org Tue Sep 3 10:44:16 2002 From: kf_bulk at excelcia.org (Kurt Fitzner) Date: Thu Jan 13 18:02:47 2005 Subject: [CF-Devel] blinding code not working Message-ID: I noticed, since my characters normally pick Valriel, that blinding didn't tend to do much. I've traced the issue down to a problem with operator presedence. Either my compiler doesn't do it right, or there was a subtle bug in the program. The following code is from monster.c check_wakeup() if (rv->distance < QUERY_FLAG(enemy, FLAG_STEALTH)?(radius/2)+1:radius) { CLEAR_FLAG(op,FLAG_SLEEP); return 1; } On my version of GCC (I'm not an expert on precedence, so I don't know what the ANSI spec says), the < operator takes precedence over the ? operator, so the expression is reading: if ( (rv->distance < QUERY_FLAG(enemy, FLAG_STEALTH)) ? (radius/2)+1:radius ) Which will always return true because radius will always be nonzero. This makes it so that blinding never works. Also, the code for blinding is set up so that it checks if the monster is blind, but also if the monster can't see in the dark. IF the monster can see in the dark, then apparently blinding has no effect. I'd suggest changing this. Elf and Dwarf players can see in the dark, but don't have blinding protection. If anything, seeing in the dark would make you more succeptable to blinding. My real issue, though, is that if you want to protect a monster from blinding, making it see in the dark isn't the way to do it. The way to do it is resist_blind 100 in the archtype. This would be for monsters that don't depend on actual sight but, for example, smell. There are a lot of see in the dark monsters for whom it is not appropriate for them to be immune to blinding. Kurt. From kfitzner at excelcia.org Tue Sep 3 10:43:51 2002 From: kfitzner at excelcia.org (Kurt Fitzner) Date: Thu Jan 13 18:02:47 2005 Subject: [CF-Devel] blinding code not working Message-ID: I noticed, since my characters normally pick Valriel, that blinding didn't tend to do much. I've traced the issue down to a problem with operator presedence. Either my compiler doesn't do it right, or there was a subtle bug in the program. The following code is from monster.c check_wakeup() if (rv->distance < QUERY_FLAG(enemy, FLAG_STEALTH)?(radius/2)+1:radius) { CLEAR_FLAG(op,FLAG_SLEEP); return 1; } On my version of GCC (I'm not an expert on precedence, so I don't know what the ANSI spec says), the < operator takes precedence over the ? operator, so the expression is reading: if ( (rv->distance < QUERY_FLAG(enemy, FLAG_STEALTH)) ? (radius/2)+1:radius ) Which will always return true because radius will always be nonzero. This makes it so that blinding never works. Also, the code for blinding is set up so that it checks if the monster is blind, but also if the monster can't see in the dark. IF the monster can see in the dark, then apparently blinding has no effect. I'd suggest changing this. Elf and Dwarf players can see in the dark, but don't have blinding protection. If anything, seeing in the dark would make you more succeptable to blinding. My real issue, though, is that if you want to protect a monster from blinding, making it see in the dark isn't the way to do it. The way to do it is resist_blind 100 in the archtype. This would be for monsters that don't depend on actual sight but, for example, smell. There are a lot of see in the dark monsters for whom it is not appropriate for them to be immune to blinding. Kurt. From kbulgrien at worldnet.att.net Tue Sep 3 19:39:59 2002 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Thu Jan 13 18:02:47 2005 Subject: [CF-Devel] Sept 2 CVS updated Crossfire server is unstable? In-Reply-To: <20020902085740.YVIU2447.mtiwmhc22.worldnet.att.net@there> References: <3D731649.1080403@sonic.net> <000001c24e79$515c0670$c86ebb81@gizmo> <1fb5nu8mg96s8ehmorbsiklbeil878maq7@flonk> <3D731649.1080403@sonic.net> Message-ID: <5.1.0.14.0.20020903193324.00a123e0@postoffice.worldnet.att.net> The latest CVS update (Sept 2) I have done on the server appears to be unstable... Today I've already experienced at least four crashes. Prior to this update, the server has been fairly stable. I have now started running the server from the debugger to see what can be discovered... So far, crashes have primarily seem to occur when a player is "shopping". So far no crashes have occurred when everyone is "battling". This isn't based on very much data though. I just thought I'd share my impressions so that other testers can watch their installations also. From kbulgrien at worldnet.att.net Tue Sep 3 22:47:25 2002 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Thu Jan 13 18:02:47 2005 Subject: [CF-Devel] Occidental Mages Sword +2 crashes server... In-Reply-To: <3D73C150.3050307@sonic.net> References: <20020902072413.YOZL2447.mtiwmhc22.worldnet.att.net@there> <3D73C150.3050307@sonic.net> Message-ID: <20020904034352.XIYL23721.mtiwmhc21.worldnet.att.net@there> On Monday 02 September 2002 14:51, you wrote: > Kevin R. Bulgrien wrote: > > I have a sword of Occidental Mages +2 that I wanted to try out to see > > what it does... > > > > Every single time I kill things with it, the server crashes. > Run the server under the debugger, eg: > > gdb crossfire > (gdb) run > > When it crashes, do a > (gdb) where LOGIN: Player named SirK from ip 127.0.0.1 Trying to load map /home/games/var/crossfire/players/SirK/_city_apartment_apartments. load_original_map: /home/games/var/crossfire/players/SirK/_city_apartment_apartments (2) Scripting Weapon wielded Trying to load map /home/games/share/crossfire/maps/city/misc/beginners. load_original_map: /city/misc/beginners (0) Can't open /home/games/var/crossfire/maps/city/misc/beginners Can't open overlay /home/games/var/crossfire/maps/city/misc/beginners get_nearest_player: Found free/non friendly object on friendly list Program received signal SIGSEGV, Segmentation fault. 0x00000000 in ?? () (gdb) where #0 0x00000000 in ?? () #1 0x08052134 in attack_ob_simple (op=0x8a68b90, hitter=0x8121ed0, base_dam=16, base_wc=6) at attack.c:627 #2 0x0805254b in attack_ob (op=0x8a68b90, hitter=0x8121ed0) at attack.c:768 #3 0x0807bb84 in do_skill_attack (tmp=0x8a68b90, op=0x8121ed0, string=0x0) at skill_util.c:1476 #4 0x08070554 in move_player_attack (op=0x8121ed0, dir=3) at player.c:1762 #5 0x080706b9 in move_player (op=0x8121ed0, dir=3) at player.c:1798 #6 0x08059739 in move_internal (op=0x8121ed0, params=0x0, dir=3) at c_move.c:48 #7 0x08059765 in command_east (op=0x8121ed0, params=0x0) at c_move.c:54 #8 0x08059aaa in execute_newserver_command (pl=0x8121ed0, command=0xbffff530 "east") at c_new.c:112 #9 0x080c2881 in NewPlayerCmd (buf=0x8698af7 "", len=10, pl=0x40241008) at request.c:347 #10 0x080c0d50 in HandleClient (ns=0x4024100c, pl=0x40241008) at loop.c:361 #11 0x080c1461 in doeric_server () at loop.c:611 #12 0x08068ebf in main (argc=1, argv=0xbffff954) at main.c:1156 #13 0x400a4280 in __libc_start_main () from /lib/libc.so.6 (gdb) From kbulgrien at worldnet.att.net Tue Sep 3 22:50:55 2002 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Thu Jan 13 18:02:47 2005 Subject: [CF-Devel] Occidental Mages Sword +2 crashes server... In-Reply-To: <3D73C150.3050307@sonic.net> References: <20020902072413.YOZL2447.mtiwmhc22.worldnet.att.net@there> <3D73C150.3050307@sonic.net> Message-ID: <20020904034719.POPY11091.mtiwmhc22.worldnet.att.net@there> The (gdb) where output was generated on a server built from a Sept. 2 CVS update. From mwedel at sonic.net Tue Sep 3 23:05:40 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:47 2005 Subject: [CF-Devel] blinding code not working References: Message-ID: <3D758694.4050509@sonic.net> Kurt Fitzner wrote: > I noticed, since my characters normally pick Valriel, that blinding didn't > tend to do much. I've traced the issue down to a problem with operator > presedence. Either my compiler doesn't do it right, or there was a subtle bug > in the program. The following code is from monster.c check_wakeup() > > if (rv->distance < QUERY_FLAG(enemy, FLAG_STEALTH)?(radius/2)+1:radius) { > CLEAR_FLAG(op,FLAG_SLEEP); > return 1; > } Yeah - that looks bad. should have parens just to make it clearer to read the statement. No harm in putting them in - i'll check in a change for this shortly. > Also, the code for blinding is set up so that it checks if the monster is > blind, but also if the monster can't see in the dark. IF the monster can see > in the dark, then apparently blinding has no effect. I'd suggest changing > this. Elf and Dwarf players can see in the dark, but don't have blinding > protection. If anything, seeing in the dark would make you more succeptable > to blinding. My real issue, though, is that if you want to protect a monster > from blinding, making it see in the dark isn't the way to do it. The way to > do it is resist_blind 100 in the archtype. This would be for monsters that > don't depend on actual sight but, for example, smell. There are a lot of see > in the dark monsters for whom it is not appropriate for them to be immune to > blinding. I don't see anything in the attack code like what you describe, so presumably you are talking the bit in monster.c that looks sort of like: if ( QUERY_FLAG(op, FLAG_SLEEP) || QUERY_FLAG(op, FLAG_BLIND) || ((op->map->darkness>0) && !QUERY_FLAG(op,FLAG_SEE_IN_DARK) && !QUERY_FLAG(op,FLAG_SEE_INVISIBLE))) { if(!check_wakeup(op,enemy,&rv)) return 0; } (I've added some whitespace to it to make it more readable. since the BLIND check is part the the OR checks, if the creature is blind, it will always make a call to check_wakeup(). The check for see in dark will only happen if the player isn't blind or asleep. IF this is not what your talking about, I'd need some more specific area of the code you are talking about. From mwedel at sonic.net Wed Sep 4 00:25:09 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:47 2005 Subject: [CF-Devel] Occidental Mages Sword +2 crashes server... References: <20020902072413.YOZL2447.mtiwmhc22.worldnet.att.net@there> <3D73C150.3050307@sonic.net> <20020904034352.XIYL23721.mtiwmhc21.worldnet.att.net@there> Message-ID: <3D759935.2020605@sonic.net> Kevin R. Bulgrien wrote: > Program received signal SIGSEGV, Segmentation fault. > 0x00000000 in ?? () > (gdb) where > #0 0x00000000 in ?? () > #1 0x08052134 in attack_ob_simple (op=0x8a68b90, hitter=0x8121ed0, > base_dam=16, base_wc=6) at attack.c:627 > #2 0x0805254b in attack_ob (op=0x8a68b90, hitter=0x8121ed0) at attack.c:768 > #3 0x0807bb84 in do_skill_attack (tmp=0x8a68b90, op=0x8121ed0, string=0x0) > at skill_util.c:1476 > #4 0x08070554 in move_player_attack (op=0x8121ed0, dir=3) at player.c:1762 > #5 0x080706b9 in move_player (op=0x8121ed0, dir=3) at player.c:1798 > #6 0x08059739 in move_internal (op=0x8121ed0, params=0x0, dir=3) > at c_move.c:48 > #7 0x08059765 in command_east (op=0x8121ed0, params=0x0) at c_move.c:54 > #8 0x08059aaa in execute_newserver_command (pl=0x8121ed0, > command=0xbffff530 "east") at c_new.c:112 > #9 0x080c2881 in NewPlayerCmd (buf=0x8698af7 "", len=10, pl=0x40241008) > at request.c:347 > #10 0x080c0d50 in HandleClient (ns=0x4024100c, pl=0x40241008) at loop.c:361 > #11 0x080c1461 in doeric_server () at loop.c:611 > #12 0x08068ebf in main (argc=1, argv=0xbffff954) at main.c:1156 > #13 0x400a4280 in __libc_start_main () from /lib/libc.so.6 > (gdb) Line 627 in attack.c is: (PlugList[findPlugin(hitter->current_weapon->event_plugin[k])].eventfunc) (&CFP); So my guess is that event_plugin is set for the weapon, but there is no plugin by that name. Might be useful to do a : print *hitter->current_weapon My guess is that the event pointers for the weapon are bogus, so it is trying to execute a null function. From kf_bulk at excelcia.org Wed Sep 4 02:25:19 2002 From: kf_bulk at excelcia.org (Kurt Fitzner) Date: Thu Jan 13 18:02:48 2005 Subject: [CF-Devel] blinding code not working In-Reply-To: <3D758694.4050509@sonic.net> Message-ID: On 04-Sep-2002 Mark Wedel wrote: > Kurt Fitzner wrote: > IF this is not what your talking about, I'd need some more specific area > of the code you are talking about. The code I mean is check_wakeup() line 226 (or close to it) in monster.c if(QUERY_FLAG(op, FLAG_BLIND) && !QUERY_FLAG(op, FLAG_SEE_INVISIBLE)) radius = MIN_MON_RADIUS; I think this makes blinding quite a bit less useful than it deserves to be. For example, most demons have see_invisible in the archtype. This makes blinding useless against the monsters that, really, should be the particular target of that attack. The issue, too, is that it's quietly useless. You'll get the message that a fiend or big demon or demon lord is blinded, but the blinding just won't ahve any effect. The same check is in can_see_enemy() or'ed with a check for FLAG_XRAYS. I've commented out the FLAG_SEE_INVISIBLE checks on my server. I've had a chance to play more with the precedence issue fixed, by the way. It didn't just affect blinding. It made it so every monster on a map would target you the instant you entered a map, regardless of how far away you were. With the braces put in, the code acts like it should and large maps are much more fun. It actually makes it a little harder. Instead of being able to huddle by the stairs and be sure that any monster on the map will come to you, you end up running into monsters as you walk around more and they begind to target you as you get closer to them. Much more realistic and fun. This is most notable on the Meganthropos quest where the random maps are quite large and you have dozens of Galeotrolls wandering around. Kurt. From kbulgrien at worldnet.att.net Wed Sep 4 17:51:15 2002 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Thu Jan 13 18:02:48 2005 Subject: [CF-Devel] Sept 2 CVS updated Crossfire server is unstable? In-Reply-To: <5.1.0.14.0.20020903193324.00a123e0@postoffice.worldnet.att.net> References: <3D731649.1080403@sonic.net> <5.1.0.14.0.20020903193324.00a123e0@postoffice.worldnet.att.net> Message-ID: <20020904224714.CWLN3050.mtiwmhc23.worldnet.att.net@there> On Tuesday 03 September 2002 19:39, you wrote: > The latest CVS update (Sept 2) I have done on the server > appears to be unstable... Today I've already experienced at > least four crashes. Prior to this update, the server has > been fairly stable. One of the crashes (from the gdb log): Also some BUG: messages? make_path_tofile /home/games/var/crossfire/players/MrsB/_city_apartment_apartments... Saving map /home/games/var/crossfire/players/MrsB/_city_apartment_apartments Saving map /city/city Resetting map /home/games/var/crossfire/players/MrsB/_city_apartment_apartments. Saving map /city/misc/gatehouse Saving map /world/world_a3 Saving map /world/world_a2 load_original_map: /styles/specialmaps/fake_heal_post (8) load_original_map: /styles/monsterstyles/humanoid/humanoid_2 (8) Saving map /random/0000000000000003 Saving map /random/0000000000000002 BUG: SK_level(arch rune_icestorm, name Rune of Icestorm): level <= 0 BUG: SK_level(arch rune_icestorm, name Rune of Icestorm): level <= 0 BUG: SK_level(arch rune_icestorm, name Rune of Icestorm): level <= 0 BUG: SK_level(arch rune_icestorm, name Rune of Icestorm): level <= 0 BUG: SK_level(arch rune_icestorm, name Rune of Icestorm): level <= 0 BUG: SK_level(arch rune_icestorm, name Rune of Icestorm): level <= 0 BUG: SK_level(arch rune_icestorm, name Rune of Icestorm): level <= 0 BUG: SK_level(arch rune_icestorm, name Rune of Icestorm): level <= 0 BUG: SK_level(arch rune_icestorm, name Rune of Icestorm): level <= 0 BUG: SK_level(arch rune_icestorm, name Rune of Icestorm): level <= 0 BUG: SK_level(arch rune_icestorm, name Rune of Icestorm): level <= 0 BUG: SK_level(arch rune_icestorm, name Rune of Icestorm): level <= 0 BUG: SK_level(arch rune_icestorm, name Rune of Icestorm): level <= 0 CSSTAT: Wed Sep 4 09:16 tot 109814 2656283 1 37708 inc 27294 320353 1 600 make_path_tofile /home/games/var/crossfire/players/MrsB/MrsB.pl... load_original_map: /styles/specialmaps/turrettrap (8) load_original_map: /styles/monsterstyles/humanoid/humanoid_3 (8) Saving map /random/0000000000000005 CSSTAT: Wed Sep 4 09:26 tot 125692 2803159 1 38308 inc 15878 146876 1 600 make_path_tofile /home/games/var/crossfire/players/MrsB/MrsB.pl... Trying to load map /home/games/share/crossfire/maps/peterm/quests/goblin_chief. load_original_map: /peterm/quests/goblin_chief (0) Can't open /home/games/var/crossfire/maps/peterm/quests/goblin_chief Can't open overlay /home/games/var/crossfire/maps/peterm/quests/goblin_chief load_original_map: /styles/monsterstyles/humanoid/humanoid_4 (8) Saving map /random/0000000000000006 Saving map /peterm/quests/goblin_chief enter_exit: Exit stairs going down (1,23) on map /random/0000000000000007 is 0 destination coordinates Saving map /random/0000000000000007 Player 'MrsB' tried apply the unknown object (184783) Adding friendly object gatehouse guard. Adding friendly object gatehouse guard. Adding friendly object gatehouse guard. Adding friendly object gatehouse guard. Saving map /peterm/quests/goblin_chief CSSTAT: Wed Sep 4 09:36 tot 157350 3079602 1 38908 inc 31658 276443 1 600 Trying to load map /home/games/share/crossfire/maps/city/misc/drywell. load_original_map: /city/misc/drywell (0) Can't open /home/games/var/crossfire/maps/city/misc/drywell Can't open overlay /home/games/var/crossfire/maps/city/misc/drywell Saving map /world/world_a2 Saving map /random/0000000000000001 Saving map /world/world_a3 Saving map /city/misc/gatehouse make_path_tofile /home/games/var/crossfire/players/MrsB/MrsB.pl... Saving map /random/0000000000000000 Saving map /city/city BUG: SK_level(arch snowstorm, name snowstorm): level <= 0 BUG: SK_level(arch snowstorm, name snowstorm): level <= 0 BUG: SK_level(arch snowstorm, name snowstorm): level <= 0 Resetting map /city/misc/beginners. Fixed inventory in MrsB (1938651 -> 1938657) Trying to load map /home/games/share/crossfire/maps/city/shops/magicshop. load_original_map: /city/shops/magicshop (0) Can't open /home/games/var/crossfire/maps/city/shops/magicshop Can't open overlay /home/games/var/crossfire/maps/city/shops/magicshop Saving map /city/misc/drywell Saving map /city/city CSSTAT: Wed Sep 4 09:46 tot 178574 3407268 1 39508 inc 21224 327666 1 600 Fixed inventory in MrsB (2525674 -> 2525677) make_path_tofile /home/games/var/crossfire/players/MrsB/MrsB.pl... Trying to load map /home/games/var/crossfire/players/MrsB/_city_apartment_apartments. load_original_map: /home/games/var/crossfire/players/MrsB/_city_apartment_apartments (2) make_path_tofile /home/games/var/crossfire/players/MrsB/MrsB.pl... ReadPacket got an error.: Connection reset by peer ReadPacket got error 104, returning 0 Program received signal SIGPIPE, Broken pipe. 0x4016a384 in write () from /lib/libc.so.6 (gdb) where #0 0x4016a384 in write () from /lib/libc.so.6 #1 0xbfffc8f0 in ?? () #2 0x080c1b92 in Send_With_Handling (ns=0x9159714, msg=0xbfffc8f0) at lowlevel.c:414 #3 0x080c43a0 in esrv_map_doneredraw (ns=0x9159714, newmap=0xbfffc950) at request.c:888 #4 0x080c5ea4 in draw_client_map (pl=0x8121ed0) at request.c:1456 #5 0x080c14d6 in doeric_server () at loop.c:631 #6 0x08068ebf in main (argc=1, argv=0xbffff954) at main.c:1156 #7 0x400a4280 in __libc_start_main () from /lib/libc.so.6 (gdb) From kbulgrien at worldnet.att.net Wed Sep 4 18:27:59 2002 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Thu Jan 13 18:02:48 2005 Subject: [CF-Devel] Apartments & Server crashes - Bad voodoo... In-Reply-To: <20020904224714.CWLN3050.mtiwmhc23.worldnet.att.net@there> References: <5.1.0.14.0.20020903193324.00a123e0@postoffice.worldnet.att.net> <3D731649.1080403@sonic.net> <5.1.0.14.0.20020903193324.00a123e0@postoffice.worldnet.att.net> Message-ID: <5.1.0.14.0.20020904182231.00a1db70@postoffice.worldnet.att.net> Scenario: 1) Enter apartment 2) Drop ultra-cool artifact on floor 3) Exit apartment 4) Play a while 5) Server crashes Results: The ultra-cool artifact is GONE! Not in player inventory, not in apartment! This is REALLY BAD VOODOO... It was a VERY ULTRA COOL ARTIFACT! Why isn't the apartment saved when you exit? I think that the player autosaved during step 4, which is why the artifact is no longer in his inventory, but the apartment did not autosave... Server version: near top of current CVS. From kbulgrien at worldnet.att.net Wed Sep 4 19:28:47 2002 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Thu Jan 13 18:02:48 2005 Subject: [CF-Devel] Occidental Mages Sword +2 crashes server... In-Reply-To: <3D73C150.3050307@sonic.net> References: <20020902072413.YOZL2447.mtiwmhc22.worldnet.att.net@there> <3D73C150.3050307@sonic.net> Message-ID: <20020905002442.FSOQ3050.mtiwmhc23.worldnet.att.net@there> Ok, here is the additional info (after digging through help files.... (BTW, this weapon was generated by a store). --- Saving map /city/city make_path_tofile /home/games/var/crossfire/players/SirK/SirK.pl... Unrecognized string: resist_life_stealing 25 Player 'SirK' tried to move the unknown object (0) Player 'SirK' tried to move the unknown object (0) Player 'SirK' tried to move the unknown object (0) Saving map /city/misc/drywell Saving map /city/city Fixed inventory in SirK (408191 -> 408193) CSSTAT: Wed Sep 4 19:02 tot 126553 2715360 1 4200 inc 10836 351923 1 600 make_path_tofile /home/games/var/crossfire/players/SirK/SirK.pl... Trying to load map /home/games/var/crossfire/players/SirK/_city_apartment_apartments. load_original_map: /home/games/var/crossfire/players/SirK/_city_apartment_apartments (2) CSSTAT: Wed Sep 4 19:12 tot 126847 2723751 1 4800 inc 294 8391 1 600 make_path_tofile /home/games/var/crossfire/players/SirK/SirK.pl... Scripting Weapon wielded Trying to load map /home/games/share/crossfire/maps/city/misc/beginners. load_original_map: /city/misc/beginners (0) Can't open /home/games/var/crossfire/maps/city/misc/beginners Can't open overlay /home/games/var/crossfire/maps/city/misc/beginners Program received signal SIGSEGV, Segmentation fault. 0x00000000 in ?? () (gdb) where #0 0x00000000 in ?? () #1 0x08052134 in attack_ob_simple (op=0x815c008, hitter=0x8121ed0, base_dam=26, base_wc=6) at attack.c:627 #2 0x0805254b in attack_ob (op=0x815c008, hitter=0x8121ed0) at attack.c:768 #3 0x0807bb84 in do_skill_attack (tmp=0x815c008, op=0x8121ed0, string=0x0) at skill_util.c:1476 #4 0x08070554 in move_player_attack (op=0x8121ed0, dir=3) at player.c:1762 #5 0x080706b9 in move_player (op=0x8121ed0, dir=3) at player.c:1798 #6 0x08059739 in move_internal (op=0x8121ed0, params=0x0, dir=3) at c_move.c:48 #7 0x08059765 in command_east (op=0x8121ed0, params=0x0) at c_move.c:54 #8 0x08059aaa in execute_newserver_command (pl=0x8121ed0, command=0xbffff530 "east") at c_new.c:112 #9 0x080c2881 in NewPlayerCmd (buf=0x8698af7 "", len=10, pl=0x40241008) at request.c:347 #10 0x080c0d50 in HandleClient (ns=0x4024100c, pl=0x40241008) at loop.c:361 #11 0x080c1461 in doeric_server () at loop.c:611 #12 0x08068ebf in main (argc=1, argv=0xbffff954) at main.c:1156 #13 0x400a4280 in __libc_start_main () from /lib/libc.so.6 (gdb) print *hitter->current_weapon No symbol "hitter" in current context. (gdb) ? Undefined command: "". Try "help". (gdb) help (gdb) help stack Examining the stack. The stack is made up of stack frames. Gdb assigns numbers to stack frames counting from zero for the innermost (currently executing) frame. At any time gdb identifies one frame as the "selected" frame. Variable lookups are done with respect to the selected frame. When the program being debugged stops, gdb selects the innermost frame. The commands below can be used to select other frames by number or address. List of commands: backtrace -- Print backtrace of all stack frames bt -- Print backtrace of all stack frames down -- Select and print stack frame called by this one frame -- Select and print a stack frame return -- Make selected stack frame return to its caller select-frame -- Select a stack frame without printing anything up -- Select and print stack frame that called this one Type "help" followed by command name for full documentation. Command name abbreviations are allowed if unambiguous. (gdb) select-frame #1 Invalid character '#' in expression. (gdb) help select-frame 1 Select a stack frame without printing anything. An argument specifies the frame to select. It can be a stack frame number or the address of the frame. (gdb) select-frame 1 (gdb) print *hitter->current_weapon $1 = {contr = 0x0, next = 0x8f06598, prev = 0x8f07d58, active_next = 0x0, active_prev = 0x0, below = 0x8e4ed30, above = 0x0, inv = 0x0, container = 0x0, env = 0x8121ed0, more = 0x0, head = 0x0, map = 0x0, count = 147852, refcount = 0, name = 0x83d67ca "long sword", name_pl = 0x83d67ea "long swords", title = 0x8ccb70a "of Occidental Mages", race = 0x0, slaying = 0x0, msg = 0x83f614a " The Ancient School of Occidental Mages created that weapon during\n the Empire Wars, charging it with their Chaotic Powers.\n", x = 0, y = 0, ox = 0, oy = 0, speed = 0, speed_left = -0.100000001, casting_speed = 0, nrof = 1, face = 0x81a2818, direction = 0 '\000', facing = 0 '\000', type = 15 '\017', client_type = 101, resist = { 0 }, attacktype = 1, path_attuned = 0, path_repelled = 0, path_denied = 0, material = 2, magic = 2 '\002', thrownthaco = 0 '\000', state = 0 '\000', value = 900, level = 0, last_heal = 0, last_sp = 8, last_grace = 0, last_eat = 0, invisible = 0, pick_up = 0 '\000', item_power = 1 '\001', gen_sp_armour = 0 '\000', weight = 12000, weight_limit = 0, carrying = 0, glow_radius = 0, stats = { Str = 0 '\000', Dex = 0 '\000', Con = 0 '\000', Wis = 0 '\000', Cha = 0 '\000', Int = 0 '\000', Pow = 0 '\000', wc = 0 '\000', ac = 0 '\000', hp = 0, maxhp = 0, sp = 0, maxsp = 0, grace = 0, maxgrace = 0, exp = 0, food = 0, dam = 8, luck = 0 '\000'}, current_weapon_script = 0x0, current_weapon = 0x0, weapontype = 1, body_info = "\000?\000\000\000\000\000\000\000\000\000", body_used = "\000?\000\000\000\000\000\000\000\000\000", owner = 0x0, ownercount = 0, enemy = 0x0, attacked_by = 0x0, attacked_by_count = 4294967295, randomitems = 0x0, run_away = 0, chosen_skill = 0x0, exp_obj = 0x0, hide = 0, move_status = 0, move_type = 0, will_apply = 0 '\000', spellitem = 0x0, expmul = 1, arch = 0x83d6490, other_arch = 0x0, flags = {536870944, 0, 65536, 4}, animation_id = 0, anim_speed = 0 '\000', last_anim = 0 '\000', elevation = 0, event_hook = {0x0, 0x0, 0x83f6242 "/python/weapon_occidental_mages.py", 0x0 }, event_plugin = {0x0, 0x0, 0x83f6132 "Python", 0x0 }, event_options = {0x0 }} (gdb) From kbulgrien at worldnet.att.net Wed Sep 4 20:51:04 2002 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Thu Jan 13 18:02:48 2005 Subject: [CF-Devel] Apartments & Server crashes - Bad voodoo... In-Reply-To: <5.1.0.14.0.20020904182231.00a1db70@postoffice.worldnet.att.net> References: <5.1.0.14.0.20020903193324.00a123e0@postoffice.worldnet.att.net> <5.1.0.14.0.20020904182231.00a1db70@postoffice.worldnet.att.net> Message-ID: <20020905014709.IMBN3050.mtiwmhc23.worldnet.att.net@there> On Wednesday 04 September 2002 18:27, I wrote: > Scenario: > > 1) Enter apartment > 2) Drop ultra-cool artifact on floor > 3) Exit apartment > 4) Play a while > 5) Server crashes > > Results: > > The ultra-cool artifact is GONE! > > Not in player inventory, not in apartment! > > This is REALLY BAD VOODOO... It was a VERY ULTRA COOL ARTIFACT! > > Why isn't the apartment saved when you exit? I think that the > player autosaved during step 4, which is why the artifact is > no longer in his inventory, but the apartment did not > autosave... > > Server version: near top of current CVS. This, combined with the occidental mage invoked crashes allows one to duplicate items... 8-O From andi.vogl at gmx.net Wed Sep 4 22:22:45 2002 From: andi.vogl at gmx.net (Andreas Vogl) Date: Thu Jan 13 18:02:48 2005 Subject: [CF-Devel] mood floors broken? Message-ID: <000001c2548b$843a5d40$c86ebb81@gizmo> I've noticed a problem with mood floors in the latest CVS version: In several maps I have used mood floors to turn unagressive monsters agressive. I did so by inserting a creator under the feet of the unagressive monster. On activation, the creator creates a "furious_floor" which is supposed to make the monster go angry. This mechanism provided a very cool way to control monster attacks, especially for "boss-monsters". Recently this mechanism ceased to work. The monsters stay unagressive even after the furious_floor was created. Other ways of using mood floors still work, so I suspect the way how mood floors get processed might be broken. Maybe they are now processed only every time a monster moves (looking if it stepped on a mood floor). (Formerly) working examples of this kinda mood floor mechanism can be found on the following maps: - pup_land/castle_eureca/chest - santo_dominion/tavern.2ndfloor - pup_land/ancient/castle/gothwolte.3 I would be very happy if this problem could be fixed so the mood floors work like before. Any ideas what could have cause this, and/or where to look for it in the code? AndreasV From kbulgrien at worldnet.att.net Wed Sep 4 22:47:02 2002 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Thu Jan 13 18:02:48 2005 Subject: [CF-Devel] Occidental Mages Saber +3 crashes server... In-Reply-To: <20020905002442.FSOQ3050.mtiwmhc23.worldnet.att.net@there> References: <3D73C150.3050307@sonic.net> <20020905002442.FSOQ3050.mtiwmhc23.worldnet.att.net@there> Message-ID: <20020905034254.EDJQ23721.mtiwmhc21.worldnet.att.net@there> Another Occidental Mages weapon does this too... --- Scripting Weapon wielded Program received signal SIGSEGV, Segmentation fault. 0x00000000 in ?? () (gdb) where #0 0x00000000 in ?? () #1 0x08052134 in attack_ob_simple (op=0x8c72330, hitter=0x8a48160, base_dam=16, base_wc=5) at attack.c:627 #2 0x0805254b in attack_ob (op=0x8c72330, hitter=0x8a48160) at attack.c:768 #3 0x0807bd24 in do_skill_attack (tmp=0x8c72330, op=0x8a48160, string=0x0) at skill_util.c:1476 #4 0x080706f4 in move_player_attack (op=0x8a48160, dir=3) at player.c:1761 #5 0x08070859 in move_player (op=0x8a48160, dir=3) at player.c:1797 #6 0x08059809 in move_internal (op=0x8a48160, params=0x0, dir=3) at c_move.c:48 #7 0x08059835 in command_east (op=0x8a48160, params=0x0) at c_move.c:54 #8 0x08059b7a in execute_newserver_command (pl=0x8a48160, command=0xbffff530 "east") at c_new.c:112 #9 0x080c2cb1 in NewPlayerCmd (buf=0x8a5a45f "", len=10, pl=0x40267008) at request.c:347 #10 0x080c1180 in HandleClient (ns=0x4026700c, pl=0x40267008) at loop.c:361 #11 0x080c1891 in doeric_server () at loop.c:611 #12 0x08068f8f in main (argc=1, argv=0xbffff954) at main.c:1156 #13 0x400a4280 in __libc_start_main () from /lib/libc.so.6 (gdb) select-frame 1 (gdb) print *hitter->current_weapon $1 = {contr = 0x0, next = 0x9119528, prev = 0x9119b18, active_next = 0x0, active_prev = 0x0, below = 0x8b92900, above = 0x0, inv = 0x0, container = 0x0, env = 0x8a48160, more = 0x0, head = 0x0, map = 0x0, count = 149335, refcount = 0, name = 0x83d5bba "sabre", name_pl = 0x83d5bd2 "sabres", title = 0x8875d6a "of Occidental Mages", race = 0x0, slaying = 0x0, msg = 0x83f65ea " The Ancient School of Occidental Mages created that weapon during\n the Empire Wars, charging it with their Chaotic Powers.\n", x = 0, y = 0, ox = 0, oy = 0, speed = 0, speed_left = -0.100000001, casting_speed = 0, nrof = 1, face = 0x81a1944, direction = 0 '\000', facing = 0 '\000', type = 15 '\017', client_type = 101, resist = {0 }, attacktype = 1, path_attuned = 0, path_repelled = 0, path_denied = 0, material = 2, magic = 3 '\003', thrownthaco = 0 '\000', state = 0 '\000', value = 760, level = 0, last_heal = 0, last_sp = 8, last_grace = 0, last_eat = 0, invisible = 0, pick_up = 0 '\000', item_power = 2 '\002', gen_sp_armour = 0 '\000', weight = 9450, weight_limit = 0, carrying = 0, glow_radius = 0, stats = { Str = 0 '\000', Dex = 0 '\000', Con = 0 '\000', Wis = 0 '\000', Cha = 0 '\000', Int = 0 '\000', Pow = 0 '\000', wc = 0 '\000', ac = 0 '\000', hp = 0, maxhp = 0, sp = 0, maxsp = 0, grace = 0, maxgrace = 0, exp = 0, food = 0, dam = 7, luck = 0 '\000'}, current_weapon_script = 0x0, current_weapon = 0x0, weapontype = 4, body_info = "\000?\000\000\000\000\000\000\000\000\000", body_used = "\000?\000\000\000\000\000\000\000\000\000", owner = 0x0, ownercount = 0, enemy = 0x0, attacked_by = 0x0, attacked_by_count = 4294967295, randomitems = 0x0, run_away = 0, chosen_skill = 0x0, exp_obj = 0x0, hide = 0, move_status = 0, move_type = 0, will_apply = 0 '\000', spellitem = 0x0, expmul = 1, arch = 0x83d5898, other_arch = 0x0, flags = {536870944, 0, 65536, 4}, animation_id = 0, anim_speed = 0 '\000', last_anim = 0 '\000', elevation = 0, event_hook = {0x0, 0x0, 0x83f66e2 "/python/weapon_occidental_mages.py", 0x0 }, event_plugin = {0x0, 0x0, 0x83f65d2 "Python", 0x0 }, event_options = {0x0 }} (gdb) From kbulgrien at worldnet.att.net Wed Sep 4 22:47:34 2002 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Thu Jan 13 18:02:48 2005 Subject: [CF-Devel] make install error: ./wizhelp/freeze In-Reply-To: <20020905002442.FSOQ3050.mtiwmhc23.worldnet.att.net@there> References: <3D73C150.3050307@sonic.net> <20020905002442.FSOQ3050.mtiwmhc23.worldnet.att.net@there> Message-ID: <20020905034323.EDRV23721.mtiwmhc21.worldnet.att.net@there> From mwedel at sonic.net Thu Sep 5 00:03:20 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:48 2005 Subject: [CF-Devel] Sept 2 CVS updated Crossfire server is unstable? References: <3D731649.1080403@sonic.net> <5.1.0.14.0.20020903193324.00a123e0@postoffice.worldnet.att.net> <20020904224714.CWLN3050.mtiwmhc23.worldnet.att.net@there> Message-ID: <3D76E598.1050006@sonic.net> Kevin R. Bulgrien wrote: The above is a normal occurence if a client is shut down. SIGPIPE signals han be ignored. Can't remember the precise syntax in GDB to do that - something like 'handle SIGPIPE nostop', but not sure on that. > > Program received signal SIGPIPE, Broken pipe. > 0x4016a384 in write () from /lib/libc.so.6 > (gdb) where > #0 0x4016a384 in write () from /lib/libc.so.6 > #1 0xbfffc8f0 in ?? () > #2 0x080c1b92 in Send_With_Handling (ns=0x9159714, msg=0xbfffc8f0) > at lowlevel.c:414 > #3 0x080c43a0 in esrv_map_doneredraw (ns=0x9159714, newmap=0xbfffc950) > at request.c:888 > #4 0x080c5ea4 in draw_client_map (pl=0x8121ed0) at request.c:1456 > #5 0x080c14d6 in doeric_server () at loop.c:631 > #6 0x08068ebf in main (argc=1, argv=0xbffff954) at main.c:1156 > #7 0x400a4280 in __libc_start_main () from /lib/libc.so.6 > (gdb) > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel From mwedel at sonic.net Thu Sep 5 00:26:02 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:48 2005 Subject: [CF-Devel] blinding code not working References: Message-ID: <3D76EAEA.9020208@sonic.net> Kurt Fitzner wrote: > On 04-Sep-2002 Mark Wedel wrote: > The code I mean is check_wakeup() line 226 (or close to it) in monster.c > > if(QUERY_FLAG(op, FLAG_BLIND) && !QUERY_FLAG(op, FLAG_SEE_INVISIBLE)) > radius = MIN_MON_RADIUS; I agree - if monsters should be immuned to blind, give them resist_blind 100, and not just because they have see invisible. > The same check is in can_see_enemy() or'ed with a check for FLAG_XRAYS. I think that check was broken - it appears that the ! operator should have been in front of the ( see_invis || xray) check. In any case, I removed the see invis from that and also removed the xray check - this means that creatures with xrays will still pass the check of can_see_enemy. Probably not that big an issue because very few monsters have xray set. From mwedel at sonic.net Thu Sep 5 00:40:44 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:48 2005 Subject: [CF-Devel] Apartments & Server crashes - Bad voodoo... References: <5.1.0.14.0.20020903193324.00a123e0@postoffice.worldnet.att.net> <3D731649.1080403@sonic.net> <5.1.0.14.0.20020903193324.00a123e0@postoffice.worldnet.att.net> <5.1.0.14.0.20020904182231.00a1db70@postoffice.worldnet.att.net> Message-ID: <3D76EE5C.5020807@sonic.net> Kevin R. Bulgrien wrote: > Scenario: > > 1) Enter apartment > 2) Drop ultra-cool artifact on floor > 3) Exit apartment > 4) Play a while > 5) Server crashes > > Results: > > The ultra-cool artifact is GONE! > > Not in player inventory, not in apartment! > > This is REALLY BAD VOODOO... It was a VERY ULTRA COOL ARTIFACT! > > Why isn't the apartment saved when you exit? I think that the > player autosaved during step 4, which is why the artifact is > no longer in his inventory, but the apartment did not > autosave... Define 'play for a while'? The players apartment should get saved in a reasonable amount of time after he exits (no worse than 5 minutes unless you have changed some of the config.h options). Maps are not saved the instant a player leaves them to increase performance - loading and saving maps is a relatively costly operation, so when a player leaves a map, it stays in memory for some amount of time so that if they revisit it, it is still in memory (think of the main city map - player hops into a shop, but are probably going to be back into the city in a pretty short period). If a player can arbitrarily crash the server, all sorts of abuses are open - there is no good way to fix those abuses except to make sure the server won't crash. From mwedel at sonic.net Thu Sep 5 01:13:56 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:48 2005 Subject: [CF-Devel] Occidental Mages Sword +2 crashes server... References: <20020902072413.YOZL2447.mtiwmhc22.worldnet.att.net@there> <3D73C150.3050307@sonic.net> <20020905002442.FSOQ3050.mtiwmhc23.worldnet.att.net@there> Message-ID: <3D76F624.9030503@sonic.net> Kevin R. Bulgrien wrote: > Ok, here is the additional info (after digging through help files.... I've made a code change so that the server won't crash. However, for you in particular, that is only half the battle - the problem is that the plugin code for that weapon doesn't exist. Why that is happening needs to be figured out. Things I would check: Make sure your maps has a 'python' directory, and that directory should contain a couple files. Make sure that the plugin_python.so.0.1 was generated and installed - it should be in /share/crossfire/plugins. From mwedel at sonic.net Thu Sep 5 01:18:19 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:48 2005 Subject: [CF-Devel] mood floors broken? References: <000001c2548b$843a5d40$c86ebb81@gizmo> Message-ID: <3D76F72B.9030601@sonic.net> Andreas Vogl wrote: > I've noticed a problem with mood floors in the latest > CVS version: Should be fixed now in CVS: common/button.c: Fix do_mood_floor() to look at all objects on space for something to effect, not just things above the moodfloor. MSW 2002-09-11 I haven't really verified it all is behaving right, but the change is pretty minor. This was caused a while back when insert_ob_in_map no longer tries to resort the objects on the space - this is to save time, especially with large area of effect spells. From andi.vogl at gmx.net Thu Sep 5 06:03:01 2002 From: andi.vogl at gmx.net (Andreas Vogl) Date: Thu Jan 13 18:02:48 2005 Subject: [CF-Devel] mood floors broken? In-Reply-To: <3D76F72B.9030601@sonic.net> Message-ID: <000001c254cb$d055bf90$c86ebb81@gizmo> Thanks a lot for fixing this so fast. Moodfloors really seem to work now as they used to. This is great. :-) Andreas > -----Original Message----- > From: crossfire-devel-admin@lists.real-time.com > [mailto:crossfire-devel-admin@lists.real-time.com] On Behalf > Of Mark Wedel > Sent: Donnerstag, 5. September 2002 08:18 > To: crossfire-devel@lists.real-time.com > Subject: Re: [CF-Devel] mood floors broken? > > > Andreas Vogl wrote: > > I've noticed a problem with mood floors in the latest > > CVS version: > > Should be fixed now in CVS: > > common/button.c: Fix do_mood_floor() to look at all objects > on space for > something to effect, not just things above the moodfloor. > MSW 2002-09-11 > > I haven't really verified it all is behaving right, but the > change is pretty minor. > > This was caused a while back when insert_ob_in_map no > longer tries to resort the objects on the space - this is > to save time, especially with large area of effect spells. From andi.vogl at gmx.net Thu Sep 5 06:29:42 2002 From: andi.vogl at gmx.net (Andreas Vogl) Date: Thu Jan 13 18:02:48 2005 Subject: [CF-Devel] monsters don't attack / blinding code Message-ID: <000101c254cf$8a6d5660$c86ebb81@gizmo> I have noticed that with today's CVS, most monsters act like they were unagressive. Just enter the newbie tower in scorn for example. The kobolds just stand there and don't attack the player unless he attacks them first. Only monsters comming out of generators seem to behave right as they instantly start to attack. I guess there is some flaw in the recent changes for monsters "sensing" players. Note that exactly the same bug appeared last time it was tried to make monsters go agressive only when players are in proper range. Dunno if that is coincidence. Second thing I'd like to mention is the changes about blinding code. Now that almost any monster can be affected by it, blinding attack has become immensly powerful. A blinded monster does hit back when it is attacked, but at a minor rate it seems. And as soon as you step away, the blinded monster stops to attack at all. So, one thing that could be improved IMO, is that blinded monsters still use their full force of melee attack, whenever a player stands next to them ("touching the monster"). Unfortunately, I'm not sure how easy it would be to implement that. I suspect the reason why monsters get "weaker" when blinded could be that they regularly loose track of where the player is. Besides, when the system is meant to stay as it is, I would like to sprinkle some blinding immunities among the high level monsters (dragons, big demons etc). Does anyone have objections to this? AndreasV From kbulgrien at att.net Thu Sep 5 08:34:50 2002 From: kbulgrien at att.net (kbulgrien@att.net) Date: Thu Jan 13 18:02:48 2005 Subject: [CF-Devel] Apartments & Server crashes - Bad voodoo... Message-ID: <20020905133450.DCIF11091.mtiwmhc22.worldnet.att.net@webmail.worldnet.att.net> > Kevin R. Bulgrien wrote: > > Scenario: > > > > 1) Enter apartment > > 2) Drop ultra-cool artifact on floor > > 3) Exit apartment > > 4) Play a while > > 5) Server crashes > > > > Results: > > > > The ultra-cool artifact is GONE! > > > > Not in player inventory, not in apartment! > > > > This is REALLY BAD VOODOO... It was a VERY ULTRA COOL ARTIFACT! > > > > Why isn't the apartment saved when you exit? I think that the > > player autosaved during step 4, which is why the artifact is > > no longer in his inventory, but the apartment did not > > autosave... > > Define 'play for a while'? I don't remember exactly, but it was on the order of just a few minutes. I have not modified the default timing parameters in the config file. This behavior has occurred a few times. Sometimes it kills a recently dropped object, and sometimes it duplicates an item that was recently picked up from the floor of the apartment. Note that since the Sept. 2 CVS update, the server has been more unstable. The crashes I am speaking of have happened without being intentionally invoked by way of the O M swords. Conjecture: I suspect that the window of opportunity is quite small... The player autosave timer may have 1 min. left on it (or a similar small time), so the player autosaves, but the apartment map doesn't save for 5 minutes. If a crash occurs in those 4 minutes, inventory madness occurs. P.S. I agree about "making sure the server doesn't crash"... Not realizing that an apartment is treated the same way as a regular map, I was surprised when I lost a 50000 platinum item I had just bought - with a character that is not high level enough to find this a meaningless loss. From kf_bulk at excelcia.org Thu Sep 5 12:13:25 2002 From: kf_bulk at excelcia.org (Kurt Fitzner) Date: Thu Jan 13 18:02:49 2005 Subject: [CF-Devel] Occidental Mages Sword +2 crashes server... In-Reply-To: <3D76F624.9030503@sonic.net> Message-ID: On 05-Sep-2002 Mark Wedel wrote: > Kevin R. Bulgrien wrote: > Things I would check: > > Make sure your maps has a 'python' directory, and that directory should > contain a couple files. Something else to check is to make sure the python files aren't gzipped. When I compressed my maps, I did a gzip `find maps/ -type f` to gzip everything in my maps folder and down. This compressed the python files, which the plugin doesn't like. If you run crossfire with the "-d" switch, you'll see if the plugin is loading and initializing properly. Kurt. From kfitzner at excelcia.org Thu Sep 5 12:13:06 2002 From: kfitzner at excelcia.org (Kurt Fitzner) Date: Thu Jan 13 18:02:49 2005 Subject: [CF-Devel] Occidental Mages Sword +2 crashes server... In-Reply-To: <3D76F624.9030503@sonic.net> Message-ID: On 05-Sep-2002 Mark Wedel wrote: > Kevin R. Bulgrien wrote: > Things I would check: > > Make sure your maps has a 'python' directory, and that directory should > contain a couple files. Something else to check is to make sure the python files aren't gzipped. When I compressed my maps, I did a gzip `find maps/ -type f` to gzip everything in my maps folder and down. This compressed the python files, which the plugin doesn't like. If you run crossfire with the "-d" switch, you'll see if the plugin is loading and initializing properly. Kurt. From kf_bulk at excelcia.org Thu Sep 5 13:37:23 2002 From: kf_bulk at excelcia.org (Kurt Fitzner) Date: Thu Jan 13 18:02:49 2005 Subject: [CF-Devel] monsters don't attack / blinding code In-Reply-To: <000101c254cf$8a6d5660$c86ebb81@gizmo> Message-ID: On 05-Sep-2002 Andreas Vogl wrote: > I have noticed that with today's CVS, most monsters > act like they were unagressive. The blinding code, from what I can tell, does nothing except reduce the range to see your opponent. It drops it down to MIN_MON_RADIUS, which is 3. I'm not sure if, for multichar oponents, this is calculated from their 'origin' or from the nearest tile to you. You all would know that code better than I. The bug in the blinding code I mentioned earlier wasn't with the blinding code, it was with the range to see code in general. Essentially, it make every monster on a map able to see any player - check_wakeup() always returned a 1. With the see radius being based on the monster wisdom, any monster with a low wisdom will act like it can't see you until you get within 3 squares. > Second thing I'd like to mention is the changes about > blinding code. Now that almost any monster can be affected > by it, blinding attack has become immensly powerful. > A blinded monster does hit back when it is attacked, but > at a minor rate it seems. And as soon as you step away, > the blinded monster stops to attack at all. Not so different with paralysis, or confusion. I can't see any code anywhere that would affect the attack speed of a blinded monster. I do notice when I walk around in large maps, that I don't have the big fight at the stairs followed by walking around a deserted level. I encounter monsters scattered through the level, and they attack me as per normal. > I suspect the reason why monsters get > "weaker" when blinded could be that they regularly loose > track of where the player is. If the player is withing 3 squares and just hacking away, the monster won't loose track of you even if blind. > Besides, when the system is meant to stay as it is, > I would like to sprinkle some blinding immunities among > the high level monsters (dragons, big demons etc). > Does anyone have objections to this? You'll need to sprinkle more in than now exist. Dragons, and monsters that don't 'see' or particularly need to see (good sense of smell). I've never been fond of resist_anything 100, though. But at least with resist_blind, you won't get a message that you blind something and have it simply not work. From kf_bulk at excelcia.org Thu Sep 5 13:41:36 2002 From: kf_bulk at excelcia.org (Kurt Fitzner) Date: Thu Jan 13 18:02:49 2005 Subject: [CF-Devel] Entrance square not checked In-Reply-To: <000001c254cb$d055bf90$c86ebb81@gizmo> Message-ID: I haven't checked in CVS, but I noticed that with 1.3, the square I pop into a map at, or teleport to, don't get checked for signs or runes. For example, the magic depletion runes in the elemental towers don't function, because they are on the square you pop into the map at (the stairs). Also, the magic mouths in the the hall of quests that are set to congratulate you on completing a quest don't work either, because you teleport right on top of them. Is this fixed in CVS? Kurt. From kbulgrien at worldnet.att.net Thu Sep 5 13:51:03 2002 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Thu Jan 13 18:02:49 2005 Subject: [CF-Devel] Occidental Mages Sword +2 crashes server... In-Reply-To: <20020905002442.FSOQ3050.mtiwmhc23.worldnet.att.net@there> References: <3D73C150.3050307@sonic.net> <20020905002442.FSOQ3050.mtiwmhc23.worldnet.att.net@there> Message-ID: <20020905184637.CKKI3050.mtiwmhc23.worldnet.att.net@there> All I see is "initializing plugins:" which seems to imply that a message will follow, but there doesn't seem to be one. Do this mean the plugin didn't load? ... (gdb) run -d Starting program: /home/games/bin/crossfire -d Reading bmaps from /home/games/share/crossfire/bmaps...done (got 3875/3876/3876) Reading faces from /home/games/share/crossfire/faces...done Reading animations from /home/games/share/crossfire/animations...done. got (774) Reading archetypes from /home/games/share/crossfire/archetypes... arch-pass 1... Object Burning Tail of many lashings of Ruggilli seems to have too low item power? 45 > 12 Adding friendly object Evil Master, Bonehead. Object amulet of lifesaving had no item power, using 4 Object strange ring had no item power, using 4 Object tooth charm had no item power, using 7 Object Chaos Sword had no item power, using 13 Object Darkblade had no item power, using 24 Object Demonbane had no item power, using 7 Object dagger of fortune had no item power, using 7 Object Frost Hammer had no item power, using 13 Object Firestar had no item power, using 50 Object Gram had no item power, using 11 Object Holy Avenger had no item power, using 45 Object Kobold Dagger had no item power, using 4 Object Lava Slasher had no item power, using 18 calc_item_power got 25 enchantments for Katana of Masamune Object Katana of Masamune had no item power, using 50 Object Sting had no item power, using 4 calc_item_power got 24 enchantments for Belzebub's sword Object Belzebub's sword had no item power, using 50 Object Bonecrusher had no item power, using 4 Object Defender had no item power, using 5 Object Dragonslayer had no item power, using 7 Object Excalibur had no item power, using 30 Object Firebrand had no item power, using 5 Object Frostbrand had no item power, using 5 Object Staff of the Magi had no item power, using 18 Object Mjoellnir had no item power, using 7 Object Mournblade had no item power, using 27 Object Skullcleaver had no item power, using 4 Object Stormbringer had no item power, using 30 done Setting up archetable...done loading treasure... done arch-pass 2... done done Reading attack messages from /home/games/share/crossfire/attackmess...got 227 messages in 19 categories. Reading clockdata from /home/games/var/crossfire/clockdata...todtick=28020 Welcome to CrossFire, v1.3.0 Copyright (C) 1994 Mark Wedel. Copyright (C) 1992 Frank Tore Johansen. Can't open /home/games/share/crossfire/shutdown Reading artifacts from /home/games/share/crossfire/artifacts...Object NULL seems to have too low item p wer? 5 > 1 Object NULL seems to have too low item power? 9 > 3 calc_item_power got 22 enchantments for (null) Object NULL seems to have too low item power? 50 > 20 Object NULL seems to have too low item power? 9 > 4 Object NULL seems to have too low item power? 7 > 3 Object NULL seems to have too low item power? 30 > 12 calc_item_power got 23 enchantments for (null) Object NULL seems to have too low item power? 50 > 14 Object NULL seems to have too low item power? 27 > 12 Object NULL seems to have too low item power? 40 > 12 calc_item_power got 26 enchantments for (null) Object NULL seems to have too low item power? 50 > 15 calc_item_power got 23 enchantments for (null) Object NULL seems to have too low item power? 50 > 10 Object NULL seems to have too low item power? 21 > 10 Object NULL seems to have too low item power? 18 > 8 Object NULL seems to have too low item power? 11 > 4 Object NULL seems to have too low item power? 35 > 10 Object NULL seems to have too low item power? 27 > 4 Object NULL seems to have too low item power? 27 > 10 Object NULL seems to have too low item power? 21 > 8 Object NULL seems to have too low item power? 24 > 10 done. Initializing spells...done. Reading races from /home/games/share/crossfire/races... Resetting race to undead from Wraith for archetype Wraith Resetting race to faerie from elf for archetype elf Resetting race to reptile from Quetzalcoatl for archetype quetzalcoatl Resetting race to fire_elemental from fireborn for archetype fireborn Resetting race to human from barbarian for archetype barbarian Resetting race to human from cleric for archetype cleric Resetting race to human from mage for archetype mage Resetting race to human from ninja for archetype ninja Resetting race to human from priest for archetype priest Resetting race to human from swashbuckler for archetype swashbuckler Resetting race to human from thief for archetype thief Resetting race to human from viking for archetype viking Resetting race to human from warrior for archetype warrior Resetting race to human from wizard for archetype wizarddone. Initializing gods...done. Initializing reading data...Reading messages from /home/games/share/crossfire/messages...done. Reading bookarch from /home/games/var/crossfire/bookarch... book archives(used/avail): (8/924)(169/169)(77/77)(69/70)(0/70)(120/120) done. init_mon_info() got 262 monsters Done Reading alchemical formulae from /home/games/share/crossfire/formulae...done. Checking formulae lists...done. Reading skill_params from /home/games/share/crossfire/skill_params...done. Initialize new client/server data Loading image file /home/games/share/crossfire/crossfire.0 Loading image file /home/games/share/crossfire/crossfire.1 Initializing plugins : Waiting for connections... From pstolarc at theperlguru.com Thu Sep 5 14:32:34 2002 From: pstolarc at theperlguru.com (pstolarc@theperlguru.com) Date: Thu Jan 13 18:02:49 2005 Subject: [CF-Devel] Entrance square not checked In-Reply-To: References: <000001c254cb$d055bf90$c86ebb81@gizmo> Message-ID: On Thu, 05 Sep 2002, Kurt Fitzner wrote: >I haven't checked in CVS, but I noticed that with 1.3, the square I pop into a >map at, or teleport to, don't get checked for signs or runes. > >For example, the magic depletion runes in the elemental towers don't function, >because they are on the square you pop into the map at (the stairs). Also, >the magic mouths in the the hall of quests that are set to congratulate you on >completing a quest don't work either, because you teleport right on top of >them. This is due to the fact that runes and other squares are walk_on 1. Teleporters and exits and town portal &c. don't trigger walk_on 1. I think this may be desired behaviour. Unfortunately, this opens the server up to some weirdness, such as: Find a small button that triggers a gate. Set your first town portal endpoint somewhere. Walk on to the small button. Set your second town portal endpoint. Use the town portal. The gate stays open, and acts in reverse of the way it's supposed to This can also be done using levitation. Walk onto a small button. Put on boots of levitation. Fly off. Remove boots, and watch as the gate stays open. The levitation thing also works in reverse. Levitate to a rune trapped square. Float down. Stand on the rune trapped square without triggering it. -Philip From kbulgrien at worldnet.att.net Thu Sep 5 21:26:11 2002 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Thu Jan 13 18:02:49 2005 Subject: [CF-Devel] doc/scripts/Makefile.in missing In-Reply-To: References: <000001c254cb$d055bf90$c86ebb81@gizmo> Message-ID: <20020906022130.ZWKN11091.mtiwmhc22.worldnet.att.net@there> cvs update on 9/5/2002 Run ./configure results in: ... configure: creating ./config.status config.status: creating Makefile config.status: creating crossedit/Makefile config.status: creating crossedit/doc/Makefile config.status: creating crossedit/include/Makefile config.status: creating crossedit/Cnv/Makefile config.status: creating crossedit/bitmaps/Makefile config.status: creating doc/Makefile config.status: creating doc/Developers/Makefile config.status: creating doc/spell-docs/Makefile config.status: creating doc/spoiler/Makefile config.status: creating doc/spoiler-html/Makefile config.status: creating doc/playbook/Makefile config.status: creating doc/playbook-html/Makefile config.status: creating doc/scripts/Makefile config.status: error: cannot find input file: doc/scripts/Makefile.in [krb@krayp120 crossfire]# ls doc/scripts The directory exists, but is empty... From temitchell at sympatico.ca Thu Sep 5 20:47:36 2002 From: temitchell at sympatico.ca (Todd Mitchell) Date: Thu Jan 13 18:02:49 2005 Subject: [CF-Devel] Python plugin setup References: <3D73C150.3050307@sonic.net> <20020905002442.FSOQ3050.mtiwmhc23.worldnet.att.net@there> <20020905184637.CKKI3050.mtiwmhc23.worldnet.att.net@there> Message-ID: <002401c25547$606891e0$0a02a8c0@kameria> Kevin Bulgrien said: >All I see is "initializing plugins:" which seems to imply that a message >will follow, but there doesn't seem to be one. Do this mean the plugin >didn't load? I managed to get the python plugin to work but I got it to work with python 1.5 which blew up with the Imperial post scripts (but nicely and with lots of logging). My redhat 7.1 (I have had such a crummy time with this version!) is balking at the python 2.2 srpms so I will have to work on that, but this is how I did it from the CVS: ./configure --with-includes=-I/usr/include/python1.5 (you'd probably want to point this to the 2x python - look for Python.h) then do make whatever then go into the /crossfire/plugin folder and do make - it should compile, then make install when you start up the server you can't miss the message ->loading plugin : plugin_python.so.0.1 Then you have to deal with any problems in the python scripts too ;) From temitchell at sympatico.ca Thu Sep 5 15:35:40 2002 From: temitchell at sympatico.ca (Todd Mitchell) Date: Thu Jan 13 18:02:49 2005 Subject: [CF-Devel] Occidental Mages Sword +2 crashes server... References: <3D73C150.3050307@sonic.net> <20020905002442.FSOQ3050.mtiwmhc23.worldnet.att.net@there> <20020905184637.CKKI3050.mtiwmhc23.worldnet.att.net@there> Message-ID: <001c01c2551b$f0819fa0$0802a8c0@ott.ca.dmr> I too am having some fun with the python plugin, I got past the ./configure --with-includes =I/usr/include/python2.2 (to get the Python.h) Then I got an error that the plugin_python.h file could not be found --then I got the plugin files from CVS (was using 1.3.0) and now I get the error : CFCanUseWand: FLAG_USE_RANGE undeclared when doing make of the plugin so it bombs out on me. Apparently you can find out what plugins are installed by using dm command: pluglist (thanks to Joris B for this). Looks to me like you don't have any if it doesn't list any. Anyway still banging away on this...anyone know if this plugin is working? From kbulgrien at worldnet.att.net Thu Sep 5 22:07:08 2002 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Thu Jan 13 18:02:49 2005 Subject: [CF-Devel] crossfire/INSTALL file error In-Reply-To: References: <000001c254cb$d055bf90$c86ebb81@gizmo> Message-ID: <20020906030226.RGIE3050.mtiwmhc23.worldnet.att.net@there> This paragraph is incorrect: If you want the python plugin support, you will likely need to add the --with-includes=/usr/include/pythonX.Y, where X.Y will vary depending on the version of python installed on your system. Instead, it should read: If you want the python plugin support, you will likely need to add the --with-includes="-I /usr/include/pythonX.Y", where X.Y will vary depending on the version of python installed on your system. The configure script does not insert a -I option, and this must be specifed in the --with-includes option data. From kbulgrien at worldnet.att.net Thu Sep 5 22:22:08 2002 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Thu Jan 13 18:02:49 2005 Subject: [CF-Devel] doc/scripts/Makefile.in missing Message-ID: <20020906031729.BOUF11091.mtiwmhc22.worldnet.att.net@there> > cvs update on 9/5/2002 > > Run ./configure results in: > > ... > configure: creating ./config.status > config.status: creating Makefile > config.status: creating crossedit/Makefile > config.status: creating crossedit/doc/Makefile > config.status: creating crossedit/include/Makefile > config.status: creating crossedit/Cnv/Makefile > config.status: creating crossedit/bitmaps/Makefile > config.status: creating doc/Makefile > config.status: creating doc/Developers/Makefile > config.status: creating doc/spell-docs/Makefile > config.status: creating doc/spoiler/Makefile > config.status: creating doc/spoiler-html/Makefile > config.status: creating doc/playbook/Makefile > config.status: creating doc/playbook-html/Makefile > config.status: creating doc/scripts/Makefile > config.status: error: cannot find input file: doc/scripts/Makefile.in > [krb@krayp120 crossfire]# ls doc/scripts > > The directory exists, but is empty... I deleted the directory reference in the script and it appeared to work... [krb@krayp120 crossfire]# diff --unified configure configure.orig --- configure Thu Sep 5 22:13:56 2002 +++ configure.orig Thu Sep 5 22:13:36 2002 @@ -7151,7 +7151,7 @@ datadir=${ndatadir} localstatedir=${nlocaldir} -ac_config_files="$ac_config_files Makefile crossedit/Makefile crossedit/doc/Makefile crossedit/include/Makefile crossedit/Cnv/Makefile crossedit/bitmaps/Makefile doc/Makefile doc/Developers/Makefile doc/spell-docs/Makefile doc/spoiler/Makefile doc/spoiler-html/Makefile doc/playbook/Makefile doc/playbook-html/Makefile lib/Makefile random_maps/Makefile socket/Makefile server/Makefile include/Makefile utils/Makefile lib/checkarch.pl lib/collect.pl utils/add_throw.perl utils/crossloop utils/crossloop.pl utils/metaserver.pl utils/crossloop.web common/Makefile plugin/Makefile" +ac_config_files="$ac_config_files Makefile crossedit/Makefile crossedit/doc/Makefile crossedit/include/Makefile crossedit/Cnv/Makefile crossedit/bitmaps/Makefile doc/Makefile doc/Developers/Makefile doc/spell-docs/Makefile doc/spoiler/Makefile doc/spoiler-html/Makefile doc/playbook/Makefile doc/playbook-html/Makefile doc/scripts/Makefile lib/Makefile random_maps/Makefile socket/Makefile server/Makefile include/Makefile utils/Makefile lib/checkarch.pl lib/collect.pl utils/add_throw.perl utils/crossloop utils/crossloop.pl utils/metaserver.pl utils/crossloop.web common/Makefile plugin/Makefile" cat >confcache <<\_ACEOF # This file is a shell script that caches the results of configure # tests run on this system so they can be shared between configure From mwedel at sonic.net Thu Sep 5 22:36:35 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:49 2005 Subject: [CF-Devel] Occidental Mages Sword +2 crashes server... References: <3D73C150.3050307@sonic.net> <20020905002442.FSOQ3050.mtiwmhc23.worldnet.att.net@there> <20020905184637.CKKI3050.mtiwmhc23.worldnet.att.net@there> <001c01c2551b$f0819fa0$0802a8c0@ott.ca.dmr> Message-ID: <3D7822C3.2090203@sonic.net> Todd Mitchell wrote: > I too am having some fun with the python plugin, I got past the > ./configure --with-includes =I/usr/include/python2.2 (to get the Python.h) > Then I got an error that the plugin_python.h file could not be found --then > I got the plugin files from CVS (was using 1.3.0) and now I get the error : > CFCanUseWand: FLAG_USE_RANGE undeclared when doing make of the plugin so it > bombs out on me. Make sure your entire crossfire (server) directory is from CVS. Taking just the plugin portion is likely to cause problems. If you have fully update CVS, the plugin stuff should at least compile OK and load OK. I haven't tested any scripts with it. From mwedel at sonic.net Thu Sep 5 22:38:47 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:49 2005 Subject: [CF-Devel] doc/scripts/Makefile.in missing References: <000001c254cb$d055bf90$c86ebb81@gizmo> <20020906022130.ZWKN11091.mtiwmhc22.worldnet.att.net@there> Message-ID: <3D782347.3010206@sonic.net> Kevin R. Bulgrien wrote: > cvs update on 9/5/2002 Make sure you do a 'cvs update -d'. Otherwise, it won't generate the new directories. From kbulgrien at worldnet.att.net Thu Sep 5 23:02:44 2002 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Thu Jan 13 18:02:49 2005 Subject: [CF-Devel] Python plugin setup In-Reply-To: <002401c25547$606891e0$0a02a8c0@kameria> References: <20020905184637.CKKI3050.mtiwmhc23.worldnet.att.net@there> <002401c25547$606891e0$0a02a8c0@kameria> Message-ID: <20020906035801.SSKB3050.mtiwmhc23.worldnet.att.net@there> On Thursday 05 September 2002 20:47, you wrote: > Kevin Bulgrien said: > >All I see is "initializing plugins:" which seems to imply that a message > >will follow, but there doesn't seem to be one. Do this mean the plugin > >didn't load? > > I managed to get the python plugin to work but I got it to work with python > 1.5 which blew up with the Imperial post scripts (but nicely and with lots > of logging). > My redhat 7.1 (I have had such a crummy time with this version!) is balking > at the python 2.2 srpms so I will have to work on that, but this is how I > did it from the CVS: > > ./configure --with-includes=-I/usr/include/python1.5 (you'd probably want > to point this to the 2x python - look for Python.h) > then do make whatever > then go into the /crossfire/plugin folder and do make - it should compile, > then make install > when you start up the server you can't miss the message ->loading plugin : > plugin_python.so.0.1 > > Then you have to deal with any problems in the python scripts too ;) Ok, this looks better... Initializing plugins : -> Loading plugin : plugin_python.so.0.1 [New Thread 1024 (LWP 24597)] CFPython Plugin loading..... PYTHON - Start initCFPython. [Done] Plugin CFPython Plugin 0.1 loaded under the name of Python Done PYTHON - Start postinitPlugin. Plugin Python (0) registered the event 13 Plugin Python (0) registered the event 15 Plugin Python (0) registered the event 18 Plugin Python (0) registered the event 19 Plugin Python (0) registered the event 23 Plugin Python (0) registered the event 24 Plugin Python (0) registered the event 20 Plugin Python (0) registered the event 21 Plugin Python (0) registered the event 22 [Done] Waiting for connections... When I upgraded from Mandrake 8.0 to 8.2, python-devel did not get updated, and in fact, Mandrake does not seem to offer a python-devel package to go with their other packages. I downloaded python2-devel out of the RedHat 7.3 packages since it is close to the same version. [krb@krayp120 krb]$ rpm -qa | grep python python-base-2.2-9mdk python-numeric-20.3-2mdk python-docs-2.2-9mdk libpython2.2-2.2-9mdk python-2.2-9mdk rpm-python-4.0.3-10mdk python2-devel-2.2-16 Ok, now to try it: You pick up the long sword of Occidental Mages +2. You unwield SirK's trident of Valriel +5 *. Readied skill: melee weapons. You wield long sword of Occidental Mages +2 (wielded). You turn the handle. You cut kobold hard. You turn the handle. You turn the handle. You cause kobold to shiver. You coat kobold in frost. You coat kobold in frost. You coat ant in frost. You turn the handle. You coat orc in frost. You coat orc in frost. From mwedel at sonic.net Thu Sep 5 22:46:47 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:50 2005 Subject: [CF-Devel] Entrance square not checked References: <000001c254cb$d055bf90$c86ebb81@gizmo> Message-ID: <3D782527.1030602@sonic.net> pstolarc@theperlguru.com wrote: > On Thu, 05 Sep 2002, Kurt Fitzner wrote: > > This is due to the fact that runes and other squares are walk_on 1. > Teleporters and exits and town portal &c. don't trigger walk_on 1. I think > this may be desired behaviour. Unfortunately, this opens the server up to > some weirdness, such as: Not sure if walk/fly on not working when using an exit is desired or not. For some exits, it is sort of clear that the character would be walking or flying to the destination (eg, stairs). Things let teleporters may not literally get walked on. I notice the code explicitly calls insert_ob_in_map () with the no walk on parameter. As I think about this, this may be to prevent infinite 'hopping' back and forth between exits. EG, I use an invis exit. That exit puts me on top of another invis exit. If the walk_on check was done, that invis exit would bounce me back to the original, and so on. Not a good thing. > > The levitation thing also works in reverse. Levitate to a rune trapped > square. Float down. Stand on the rune trapped square without triggering > it. I'm not too concerned with these issues. If that rune trapped square in that second case has something important on it the player isn't supposed to get without triggering the rune, the rune could have fly_on 1 set. Dealing with the issues of players mucking with small buttons isn't a very big deal IMO either. A player can just as easily always keep the button depressed by dropping some items on it. I suppose it is a bit od. I suppose it may be possible to do a walk_off/fly on check when player puts on boots. However, this could result in extra damage for the character if there is some bad effect on it that only happens when you enter, not when you stand still. From temitchell at sympatico.ca Thu Sep 5 23:19:34 2002 From: temitchell at sympatico.ca (Todd Mitchell) Date: Thu Jan 13 18:02:50 2005 Subject: [CF-Devel] Occidental Mages Sword +2 crashes server... References: <3D73C150.3050307@sonic.net> <20020905002442.FSOQ3050.mtiwmhc23.worldnet.att.net@there> <20020905184637.CKKI3050.mtiwmhc23.worldnet.att.net@there> <001c01c2551b$f0819fa0$0802a8c0@ott.ca.dmr> <3D7822C3.2090203@sonic.net> Message-ID: <005e01c2555c$9ad815c0$0a02a8c0@kameria> Yes, thanks. I found it does work correctly when I take the whole CVS. Also some people might have to modify the location of their python lib in the makefile (I did- the plugin was compiled with the 2.1 include but was looking in the 1.5 lib and giving me a version mismatch until I removed the 1.5 path entry). I have also gotten some of the IPO scripts to run once I installed python 2.1. > > Make sure your entire crossfire (server) directory is from CVS. Taking just > the plugin portion is likely to cause problems. > > If you have fully update CVS, the plugin stuff should at least compile OK and > load OK. I haven't tested any scripts with it. -By the way the DX client is still working quite well in the CVS version so far as I can tell. From kbulgrien at worldnet.att.net Thu Sep 5 23:31:01 2002 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Thu Jan 13 18:02:50 2005 Subject: [CF-Devel] doc/scripts/Makefile.in missing In-Reply-To: <3D782347.3010206@sonic.net> References: <000001c254cb$d055bf90$c86ebb81@gizmo> <20020906022130.ZWKN11091.mtiwmhc22.worldnet.att.net@there> <3D782347.3010206@sonic.net> Message-ID: <20020906042618.DDTS11091.mtiwmhc22.worldnet.att.net@there> On Thursday 05 September 2002 22:38, you wrote: > Kevin R. Bulgrien wrote: > > cvs update on 9/5/2002 > > Make sure you do a 'cvs update -d'. Otherwise, it won't generate the new > directories. Thanks... I didn't know that... So far I've only used CVS when I was the only developer... From kbulgrien at worldnet.att.net Thu Sep 5 23:36:56 2002 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Thu Jan 13 18:02:50 2005 Subject: [CF-Devel] Occidental mages stuff works for me now... Message-ID: <20020906043216.DGIV11091.mtiwmhc22.worldnet.att.net@there> But lordy, the log sure streams when you are battling with it. Perhaps crossfire without the -d is quieter? Thanks for you guys help sorting things out. Unfortunately, I think my problems were largely due to the wierdness with the python installation. From temitchell at sympatico.ca Thu Sep 5 20:47:36 2002 From: temitchell at sympatico.ca (Todd Mitchell) Date: Thu Jan 13 18:02:50 2005 Subject: [CF-Devel] Python plugin setup References: <3D73C150.3050307@sonic.net> <20020905002442.FSOQ3050.mtiwmhc23.worldnet.att.net@there> <20020905184637.CKKI3050.mtiwmhc23.worldnet.att.net@there> Message-ID: <002401c25547$606891e0$0a02a8c0@kameria> Kevin Bulgrien said: >All I see is "initializing plugins:" which seems to imply that a message >will follow, but there doesn't seem to be one. Do this mean the plugin >didn't load? I managed to get the python plugin to work but I got it to work with python 1.5 which blew up with the Imperial post scripts (but nicely and with lots of logging). My redhat 7.1 (I have had such a crummy time with this version!) is balking at the python 2.2 srpms so I will have to work on that, but this is how I did it from the CVS: ./configure --with-includes=-I/usr/include/python1.5 (you'd probably want to point this to the 2x python - look for Python.h) then do make whatever then go into the /crossfire/plugin folder and do make - it should compile, then make install when you start up the server you can't miss the message ->loading plugin : plugin_python.so.0.1 Then you have to deal with any problems in the python scripts too ;) From mwedel at sonic.net Thu Sep 5 23:48:16 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:50 2005 Subject: [CF-Devel] monsters don't attack / blinding code References: <000101c254cf$8a6d5660$c86ebb81@gizmo> Message-ID: <3D783390.80803@sonic.net> Andreas Vogl wrote: > I have noticed that with today's CVS, most monsters > act like they were unagressive. This is now fixed in CVS. The new code broke it in the sense that the old code was broken. Basically, before, the rangevector/enemy wasn't being properly set up. This proved not to be a problem, since the distance value in the rangevector wasn't being used because of the logic. I made soem changes so that this is now properly set up/initalized. Did some quick tests, and it appears to work just fine. Monsters head towards the player, but not all of them - I went to the mad mages tower, and the ones nearer to the door would attack me when I first opened it, but the kobolds against the north wall didn't do anything until I moved closer. > > Besides, when the system is meant to stay as it is, > I would like to sprinkle some blinding immunities among > the high level monsters (dragons, big demons etc). > Does anyone have objections to this? I don't, and per my previous message, IMO this is the more correct thing to do. Note that the resist values for blinding reduce teh duration of effect. Thus, a monster with resist blind 95 is only blinded for 5% the length of time as a monster with resist_blind 0. But certainly some number of monsters should be immune to blinding. From yann.chachkoff at mailandnews.com Fri Sep 6 05:07:08 2002 From: yann.chachkoff at mailandnews.com (Yann Chachkoff) Date: Thu Jan 13 18:02:50 2005 Subject: [CF-Devel] Plugins and Python Message-ID: <3D789933@mailandnews.com> Well, maybe I should read all the mails on this list more often - Probably some questions could have been answered sooner, then. Some summarized notes about the plugins in general, and Python in particular: Administrative commands (only available in DM mode): ---------------------------------------------------- pluglist Lists all loaded plugins. Each plugin is identified in Crossfire by a keyword; pluglist shows those keywords, as well as a short text describing each plugin (usually a version string). If no plugin is loaded, the list will simply appear empty. The keyword for the Python plugin is Python. plugout Unloads a given plugin, identified by its _keyword_. So if you want to unload the Python plugin, you need to do 'plugout Python'. plugin Loads a given plugin, whose _filename_ is libname. So in the case of Python, you'd have to do a 'plugin plugin_python.so.0.1'. Note that all filenames are relative to the default plugin path (SHARE/plugins). Console messages. ----------------- When Crossfire starts, it tries to load all available files in the SHARE/plugins directory as plugin libraries. It first displays the 'Initializing plugins:' message. Whenever a plugin has been loaded, the plugin has the opportunity to signal itself by a message on the console. Then the server displays an informative message containing both the plugin content and its keyword. For the Python plugin, the standard load process thus gives: Initializing plugins : -> Loading plugin : plugin_python.so.0.1 Plugin CFPython Plugin 0.1 loaded under the name of Python Done When a plugin has been loaded, it can request to be warned whenever a global event occurs (global events are 'shout', 'login', 'death', and so on). When a plugin makes such a request, a message is displayed in the console log: Plugin Python (0) registered the event 13 It simply tells that the plugin associated with the keyword 'Python' asked to be warned whenever the global event Nr. 13 ('New player born') occurs. A complete list of events is available in the include/plugin.h file. Specific notes related to the Python Plugin. -------------------------------------------- The Python plugin supports all global events. The constant PYTHON_DEBUG defined at the start of the plugin_python.c file increases the verbosity of the plugin. Although it should work with Python 1.x, I strongly suggest using a 2.x version instead. Global event scripts go into SHARE/maps/python, and are named python_xxx.py, where xxx is the name of the global event to intercept. If the file doesn't exist, nothing will happen. Some problems have already been reported about the autodetection of the Python libraries. Don't forget that you need the development files of Python (it means the 'libpython2.x.a' and some header files, including 'Python.h'). If configure fails whatever you try, you can still try to edit the plugin Makefile by hand. You need to: - Add your Python headers path to the INCLUDES= line. (for example: -I/usr/include/python2.2); - Add your Python library path to the PYTHON_LIB= line. (for example: /usr/lib/python2.2/config/libpython2.2.a) And then build the plugin after the server. Although I do not recommend this technique, it may help sometimes. The plugin compiled under Win32 systems last year (using VC++ 6 compiler), but I don't know if it still works. Probably testing it on platforms other than Linux would also be a good thing - a lot of time passed since I last worked on it. Status of the logger and animator plugins isn't know (I didn't made them). Probably I should test those, too. In the hope all this could help someone... Y. Chachkoff ------------------------------------------------ Help supporting JXFire ! (http://jxfire.sf.net) ------------------------------------------------ From pstolarc at theperlguru.com Fri Sep 6 09:44:23 2002 From: pstolarc at theperlguru.com (pstolarc@theperlguru.com) Date: Thu Jan 13 18:02:50 2005 Subject: [CF-Devel] Broken doors Message-ID: pass_thru type doors don't seem to be working properly. You attack them automatically, instead of walking through them. On my server, running very late CVS, (on win32), I go to the undead church in Scorn. Without DM, I can't stand on the doors. I change to DM, and dumped the door. arch door_look_1 blocksview 8 pass_thru 16384 end An object dump on mids server works shows the same thing. On my server, I tried to patch pass_thru to 1, but it didn't change from 16384. On stepping through the code, the function blocked_link() in returns that the player was blocked by the door, in the following section of code: if (QUERY_FLAG(tmp,FLAG_NO_PASS) || (QUERY_FLAG(tmp,FLAG_ALIVE) && tmp->head != ob && tmp != ob)) As I'm in way over my head already, I think this is a good place for me to stop. I'm pretty sure that line of code is where the flaw lies, and I'm pretty sure I've given enough information that it should be obvious, but I'm too tired to see it. -Philip From michael.toennies at nord-com.net Fri Sep 6 11:17:09 2002 From: michael.toennies at nord-com.net (Michael Toennies) Date: Thu Jan 13 18:02:50 2005 Subject: [CF-Devel] Daimonin & python Message-ID: I had today loaded the Daimonin project to CVS and released win32 exe packages. I have not finished the linux makefiles, this will come ASAP. The small mapset is still in development but i have used alot of python scripts. Also, i have added some functions to the python_plugin.c stuff. The plugin stuff is still (as most source) 100% compatible to CF and the scripts too. IF needed, just rip of to re add it to CF. I had worked the last month on it, so it should be the cleanest version. http://daimonin.sourceforge.net/ From andi.vogl at gmx.net Fri Sep 6 11:32:20 2002 From: andi.vogl at gmx.net (Andreas Vogl) Date: Thu Jan 13 18:02:50 2005 Subject: [CF-Devel] Entrance square not checked References: <3D782527.1030602@sonic.net> Message-ID: <24828.1031329940@www47.gmx.net> Kurt Fitzner wrote: > I haven't checked in CVS, but I noticed that with 1.3, > the square I pop into a map at, or teleport to, don't > get checked for signs or runes. [...] Note that this is "common behaviour" even if it seems a bit odd. It has been in place long before version 1.3. Sure that system could be improved, for example by adding a "teleport_on" flag in addition to "walk/fly_on". However, I think the current system is not so bad. As mapmaker I have frequently stumbled over the problem that I wanted to teleport players onto a button. Anyways, there's workarounds for that stuff. To continue above example: Teleport player onto a mover which then pushes the player on the button - results in the button getting pressed. Changing the behaviour of walk_on/fly_on is something I would not recommend. Apart from problems like auto-apply- exits pointing onto each other, as Mark pointed out, it is outright dangerous to change these "fundamental" rules in server behaviour. When these parts of the code get only *touched*, most likely a large number of maps go broke in that instant. Picture this: A few years ago, about 50% of the pupland maps were either broken or inaccessible. And all of that was only due to marginal changes in the way buttons were processed by the server. AndreasV -- GMX - Die Kommunikationsplattform im Internet. http://www.gmx.net From kf_bulk at excelcia.org Fri Sep 6 12:33:45 2002 From: kf_bulk at excelcia.org (Kurt Fitzner) Date: Thu Jan 13 18:02:50 2005 Subject: [CF-Devel] Plugins and Python In-Reply-To: <3D789933@mailandnews.com> Message-ID: On 06-Sep-2002 Yann Chachkoff wrote: > I don't know if it still works. Probably testing it on platforms other than > Linux would also be a good thing - a lot of time passed since I last worked > on it. Works on HPUX 11.0 under GCC. Some issues there are: The makefile assumes linux-isms like .so.x.y filenames, -soname in the linking phase, and no -fPIC on the object files that it is linking against (notably the common/*.o files used in libcross.a) Also, under HPUX, the crossfire binary needs to be linked against libpthread because Python uses pthreads (because of thread-specific variable namespace issues, all binaries that use shared libraries that end up using pthreads must themselves be linked against it before it can load them). Other than the compiling and linking issues, it works like a charm. I just wish there was an easy way to put script directly on objects, rather than in separate files. Kurt. From kf_bulk at excelcia.org Fri Sep 6 13:10:31 2002 From: kf_bulk at excelcia.org (Kurt Fitzner) Date: Thu Jan 13 18:02:50 2005 Subject: [CF-Devel] button.c magic mouth suggestions Message-ID: I'd like to make a suggestion for magic mouths. After struggling in a map editor for an hour on an esoteric problem, I finally realized that a slight code change makes more sense. The gist of the problem was that I needed a magic mouth to be activated when a button was pushed, but not released. I can't think of why someone would want to 'connect' a magic mouth and then have it respond to both push and release signals. But, I'm sure that it happens, so as not to break maps, I propose the following in button.c (line 75 or so) case SIGN: if (!tmp->stats.sp || ((tmp->stats.sp > 0) && op->value) || ((tmp->stats.sp < 0) && !op->value)) if (!tmp->stats.food || tmp->last_eat < tmp->stats.food) { (*info_map_func)(NDI_UNIQUE | NDI_NAVY,tmp->map,tmp->msg); if (tmp->stats.food) tmp->last_eat++; } break; The effect is this: If sp is set and greater than zero on a magic mouth, it will respond only to button push events. If sp is set and less than zero, it will respond only to button release. This has made it easier for me to make maps where I want things like a message when a gate opens and a different message when a gate closes. I chose 'sp' since it's the same variable that reverses button push/release events on buttons. Since 'sp' hasn't done anything on magic mouths before, it shouldn't break any maps. I'm hoping this will make it into CVS, so I can release maps I'm making on my server. Kurt. From jajcus at bnet.pl Fri Sep 6 13:10:09 2002 From: jajcus at bnet.pl (Jacek Konieczny) Date: Thu Jan 13 18:02:50 2005 Subject: [CF-Devel] Plugins and Python In-Reply-To: References: <3D789933@mailandnews.com> Message-ID: <20020906181009.GB21358@nic.nigdzie> On Fri, Sep 06, 2002 at 11:33:45AM -0600, Kurt Fitzner wrote: > On 06-Sep-2002 Yann Chachkoff wrote: > > > I don't know if it still works. Probably testing it on platforms other than > > Linux would also be a good thing - a lot of time passed since I last worked > > on it. > > Works on HPUX 11.0 under GCC. Some issues there are: > > The makefile assumes linux-isms like .so.x.y filenames, -soname in the linking > phase, and no -fPIC on the object files that it is linking against (notably > the common/*.o files used in libcross.a) > > Also, under HPUX, the crossfire binary needs to be linked against > libpthread because Python uses pthreads (because of thread-specific variable > namespace issues, all binaries that use shared libraries that end up using > pthreads must themselves be linked against it before it can load them). Thease are some of problems, that libtool was created to solve. That's one of reasons why I wrote the automake/libtool patch. Unfortunately I cannot update it for the current CVS now, because of lack of time :-( Greets, Jacek From kf_bulk at excelcia.org Fri Sep 6 13:46:01 2002 From: kf_bulk at excelcia.org (Kurt Fitzner) Date: Thu Jan 13 18:02:50 2005 Subject: [CF-Devel] button.c, bug in multi-tile door animations Message-ID: Sorry for all the posts. I'll start making them in digest format to get it all at once. :) I've noticed that mine_secret_1_1 and mine_secret_2_1, which are type 26 (timed gate) multi-tile doors don't quite work properly. The issue is that only one tile's animation seems to get used on the correct 'connected' value. I've fixed this with a slight mod to button.c, but I'm not sure if this is the correct place for it: case TIMED_GATE: while (tmp) { tmp->speed = tmp->arch->clone.speed; update_ob_speed(tmp); /* original values */ tmp->value = tmp->arch->clone.value; tmp->stats.sp = 1; tmp->stats.hp = tmp->stats.maxhp; tmp = tmp->more; } break; Another way to fix is to call add_button_link() for every tile in a muli-tile archetype that has a connected value. I noticed that even though the head tile was the only one that activated on the correct button, that sometimes (without rhyme or reason) the second tile would get activated. I only noticed this a handful of times, and I've been unable to duplicate it in a debugger. At first I thought maybe the second tile was getting connected to zero, but that doesn't seem to be the case. I've made the above change on my server, and it seems to work well, but I'm not sure that making a change to the loader isn't the more correct solution. Kurt. From kfitzner at excelcia.org Fri Sep 6 13:10:10 2002 From: kfitzner at excelcia.org (Kurt Fitzner) Date: Thu Jan 13 18:02:50 2005 Subject: [CF-Devel] button.c magic mouth suggestions Message-ID: I'd like to make a suggestion for magic mouths. After struggling in a map editor for an hour on an esoteric problem, I finally realized that a slight code change makes more sense. The gist of the problem was that I needed a magic mouth to be activated when a button was pushed, but not released. I can't think of why someone would want to 'connect' a magic mouth and then have it respond to both push and release signals. But, I'm sure that it happens, so as not to break maps, I propose the following in button.c (line 75 or so) case SIGN: if (!tmp->stats.sp || ((tmp->stats.sp > 0) && op->value) || ((tmp->stats.sp < 0) && !op->value)) if (!tmp->stats.food || tmp->last_eat < tmp->stats.food) { (*info_map_func)(NDI_UNIQUE | NDI_NAVY,tmp->map,tmp->msg); if (tmp->stats.food) tmp->last_eat++; } break; The effect is this: If sp is set and greater than zero on a magic mouth, it will respond only to button push events. If sp is set and less than zero, it will respond only to button release. This has made it easier for me to make maps where I want things like a message when a gate opens and a different message when a gate closes. I chose 'sp' since it's the same variable that reverses button push/release events on buttons. Since 'sp' hasn't done anything on magic mouths before, it shouldn't break any maps. I'm hoping this will make it into CVS, so I can release maps I'm making on my server. Kurt. From huet.o at free.fr Fri Sep 6 16:21:00 2002 From: huet.o at free.fr (huet.o@free.fr) Date: Thu Jan 13 18:02:50 2005 Subject: [CF-Devel] Server crash (seems to be implicated by get_random_mon function) Message-ID: <1031347260.3d791c3c6ee35@imp.free.fr> Hello, I had many time a server crash in a recent cvs tree. (To see which version exactly, the last entry I have in CHANGES is : ---- This change mostly deals with improving behaviour of pet monstes. Most of the code is from K. Reinert - however, I did some code cleanup/ ---- ) So it crash when I enter in a shop I've never visited : when it generate it. I have both output of the server and core file : ------------------------------- The server output is : Trying to load map /usr/local/crossfire/share/crossfire/maps/santo_dominion/shops/rings. load_original_map: /santo_dominion/shops/rings (0) Can't open /usr/local/crossfire/var/crossfire/maps/santo_dominion/shops/rings Can't open overlay /usr/local/crossfire/var/crossfire/maps/santo_dominion/shops/rings Trying to load map /usr/local/crossfire/share/crossfire/maps/santo_dominion/shops/nosferatu. load_original_map: /santo_dominion/shops/nosferatu (0) get_random_mon() couldnt return monster for level 51 SIGSEGV received. Emergency saves disabled, no save attempted Cleaning up... Saving map /santo_dominion/town Player on map that is being saved Saving map /dragonisland/stoneville Saving map /city/city Saving map /city/anthony/portgate Saving map /Lake_Country/kundi_area Saving map /Lake_Country/shops/Olds_jewel Saving map /santo_dominion/shops/rings Saving map /santo_dominion/shops/nosferatu Abandon (core dumped) ------------------------ With core file, here is the backtrace : There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-mandrake-linux"... Core was generated by `crossfire'. Program terminated with signal 6, Abandon. Reading symbols from /lib/libdl.so.2...done. Reading symbols from /lib/libcrypt.so.1...done. Reading symbols from /lib/libm.so.6...done. Reading symbols from /lib/libnsl.so.1...done. Reading symbols from /lib/libc.so.6...done. Reading symbols from /lib/ld-linux.so.2...done. Reading symbols from /lib/libnss_nisplus.so.2...done. Reading symbols from /lib/libnss_files.so.2...done. #0 0x2ab4fee1 in __kill () from /lib/libc.so.6 (gdb) bt #0 0x2ab4fee1 in __kill () from /lib/libc.so.6 #1 0x2ab4fb1d in raise () from /lib/libc.so.6 #2 0x8063926 in fatal_signal (make_core=1, close_sockets=1) at init.c:687 #3 0x8063818 in rec_sigsegv (i=11) at init.c:629 #4 0x7fffdf94 in ?? () #5 0x80a8ff5 in mon_info_msg (level=17, booksize=280) at readable.c:1335 #6 0x80aa507 in tailor_readable_ob (book=0x89acc00, msg_type=-1) at readable.c:1972 #7 0x80ae4cf in fix_generated_item (op=0x89acc00, creator=0x89f0aa8, difficulty=1, max_magic=0, flags=8) at treasure.c:842 #8 0x80ad611 in create_one_treasure (tl=0x83dcf90, op=0x89f0aa8, flag=8, difficulty=1, tries=3) at treasure.c:377 #9 0x80ad65e in create_treasure (t=0x83dcf90, op=0x89f0aa8, flag=8, difficulty=1, tries=1) at treasure.c:396 #10 0x80ad3fb in create_all_treasures (t=0x83dcf68, op=0x89f0aa8, flag=8, difficulty=1, tries=1) at treasure.c:327 #11 0x80ad494 in create_all_treasures (t=0x83dcf40, op=0x89f0aa8, flag=8, difficulty=1, tries=1) at treasure.c:343 #12 0x80ad494 in create_all_treasures (t=0x83dcf18, op=0x89f0aa8, flag=8, difficulty=1, tries=1) at treasure.c:343 #13 0x80ad66d in create_treasure (t=0x83dcee0, op=0x89f0aa8, flag=8, difficulty=1, tries=0) at treasure.c:398 #14 0x804fd82 in fix_auto_apply (m=0x8800610) at apply.c:3097 #15 0x80a27ef in ready_map_name ( name=0x80f4ba0 "/santo_dominion/shops/nosferatu", flags=0) at map.c:1419 #16 0x8067289 in enter_exit (op=0x8120550, exit_ob=0x8becba8) at main.c:630 #17 0x804ea4c in manual_apply (op=0x8120550, tmp=0x8b70368, aflag=0) at apply.c:2182 #18 0x804ed75 in player_apply (pl=0x8120550, op=0x8b70368, aflag=0, quiet=1) at apply.c:2373 #19 0x804ee25 in player_apply_below (pl=0x8120550) at apply.c:2416 #20 0x8059146 in command_apply (op=0x8120550, params=0x0) at c_object.c:102 #21 0x8058f4b in execute_newserver_command (pl=0x8120550, command=0x7ffff74c "apply") at c_new.c:112 #22 0x80bfc3b in NewPlayerCmd (buf=0x8699f37 "", len=11, pl=0x2acaf008) at request.c:347 #23 0x80be0f3 in HandleClient (ns=0x2acaf00c, pl=0x2acaf008) at loop.c:361 #24 0x80be83d in doeric_server () at loop.c:611 #25 0x8067f29 in main (argc=1, argv=0x7ffffb14) at main.c:1156 ------------------- ------------------- I've up the stack : #4 seems to be the crash space : on #5, it's #5 0x80a8ff5 in mon_info_msg (level=17, booksize=280) at readable.c:1335 1335 sprintf (tmpbuf, "\n---\n%s", mon_desc (tmp)); ---> I printed retbuf : (gdb) printf "%s\n", retbuf This beastiary contains: (gdb) ---> To see stack residue : (gdb) p retbuf $7 = "This beastiary contains:\000---\n *** skeleton ***\n(fast movement)(undead)(wield weapon)(wear armour)(wear ring)(Attacks: physical, cold)(resist fire -100)(resist cold +30)(resist fear +100)\n---\n *** nigh"... on previous code, tmp is a monster : there is tmp = get_random_mon (level * 3); ----> my error message displayed (get_random_mon() couldnt return monster for level 51) is in this function... and it return NULL... it's perhaps the reason of the crash.... (but gdb give me strange value on tmp : (gdb) p tmp $14 = (object *) 0x77b858 ) It seems like the crash is because tmp is NULL somewhere in function mon_desc... I keep the core file : if you would like to have another info... -- Olivier. From huet.o at free.fr Fri Sep 6 16:26:06 2002 From: huet.o at free.fr (huet.o@free.fr) Date: Thu Jan 13 18:02:50 2005 Subject: [CF-Devel] Server crash (seems to be implicated by get_random_mon) Message-ID: <1031347566.3d791d6ea1210@imp.free.fr> Hello, I had many time a server crash in a recent cvs tree. (To see which version exactly, the last entry I have in CHANGES is : ---- This change mostly deals with improving behaviour of pet monstes. Most of the code is from K. Reinert - however, I did some code cleanup/ ---- ) So it crash when I enter in a shop I've never visited : when it generate it. I have both output of the server and core file : ------------------------------- The server output is : Trying to load map /usr/local/crossfire/share/crossfire/maps/santo_dominion/shops/rings. load_original_map: /santo_dominion/shops/rings (0) Can't open /usr/local/crossfire/var/crossfire/maps/santo_dominion/shops/rings Can't open overlay /usr/local/crossfire/var/crossfire/maps/santo_dominion/shops/rings Trying to load map /usr/local/crossfire/share/crossfire/maps/santo_dominion/shops/nosferatu. load_original_map: /santo_dominion/shops/nosferatu (0) get_random_mon() couldnt return monster for level 51 SIGSEGV received. Emergency saves disabled, no save attempted Cleaning up... Saving map /santo_dominion/town Player on map that is being saved Saving map /dragonisland/stoneville Saving map /city/city Saving map /city/anthony/portgate Saving map /Lake_Country/kundi_area Saving map /Lake_Country/shops/Olds_jewel Saving map /santo_dominion/shops/rings Saving map /santo_dominion/shops/nosferatu Abandon (core dumped) ------------------------ With core file, here is the backtrace : There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-mandrake-linux"... Core was generated by `crossfire'. Program terminated with signal 6, Abandon. Reading symbols from /lib/libdl.so.2...done. Reading symbols from /lib/libcrypt.so.1...done. Reading symbols from /lib/libm.so.6...done. Reading symbols from /lib/libnsl.so.1...done. Reading symbols from /lib/libc.so.6...done. Reading symbols from /lib/ld-linux.so.2...done. Reading symbols from /lib/libnss_nisplus.so.2...done. Reading symbols from /lib/libnss_files.so.2...done. #0 0x2ab4fee1 in __kill () from /lib/libc.so.6 (gdb) bt #0 0x2ab4fee1 in __kill () from /lib/libc.so.6 #1 0x2ab4fb1d in raise () from /lib/libc.so.6 #2 0x8063926 in fatal_signal (make_core=1, close_sockets=1) at init.c:687 #3 0x8063818 in rec_sigsegv (i=11) at init.c:629 #4 0x7fffdf94 in ?? () #5 0x80a8ff5 in mon_info_msg (level=17, booksize=280) at readable.c:1335 #6 0x80aa507 in tailor_readable_ob (book=0x89acc00, msg_type=-1) at readable.c:1972 #7 0x80ae4cf in fix_generated_item (op=0x89acc00, creator=0x89f0aa8, difficulty=1, max_magic=0, flags=8) at treasure.c:842 #8 0x80ad611 in create_one_treasure (tl=0x83dcf90, op=0x89f0aa8, flag=8, difficulty=1, tries=3) at treasure.c:377 #9 0x80ad65e in create_treasure (t=0x83dcf90, op=0x89f0aa8, flag=8, difficulty=1, tries=1) at treasure.c:396 #10 0x80ad3fb in create_all_treasures (t=0x83dcf68, op=0x89f0aa8, flag=8, difficulty=1, tries=1) at treasure.c:327 #11 0x80ad494 in create_all_treasures (t=0x83dcf40, op=0x89f0aa8, flag=8, difficulty=1, tries=1) at treasure.c:343 #12 0x80ad494 in create_all_treasures (t=0x83dcf18, op=0x89f0aa8, flag=8, difficulty=1, tries=1) at treasure.c:343 #13 0x80ad66d in create_treasure (t=0x83dcee0, op=0x89f0aa8, flag=8, difficulty=1, tries=0) at treasure.c:398 #14 0x804fd82 in fix_auto_apply (m=0x8800610) at apply.c:3097 #15 0x80a27ef in ready_map_name ( name=0x80f4ba0 "/santo_dominion/shops/nosferatu", flags=0) at map.c:1419 #16 0x8067289 in enter_exit (op=0x8120550, exit_ob=0x8becba8) at main.c:630 #17 0x804ea4c in manual_apply (op=0x8120550, tmp=0x8b70368, aflag=0) at apply.c:2182 #18 0x804ed75 in player_apply (pl=0x8120550, op=0x8b70368, aflag=0, quiet=1) at apply.c:2373 #19 0x804ee25 in player_apply_below (pl=0x8120550) at apply.c:2416 #20 0x8059146 in command_apply (op=0x8120550, params=0x0) at c_object.c:102 #21 0x8058f4b in execute_newserver_command (pl=0x8120550, command=0x7ffff74c "apply") at c_new.c:112 #22 0x80bfc3b in NewPlayerCmd (buf=0x8699f37 "", len=11, pl=0x2acaf008) at request.c:347 #23 0x80be0f3 in HandleClient (ns=0x2acaf00c, pl=0x2acaf008) at loop.c:361 #24 0x80be83d in doeric_server () at loop.c:611 #25 0x8067f29 in main (argc=1, argv=0x7ffffb14) at main.c:1156 ------------------- ------------------- I've up the stack : #4 seems to be the crash space : on #5, it's #5 0x80a8ff5 in mon_info_msg (level=17, booksize=280) at readable.c:1335 1335 sprintf (tmpbuf, "\n---\n%s", mon_desc (tmp)); ---> I printed retbuf : (gdb) printf "%s\n", retbuf This beastiary contains: (gdb) ---> To see stack residue : (gdb) p retbuf $7 = "This beastiary contains:\000---\n *** skeleton ***\n(fast movement)(undead)(wield weapon)(wear armour)(wear ring)(Attacks: physical, cold)(resist fire -100)(resist cold +30)(resist fear +100)\n---\n *** nigh"... on previous code, tmp is a monster : there is tmp = get_random_mon (level * 3); ----> my error message displayed (get_random_mon() couldnt return monster for level 51) is in this function... and it return NULL... it's perhaps the reason of the crash.... (but gdb give me strange value on tmp : (gdb) p tmp $14 = (object *) 0x77b858 ) It seems like the crash is because tmp is NULL somewhere in function mon_desc... I keep the core file : if you would like to have another info... -- Olivier. From pstolarc at theperlguru.com Fri Sep 6 18:11:34 2002 From: pstolarc at theperlguru.com (pstolarc@theperlguru.com) Date: Thu Jan 13 18:02:51 2005 Subject: [CF-Devel] button.c magic mouth suggestions In-Reply-To: References: Message-ID: On Fri, 06 Sep 2002 12:10:31 -0600 (MDT), you wrote: >If sp is set and greater than zero on a magic mouth, it will respond only to >button push events. If sp is set and less than zero, it will respond only to >button release. This has made it easier for me to make maps where I want >things like a message when a gate opens and a different message when a gate >closes. I chose 'sp' since it's the same variable that reverses button >push/release events on buttons. Since 'sp' hasn't done anything on magic >mouths before, it shouldn't break any maps. Solution exists already. Set the attributes on the button to walk_on 0, walk_off 1, and the button will only trigger on a walk_off. Or visa-versa. -Philip From kbulgrien at worldnet.att.net Fri Sep 6 20:48:30 2002 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Thu Jan 13 18:02:51 2005 Subject: [CF-Devel] GTK client (realtime.3 RPM) crashes on save keybindings In-Reply-To: <3D783390.80803@sonic.net> References: <000101c254cf$8a6d5660$c86ebb81@gizmo> <3D783390.80803@sonic.net> Message-ID: <20020907014323.BRZH11091.mtiwmhc22.worldnet.att.net@there> This happens a lot. I don't know if this data is helpful or not... I guess I ought to build the client with debug data...: Playing on server type Crossfire Server Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1024 (LWP 29106)] 0x0806610e in init_SDL () (gdb) where #0 0x0806610e in init_SDL () #1 0x080504e2 in applyconfig () #2 0x0805051b in saveconfig () #3 0x4013b0e1 in gtk_marshal_NONE__NONE () from /usr/lib/libgtk-1.2.so.0 #4 0x0000c315 in ?? () Cannot access memory at address 0x70 (gdb) From mwedel at sonic.net Fri Sep 6 23:03:43 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:51 2005 Subject: [CF-Devel] Server crash (seems to be implicated by get_random_mon) References: <1031347566.3d791d6ea1210@imp.free.fr> Message-ID: <3D797A9F.7020009@sonic.net> huet.o@free.fr wrote: > Hello, > > I had many time a server crash in a recent cvs tree. > (To see which version exactly, the last entry I have in > CHANGES is : > ---- > This change mostly deals with improving behaviour of pet monstes. > Most of the code is from K. Reinert - however, I did some code cleanup/ Update to latest CVS - that crash is now fixed. From mwedel at sonic.net Sat Sep 7 01:02:58 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:51 2005 Subject: [CF-Devel] Broken doors References: Message-ID: <3D799692.1030900@sonic.net> pstolarc@theperlguru.com wrote: > pass_thru type doors don't seem to be working properly. You attack them > automatically, instead of walking through them. > > On my server, running very late CVS, (on win32), I go to the undead church > in Scorn. Without DM, I can't stand on the doors. I change to DM, and > dumped the door. I've fixed this up in CVS. In some sense, this is broken on the maps - if they are going to clear no_pass, they should also clear the alive flag. Having a special check which says 'alive but a door doesn't block' is a bit of a hack. But that is what the old code did. As a note, it is also a little odd at times not knowing if the door actually blocks you from passing through or not. I know more than once I've searched on a door, disarmed out, and then found I could just walk through the opening. This bad block of code actually existed for quite a while. I remember if you had some pet monsters and wandered into the scorn inn, the pets would get busy bashing the doors. This just showed up for players since one of the recent changes made much more of move code for players and monsters the same (they were previously mostly the same before, just happened to use different blocked functions). From andi.vogl at gmx.net Sat Sep 7 04:49:58 2002 From: andi.vogl at gmx.net (Andreas Vogl) Date: Thu Jan 13 18:02:51 2005 Subject: [CF-Devel] button.c magic mouth suggestions In-Reply-To: Message-ID: <000201c25653$f0cc2460$c86ebb81@gizmo> in reply to Kurt and Philip: > > I'd like to make a suggestion for magic mouths. > > [...] The gist of the problem was that I needed a > > magic mouth to be activated when a button was > > pushed, but not released. > > [...] > > I propose the following: [...] > > If sp is set and greater than zero on a magic mouth, > > it will respond only to button push events. > > If sp is set and less than zero, it will respond only > > to button release. I totally agree with Kurt. This is an excellent proposal and I'd love to have it in CVS. I experienced the same restrictions about magic_mouths and always wanted to have that improved. Before putting it on CVS though, I believe it would be very good if the patch was tested. One thing I wonder for example: Kurt you said this works for buttons connected to a magic_mouth, but does it also work for inventory-checkers and pedestals? It would be wonderful if it worked for all of this, not only buttons. It sounded like you already tested the patch on your server? If it ran bug-free there I would be pretty confident about putting in on CVS soon, assumed nobody else on the list has objections. > Solution exists already. Set the attributes on the button > to walk_on 0, walk_off 1, and the button will only trigger > on a walk_off. Or visa-versa. From pstolarc at theperlguru.com Sat Sep 7 06:28:13 2002 From: pstolarc at theperlguru.com (pstolarc@theperlguru.com) Date: Thu Jan 13 18:02:51 2005 Subject: [CF-Devel] Broken doors In-Reply-To: <3D799692.1030900@sonic.net> References: <3D799692.1030900@sonic.net> Message-ID: <7vnjnucnu4nu75vjp18lnge7ie5uoprmjb@flonk> On Fri, 06 Sep 2002, Mark Wedel wrote: >pstolarc@theperlguru.com wrote: >> pass_thru type doors don't seem to be working properly. You attack them >> automatically, instead of walking through them. > > I've fixed this up in CVS. > This bad block of code actually existed for quite a while. I remember if you >had some pet monsters and wandered into the scorn inn, the pets would get busy >bashing the doors. This just showed up for players since one of the recent >changes made much more of move code for players and monsters the same (they were >previously mostly the same before, just happened to use different blocked >functions). Another place this new code fails is with checkinvs that have no_pass 1 set. They are a special case, where you can pass if you would otherwise trigger the checkinv. (See the mapmaker's guide if this doesn't make sense.) For an example of this, try to enter a guild for which you have the key. The gate opens, but the player can't get past the burglar prevention force field. (OK, its not really called that, but it should be.) -Philip From kf_bulk at excelcia.org Sat Sep 7 12:09:54 2002 From: kf_bulk at excelcia.org (Kurt Fitzner) Date: Thu Jan 13 18:02:51 2005 Subject: [CF-Devel] button.c magic mouth suggestions In-Reply-To: <000201c25653$f0cc2460$c86ebb81@gizmo> Message-ID: On 07-Sep-2002 Andreas Vogl wrote: > Before putting it on CVS though, I believe it would be > very good if the patch was tested. One thing I wonder > for example: Kurt you said this works for buttons connected > to a magic_mouth, but does it also work for inventory-checkers > and pedestals? It would be wonderful if it worked for > all of this, not only buttons. Sorry, I wasn't explicit. When I say "button", I mean "anything that provides an output to a 'connection'". One thing to note, is that 'sp 1' set on a button will reverse it's action. It makes pressing it cause a release and releasing it cause a press. In this case, if the button has 'sp 1' and the magic mouth has 'sp 1', then instead of activating the magic mouth on button presses, it will get activated on button releases. In my opinion, though, this is desired behavior. If you explicitely reverse the operation of a button, the magic mouth will honor that reversal. > It sounded like you already tested the patch on your > server? If it ran bug-free there I would be pretty > confident about putting in on CVS soon, assumed nobody > else on the list has objections. It's been fairly well tested. I use it on a map to create a magic mouth that activates only when someone goes through a tunnel one way. >> Solution exists already. Set the attributes on the button >> to walk_on 0, walk_off 1, and the button will only trigger >> on a walk_off. Or visa-versa. > >>From my experience this doesn't work. > When you set "walk_on 0" to a button it will never get > pressed because it doesn't realize a step-on. When you set > "walk_off 0" the button will get pressed only once and never > be released because it doesn't realize the step-off. I tested this out and this is true. When walk_off is 0, the button never gets released and the magic mouth is activated only once. When walk_on is zero, the button is never pressed at all. > Kurt's proposed changes make a lot of sense, really. > AFAIK it is not possible to make a sane work-around for > the problem, and I really tried hard once. I won't tell you how long I worked on this before I gave up and changed the hard code. Kurt. From kf_bulk at excelcia.org Sat Sep 7 15:24:28 2002 From: kf_bulk at excelcia.org (Kurt Fitzner) Date: Thu Jan 13 18:02:51 2005 Subject: [CF-Devel] bug in remove_ob (object.c) Message-ID: I've noticed some funny behavior with exits. When first travelling through an exit, the exit will drop me on the correct drop coordinates. If I travel through the exit again, then it almost never does. Try going back and forth between exits and you'll see what I mean. The issue seems to be around the P_IS_ALIVE flag not getting updated when a player leaves a map. This is causing the blocked() function to say the destination square is blocked because the last person who left it didn't cause the flag to get updated. I think the problem is in remove_ob(). The code that looks bad to me is: /* last == NULL of there are no objects on this space */ if (last==NULL) { /* comment removed */ SET_MAP_FLAGS(op->map, op->x, op->y, P_NEED_UPDATE); update_position(op->map, op->x, op->y); } else update_object(last, UP_OBJ_REMOVE); This is at line 1255 or so. The loop just before this code is looping through all the objects on the square the player was at, activating the walk_off if needed. 'last' in this case, is the last object remaining in the pile (the player using the exit has already been unlinked from the chain at this point). The issue is that update_object() is being called given 'last', which is the last object still in the list, instead of the object being removed. update_object() then is not doing an update of the player's square, because 'last' isn't an alive object. I think update_object here needs to be called with op, which is the pointer to the actual object being removed. I've made this change on my server, and initial tests show that it fixed the problem. I'm not familliar enough with the workings of movement and map flag updating, though, to know if this might not break something else. Kurt. From kf_bulk at excelcia.org Sat Sep 7 15:25:50 2002 From: kf_bulk at excelcia.org (Kurt Fitzner) Date: Thu Jan 13 18:02:51 2005 Subject: Maps that need fixing (was Re: [CF-Devel] Entrance square not ch In-Reply-To: <24828.1031329940@www47.gmx.net> Message-ID: On 06-Sep-2002 Andreas Vogl wrote: > Note that this is "common behaviour" even if it seems a bit > odd. It has been in place long before version 1.3. ... > Changing the behaviour of walk_on/fly_on is something > I would not recommend. Apart from problems like auto-apply- > exits pointing onto each other, as Mark pointed out, > it is outright dangerous to change these "fundamental" > rules in server behaviour. When these parts of the code > get only *touched*, most likely a large number of maps > go broke in that instant. It's not really a problem. I was quite active with Crossfire back in the version .93-.95 era, so some of my observations are based on very old behavior. However, having my recolections be from that time period, I can tell you that this 'fundamental change' was already made, and that there are a few maps still around that are broken because of this change. It's not beneficial to change the code back, I agree (though your idea of a teleport_on flag is very interesting). But the maps should be updated. The mana drain runes in the demonology tower in maps: /peterm/Demonology/FireMaster,WaterMaster,EarthMaster,AirMaster don't work any more. It used to be that you entered the map and the rune drained you so that you had to face the master sans-magic. Now the runes don't do anything, and a few dragonbreaths or burning hands even will blow away the master, and then you just have to mop up anything it happened to summon. These maps should be adjusted with a no-magic on the entrance and mana drain runes on the three adjoining tiles in order to put it back to the old behavior. Another map broken when this was changed was /city/misc/HallOfQuests. The teleporters drop you on magic mouth messages at the end of each quest that you never see. Another map that needs changing (for an unrelated reason) is /dragonisland/thievesden. It was made with store tiles on the floor. Makes it so you have to buy the treasure you find. Now is that cheap or what? :) From mwedel at sonic.net Sat Sep 7 15:37:08 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:51 2005 Subject: [CF-Devel] Broken doors References: <3D799692.1030900@sonic.net> <7vnjnucnu4nu75vjp18lnge7ie5uoprmjb@flonk> Message-ID: <3D7A6374.10808@sonic.net> pstolarc@theperlguru.com wrote: > Another place this new code fails is with checkinvs that have no_pass 1 > set. They are a special case, where you can pass if you would otherwise > trigger the checkinv. (See the mapmaker's guide if this doesn't make > sense.) > > For an example of this, try to enter a guild for which you have the key. > The gate opens, but the player can't get past the burglar prevention force > field. (OK, its not really called that, but it should be.) I believe (though not mentioned) the fix I did last night for the doors should also fix this - there were several bits of code in blocked_two() (which is what used to be used for players) that wasn't in blocked_link() - I took those bits and blocked_link should now do everything blocked_two did plus more. From mwedel at sonic.net Sat Sep 7 16:11:08 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:51 2005 Subject: [CF-Devel] button.c, bug in multi-tile door animations References: Message-ID: <3D7A6B6C.3030501@sonic.net> Kurt Fitzner wrote: > Sorry for all the posts. I'll start making them in digest format to get it > all at once. :) > > I've noticed that mine_secret_1_1 and mine_secret_2_1, which are type 26 > (timed gate) multi-tile doors don't quite work properly. The issue is that > only one tile's animation seems to get used on the correct 'connected' value. > > I've fixed this with a slight mod to button.c, but I'm not sure if this is the > correct place for it: > > case TIMED_GATE: > while (tmp) { > tmp->speed = tmp->arch->clone.speed; > update_ob_speed(tmp); /* original values */ > tmp->value = tmp->arch->clone.value; > tmp->stats.sp = 1; > tmp->stats.hp = tmp->stats.maxhp; > tmp = tmp->more; > } > break; > > Another way to fix is to call add_button_link() for every tile in a muli-tile > archetype that has a connected value. > > I noticed that even though the head tile was the only one that activated on > the correct button, that sometimes (without rhyme or reason) the second tile > would get activated. I only noticed this a handful of times, and I've been > unable to duplicate it in a debugger. At first I thought maybe the second > tile was getting connected to zero, but that doesn't seem to be the case. Another place to make the change would be to the move_gate() in server/time.c. But then again, I'm not sure about that as I think about it - while in theory the gates should be synced up, that doesn't happen in numerous cases (eg, something on the gate preventing it from closing) - if they were linked up, you could get a case where the first gate has done all its work, but the second gate isn't done yet, but since the first gate isn't processing, the second gate stays in that odd state. I'm a little concerned about the above method - In most cases, a lot of the code refers to the head for proper values. Certainly for things like monsters, the head is the piece that gets called to action, and the code that moves the head deals with moving the rest of the monster. So I'm concerned that at some level, people may think that the values for the second piece (like the type value) are not really necessary - if that type value got removed, the above suggestions would not work, as the second piece would not have proper type value. But it is probably easiest to say something like 'gates are a special case - the values in the second piece are important'. Or maybe just add a line to your above code which also sets the type value. As I think about it, thats probably what I'll do. From mwedel at sonic.net Sat Sep 7 16:21:01 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:51 2005 Subject: [CF-Devel] button.c magic mouth suggestions References: Message-ID: <3D7A6DBD.90308@sonic.net> Kurt Fitzner wrote: > On 07-Sep-2002 Andreas Vogl wrote: > > >>Before putting it on CVS though, I believe it would be >>very good if the patch was tested. One thing I wonder >>for example: Kurt you said this works for buttons connected >>to a magic_mouth, but does it also work for inventory-checkers >>and pedestals? It would be wonderful if it worked for >>all of this, not only buttons. > > > Sorry, I wasn't explicit. When I say "button", I mean "anything that > provides an output to a 'connection'". > > One thing to note, is that 'sp 1' set on a button will reverse it's action. > It makes pressing it cause a release and releasing it cause a press. In this > case, if the button has 'sp 1' and the magic mouth has 'sp 1', then instead of > activating the magic mouth on button presses, it will get activated on button > releases. In my opinion, though, this is desired behavior. If you > explicitely reverse the operation of a button, the magic mouth will honor that > reversal. Just a note/clarification - This works for anything that activates the sign (magic mouth). It won't do anything for other objects that can get connected and that currently get called two times (one on push, one on unpush), like mood floors, directors, teleports, creators. That probably isn't a big deal - it would be easy to add similar code for those. Only danger for some of those is that they may use 'sp' for something else. I'd really like to get away from overloading meanings of variables like this. I know crossfire has done a lot of this in the past, but there is no reason to continue to do this (other than it is slightly easier to code). That said, I'd much rather add something like a couple new flags ' FLAG_ON_BUTTON_PRESS' and FLAG_ON_BUTTON_RELEASE' or the like (those are perhaps a bit verbose). That is much clearer than using sp, and would also mean that other objects could use those flags without worry about possible conflicts or the like. From mwedel at sonic.net Sat Sep 7 17:35:50 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:51 2005 Subject: [CF-Devel] Automake patch available, please test it References: <20020811105642.GA28190@nic.nigdzie> <3D5B3186.5050106@sonic.net> <20020901170823.GB29162@nic.nigdzie> <3D73F260.8050302@sonic.net> Message-ID: <3D7A7F46.9050909@sonic.net> As for the gobs of log messages, I've put the automake patch into CVS. I had to make a few minor changes for it to work on solaris (only in the utils directory). From michael.toennies at nord-com.net Sat Sep 7 18:50:01 2002 From: michael.toennies at nord-com.net (Michael Toennies) Date: Thu Jan 13 18:02:51 2005 Subject: [CF-Devel] metaserver Message-ID: I found this way to show the metaserver data very nice. http://t-o-m-e.net/servers.php?tome_current=1 This is the mmorpg version of angband.. From andi.vogl at gmx.net Sun Sep 8 05:13:29 2002 From: andi.vogl at gmx.net (Andreas Vogl) Date: Thu Jan 13 18:02:51 2005 Subject: [CF-Devel] button.c magic mouth suggestions References: <3D7A6DBD.90308@sonic.net> Message-ID: <8862.1031480009@www4.gmx.net> Mark W. wrote: > [...] it would be easy to add similar code for [mood floors, directors, > teleports and creators.] Only danger for some of those is that they > may use 'sp' for something else. > > I'd really like to get away from overloading meanings of variables like > this. I know crossfire has done a lot of this in the past, but there is > no reason to continue to do this (other than it is slightly easier to > code). Guess we had this topic already once, but I don't think overloading is so bad, given the way our code currently works. If we add new flags and variables for every object, memory consumtion would explode and we can't afford that IMO. The server is already seriously memory-hungry. I could update "types.txt" for the JavaEditor and there it will show all the "real" meanings of the fields. Nobody has to keep in mind the overloaded variable names like sp, last_eat, and all that. That is only the internal way values get stored. Mapmakers have the masked GUI from the editor to understand things. Even developers can take a look there if in doubt. > That said, I'd much rather add something like a couple new flags ' > FLAG_ON_BUTTON_PRESS' and FLAG_ON_BUTTON_RELEASE' or the > like (those are perhaps a bit verbose). > > That is much clearer than using sp, and would also mean that other > objects could use those flags without worry about possible conflicts > or the like. In spite of what I said before, I agree to you in this case. It would be nicer to use flags here, because they can be used in multiple objects, as said. Though I would name them like 'FLAG_ACTIVATE_AT_PUSH' or something. However, the patch from Kurt already exists. The solution with flags does not. Would you do it? Would Kurt do it? I'd really like to have this feature - one way or the other. And to me Kurt's patch seems quite good enough. Andreas -- GMX - Die Kommunikationsplattform im Internet. http://www.gmx.net From temitchell at sympatico.ca Sun Sep 8 12:31:50 2002 From: temitchell at sympatico.ca (Todd Mitchell) Date: Thu Jan 13 18:02:52 2005 Subject: [CF-Devel] Madhatter? Message-ID: <002c01c2575d$9d9ecbc0$0a02a8c0@kameria> I built crossfire from the CVS this morning. Noticed the changes (etc is good idea), but I get this message when I try to run crossloop - rmdir: '/madhatter/lib/X11/crossfire/players/*.lock' :no such file or directory crossfire really unhappy thinking somebody slipped up? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://shadowknight.real-time.com/pipermail/crossfire/attachments/20020908/f3c440bb/attachment.htm From mwedel at sonic.net Sun Sep 8 17:38:45 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:52 2005 Subject: [CF-Devel] button.c magic mouth suggestions References: <3D7A6DBD.90308@sonic.net> <8862.1031480009@www4.gmx.net> Message-ID: <3D7BD175.5040600@sonic.net> Andreas Vogl wrote: > Mark W. wrote: > > Guess we had this topic already once, but I don't think overloading > is so bad, given the way our code currently works. > If we add new flags and variables for every object, memory > consumtion would explode and we can't afford that IMO. > The server is already seriously memory-hungry. Off topic, but I disagree a bit here. Metalforge, with 3 active players, was using about 30 MB. The 14,000 objects acount for about 10.5 MB. Size of the current object is 760 bytes. I would estimate that it would take just a couple hundred bytes to completely eliminate the overloading of values in the object structure. Means the server would use maybe 4 more megs. Now you can say the metalforge isn't in really heavy use right now. But if we say had 10 times the memory consumption, that is just a difference of 40 MB - this would probably make the resident size of crossfire somehwere around 200 MB. Given the current systems out there, I don't consider it that big a deal. And of course, memory usage isn't linear with players - If you have 10 times the players, you probably don't have 10 times the number of maps in memory - likely that several will be in town at the same time, or on the same world maps, etc. > I could update "types.txt" for the JavaEditor and there it will > show all the "real" meanings of the fields. Nobody has to > keep in mind the overloaded variable names like sp, last_eat, > and all that. That is only the internal way values get stored. > Mapmakers have the masked GUI from the editor to understand > things. Even developers can take a look there if in doubt. You can hide it from mapmakers, but the problem is for developers. More than one bug has been because a developer used a field they that was free but was in fact overloaded with something else. Is that extra hassle/debugging worth the extra few MB? probably not. And in this specific case, the amount of memory we are talking about is 2 bits - which means on metalforge, we're talking about 28K more memory consumption (realistically, it would be 0 more memory consumption, because the flags fields are already allocated and wouldn't be increased). And I can already think of a case where using SP doesn't work - any connected item that you want to cast a spell would hold that spell in 'sp' (or should). > > In spite of what I said before, I agree to you in this case. > It would be nicer to use flags here, because they can be used > in multiple objects, as said. Though I would name them > like 'FLAG_ACTIVATE_AT_PUSH' or something. Thats good at least. The only issue with doing it this way is the objects would need to get updated. I really like to try to keep flags 'positive', eg, if the flag is set, the action happens if the conditions are right. Vs using inverse flags like 'flag_dont_activate_on_unpush' or the like, which makes life confusing. So that said, probably would need to do something like 'FLAG_ACTIVATE_AT_PUSH' and 'FLAG_ACTIVATE_AT_RELEASE' or the like, and update the archs. > > However, the patch from Kurt already exists. The solution > with flags does not. Would you do it? Would Kurt do it? > I'd really like to have this feature - one way or the other. > And to me Kurt's patch seems quite good enough. At some point, I think we have to say to some things 'it should be done the right way, not the fast way'. I'll do the appropriate changes - it may just be a few days before it gets done. From mwedel at sonic.net Sun Sep 8 17:40:03 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:52 2005 Subject: [CF-Devel] Madhatter? References: <002c01c2575d$9d9ecbc0$0a02a8c0@kameria> Message-ID: <3D7BD1C3.7080901@sonic.net> Todd Mitchell wrote: > I built crossfire from the CVS this morning. Noticed the changes (etc > is good idea), but I get this message when I try to run crossloop - > > rmdir: '/madhatter/lib/X11/crossfire/players/*.lock' :no such file or > directory > crossfire really unhappy > > thinking somebody slipped up? > Fixed in CVS. You'll need to re-run configure (or config.status), as it is a change in the Makefile. From temitchell at sympatico.ca Sun Sep 8 23:28:17 2002 From: temitchell at sympatico.ca (Todd Mitchell) Date: Thu Jan 13 18:02:52 2005 Subject: [CF-Devel] Madhatter? References: <002c01c2575d$9d9ecbc0$0a02a8c0@kameria> <3D7BD1C3.7080901@sonic.net> Message-ID: <001301c257b9$51eabde0$0302a8c0@kameria> Thanks - works now. One thing - the python plugin is automagicly installed now, but I got a python mismatch error in the plugin because there were lines in the plugin makefile which point to version 1.5 and version 2.1 of the library. I had running python code which wasn't executing because the plugin seems to look to version 1.5 python modules first but the plugin used the 2.1 Python.h. I had to edit out the 1.5 entries in the Makefile to get things to work (but now have all the plugins working - including IPO (I had missed editing the second entry last try) and one of my own). Could the make file be changed to link to the highest python version - or the version used for Python.h instead of both? (thinking for redhat system have to keep 1.5 around but install python2...) The lines in the makefile are: PYTHON_LIB plugin_python_la_LIBADD From kbulgrien at worldnet.att.net Sun Sep 8 23:35:10 2002 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Thu Jan 13 18:02:52 2005 Subject: [CF-Devel] 09/08 CVS make install badly broken... In-Reply-To: <3D7BD1C3.7080901@sonic.net> References: <002c01c2575d$9d9ecbc0$0a02a8c0@kameria> <3D7BD1C3.7080901@sonic.net> Message-ID: <20020909042852.BXVT12112.mtiwmhc21.worldnet.att.net@there> "make depend" doesn't work any more. INSTALL still refers to it. "make install" doesn't seem to to a complete job of installing... bmaps causes a problem... [krb@krayp120 bin]# gdb crossfire GNU gdb 5.1.1 Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certainconditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-mandrake-linux"... (gdb) run -d Starting program: /home/games/bin/crossfire -d Reading bmaps from /home/games/etc/crossfire/bmaps...Can't open bmaps file: No such file or directory buf = /home/games/etc/crossfire/bmaps Program exited with code 0377. (gdb) where No stack. (gdb) "make install" also seemed to have trouble with {prefix}/etc/crossfire, but, I can't be sure that I didn't have a manually installed file there in the first place. The first make install choked. {prefix}/etc/crossfire was not a directory. I moved bmaps from {prefix}/share/crossfire to {prefix}/etc/crossfire, but now there is another problem... (gdb) run -d Starting program: /home/games/bin/crossfire -d Reading bmaps from /home/games/etc/crossfire/bmaps...done (got 3875/3876/3876) Reading faces from /home/games/etc/crossfire/faces...Can't open faces file: No such file or directory buf = /home/games/etc/crossfire/faces Program exited with code 0377. (gdb) I moved faces from {prefix}/share/crossfire to {prefix}/etc/crossfire, but now there is another problem... (gdb) run -d Starting program: /home/games/bin/crossfire -d Reading bmaps from /home/games/etc/crossfire/bmaps...done (got 3875/3876/3876) Reading faces from /home/games/etc/crossfire/faces...done Reading animations from /home/games/etc/crossfire/animations...Can not open animations file: No such file or directory Filename=/home/games/etc/crossfire/animations Program exited with code 0377. (gdb) I moved animations from {prefix}/share/crossfire to {prefix}/etc/crossfire, but now there is another problem... (gdb) run -d Starting program: /home/games/bin/crossfire -d Reading bmaps from /home/games/etc/crossfire/bmaps...done (got 3875/3876/3876) Reading faces from /home/games/etc/crossfire/faces...done Reading animations from /home/games/etc/crossfire/animations...done. got (774) Reading archetypes from /home/games/etc/crossfire/maps... Can't open archetype file. You Need a archetype called 'map' and it have to contain start map Program exited with code 0377. (gdb) I presume this is up to me... so I moved the link to the maps into {prefix}/etc/crossfire... hmm.. but this isn't the maps directory... (gdb) run -d Starting program: /home/games/bin/crossfire -d Reading bmaps from /home/games/etc/crossfire/bmaps...done (got 3875/3876/3876) Reading faces from /home/games/etc/crossfire/faces...done Reading animations from /home/games/etc/crossfire/animations...done. got (774) Reading archetypes from /home/games/etc/crossfire/maps... Can't open /home/games/etc/crossfire/maps - not a regular file Can't open archetype file. You Need a archetype called 'map' and it have to contain start map Program exited with code 0377. Ok, I don't know where the proper file is... It's not in my cvs directory, nor is it in {prefix}. I put the maps directory back into {prefix}/share/crossfire. Server is broken... What now? I still show in {prefix}/share/crossfire: [krb@krayp120 games]# ls -l share/crossfire total 3396 drwxr-xr-x 2 root root 4096 Sep 8 22:51 adm/ -rw-r--r-- 1 root root 459493 Sep 8 22:52 archetypes -rw-r--r-- 1 root root 54815 Sep 8 22:52 artifacts -rw-r--r-- 1 root root 12587 Sep 8 22:52 attackmess -rw-r--r-- 1 root root 163888 Sep 8 22:52 bmaps.paths -rw-r--r-- 1 root root 2122359 Sep 8 22:52 crossfire.0 -rw-r--r-- 1 root root 491010 Sep 8 22:52 crossfire.1 -rw-r--r-- 1 root root 148 Sep 8 22:52 def_help -rw-r--r-- 1 root root 26022 Sep 8 22:52 formulae drwxr-xr-x 2 games users 4096 Sep 8 22:51 help/ -rw-r--r-- 1 root root 1533 Sep 8 22:52 image_info lrwxrwxrwx 1 root root 33 Aug 3 14:50 maps -> /home/operator/cvs/crossfire/maps/ -rw-r--r-- 1 root root 3469 Sep 8 22:52 messages drwxr-xr-x 2 games users 4096 Sep 6 20:53 plugins/ -rw-r--r-- 1 root root 3676 Sep 8 22:52 races -rw-r--r-- 1 root root 68280 Sep 8 22:52 treasures drwxr-xr-x 2 games users 4096 Sep 8 22:52 wizhelp/ From mwedel at sonic.net Mon Sep 9 00:29:45 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:52 2005 Subject: [CF-Devel] Madhatter? References: <002c01c2575d$9d9ecbc0$0a02a8c0@kameria> <3D7BD1C3.7080901@sonic.net> <001301c257b9$51eabde0$0302a8c0@kameria> Message-ID: <3D7C31C9.8020709@sonic.net> Todd Mitchell wrote: > Thanks - works now. > > One thing - the python plugin is automagicly installed now, but I got a > python mismatch error in the plugin because there were lines in the plugin > makefile which point to version 1.5 and version 2.1 of the library. I had > running python code which wasn't executing because the plugin seems to look > to version 1.5 python modules first but the plugin used the 2.1 Python.h. I > had to edit out the 1.5 entries in the Makefile to get things to work (but > now have all the plugins working - including IPO (I had missed editing the > second entry last try) and one of my own). Could the make file be changed > to link to the highest python version - or the version used for Python.h > instead of both? (thinking for redhat system have to keep 1.5 around but > install python2...) So where are the Python.h files for the two versions, as well as where are the libraries located? The Makfiles are automatically generated, so changing the Makefile probably isn't the right long term solution - instead, the detection logic needs to be modified to do the right thing. From mwedel at sonic.net Mon Sep 9 00:35:28 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:52 2005 Subject: [CF-Devel] 09/08 CVS make install badly broken... References: <002c01c2575d$9d9ecbc0$0a02a8c0@kameria> <3D7BD1C3.7080901@sonic.net> <20020909042852.BXVT12112.mtiwmhc21.worldnet.att.net@there> Message-ID: <3D7C3320.1090203@sonic.net> Kevin R. Bulgrien wrote: > "make depend" doesn't work any more. INSTALL still refers to it. I'll update the file. > > "make install" doesn't seem to to a complete job of installing... bmaps > causes a problem... Do a 'make clean' followed by a re-compile of the code. The switch between the old and new make system doesn't seem to catch all the dependencies - it makes a dependency list as the files are compiled, so if you start from clean source distribution (or do a make clean), everything will work right in the future. > "make install" also seemed to have trouble with {prefix}/etc/crossfire, but, > I can't be sure that I didn't have a manually installed file there in the > first place. The first make install choked. {prefix}/etc/crossfire was > not a directory. Make sure your CVS is up to date, and re-run config.status - there was a few files missing in the utils directory - one of those is responsible for making target directories. From pstolarc at theperlguru.com Mon Sep 9 05:17:09 2002 From: pstolarc at theperlguru.com (pstolarc@theperlguru.com) Date: Thu Jan 13 18:02:52 2005 Subject: [CF-Devel] Unknown bookstore server crashes Message-ID: I've heard from a couple players about the server crashing when they enter "the big bookstore". (Lots or randomly generated spellbooks and readables, and not much else.) I tried to confirm this, but I couldn't. I then experienced a similar crash a few seconds after(!) entering a different store. The reports I'd gotten from people indicated that it crashed as soon as the map was loaded. Anyway, there isn't enough information here to find the bug, but I hope it helps diagnose bugs if you do happen to come across them. -Philip From andi.vogl at gmx.net Mon Sep 9 06:23:18 2002 From: andi.vogl at gmx.net (Andreas Vogl) Date: Thu Jan 13 18:02:52 2005 Subject: [CF-Devel] button.c magic mouth suggestions References: <3D7BD175.5040600@sonic.net> Message-ID: <3657.1031570598@www26.gmx.net> Mark W. wrote: > Metalforge, with 3 active players, was using about 30 MB. > The 14,000 objects acount for about 10.5 MB. Size of the > current object is 760 bytes. Seriously, I thought these numbers were much higher. I heard people complain that a populated CF server would eat up more then 256 MB RAM at times... But it sounds like your numbers are true (from Metalforge), so I believe you. I remember that we had some serious memory-leaks at times, maybe that got me thinking the mem-consumtion is so high. > > I could update "types.txt" for the JavaEditor and there it will > > show all the "real" meanings of the fields. [...] > > You can hide it from mapmakers, but the problem is for developers. > More than one bug has been because a developer used a field they > that was free but was in fact overloaded with something else. > Is that extra hassle/debugging worth the extra few MB? probably not. If memory is not an issue, then you are right. > > However, the patch from Kurt already exists. The solution > > with flags does not. [...] > > At some point, I think we have to say to some things 'it should be > done the right way, not the fast way'. Yes, you are right of course. Maybe I was a bit over-enthusiastic because I really like what Kurt has done. Sorry. > I'll do the appropriate changes - it may just be a few days > before it gets done. That's very nice, but I don't want to make you feel like it is your "duty" to work on this now. Please do it only when you want to do it. I can live without it too. AndreasV -- GMX - Die Kommunikationsplattform im Internet. http://www.gmx.net From kf_bulk at excelcia.org Mon Sep 9 05:39:27 2002 From: kf_bulk at excelcia.org (Kurt Fitzner) Date: Thu Jan 13 18:02:52 2005 Subject: [CF-Devel] button.c magic mouth suggestions In-Reply-To: <3D7BD175.5040600@sonic.net> Message-ID: On 08-Sep-2002 Mark Wedel wrote: > At some point, I think we have to say to some things 'it should be done > the right way, not the fast way'. The problem is that it hasn't been done the right way from the beginning. I'm not trying to point any fingers here - the way it is now is a natural progression from where it started to where it is. What I'm saying, though, is we can add a gazillion flags for everything. Letting the flags/attributes grow ad-infinitum will only cause more problems than it will solve. Memory wastage is one. CPU wastage for memcopies is another. But really, the issue becomes planning for the future. This is a policy decision that will come back and bite you in the heiny. Two years from now when there are a million new features and you're looking at bloated objects and an organizational nightmare, you'll regret going with 'new feature, new flag' for every little type-specific behavior you want to add to the system. Your rule needs to be 'if the property of flag is meaningful to the majority of object types then give it its own value in the object struct - otherwise, use existing space'. I promise you, anything else will be more of a nightmare than overloading is now. What I suggest we do that will (I believe) solve both issues is we create 32 bits of new flag space in each object, 16 ints, pointers and floats (that count was picked out of the air - we can choose more or less, or expand later). We designate these as "type-specific storage" and make nice #define's for them like TYPE_FLAG_1, TYPE_INT_1, etc. We then use them for any type-specific storage. Anything that makes sense only for one object type. The reversal flag on buttons (currently sp = 1), the activate only on button press/rel easef or signs (currently sp = 1/-1) etc. The way we make it readable, then, will not be in the map editors though. I would suggest that this is not the appropriate place to hide the complexity. We make it readable by overloading their meaning in loader.l. We can assign "ACTIVATE_ON_PUSH_ONLY" to set TYPE_FLAG_1 (bit 1 of the type-specific flag area). I don't even suggest we make loader.l context-sensitive. Of course, this will make it so that if that is set on the wrong object type, then wierdness will result. This is where the map editors would need to show a little inteligence, only writing "ACTIVATE_ON_PUSH_ONLY 1" to the map file for signs/magic mouths. If, in the future, there is a lot of problem with the wrong flags ending up on the wrong object types, we can start to add contextual sensitivuty to the loader. I don't foresee this as a problem, though. The good news is this is something we can do today. It's a couple hours worth of work to get the initial support in for it. Once it's started, we can even begin to un-overload the existing stuff into the type-specific areas. There will have to be a few caveats. I suggest we enforce a documentation rule where we have an external document that outlines what type-specific flag, int, float, and pointer means in relation to each object type. I suggest we religeously maintain this, and also put copious documentation into the source and into loader.l each time we support a new name in it. I'll be happy to make the initial changes. Kurt. From temitchell at sympatico.ca Mon Sep 9 08:32:48 2002 From: temitchell at sympatico.ca (Todd Mitchell) Date: Thu Jan 13 18:02:52 2005 Subject: [CF-Devel] Madhatter? (Python plugin automake) References: <002c01c2575d$9d9ecbc0$0a02a8c0@kameria> <3D7BD1C3.7080901@sonic.net> <001301c257b9$51eabde0$0302a8c0@kameria> <3D7C31C9.8020709@sonic.net> Message-ID: <000401c25805$64a968e0$0802a8c0@ott.ca.dmr> Mark said: > So where are the Python.h files for the two versions, as well as where are the > libraries located? > > The Makfiles are automatically generated, so changing the Makefile probably > isn't the right long term solution - instead, the detection logic needs to be > modified to do the right thing. The autobuild does use the proper Python.h (on my system I have /usr/include/python1.5 and /usr/include/python2.1 - and the CPPFLAGS that is generated in the Makefile is -I/usr/include/python2.1 (note on another system I have python2.2 instead and it is happy using that as well- generating -I/usr/include/python2.2, so this could be considered interchangable between the 2x versions) The problem is with the python libraries. The Makefile when generated, gets this inserted for @PYTHON_LIB@ : /usr/lib/python1.5/config/libpython1.5a /usr/lib/python2.1/config/libpython2.1a In the plugin directory the Makefile.in says PYTHON_LIB =@PYTHON_LIB@ As I mentioned since the plugin was generated against Python2.1 headers (properly), I had to remove the portions of the PYTHON_LIB pointing to libpython1.5a or most of the code would bomb. Not sure how it works - but I imagine this problem would be found on older redhat type systems (prior to 7.3) and others which rely on having the python1.5 libraries. From kfitzner at excelcia.org Mon Sep 9 05:36:48 2002 From: kfitzner at excelcia.org (Kurt Fitzner) Date: Thu Jan 13 18:02:52 2005 Subject: [CF-Devel] button.c magic mouth suggestions In-Reply-To: <3D7BD175.5040600@sonic.net> Message-ID: On 08-Sep-2002 Mark Wedel wrote: > At some point, I think we have to say to some things 'it should be done > the right way, not the fast way'. The problem is that it hasn't been done the right way from the beginning. I'm not trying to point any fingers here - the way it is now is a natural progression from where it started to where it is. What I'm saying, though, is we can add a gazillion flags for everything. Letting the flags/attributes grow ad-infinitum will only cause more problems than it will solve. Memory wastage is one. CPU wastage for memcopies is another. But really, the issue becomes planning for the future. This is a policy decision that will come back and bite you in the heiny. Two years from now when there are a million new features and you're looking at bloated objects and an organizational nightmare, you'll regret going with 'new feature, new flag' for every little type-specific behavior you want to add to the system. Your rule needs to be 'if the property of flag is meaningful to the majority of object types then give it its own value in the object struct - otherwise, use existing space'. I promise you, anything else will be more of a nightmare than overloading is now. What I suggest we do that will (I believe) solve both issues is we create 32 bits of new flag space in each object, 16 ints, pointers and floats (that count was picked out of the air - we can choose more or less, or expand later). We designate these as "type-specific storage" and make nice #define's for them like TYPE_FLAG_1, TYPE_INT_1, etc. We then use them for any type-specific storage. Anything that makes sense only for one object type. The reversal flag on buttons (currently sp = 1), the activate only on button press/rel easef or signs (currently sp = 1/-1) etc. The way we make it readable, then, will not be in the map editors though. I would suggest that this is not the appropriate place to hide the complexity. We make it readable by overloading their meaning in loader.l. We can assign "ACTIVATE_ON_PUSH_ONLY" to set TYPE_FLAG_1 (bit 1 of the type-specific flag area). I don't even suggest we make loader.l context-sensitive. Of course, this will make it so that if that is set on the wrong object type, then wierdness will result. This is where the map editors would need to show a little inteligence, only writing "ACTIVATE_ON_PUSH_ONLY 1" to the map file for signs/magic mouths. If, in the future, there is a lot of problem with the wrong flags ending up on the wrong object types, we can start to add contextual sensitivuty to the loader. I don't foresee this as a problem, though. The good news is this is something we can do today. It's a couple hours worth of work to get the initial support in for it. Once it's started, we can even begin to un-overload the existing stuff into the type-specific areas. There will have to be a few caveats. I suggest we enforce a documentation rule where we have an external document that outlines what type-specific flag, int, float, and pointer means in relation to each object type. I suggest we religeously maintain this, and also put copious documentation into the source and into loader.l each time we support a new name in it. I'll be happy to make the initial changes. Kurt. From mwedel at sonic.net Tue Sep 10 01:38:00 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:52 2005 Subject: [CF-Devel] button.c magic mouth suggestions References: Message-ID: <3D7D9348.4020309@sonic.net> Kurt Fitzner wrote: > On 08-Sep-2002 Mark Wedel wrote: > > The problem is that it hasn't been done the right way from the beginning. > I'm not trying to point any fingers here - the way it is now is a natural > progression from where it started to where it is. What I'm saying, though, > is we can add a gazillion flags for everything. Letting the flags/attributes > grow ad-infinitum will only cause more problems than it will solve. Memory > wastage is one. CPU wastage for memcopies is another. But really, the issue > becomes planning for the future. This is a policy decision that will come > back and bite you in the heiny. Two years from now when there are a million > new features and you're looking at bloated objects and an organizational > nightmare, you'll regret going with 'new feature, new flag' for every little > type-specific behavior you want to add to the system. Your rule needs to be > 'if the property of flag is meaningful to the majority of object types then > give it its own value in the object struct - otherwise, use existing space'. I > promise you, anything else will be more of a nightmare than overloading is now. I'm not certain that your forecast is correct. Crossfire has been around for 10 years or something. Given that timeframe, the object structure has increased, but isn't a nightmare now, and I doubt would be even if the current overloading of some values was removed. It should be mentioned what I'm mostly against is using fields of the object structure to enforce/use some feature which is completely non obvious. I don't for example have a problem with 'sp' being used to denote the spell to cast for many objects - sp can at least look like spell. > > What I suggest we do that will (I believe) solve both issues is we > create 32 bits of new flag space in each object, 16 ints, pointers and > floats (that count was picked out of the air - we can choose more or less, or > expand later). We designate these as "type-specific storage" and make nice > #define's for them like TYPE_FLAG_1, TYPE_INT_1, etc. We then use > them for any type-specific storage. Anything that makes sense only for one > object type. The reversal flag on buttons (currently sp = 1), the activate > only on button press/rel easef or signs (currently sp = 1/-1) etc. The way we > make it readable, then, will not be in the map editors though. I would > suggest that this is not the appropriate place to hide the complexity. We > make it readable by overloading their meaning in loader.l. We can assign > "ACTIVATE_ON_PUSH_ONLY" to set TYPE_FLAG_1 (bit 1 of the type-specific > flag area). I don't even suggest we make loader.l context-sensitive. Of > course, this will make it so that if that is set on the wrong object type, > then wierdness will result. This is where the map editors would need to show a > little inteligence, only writing "ACTIVATE_ON_PUSH_ONLY 1" to the map file for > signs/magic mouths. If, in the future, there is a lot of problem with the > wrong flags ending up on the wrong object types, we can start to add > contextual sensitivuty to the loader. I don't foresee this as a problem, > though. I'm presuming by the above, access would be like: op->int[WAND_NUM_CHARGES] op->flag[BUTOTN_ACTIVE_ON_PUSH_ONLY] op->ptr[WEAPON_SLAYING] or the like? That works. Does make debugging more difficult - right now I find it a pain simply to debug the flag values, because I have to do the translation by looking at define.h (eg, value 10 in the FLAG tables is ..., so it means this object has that set). If this happens for a lot of fields, looking at the object structure would be pretty difficult. I had briefly started such an endeavor before - it was difficult to keep up with the changing code. However, I took a different approach: The common elements in the object structure remained as they are now. Things which maybe weren't common to every object, but were to most of them were still in the object structure. For the other ones, it was done like: union { Player *player; Stationary_Caster *caster; Monster *monster; } cst; And extend as needed. At least in that way, you could look at the type, see what type of object it was, and look at the appropriate field in the union. However, this approach required a bit more work. Some obvious problem areas in trying to fix this up are fields at are currently overloaded and saved that way. For example, you could argue that fixing up exits so that destination doesn't use slaying and hp and sp. But in my system, very hard to do that - if you get the slaying field, you would need to know the object type to store it in the right place. You say you wouldn't worry about that, which certainly makes it easier. But then it seems the problem is that exits would still use something like MON_SLAYING and MON_HP and MON_SP. The exits are arguably a bad example, as there currently are macros that help control that, and slaying, hp, and sp are pretty common values, so should be in the top level object. However, I think it probably is safe to say that there are some objects out there that are overloading values that shouldn't do so. Its unclear to me how you would handle that in your loader, other than use the misnamned fields - in purpose of this discussion, buttons currently use the 'sp' field to control inversion. But how to transfer that the BUTTON_INVERSION and not ITEM_SP is tricky. > The good news is this is something we can do today. It's a couple hours worth > of work to get the initial support in for it. Once it's started, we can even > begin to un-overload the existing stuff into the type-specific areas. There > will have to be a few caveats. I suggest we enforce a documentation rule > where we have an external document that outlines what type-specific flag, int, > float, and pointer means in relation to each object type. I suggest we > religeously maintain this, and also put copious documentation into the source > and into loader.l each time we support a new name in it. Not sure the right approach on this - as said above, the use of unions or the like would certainly make debugging easier than needing to deal with offsets. But the other problem is knowing how objects deal with each other and forseeing future needs. And you have cases where objects of different types have similar functions, and it may not be clear how the objects should get grouped together. Eg, you could have an object of type X, which has some features of A, and some features of B. A and B are different enough not to use the same values. Do you put object X as yet another class? Do you try to extend A or B for X? While I know that predicting the future is difficult, before going down this road, I'd like to see what features may be out there to cause the object field to bloat to some extent. Taking a quick look over the TODO list, some entries will cause some bloat, but I can't see more than about 100 bytes being added. While not a defense, the power of computers has grown much faster than crossfires object or other growth. At current time, I'd much rather trade ease of debugging and code readability for a few megabytes of ram and some percentage of cpu impact. After all, right now, the model for exits (using EXIT_PATH, EXIT_X and EXIT_Y macros that refer to the actual values in the object could be used. The problem with this approach is when and object is extended to the extend that using those values doesn't work anymore because it makes more sense for the extensions to use those values. In summary, I'm not sure what should be done. Eliminating overloaded values is something that should be done. Yet, I don't want it to be harder than it currently is to debug the code. I'm also not sure that redoing the object structure following the current method will add that much bloat to the object structure. From mwedel at sonic.net Tue Sep 10 01:42:44 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:52 2005 Subject: [CF-Devel] button.c magic mouth suggestions References: <3D7BD175.5040600@sonic.net> <3657.1031570598@www26.gmx.net> Message-ID: <3D7D9464.708@sonic.net> Andreas Vogl wrote: > Mark W. wrote: > > Seriously, I thought these numbers were much higher. > I heard people complain that a populated CF server would eat up > more then 256 MB RAM at times... > But it sounds like your numbers are true (from Metalforge), > so I believe you. I remember that we had some serious memory-leaks > at times, maybe that got me thinking the mem-consumtion is so high. Yeah - I think there was some pretty horendous memory leaks - it looks like most of those have been fixed up. I'd have to watch metalforge for a longer period of time to see how much more memory it takes up. Size of object structure can have some effect on memory leaks if the leak itself is leaking the object structure, or something that contains the object structure. > That's very nice, but I don't want to make you feel like it is > your "duty" to work on this now. Please do it only when you > want to do it. I can live without it too. should be pretty easy to do. At the same time, I'll update the docs about how to add flag values, since I think that info doesn't currently exist. Adding new values isn't very difficult. I think at one time a perception that is was very difficult got started - not as much because it was, but because it isn't documented, and forgetting to do one step out of the several needed can result in it still not working, which can make it very frustrating for the person adding the value. From mwedel at sonic.net Wed Sep 11 01:30:10 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:52 2005 Subject: [CF-Devel] Unknown bookstore server crashes References: Message-ID: <3D7EE2F2.4020706@sonic.net> pstolarc@theperlguru.com wrote: > I've heard from a couple players about the server crashing when they enter > "the big bookstore". (Lots or randomly generated spellbooks and readables, > and not much else.) I tried to confirm this, but I couldn't. > > I then experienced a similar crash a few seconds after(!) entering a > different store. The reports I'd gotten from people indicated that it > crashed as soon as the map was loaded. > > Anyway, there isn't enough information here to find the bug, but I hope it > helps diagnose bugs if you do happen to come across them. If your running an intermediate CVS version (between 8-25 and 9-6) there was a bug that would cause it to crash when creating a readable. Ideally, if you can do something like use the utils/crossloop.web script to generate stack traces and keep the core files around, this in itself can be useful. In many cases, I can just look at the stack trace that that generates (it mails it out) and figure out the cause. In some cases, I need more information, and would need to look at the core files. From kf_bulk at excelcia.org Thu Sep 12 04:16:57 2002 From: kf_bulk at excelcia.org (Kurt Fitzner) Date: Thu Jan 13 18:02:53 2005 Subject: [CF-Devel] button.c magic mouth suggestions In-Reply-To: <3D7D9348.4020309@sonic.net> Message-ID: On 10-Sep-2002 Mark Wedel wrote: > I'm not certain that your forecast is correct. Crossfire has been around > for 10 years or something. Given that timeframe, the object structure has > increased, but isn't a nightmare now, and I doubt would be even if the > current overloading of some values was removed. I'd have to dissagree. Much of the early life of crossfire was adding global behavior. In the last three years where there's been more unique type of behavior is where you've seen the proliferation of rampant overloading. If we were to take it out now, we'd add at least 50 or 60 values, possibly more. As we get more and more interesting code, I think we'll see the object.h get more and more bloated. > It should be mentioned what I'm mostly against is using fields of the > object structure to enforce/use some feature which is completely non > obvious. I don't for example have a problem with 'sp' being used to denote > the spell to cast for many objects - sp can at least look like spell. I'd suggest that this is even more dangerous. We use variables as mnemonics. Having code that uses a variable for two different (but similarly spelled) concepts where the mnemonics are the same is harder to debug than when it's a clear exception. > I'm presuming by the above, access would be like: > > op->int[WAND_NUM_CHARGES] > op->flag[BUTOTN_ACTIVE_ON_PUSH_ONLY] > op->ptr[WEAPON_SLAYING] > > or the like? Correct. We make it clear that it's type-specific by the name and perhaps with macros like: #define GET_TYPE_SPECIFIC_INT(op,x) op->type_ints[x] > That works. Does make debugging more difficult - right now I find it a > pain simply to debug the flag values, because I have to do the translation by > looking at define.h (eg, value 10 in the FLAG tables is ..., so it means > this object has that set). > If this happens for a lot of fields, looking at the object structure would > be pretty difficult. Adding more flag bits will only ensure that we have to look at define.h more. And, if you ask me, making define.h the canonical location for all type-specific information is a very good thing. It took me two days of tracing around to figure out how the dragon stuff worked, because nowhere does it say that 'exp' in a dragon ability force means that's what my dragon's metabolism is attuned to. Remember, my suggestion is only to put stuff that is meaningfull for small numbers of types into the type-specific storage. This way, if I'm debugging behavior that is type-specific, I look at define.h and see what all type vars are used for that type, and go from there. Right now, I have to trace through tons of code to figure out what any particular usage of 'exp' or 'sp' means. > For the other ones, it was done like: > > union { > Player *player; > Stationary_Caster *caster; > Monster *monster; > } cst; > > And extend as needed. At least in that way, you could look at the type, > see what type of object it was, and look at the appropriate field in the > union. This works. If we go this route, I'd suggest a union of structs, with one struct per type that needs storage. This will make it a little more readable and make it more clear that this is type-specific behavior. > However, this approach required a bit more work. Some obvious problem > areas in trying to fix this up are fields at are currently overloaded and > saved that way. > > For example, you could argue that fixing up exits so that destination > doesn't use slaying and hp and sp. But in my system, very hard to do that - > if you get the slaying field, you would need to know the object type to > store it in the right place. Well, not necesarily. In the case of pointers, it would make freeing up the memory harder, because we'd need all sorts of type-specific code in there. My way, we'd only have to loop through the pointer list and free() up anything that's not null. > You say you wouldn't worry about that, which certainly makes it easier. I wouldn't worry about having loader.l be type aware. No context sensitivity on a type-by-type basis. For example, an exit in my scheme might have look like this in a map file: arch somesortofexit x 3 y 6 destination_x 12 destination_y 4 destination_map /some/map end A magic mouth might be this: arch magicmouth x 3 y 5 activate_on_push 1 end some loader.l code that might go along with some of the type-specific values could be: # The following are type-specific values. # These values all decode to the first type-specific int: ^destination_x{S} SET_TYPE_SPECIFIC_INT(op, 0, IVAL); ^activate_on_push{S} SET_TYPE_SPECIFIC_INT(op, 0, IVAL); This is actually a bad example, because activate_on_push should be a flag, not an int, but you get the idea. If I had a sword like this: arch sword destination_x 3 end Then loader.l would happily set op->type_ints[0] = 3 in this case, which may or may not cause odd behavior. This is a weakness in the scheme. However, I think the net gain in overal readability would be so great, that these types of problems would be rare. And, when they show up, it would be not difficult to detect in the map files. Now, even though there would be no type-by-type contextual checking, my scheme makes it MUCH easier to do value-by-value checking. For example, I recently got into a long stream of server crashes when a corruption got into my dragon char. The reason was the 'exp' value in the dragon force. This is actually used as the indicator to what my dragon's metabolism is set at. It's used raw as an index to an array. Right now, loader.l has no idea that in a dragon force object, that the 'exp' shouldn't be greater than a certain value, because values of a few million are reasonable in many objects. But, if we used my scheme, we could add bounds checking on all type-specific variables. So, loader.l might be: # The following are type-specific values. # These values all decode to the first type-specific int: ^destination_x{S} SET_WITH_BOUNDS_CHECK(op, 0, IVAL, MIN_X, MAX_X, "destination_x"); ^activate_on_push{S} SET_WITH_BOUNDS_CHECK(op, 0, IVAL, 0, 1, "activate_on_push"); ^dragon_metabolism{S} SET_WITH_BOUNDS_CHECK(op, 0, IVAL, 0, 3, "dragon_metabolism"); In this case, we could end up with a log entry of: Type-specific variable 'dragon_metabolism' in object 'blah' is out of bounds in map '/city/buggymap' > But the other problem is knowing how objects deal with each other and > forseeing future needs. And you have cases where objects of different types > have similar functions, and it may not be clear how the objects should get > grouped together. Eg, you could have an object of type X, which has some > features of A, and some features of B. A and B are different enough not to > use > the same values. Do you put object X as yet another class? Do you try to > extend A or B for X? If it has it's own type, then put it into the type-specific storage. There will always be cases where it's not cut and dried, but I think this scheme will ned up being an overall net improvement. The code isn't complex, and the very nature of the code will enforce self-documentation. In fact, we could have a file that is gawk'ed over to create loader.l, adding in the type-specific variables as needed from a master file. This is elaborate, and not needed now, but in the future as we get larger numbers of this sort of thing, it would make things very readable. And, it's not so very hard to do. > While not a defense, the power of computers has grown much faster than > crossfires object or other growth. At current time, I'd much rather trade > ease of debugging and code readability for a few megabytes of ram and some > percentage of cpu impact. This is true. But, it's a fine line between that and some very innefficient code. We could (and sometime in the future we might) want run-time arbitrary atributes on objects, like MUSHes have. Where the attrib name and value are stored on each object. This, really, is the direction we're heading. And the above ideas might make it easier to switch over to something like this in the future. > In summary, I'm not sure what should be done. Eliminating overloaded > values is something that should be done. Yet, I don't want it to be harder > than it currently is to debug the code. I'm also not sure that redoing the > object structure following the current method will add that much bloat to the > object structure. Honestly, I think you're proabably right at this point. If we added a value in for every overloaded value, we might get away with under 256 added bytes per object. Saying that there are 50 overloaded variables is probably around the mark. For 20000 object, that's 5 extra magabytes. But, it's 5 meg we don't need to use. I think the above ideas would be a net reduction in debugging complexity, and it's easily extensible in the future with little size impact. It also starts getting us to use functions or function-like macros for storage and retrieval of type-specific data, which makes moving to dynamic attribute storage easier. Add to that how easy bounds checking is, and how little work it is to start implementing this, and it becomes a good way to ease out of overloading into something more readable and usable. Kurt. From mwedel at sonic.net Thu Sep 12 23:23:59 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:53 2005 Subject: [CF-Devel] button.c magic mouth suggestions References: Message-ID: <3D81685F.70705@sonic.net> Kurt Fitzner wrote: >> It should be mentioned what I'm mostly against is using fields of the >>object structure to enforce/use some feature which is completely non >>obvious. I don't for example have a problem with 'sp' being used to denote >>the spell to cast for many objects - sp can at least look like spell. > > > I'd suggest that this is even more dangerous. We use variables as mnemonics. > Having code that uses a variable for two different (but similarly > spelled) concepts where the mnemonics are the same is harder to debug than > when it's a clear exception. I think this is probably a double edged sword - using mnemonic variable names might make it more likely that something gets overloaded for the same use. However, at the same time, if something is using such a variable, it may be more likely that the programmer will double check to make sure that it isn't being used for something else by that object. I've certainly seen the case where variables of names that are completely unrelated to the purpose get used for multiple things, causing bugs. Most likely because the programmer thought 'nothing else is using this odd named variable, so it should be safe'. > Adding more flag bits will only ensure that we have to look at define.h more. > And, if you ask me, making define.h the canonical location for all > type-specific information is a very good thing. It took me two days of > tracing around to figure out how the dragon stuff worked, because nowhere does > it say that 'exp' in a dragon ability force means that's what my dragon's > metabolism is attuned to. Lack of documentation is certainly an issue. Arguably, the flag stuff is poorly done (and I'm the one that is responsible for the current implementation) - using things like op->removed and op->freed and op->monster, ... and having those defined as a bitfield would have made things easier to debug. OTOH, that means the object structure has another 100 elements in it (even if space is the same), which means when in the debugger you do a print *op, the amount of information is a lot. Ideally, having something like uint32 flags[100]:1 or the like would be ideal, as the FLAG values could just index directly into that, meaning that at least I don't need to do bit arithmetic when trying to look at the flag values. But that isn't valid. I'm not sure what the ideal way to deal with flags is. I don't believe there is any requirement that the compiler merges all those bitfields to save space - in fact, as I think about it, it is possible that some compiler options (maximize for speed optimization) but in fact leave each one aligned on a byte or something simply because access would be faster. But that then adds 100 bytes to the size of the object structure. >> For the other ones, it was done like: >> >> union { >> Player *player; >> Stationary_Caster *caster; >> Monster *monster; >> } cst; >> >> And extend as needed. At least in that way, you could look at the type, >>see what type of object it was, and look at the appropriate field in the >>union. > > > This works. If we go this route, I'd suggest a union of structs, with one > struct per type that needs storage. This will make it a little more readable > and make it more clear that this is type-specific behavior. Yeah. Its sort of odd however - from some perspective, it doesn't make a lot of sense to add a structure that may just hold a couple values - I guess it would just seem odd to so. But I guess the use of unions doesn't cost any memory space, as it is taken care of by the compiler. Arguably, poor style, but I'd prefer to use an anonymous union like C++ allows, since this union will contain substructure with obvious naming conventions, the the tag of the union itself is pretty irrelevant (I think I chose 'cst' above as something like c? sub type (don't remember what the c stood for). > Well, not necesarily. In the case of pointers, it would make freeing up the > memory harder, because we'd need all sorts of type-specific code in there. My > way, we'd only have to loop through the pointer list and free() up anything > that's not null. True, but that probably isn't too much an issue - new pointers don't get added very often - most what gets overloaded are the things like ints, which you don't need to free. > I wouldn't worry about having loader.l be type aware. No context sensitivity > on a type-by-type basis. For example, an exit in my scheme might have look > like this in a map file: > > arch somesortofexit > x 3 > y 6 > destination_x 12 > destination_y 4 > destination_map /some/map > end That works of course, but the fact that all maps currently would have that as: arch somesortofexit x 3 y 6 sp 12 hp 4 slaying /some/map end So the problem is how do you know that sp could get loaded into destination_x, hp into destination_y, and slaying into destination_map without knowing that 'somesortofexit' is really an exit? Obviously, updating all the maps to use the right syntax would fix that problem. But that may not be very realistic (how do you deal with maps that may be available for download as 'add ons' but not part of the standard distribution?) Now you could arrange things so that sp and destination_x (and others) use the same memory locations. But that seems like a generally bad idea when at some point they don't match up and people then wonder why something is completely broken. > # The following are type-specific values. > # These values all decode to the first type-specific int: > ^destination_x{S} SET_TYPE_SPECIFIC_INT(op, 0, IVAL); > ^activate_on_push{S} SET_TYPE_SPECIFIC_INT(op, 0, IVAL); I would think that the hardcoded value of '0' above is for example purposes, and not the real use? I would think that should always be a #define of some sort, like #define EXIT_DEST_X 0 #define BUTTON_ACT_ON_PUSH 0 and so on. Not sure I see the point of using macros vs accessing the lower memory directly, like op->type_ints[EXIT_DEST_X] = IVAL I'm just thinking the later is a bit more terse but conveys the same information. > > This is actually a bad example, because activate_on_push should be a flag, not > an int, but you get the idea. If I had a sword like this: > > arch sword > destination_x 3 > end > > Then loader.l would happily set op->type_ints[0] = 3 in this case, which may > or may not cause odd behavior. Which is probably one good reason why you can't have anything rely on some specific location (like SP and DEST_X) be in the same location, as someone could say 'well, it makes sense for dest_x to get set in weapons, so let me put that at the end of the table). > This is a weakness in the scheme. However, I think the net gain in overal > readability would be so great, that these types of problems would be rare. > And, when they show up, it would be not difficult to detect in the map files. I do see this case: Programmer adds some new field to some object, and uses the above scheme. Say he adds it to weapons. Someone later then says 'hey - that same value should be used for monsters also.'. So you now have the case of new_var getting used for two things. The question of course is whether the developer will do the right thing (which is probably to move that element name into the top level object now), or do something like set it so that both monsters and weapons use that same position in the array, but try to make it so that nothing else uses that location. I think that this is a cause of a lot of the current problem - do it quick and fast. Which means not adding new variables. Which means not documenting what the values really mean. I note that a lot of people have been very good about documenting what they do. But the point here is that it is the style of contributors that needs to be properly enforced. > # The following are type-specific values. > # These values all decode to the first type-specific int: > ^destination_x{S} > SET_WITH_BOUNDS_CHECK(op, 0, IVAL, MIN_X, MAX_X, "destination_x"); > ^activate_on_push{S} > SET_WITH_BOUNDS_CHECK(op, 0, IVAL, 0, 1, "activate_on_push"); > ^dragon_metabolism{S} > SET_WITH_BOUNDS_CHECK(op, 0, IVAL, 0, 3, "dragon_metabolism"); > > In this case, we could end up with a log entry of: > > Type-specific variable 'dragon_metabolism' in object 'blah' is out of bounds > in map '/city/buggymap' Any method that has the variables in the save files be appropriate unique can handle the above just fine. But how do you handle all the legacy maps, players, etc? To me, that is the hard part. If you know that this is dragon metabolism, even though it is loaded as an 'exp' value, you could still do that bounds checking. Obviously, this isn't a problem for new values/names that get added. But that bounds checking doesn't matter if the value is stored in an array, in a structure unique for the object type, or whatever else, as the bound checking gets done on the value actually loaded. Eg, it would be something like: ^dragon_metabolism{S} if (IVAL < 0 || IVAL > MAX_VALUE_FOR_DRAGON_META) do error; else op->however_this_gets_done = IVAL; And that first line can just as easily get replaced with a macro that does the checking/logging without setting value. I think we both agree that names should be unique for the purpose they have. And that is enough for bounds checking. The only real issue is how to store the values. > Honestly, I think you're proabably right at this point. If we added a value > in for every overloaded value, we might get away with under 256 added bytes > per object. Saying that there are 50 overloaded variables is probably around > the mark. For 20000 object, that's 5 extra magabytes. But, it's 5 meg we > don't need to use. I think the above ideas would be a net reduction in > debugging complexity, and it's easily extensible in the future with little > size impact. It also starts getting us to use functions or function-like > macros for storage and retrieval of type-specific data, which makes moving to > dynamic attribute storage easier. Add to that how easy bounds checking is, and > how little work it is to start implementing this, and it becomes a > good way to ease out of overloading into something more readable and usable. I will note that if space of objects is any concern, we should look over the object and see what to clean up. Looking right away, how plugin events are handled could get greatly optimized. Right now, the object structure is something like 750 bytes. There are 90 pointers for plugins - 90 * 4 = 360, so right now, almost half the space is used for plugin support. Now I think plugins are a great thing, and are likely to get used more and more in the future. But realistically, what portion of objects will actually have plugins attached to them? Probably pretty small. So something like put all those into a structure, and have the object contain a pointer for that structure. Only allocate the plugin structure if the object in question is using a plugin. So in summary: I think we both agree that overloading the meaning of an element in the structure is a really bad idea, and shouldn't be done. We disagree on how to best store specific per type information into the object. I don't see any easy way to convert currently overloaded meanings in the objects other than to either have context based loaded/storing (eg, if exit and value is sp, it goes in dest_x) So what does that all mean? It seems that most likely that any such policy mostly comes into play for any new fields that need to get added. From dexhm2 at hotmail.com Fri Sep 13 10:41:52 2002 From: dexhm2 at hotmail.com (dex Milano) Date: Thu Jan 13 18:02:53 2005 Subject: [CF-Devel] developing a PalmOS client Message-ID: What do you think about the possibility to develop a PalmOS client for the mud? let me know you're idea to dexhm2@hotmail.com bye _________________________________________________________________ Specisci e ricevi le tue email Hotmail dal tuo cellulare con: http://mobile.msn.it From kfitzner at excelcia.org Thu Sep 12 02:27:04 2002 From: kfitzner at excelcia.org (Kurt Fitzner) Date: Thu Jan 13 18:02:53 2005 Subject: [CF-Devel] button.c magic mouth suggestions In-Reply-To: <3D7D9348.4020309@sonic.net> Message-ID: On 10-Sep-2002 Mark Wedel wrote: > I'm not certain that your forecast is correct. Crossfire has been around > for 10 years or something. Given that timeframe, the object structure has > increased, but isn't a nightmare now, and I doubt would be even if the > current overloading of some values was removed. I'd have to dissagree. Much of the early life of crossfire was adding global behavior. In the last three years where there's been more unique type of behavior is where you've seen the proliferation of rampant overloading. If we were to take it out now, we'd add at least 50 or 60 values, possibly more. As we get more and more interesting code, I think we'll see the object.h get more and more bloated. > It should be mentioned what I'm mostly against is using fields of the > object structure to enforce/use some feature which is completely non > obvious. I don't for example have a problem with 'sp' being used to denote > the spell to cast for many objects - sp can at least look like spell. I'd suggest that this is even more dangerous. We use variables as mnemonics. Having code that uses a variable for two different (but similarly spelled) concepts where the mnemonics are the same is harder to debug than when it's a clear exception. > I'm presuming by the above, access would be like: > > op->int[WAND_NUM_CHARGES] > op->flag[BUTOTN_ACTIVE_ON_PUSH_ONLY] > op->ptr[WEAPON_SLAYING] > > or the like? Correct. We make it clear that it's type-specific by the name and perhaps with macros like: #define GET_TYPE_SPECIFIC_INT(op,x) op->type_ints[x] > That works. Does make debugging more difficult - right now I find it a > pain simply to debug the flag values, because I have to do the translation by > looking at define.h (eg, value 10 in the FLAG tables is ..., so it means > this object has that set). > If this happens for a lot of fields, looking at the object structure would > be pretty difficult. Adding more flag bits will only ensure that we have to look at define.h more. And, if you ask me, making define.h the canonical location for all type-specific information is a very good thing. It took me two days of tracing around to figure out how the dragon stuff worked, because nowhere does it say that 'exp' in a dragon ability force means that's what my dragon's metabolism is attuned to. Remember, my suggestion is only to put stuff that is meaningfull for small numbers of types into the type-specific storage. This way, if I'm debugging behavior that is type-specific, I look at define.h and see what all type vars are used for that type, and go from there. Right now, I have to trace through tons of code to figure out what any particular usage of 'exp' or 'sp' means. > For the other ones, it was done like: > > union { > Player *player; > Stationary_Caster *caster; > Monster *monster; > } cst; > > And extend as needed. At least in that way, you could look at the type, > see what type of object it was, and look at the appropriate field in the > union. This works. If we go this route, I'd suggest a union of structs, with one struct per type that needs storage. This will make it a little more readable and make it more clear that this is type-specific behavior. > However, this approach required a bit more work. Some obvious problem > areas in trying to fix this up are fields at are currently overloaded and > saved that way. > > For example, you could argue that fixing up exits so that destination > doesn't use slaying and hp and sp. But in my system, very hard to do that - > if you get the slaying field, you would need to know the object type to > store it in the right place. Well, not necesarily. In the case of pointers, it would make freeing up the memory harder, because we'd need all sorts of type-specific code in there. My way, we'd only have to loop through the pointer list and free() up anything that's not null. > You say you wouldn't worry about that, which certainly makes it easier. I wouldn't worry about having loader.l be type aware. No context sensitivity on a type-by-type basis. For example, an exit in my scheme might have look like this in a map file: arch somesortofexit x 3 y 6 destination_x 12 destination_y 4 destination_map /some/map end A magic mouth might be this: arch magicmouth x 3 y 5 activate_on_push 1 end some loader.l code that might go along with some of the type-specific values could be: # The following are type-specific values. # These values all decode to the first type-specific int: ^destination_x{S} SET_TYPE_SPECIFIC_INT(op, 0, IVAL); ^activate_on_push{S} SET_TYPE_SPECIFIC_INT(op, 0, IVAL); This is actually a bad example, because activate_on_push should be a flag, not an int, but you get the idea. If I had a sword like this: arch sword destination_x 3 end Then loader.l would happily set op->type_ints[0] = 3 in this case, which may or may not cause odd behavior. This is a weakness in the scheme. However, I think the net gain in overal readability would be so great, that these types of problems would be rare. And, when they show up, it would be not difficult to detect in the map files. Now, even though there would be no type-by-type contextual checking, my scheme makes it MUCH easier to do value-by-value checking. For example, I recently got into a long stream of server crashes when a corruption got into my dragon char. The reason was the 'exp' value in the dragon force. This is actually used as the indicator to what my dragon's metabolism is set at. It's used raw as an index to an array. Right now, loader.l has no idea that in a dragon force object, that the 'exp' shouldn't be greater than a certain value, because values of a few million are reasonable in many objects. But, if we used my scheme, we could add bounds checking on all type-specific variables. So, loader.l might be: # The following are type-specific values. # These values all decode to the first type-specific int: ^destination_x{S} SET_WITH_BOUNDS_CHECK(op, 0, IVAL, MIN_X, MAX_X, "destination_x"); ^activate_on_push{S} SET_WITH_BOUNDS_CHECK(op, 0, IVAL, 0, 1, "activate_on_push"); ^dragon_metabolism{S} SET_WITH_BOUNDS_CHECK(op, 0, IVAL, 0, 3, "dragon_metabolism"); In this case, we could end up with a log entry of: Type-specific variable 'dragon_metabolism' in object 'blah' is out of bounds in map '/city/buggymap' > But the other problem is knowing how objects deal with each other and > forseeing future needs. And you have cases where objects of different types > have similar functions, and it may not be clear how the objects should get > grouped together. Eg, you could have an object of type X, which has some > features of A, and some features of B. A and B are different enough not to > use > the same values. Do you put object X as yet another class? Do you try to > extend A or B for X? If it has it's own type, then put it into the type-specific storage. There will always be cases where it's not cut and dried, but I think this scheme will ned up being an overall net improvement. The code isn't complex, and the very nature of the code will enforce self-documentation. In fact, we could have a file that is gawk'ed over to create loader.l, adding in the type-specific variables as needed from a master file. This is elaborate, and not needed now, but in the future as we get larger numbers of this sort of thing, it would make things very readable. And, it's not so very hard to do. > While not a defense, the power of computers has grown much faster than > crossfires object or other growth. At current time, I'd much rather trade > ease of debugging and code readability for a few megabytes of ram and some > percentage of cpu impact. This is true. But, it's a fine line between that and some very innefficient code. We could (and sometime in the future we might) want run-time arbitrary atributes on objects, like MUSHes have. Where the attrib name and value are stored on each object. This, really, is the direction we're heading. And the above ideas might make it easier to switch over to something like this in the future. > In summary, I'm not sure what should be done. Eliminating overloaded > values is something that should be done. Yet, I don't want it to be harder > than it currently is to debug the code. I'm also not sure that redoing the > object structure following the current method will add that much bloat to the > object structure. Honestly, I think you're proabably right at this point. If we added a value in for every overloaded value, we might get away with under 256 added bytes per object. Saying that there are 50 overloaded variables is probably around the mark. For 20000 object, that's 5 extra magabytes. But, it's 5 meg we don't need to use. I think the above ideas would be a net reduction in debugging complexity, and it's easily extensible in the future with little size impact. It also starts getting us to use functions or function-like macros for storage and retrieval of type-specific data, which makes moving to dynamic attribute storage easier. Add to that how easy bounds checking is, and how little work it is to start implementing this, and it becomes a good way to ease out of overloading into something more readable and usable. Kurt. From pstolarc at theperlguru.com Sun Sep 15 16:21:31 2002 From: pstolarc at theperlguru.com (pstolarc@theperlguru.com) Date: Thu Jan 13 18:02:53 2005 Subject: [CF-Devel] compiling the server under Win32, again. Message-ID: A few small changes. diffs below. -Philip Index: crossfire/include/win32.h =================================================================== RCS file: /cvsroot/crossfire/crossfire/include/win32.h,v retrieving revision 1.8 diff -c -r1.8 win32.h *** crossfire/include/win32.h 19 Nov 2001 23:30:28 -0000 1.8 --- crossfire/include/win32.h 15 Sep 2002 21:15:44 -0000 *************** *** 5,11 **** #if !defined(AFX_STDAFX_H__31666CA1_2474_11D5_AE6C_F07569C10000__INCLUDED_) #define AFX_STDAFX_H__31666CA1_2474_11D5_AE6C_F07569C10000__INCLUDED_ ! #if _MSC_VER > 1000 #pragma once #endif /* _MSC_VER > 1000 */ --- 5,15 ---- #if !defined(AFX_STDAFX_H__31666CA1_2474_11D5_AE6C_F07569C10000__INCLUDED_) #define AFX_STDAFX_H__31666CA1_2474_11D5_AE6C_F07569C10000__INCLUDED_ ! ! /* Define the version here. In Unixland, it's defined on the command line now. */ ! #define VERSION "1.4.0" ! ! #if _MSC_VER > 1000 #pragma once #endif /* _MSC_VER > 1000 */ *************** *** 88,94 **** #endif /* Location of read-only machine independent data */ ! #define DATADIR "share" /* Location of changeable single system data (temp maps, hiscore, etc) */ #define LOCALDIR "var" --- 92,100 ---- #endif /* Location of read-only machine independent data */ ! #define DATADIR "share" ! #define LIBDIR "share" ! #define CONFDIR "share" /* Location of changeable single system data (temp maps, hiscore, etc) */ #define LOCALDIR "var" From mwedel at sonic.net Sun Sep 15 01:22:41 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:53 2005 Subject: [CF-Devel] Crossfire 1.4.0 released Message-ID: <3D842731.8060709@sonic.net> Crossfire 1.4.0 has been released. The main change is the use of automake. The addition of abstracting body locations for equipment is included - this allwos for finer granularity in controlling what different races can put on. The experience for different levels is now moved to a configuration file, making it easier to tune the differeing values. There are also lots of bugfixes. NOTE: With the automake changes, the location of the configuration files has changed. See the NEWS file in the server directory. I packed up gnuzip (.gz) versions of the files. Looking at the download stats on sourceforge, these are more popular, and for the most part, are not that much larger than the .bz2. Only doing one such method also makes it easier on me to distribute the files. Files released for this version: sums (bsd) filename 61293 1464 crossfire-1.4.0-arch.tar.gz 63480 4523 crossfire-1.4.0-maps.tar.gz 21772 3477 crossfire-1.4.0.tar.gz 13017 394 crossfire-client-1.4.0.tar.gz 11454 1304 crossfire-client-images-1.4.0.tar.gz 06374 253 crossfire-client-sounds-1.4.0.tar.gz Sums (md5) 5df9f8981afdd4e6c174b49e8e3c0db2 crossfire-1.4.0-README dd54ea16b98d0bb95a6ed176e0046013 crossfire-1.4.0-arch.tar.gz 788381affd5b29d6601dd4371314bb80 crossfire-1.4.0-maps.tar.gz 999b7a1a678e8ffa075fed45545a6ef6 crossfire-1.4.0.tar.gz 6ab310b8d2ea80e7fae246775dc819e2 crossfire-client-1.4.0.tar.gz 7b8ea870de491cf5070f05ae876bcbf2 crossfire-client-images-1.4.0.tar.gz 1b33401d9d2af0d391fee7ad04282cfd crossfire-client-sounds-1.4.0.tar.gz crossfire-client-1.4.0 is the client (X11) distribution - standard X11 and gtk interfaces are provided. A major bug related to image caching is fixed. Better handling of configuration options was done. Stat bars can now be drawn in graduated colors. crossfire-client-images.1.4.0.tar.gz is a prebuilt image file for the client - downloading this file will reduce the amount of download that needs to happen during play if the -cache option is used. This file should be untarred in the ${prefix}/share/crossfire-client directory, where ${prefix} is the --prefix option given when configure is run. The default path is /usr/local/share/crossfire-client/. crossfire-client-sounds-1.4.0.tar.gz contains sound files for the client. The change was to increase the volume of the sound files so that they are more in line with other sounds played on the system. crossfire-1.4.0.tar.gz contains the server code with prebuilt archetype and image files. crossfire-1.4.0.arch.tar.gz contains the unpacked archetype changes. This is not needed if you only want to compile the server and play the game. Several monsters were tuned, and new ones added. crossfire-1.4.0-maps.tar.gz contains the maps. This is needed with the server distribution. FOR FIRST TIME USERS: You will only need the appropriate server, map and client file. You do not need the arch file. You may wish to get a copy of the doc file. If you just want to play the game at some remote server, you need the client and perhaps the image archive file. Crossfire is avaible on the following ftp sites Primary: ftp://ftp.sourceforge.net/pub/sourceforge/crossfire (64.28.67.101) Secondary: ftp://ftp.real-time.com/pub/games/crossfire ftp://ftp.cs.city.ac.uk/pub/games/crossfire/ ftp://ftp.cs.titech.ac.jp/pub/games/crossfire ftp://mirror.aarnet.edu.au/games/roguelike/crossfire/ ftp://crossfire.futt.org//pub/crossfire The initial upload of this release is only made to sourceforge - it should show up on the mirrors shortly. Mark Wedel mwedel@sonic.net Complete changelog: server: server/disease.c: Change move_disease() somehwat - before, if you were not susceptible to a disease, it would never run its course. Yet you would still get stuck with the symptoms. there was a case on metalforge where a character had a symptom with no disease, and had immunity, yet was still getting stuck with the symptoms. Not sure if this change will help prevent that in the future or not. include/player.h: Change item_power in player structure to be 16 bits - 8 bit values were getting overflowed. MSW 2002-09-14 INSTALL: Update directions with new automake method. common/Makefile.am, common/Makefile.in: Fix code for building the libproto.h file - it was including loader.l and not loader.c common/exp.c: Add init_experience() and dump_experience() functions - init_experience() loads the experience table from a file. Add default experience table into this file common/init.c: Add call to init_experience() common/living.c: Remove experience tables - players can select the one they want by changing the exp_table file. Remove reference to new_levels[] - only levels[] is used now for the formentioned reason. include/config.h: Update notes about SIMPLE_EXP system. include/libproto.h: rebuilt. lib/Makefile.am, lib/Makefile.in: Add exp_table to list of files. lib/exp_table: New file that contains experience information. server/c_object.c: Modify command_take() to look for objects above the player to pick up, then objects below. This fixes the bug with not being able to use the take command on items from a chest the player opens without moving off the space. server/init.c: Add -mexp dump switch to dump the experience table. Allow the simple experience system to be set in the settings file. server/skill_util.c: Fix oddness in calc_skill_exp() which could result in add amounts of exp given. MSW 2002-09-10 include/sproto.h: rebuilt lib/help/killpets: New file lib/Makefile.in: Add help/killpets file. server/c_misc.c: Add command_kill_pets(). server/commands.c: add killpets command which kills your pets. server/monster.c: Add some code in check_enemy so that the enemy has to be a monster/generator/player to be considered valid - I was seeing things like arrows ending up as target enemies. MSW 2002-09-07 More bugfixes: common/loader.l, loader.c: Fix up the handling with speed with respect to style maps - the objects were still getting put on the active list. common/map.c: Fix up blocked_link() to behave more like the blocked_two() function - inventory checkers and door handling. Comment out blocked_two since it isn't used anymore. Modify load_objects to remove objects on style maps from the active list. Remove some of the debug messages about map loading. common/object.c: Add remove_from_active_list() function for use in map.c to remove objects from active list. common/porting.c: Comment out debug message if open_and_uncompress() can open a file - caller of the function should print out messages, and it really isn't much of an error in any case. include/libproto.h: rebuilt. random_maps/special.c: Modify place_special_exit() - this should fix bug of very large treasure maps - problem was if the generated map size was too small, when generate_random_map was called, it would generate a newly sized map that was much larger. Code was also re-arranged some to make it a little more readable. server/attack.c: Fix crash when creature may not have an owner and it kills something else. server/move.c: comment added - no code change. socket/request.c: Fix off by one error in esrv_send_animation() - rare condition as it only showed up when trying to send the last animation (zombie) - only an issue if the player is put on top of a zombie for some reason (no other space for them) - observed when leaving the random dungeon in the undead church in scorn without clearing out all the zombies first. MSW 2002-09-06 CHANGES: Update build instructions for the plugin. random_maps/square_spiral.c: Fix bug that could cause the search function to go off the edge of the map looking for a clear space. Doesn't happen often, but one crash did happen here. server/monster.c: Fix some bugs with monsters and wakeup - remove check for friendly that could never be true, and also fix logic so that monsters will now find the players. MSW 2002-09-05 common/button.c: Fix do_mood_floor() to look at all objects on space for something to effect, not just things above the moodfloor. server/attack.c: Add missing check to make sure the plugin exists before we try to access the plugin function. common/readlable.c: Fix crash caused by passing null value to mon_desc - check for non null was at end of { } do loop - check should be at the start. server/monster.c: Make it so that monsters with see invisible are not immune to blind - monster can be given appropriate resistance to make it so it is not effected by blind. MSW 2002-09-04 server/main.c: Move #endif in crypt_string to more proper place. server/monster.c: Fix bad if statement that may have been waking up monsters when they shouldn't have been. MSW 2002-09-03 This change mostly deals with improving behaviour of pet monstes. Most of the code is from K. Reinert - however, I did some code cleanup/ fixes related to pet monsters, so it is difficult to note where each piece of code came from. One thing this does fix is handling of multipart pets - these now work properly. common/map.c: Update comment for get_rangevector() - no code change. common/object.c: Add get_search_arr() which is used in pet monster code. This returns a semi random scrambling of the freearr array. doc/Developers/protocol: Update documentation about map1a protocol command. include/libproto.h, include/sproto.h: rebuilt. server/attack.c: Have drain attacks return 1 damage so that it is clear that you are actually hitting your opponent. Otherwise, you would get messages that 'you missed xyz', even though you are draining it. This extra point of damage shouldn't change balance in any significant way. server/monster.c: Update hnadling of enemies for pet monsters. It should more intelligently choose the monsters and not switch/clear the enemy field for no reason anymore. Change find_nearest_living_creature to use the get_search_arr() to more randomly choose direction of target - before, there was a proclivity to always look in the north direction. Modify can_hit() to look for closes part of enemy - otherwise, monsters may not attack opponents even if they were right next to them because they couldn't get to the enemies head. Remove move_object from this function - merged with move_ob in move.c server/move.c: Fix move_ob to use 'cleaner' code of move_object, but also have specific features that move_ob had (player handling). Before move_ob didn't handle multipart objects correctly, and the two functions were largely the same. Now move_object() just calls move_ob - the only difference in the functions is that move_ob() takes 3 parameters instead of 2 of move_object() (added parameter is originator). I think this should now mean multipart player objects may now work. server/pets.c: get_pet_enemy enhanced to be much smarter about selecting/finding things for the pet to attack. server/player.c: Remove commented out line of init_beforeplay MSW 2002-08-31 server/attack.c: Modify drain attack code so that if some agent of the player is doing the drain (eg, avatar, summoned monster, or even spell), player gets exp added to his total. Otherwise, the agent could suck all the exp out of the monster, resulting in no gain for the player. Also, fix bug in drain code where uninitialized value was being used if enemy had 0 protection to drain. MSW 2002-08-30 Various bugfixes: common/map.c: Change so that same logic is used to determine pclose/fclose that is used to determine popen/fopen - otherwise, compressed map files probably don't work properly. common/treasure.c: Do a memset to make sure entire treasureslist is set to sane values. lib/archetypes: Fix 'slaying' field (which determines spell name) in god_spelldirect_face_of_death and god_spelldirect_finger_of_death server/apply.c: Fix infinite loop if the player had cursed items that needed to be unapplied to apply an item - setting up next item iteration was inside if check when it shouldn't be. Also, print message to player if this is the case. server/monster.c: Better format some of the code for improved readability. Fix indentation of can_see_enemy. Clean up invisiblity check - may have fixed a bug - old code should have worked, but wasn't very readable. server/move.c: Fix some bad code from last checkin - didn't fix the crash on no floor for door type, and instead removed check type from next line by accident. server/player.c: Remove call for init_beforeplay - this is already properly called, and re-calling it resulted in some things being redone when they shouldn't be. server/skills.c: Add message if there is nothing to steal form the monster. server/spell_effect.c: Improve message when invisiblity duration is maximized. socket/init.c: change O_NDELAY to O_NONBLOCK of fcntl. MSW 2002-08-25 doc/Developers/objects: Update with new (better) information from Todd Mitchell. Doc is more complete, and now has an index which should make it easier to find things. server/move.c: Fix dereferencing NULL problem - was looking at op->above, but op could be NULL if the map had no objects on a space (typically not the case, but...) No reason I can see that we care about the object above - just process in normal order. MSW 2002-08-21 server/time.c: Possible fix for bug seen on metalforge - in move_player_mover, make sure we are working with the head of the monster. MSW 2002-08-13 More spoiler-html fixes - was not including attacktype information, but also fixed some formatting issues. common/item.c: Include attacktypes in describe_monster. doc/scripts/Makefile.in: Add monsters-extract.pl file. doc/spoiler-html/Makefile.in: Update to use ../scripts/monster-extract.pl file, remove monster-extract file. doc/spoiler-html/spoiler.html: rebuilt. MSW 2002-08-11 Fix spoiler-html generation to show resistances. Need to do normal spoiler next. Add a new docs/scripts directory to hold the common scripts, instead of spoiler, spoiler-html, playbook, and playbook-html each having their own copies. configure, configure.in: Add doc/scripts directory. doc/spoiler-html/Makefile.in: Update build directions to use ../scripts/items-extract.pl doc/spoiler-html/spoiler.html: Rebuilt with updated information. doc/scripts/Makefile.in: Makefile for directory. doc/scripts/items-extract.pl: perl version of the items-extract file. doc/spoiler-html/items-extract: awk version - no longer used. MSW 2002-08-02 common/item.c: Have describe monster show resistances of monsters - useful for spoiler output, as well probe spell. server/disease.c: Fix typo. MSW 2002-08-02 include/global.h: add FREE_AND_CLEAR_STR macro, relocate DELETE_STRING by the other macros. server/c_misc.c: Fix string printout in applymode function. server/disease.c: Update name_pl in diseases. server/player.c: replace FREE_AND_CLEAR with FREE_AND_CLEAR_STR - was freeing data that shouldn't be freed. MSW 2002-08-01 Various fixes: INSTALL: Update with note about --with-includes configure option. common/loader.c, common/loader.l: Add comment about flag_invis_undead include/define.h: Add FLAG_INVIS_UNDEAD lib/adm/map_info: Modify to not follow symbolic links. server/monster.c: Modify can_detect_enemy to be a bit more straightforward in its logic. Also, modify detection of invisible creatures - don't reduce duration, just return that the monster can detect the player. There were also spurious messages about the player being seen. Modify can_see_enemy to check FLAG_INVIS_UNDEAD, also fix broken comparison server/player.c: Clear FLAG_INVIS_UNDEAD when invisibility ends. Fix action_makes_visible() - had reverse logic on FLAG_MAKE_INVIS check, and a typo in the printed message. server/spell_effect.c: cast_invisible() to use FLAG_INVIS_UNDEAD - also check for maximum duration, and only search active objects when clearing enemy. server/weather.c: Fix off by one on comparision when intializing maps darkness when loading map from disk. In dawn_to_dusk, don't do further processing if the light hasn't changed. MSW 2002-07-29 Various bug fixes, add glyph spell: TODO: Updated common/map.c: Fix change_map_light() - if darkness was reduced to zero, it wouldn't properly notify the players or update the maps they are on. Also, make it more robust to handle changes by more than one. include/define.h: Increase NROFREALSPELLS include/spellist.h: Add glyph spell. include/spells.h: Add SP_GLYPH entry. server/attack.c: Fix up kill_object() - it has had some many various additions that it was difficult to follow the logic. It should also now do better check on skill objects when awarding experience. server/player.c: Add some checks/addition to properly deal with freeing the name_pl in the player object. Fix it so that if you are braced, you still won't attack friendly creatures. server/rune.c: Add cast_generic_rune() to handle the glyph and rune spell. server/spell_effect.c: Fix up some pointers in cast_cause_disease() - needed so that it works properly when embedded in a glyph. Have it return 1 even if no one caught anything - you still cast the spell, so you should lose the grace for it. server/spell_util.c: Fix some formatting. Break out the code dealing with rune into cast_generic_rune() socket/loop.c: Add flag to player command mapping, and update structure - if flag is set, command can only be issued when player is in play, and not when waiting at the quit or login prompt - fixes crashes where players could wait for the map to get swapped out (after quitting), and then looking at a space. socket/request.c: Fix map2cmd so that invisible players are drawn. MSW 2002-07-24 Add dm command 'freeze' which freezes a player from doing anything for some amount of time. include/sproto.h: rebuilt. lib/Makefile.in: Add freeze to wizhelp files. lib/wizhelp/freeze: New file. server/c_wiz.c: Add command_freeze(). Also, break out get_other_player_from_name() - several functions need the same logic of getting a player named X that is not us - making it a function reduces the duplicate code. Fix some formatting for some functions. server/commands.c: Add command_freeze to the dispatch table. MSW 2002-07-17 lib/Makefile.in: add a 'archonly' directive that only collects archetypes and doesn't collect images. lib/archetypes: rebuilt for fixes made to arches. lib/collect.pl.in: modified to take second parameter -ARCHONLY, that causes it not to save out animation, bmaps and faces file. server/apply.c: Change order of print when applying/unapplying - print out the 'you apply/unapply' before we print out the changes that applying the item does. It seems odd for it to be 'you feel stronger. you apply xyz'. Fix can_apply_object() so that if a player needs to unapply several items, the right return code is returned and we don't say the player has a choice. server/player.c: Fix missing clearing of player->next. MSW 2002-07-15 -- Start body commit notes -- Major commit. This adds body locations which is used for equipping items. Equipment has information which body part it gets equipped to, and monsters have information on how which body locations they can have. As part of this work, I also did a lot of code cleanup. To use this, you must use up to date archetypes - the ones included in this commit are fine - just make sure you install them. If you don't, players will not be able to equip items. common/arch.c: Initialize body_used to be same as body_info for archetypes - this way when monsters are created, they can start equipping items right away. common/exp.c: update new_exp() - some flags it checked for before no longer exist or have new names. common/info.c: describe_item() now takes second parameter - update dump_abilities to use new calling convention. common/item.c: Add table that describes the body_info locations and their names. Add functions that calculate item power for objects that don't have it set. Update display functions to show item_power in items. Update describe_monster() - use_horn/wand/rod merged into just use_range. Modify describe_item() to take second paramater - who the item is being described for. Show item_power in describe_item. common/living.c: Pull out MAXLEVEL from being defined in this file - define in in define.h, since other files use it. Add NUM_STATS define - replace hard coded values of having just 7 stats with it. Update change_abil to not display that the player has a new attacktype when equipping a bow that has it - fix_player() ignores the attacktype of the bow, so it was incorrect information. fix_player(): Initialize player ranges structure to null - will get filled in by code in function, updated to deal with updating the body_used data from body_info in the objects. Replace instances of last_heal with gen_sp_armour. Rearrange some code to make function more readable. common/loader.c, common/loader.l: Remove the variable_const information - no longer needed and confusing for new people when adding in new object elements. Add set_body_info() - parses the string from the load file and sets the appropriate array element. Add check_loaded_object() - does sanity checking for an object after finished loading - replaces need for long processing directive in the actual rules by having seperate function. Remove unused flags from load directives (apply_once, no_pretext, can_apply), add some new ones (item_power, gen_sp_armour), update others to can_use_range. Replace flag_links with simple array that contains the name for each corresponding flag. Update get_ob_diff to not use the V_ values and just include the actual string name - all recent changes have done this, just updated for old stuff. Update get_ob_diff to save new values that have been added. common/object.c: clear_object: Modify to use memset to clear the structure to zero - this is less error prone than listing all the specific values, and probably faster. Also, makes it easier to add new elements - no need to update object.c in most cases. common/player.c: Remove get_player_ob routine - this is now merged in with get_player_ob in server/player.c. Remove generate_ext_title - not used. common/readable.c: Update to pass second argument to describe_item. common/treasure.c: Update to calculate item_power of generated items. Clean up a lot of code formatting. Update add_abilities to use gen_sp_armour values, not last heal (note, it appears the last_heal values weren't being used before). Update calls to describe item to take second parameter. doc/Developers/objects: Update will_apply notes, add note about item_power, body location. include/define.h: Comment out unused flags (flag_apply_once, flag_paralyzed, flag_no_pretext, flag_ready_rod, flag_read_horn). Add flag_use_shield. rename flag_use_wand to flag_use_range. rename flag_ready_wand to flag_ready_range. Add flag_ready_scroll. Update ARMOUR_SPELLS access macro. Add AP_PRINT flag to apply flags. Add CAN_APPLY_.. return types for can_apply_object function. include/includes.h: add strftime, mktime checks to this file. include/libproto.h: rebuilt. include/living.h: Add NUM_STATS define, update extern declarations to use it for sizing. include/loader.h: remove the V_.. info and xbm_.. externs that were not used. include/newserver.h: Remove ext_tile information. include/object.h: Add Body_Locations structure, NUM_BODY_LOCATIONS define. Add definitions for WILL_APPLY values. Clean up object structure - formatting is now consistent, ordering of values groups values together more logically. Update all types to use the int8/int16/int32 types. Several unused fields removed. include/player.h: Update rangetype enum. Add unapplymode enum. Clean up player structure - type updates, unused fields removed, formatting fixed up. include/spells.h: remove range_name extern. Update SpellTypeFrom field to combine wand/rod/horn into spellMisc - none of the spell casting code was differentiating these. include/sproto.h: rebuilt. lib/Makefile.in: Add new help files (applymode, bind, brace) lib/archetypes: rebuilt for body_info, gen_sp_armour, item_power, can_use_shield information. lib/artifacts: updated for item_poer and gen_sp_armour changes. lib/treasures: remove unused _force for player treasure. plugin/plugin_python.c: Change FLAG_USE_WAND to FLAG_USE_RANGE. server/apply.c: Move stftime, mktime to include/includes.h. Remove draw_find() - one line function can just as easly be in the code itself. Update calls to long_desc to pass second parameter. move gravestone_text() to player.c file. Add direction parameter to apply_scroll() - in this way monsters can use it properly. Remove dead code. Update apply_special function. Add unapply_special(), get_item_from_body_location(), unapply_for_ob(), and can_apply_object() functions. server/attack.c: Remove SET_FLAG(op, FLAG_PARALYZED) line - no code was ever checking status of FLAG_PARALYZED. server/c_misc.c: add command_body() which dumps body information for player. Update who as idle element in player structure removed - was not being used by anything. Add command_applymode() to set players prefered unapply method. Remove calls to unlock_player() in various functions - unlock_player() has not done anything meaningful for a while. server/c_object.c: Modify long_desc to take a second parameter which is who is examing the object. this is needed so that we can pass it down to some of the lower level functions. Update calls to describe_item to pass this second parameter. remove FLAG_NO_PRETEXT code - no archetyps were using it. When examining objects, also tell player where to put them on. server/c_range.c: Update legal_range() - we now store the object that is responsible for a range in the player object, so code is much simpler. Update change_spell() to not destroy golem just by readying another spell - we now let players regain control of golems after switching to another range. Update change_spell to use item name of object for range description. server/c_wiz.c: remove reference to count_left from player object - field removed from structure. server/commands.c: add new commands (applymode, body) to command dispatch table. server/login.c: Remove unlock_player() and lock_player() and calls to it - current checking of names at login should be sufficient to prevent duplicates. Remove dead code from check_name. Update load/save code for unapply mode value. Add set_flag(op, FLAG_USE_SHIELD) if player is allowed to use armor - needed since flag_use_shield is really a class feature and so is not automatically updated for old player files. server/main.c: Remove references to count_left. memset marker object to NULL - seems to increase stability on metalforge server. server/monster.c: Many updates related to the body info - monsters follow some rules as players. Add monster_should_cast_spell function - monsters will use this for all spellcasting related actions (abilities, scrolls, wands, etc). Update for merged rod/horn/wand ranges. Update bow use by monsters - they don't actually need to equip it to fire - this way we don't need to constantly swap the monsters weapons between the bow and melee item. Use fire_bow from player.c for most of the work. Modify scroll usage - monster will use it when player is near, not when it first picks it up. Add FLAG_READY_SCROLL to denote the monster has a scroll to use. Also, monster now casts it in appropriate direciton. Merge the monster_use_wand/rod/horn into monster_use_range. Modify check_good_weapon and check_good_armour to just look at the stats of the two items without needing the monster to apply it first. server/player.c: Print motd in green so it is more noticable. Update get_player function to do work it did before as well as that of get_player_ob. Have get_player take a parameter which is the object of the player if he has one. Modify to use memset to clear the player structure - more sure fire than explicitly listing values to initialize. Remove calls to unlock_player. Modify fire_bow so that monsters can also use the function. Add fire_misc_object() to fire_wand/rod/horn - removes code from fire(). Add gravesetone_text() to this file. server/shop.c: Update to pass second parameter to describe_item(). server/skill_util.c: Update check_skill_to_fire since there are fewer rangetypes now. change range_scroll name to range_golem, as that is a bit more accurate for what it actually does. Modify show_skills() to show player his item power and total of items he has equipped. server/skills.c: Add second paramater to long_desc, remove references to count_left. server/spell_effect.c: Add second paramater to long_desc, remove references to count_left. Update range_scroll to range_golem server/spell_util.c: remove references to count_left. Update messages if player trying to cast where he can't with new range names. socket/info.c: Update range information and how we display what it is - we will use the object name of the range if available. Remove reference last_known_spell, last_shoot, last_spell, last_value player structure fields. socket/init.c: Remove ext_title information. socket/request.c: Add element for life_stealing in the resistance array. Remove references to idle, count_left in player structure. remove ext2 title information. MSW 2002-07-14 -- End body commit notes -- common/anim.c, common/button.c, common/friend.c, common/glue.c, common/init.c,common/logger.c, common/los.c, common/porting.c, common/time.c, common/utils.c, crossedit/png.c, crossedit/xutil.c, include/attack.h, include/config.h, include/map.h, include/material.h, include/newclient.h, include/skills.h, include/treasure.h, random_maps/decor.c, random_maps/door.c, random_maps/floor.c, random_maps/monster.c, random_maps/special.c, random_maps/standalone.c, random_maps/style.c, random_maps/wall.c, server/alchemy.c, server/c_chat.c, server/c_party.c, server/gods.c, server/hiscore.c, server/init.c, server/pets.c, server/resurrection.c, server/rune.c, server/time.c, socket/metaserver.c: Update banner copyright with proper contact information. MSW 2002-07-14 server/disease.c: Fix propogation of diseases with negative damage (these do a percent of the creatures damage). The new disease was getting a damage rating of 1 in all cases because we were passing a negative value to random_roll for the top end of the range. MSW 2002-07-08 common/arch.c: Add 'unlocked' match for item_matched_string. lib/help/drop, lib/help/dropall: Help files for these commands. lib/Makefile.in: Update to include help commands above. server/spell_effect.c: Fix formatting of summon_pet() function. Modified so that it no longers sucks player spellpoints when casting it via scroll - scrolls should not cast the player spellpoints. No idea why that code was there - in fact, casting off a scroll used more sp than casting from memory. Modify cast_cause_disease() function so that if the passed direction is 0, we refer to the facing and cast in that direction - this means spells of cause disease now work. Also perform some minor formatting changes in the function. TODO: Add not about inscription. MSW 2002-07-05 common/arch.c: Fix bug in item_matched_string which was matching all values (inverse in fact) when passed with count > 1 in matching string - missing ! operator. README: Update - remove note about windows client, since it is currently unsupported and could stop working in some future release. MSW 2002-07-05 client: common/image.c: Fix bug of not fulling clearing the cache entry data after allocation. This resulted in various random crashes when using cached image mode. x11/x11.c: Add note about -facset. CHANGES, Makefile.in, configure, configure.in: Update for 1.4 release MSW 2002-09-14 common/item.c: Update comment about possible sorting improvements. gtk/gx11.c: Add missing foodbeep functionality to GTK client. MSW 2002-08-13 gtk/config.c: Fix crash when trying to apply config changes when compiled with SDL support but user is not using it. Fix bug where settings were not being properly updated. gtk/sound.c: initialize sound_pipe to NULL, and have init_sounds close the sound pipe if there is currently one open - fixes bug when switching sound control many times in that multiple cfsndserv processes could get started. MSW 2002-07-25 Makefile.in: if no makedepend, don't run make depend directive. README: Add not about ALSA revisions and possible problems compiling. MSW 2002-07-10 This commit adds graduated colored statbars to the gtk client. What this means is that the color of the statbar goes smoothly from red to yellow to green depending on what percentage of your hp/sp/grace/food is compared to your maximum. To use this, you need to go to the config pane and hit the 'gradually change stat bar color' button. common/client.h: Add CONFIG_ value for this, increase CONFIG_NUMS. common/init.c: Add "grad_color_bars" to config_names array. gtk/config.c: Add button to select this behaviour. Move all the special config checks to beyond the for loop that checks the values in apply_config(). There is no need to check all the values on each loop. gtk/gtkproto.h: Rebuilt for inclusion of reset_stat_bars() gtk/gx11.c: Add two styles to the Vitals (stat bar) structure so we can alternate between them. Default is to initialize one for green and the other for red (in non graduated color mode). This should be more efficient then allocating a new one each time we need to change the value. add reset_stat_bars() to reset the colors of the styles to red and green - needed because the graduated color code will change the colors of these. Remove code that freed these styles. Modify draw_stat_bar() to draw them in color or simple mode, in simple mode, we now just need to use the appropriate style and not allocated a new one. Modify draw_message_window() to pass bar values greater than 1 to the draw_stat_bar() function - in graduated color mode, we draw such values with a blue tinting (more blue the more over it is). draw_stat_bar() knows how to properly deal with these higher values. MSW 2002-07-04 gtk/config.c: Fix setting of radio button set state - it was always setting the same (last) radio button as the active button, which did not match state - now it sets the proper button active - this is for the lighting control toggle. gtk/map.c: Add/subtract 2 to the need_recenter_map function - in this way, code that checks known display position +/-1 will still be within map array. gtk/sdl.c: Fix per pixel (fastest and best) lighting code - this got broken quite a while - it was looking to see if the coordinates for the map structure where within range, and not the real coordinates. Since the map coordinates would almost never be within range, the effect was that the per pixel effects more ore less looked like the per tile effects. MSW 2002-07-03 From temitchell at sympatico.ca Mon Sep 16 00:28:42 2002 From: temitchell at sympatico.ca (Todd Mitchell) Date: Thu Jan 13 18:02:53 2005 Subject: [CF-Devel] new cut 1.4.0 and realestate idea Message-ID: <000c01c25d41$ebaf8040$0a02a8c0@kameria> Well the new 1.4 cut installs well, everything worked except the python plugin (I still had to modify the plugin Makefile, remove the references to the 1.5 libs (since it correctly detected and used the 2.x Python.h to compile) and remake the plugin , but that is pretty painless anyway.) Killpets works well, but I don't know if it is good that they drop their inventories (free money). Seems a bit cruel. Unsummon would be kinder. - but it was good work on a well needed function. M.T. should be proud, the DX Client still runs well under 1.4. Well enough to be a usable client for windows users still (thought I should mention that somewhere). I have to say it - it is still my favorite client. Still playing with a concept for buying castles/houses, I have one pretty simple solution i've been working on. I made a file called 'lots' with the following format : lot#, map, x, y, zone, owner e.g 1,/city/city,16,18,house,vacant I wrote a python script (kind of like Collette's IPO python script for mail) that will let you check the availability of a lot and what can be built on it and purchase a deed for the lot. When you buy a lot, a set of maps will be written based on a template map (read map file -> find and replace the exits and the inventory checkers -> save new file to player directory) and the target map from the 'lots' file will be edited to add in the exits (remove or cover over the for-sale signs-> place an arch linking to the player's new home map) - I'm still workin on this but I think it presents no real issues. It would be up to map makers to add in signs on their maps indicating a lot number and zone type (so players would be able to shop around) and to make an entry in the 'lots' file to make the lot available. Initially there will be two templates (which are like the guild maps in that there are lots of gold floors and altars to cozy up the maps), a 2 story house and a 4 story keep (so far single tile arches only to keep it simple and avoid map congestion). I plan on adding in two more - tower and castle if it works out. Three problems I can see so far - 1. you have to wait for the map to reset before you can see or enter your new pad. 2. mapmakers making mistakes either on maps or in the lot file 3. when updating maps have to be careful not to mung up players houses 4. problems with adding files to the server (bloat issues?)- removing old files 5. more stuff for server admins to do Advantages are: 1. easy to implement 2. lots of control for 'zoning' 3. players can buy as many as they like 4. pretty easy to do in python 5. more stuff for server admins to do... Of course with some automation enhancements some of the problems could be mitigated (I was thinking of adding a dm command to add lots (in python - if you were carrying around some kind of 'wand of realestate'), and you could always make a utility script to run through and clean up inactive players and lots) anyone have thoughts on this? Am I missing anything vital? Someone have a better plan? The Python Plugin is pretty cool. also: I installed Sorcerer Linux a bit ago to try it out and noticed that Crossfire is one one of the install spells you can cast. Unfortunatly it is 'cast crossfire' and it gets the whole ball game- arches, maps, client, server. Think it would be better to make three install spells: client, server+maps, and the jED + arches. Anyway, have to look into that later. Just a 1.4.0 FYI - thanks folks. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://shadowknight.real-time.com/pipermail/crossfire/attachments/20020916/8add213f/attachment.html From pstolarc at theperlguru.com Mon Sep 16 20:08:07 2002 From: pstolarc at theperlguru.com (pstolarc@theperlguru.com) Date: Thu Jan 13 18:02:54 2005 Subject: [CF-Devel] new cut 1.4.0 and realestate idea In-Reply-To: <000c01c25d41$ebaf8040$0a02a8c0@kameria> References: <000c01c25d41$ebaf8040$0a02a8c0@kameria> Message-ID: <2ducoukbkjr9jumes61qqik9lgtve649c5@flonk> On Mon, 16 Sep 2002 01:28:42 -0400, "Todd Mitchell" wrote: >Killpets works well, but I don't know if it is good that they drop their >inventories (free money). Seems a bit cruel. Unsummon would be kinder. >- but it was good work on a well needed function. I think it's better that they drop their inventories. I often feed specific items to a vampire, such as rings of War and so on, and then have them fight for me. Unsummoning a pet that has player supplied items is really quite annoying, and removes some of the functionality of the command. On the flip side, I wasn't aware of this new command, and I'm really looking forward to trying it out. I've killed my friends accidentally in the past, due to use_skill melee + fire, and them walking into the spot the pet was in. -Philip From mwedel at sonic.net Mon Sep 16 22:14:28 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:54 2005 Subject: [CF-Devel] new cut 1.4.0 and realestate idea References: <000c01c25d41$ebaf8040$0a02a8c0@kameria> <2ducoukbkjr9jumes61qqik9lgtve649c5@flonk> Message-ID: <3D869E14.9080801@sonic.net> pstolarc@theperlguru.com wrote: > On Mon, 16 Sep 2002 01:28:42 -0400, "Todd Mitchell" wrote: > > >>Killpets works well, but I don't know if it is good that they drop their >>inventories (free money). Seems a bit cruel. Unsummon would be kinder. >>- but it was good work on a well needed function. > > > I think it's better that they drop their inventories. I often feed > specific items to a vampire, such as rings of War and so on, and then have > them fight for me. Unsummoning a pet that has player supplied items is > really quite annoying, and removes some of the functionality of the > command. As a note, if you killed your pets (or they otherwised died) without the killpets option, they would also drop their treasure. So the killpets option doesn't given you treasure you wouldn't have been able to get before - it just gives you a way to perhaps get to it easier. If this is considered a serious bug, then the pet summoning could probably get changed so that the items that get created as part of their summoning are not left behind (giving them startequip 1 should do that). But I haven't heard of any real abuses with regards to using this to get money. As for the command name, banish was originally suggested, but I thought that could get confused with a dm command (there isn't a banish command right now, but I could see something like that getting added). I thought killpets was reasonably short and to the point. At some level, the client could provide a better interface to this through its windows, eg, for the gtk client, under actions, it could have an action line 'dismiss pets', which then just sends the killpets command to the server. From michael.toennies at nord-com.net Mon Sep 16 22:41:17 2002 From: michael.toennies at nord-com.net (Michael Toennies) Date: Thu Jan 13 18:02:54 2005 Subject: [CF-Devel] daimonin & linux Message-ID: The daimonin server & client in cvs compile now under linux. The server can be compiled by enter Daimonin/server/make/linux and do configure, make, make install. The client will compile with make, make install. The damn.informatik.uni-bremen.de server runs now with latest cvs and full python plugin. Please test the script (try talk with any NPC in the different houses of the city). I included a new item type: applyable light sources. (the old torches are removed.) Now you can apply a torch like a weapon or armor. It will shown in the player doll in a special slot. They will work in a 3 time apply chain like containers. First apply will light them up but hide the light. 2nd apply will apply them and show the light. 3rd apply will unapply and unlight them. You will see immediatly the effect, when you applied the light source. It gives 3 kind of lights: one use - torches. if they burn out, they are useless. refill - lamps. You can refill them with lamp oil. permanent - light crystals like thrains arkenstone for example. From mwedel at sonic.net Tue Sep 17 00:29:31 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:54 2005 Subject: [CF-Devel] new cut 1.4.0 and realestate idea References: <000c01c25d41$ebaf8040$0a02a8c0@kameria> Message-ID: <3D86BDBB.9010207@sonic.net> Todd Mitchell wrote: As a side note, the preferred content for e-mail is text only, not text/html combinations. > Well the new 1.4 cut installs well, everything worked except the python > plugin (I still had to modify the plugin Makefile, remove the references > to the 1.5 libs (since it correctly detected and used the 2.x Python.h > to compile) and remake the plugin , but that is pretty painless anyway.) Yeah, looking at aclocal.m4 - the first block of code: for lib in python{,2.2,2.1,2.0} ; do AC_CHECK_LIB($lib, PyArg_ParseTuple,[PYTHON_LIB="-l$lib"]) if test "x$PYTHON_LIB" != "x" ; then break fi done Doesn't work. lib would just be like 2.2, 2.1, 2.0, which is not the actual name of the file. In addition, its not passing any load path information to the client. Since there are some obvious dependencies, what should really happen is that we look for the library in the same version as we found the header file. I'll look into cleaning this - problem is that this is difficult for me to test. > Three problems I can see so far - > 1. you have to wait for the map to reset before you can see or enter > your new pad. Presuming here you mean the parent map (/city/city), this is a bit of a problem - difficult to know when, if any, that map may reset. > anyone have thoughts on this? Am I missing anything vital? Someone > have a better plan? How is the map exit updated? How is the ownership of these maps done? I thought some of the idea of these lots would be that only the owner could do something, yet anyone could visit them - more like the common apartment building. > I installed Sorcerer Linux a bit ago to try it out and noticed that > Crossfire is one one of the install spells you can cast. Unfortunatly > it is 'cast crossfire' and it gets the whole ball game- arches, > maps, client, server. Think it would be better to make three install > spells: client, server+maps, and the jED + arches. Anyway, have to look > into that later. Note that no one on the crossfire development team (that I know of at least) is actually responsible for determining what OS's/kits crossfire gets bundled with - rather, someone who works on that distribution decides to grab it. So we don't have a lot of control on that. From mwedel at sonic.net Tue Sep 17 01:31:40 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:54 2005 Subject: [CF-Devel] Madhatter? (Python plugin automake) References: <002c01c2575d$9d9ecbc0$0a02a8c0@kameria> <3D7BD1C3.7080901@sonic.net> <001301c257b9$51eabde0$0302a8c0@kameria> <3D7C31C9.8020709@sonic.net> <000401c25805$64a968e0$0802a8c0@ott.ca.dmr> Message-ID: <3D86CC4C.5090900@sonic.net> Todd Mitchell wrote: > The autobuild does use the proper Python.h (on my system I have > /usr/include/python1.5 and /usr/include/python2.1 - and the CPPFLAGS that is > generated in the Makefile is -I/usr/include/python2.1 This issue of checking the proper version of the header/library should now be fixed in CVS. Hard for me to test this particular setup, so if you can confirm that it does now do the right thing, that would be great. From jajcus at bnet.pl Tue Sep 17 01:59:37 2002 From: jajcus at bnet.pl (Jacek Konieczny) Date: Thu Jan 13 18:02:54 2005 Subject: [CF-Devel] new cut 1.4.0 and realestate idea In-Reply-To: <3D86BDBB.9010207@sonic.net> References: <000c01c25d41$ebaf8040$0a02a8c0@kameria> <3D86BDBB.9010207@sonic.net> Message-ID: <20020917065937.GC23816@serwus.bnet.pl> On Mon, Sep 16, 2002 at 10:29:31PM -0700, Mark Wedel wrote: > Yeah, looking at aclocal.m4 - the first block of code: > > for lib in python{,2.2,2.1,2.0} ; do > AC_CHECK_LIB($lib, > PyArg_ParseTuple,[PYTHON_LIB="-l$lib"]) > if test "x$PYTHON_LIB" != "x" ; then > break > fi > done > > Doesn't work. lib would just be like 2.2, 2.1, 2.0, which is not the > actual name of the file. The code above checks for: libpython, libpython2.2, libpython2.1, libpython2.0 Maybe the order is wrong (it seems it doesn't match header search order on some systems), but it works well at least for me. I have python library installed as: /usr/lib/libpython2.2.so Anybody knows the _proper_ way to find python headers/libraries? Greets, Jacek From jajcus at bnet.pl Tue Sep 17 02:05:31 2002 From: jajcus at bnet.pl (Jacek Konieczny) Date: Thu Jan 13 18:02:54 2005 Subject: [CF-Devel] Madhatter? (Python plugin automake) In-Reply-To: <3D86CC4C.5090900@sonic.net> References: <002c01c2575d$9d9ecbc0$0a02a8c0@kameria> <3D7BD1C3.7080901@sonic.net> <001301c257b9$51eabde0$0302a8c0@kameria> <3D7C31C9.8020709@sonic.net> <000401c25805$64a968e0$0802a8c0@ott.ca.dmr> <3D86CC4C.5090900@sonic.net> Message-ID: <20020917070531.GD23816@serwus.bnet.pl> On Mon, Sep 16, 2002 at 11:31:40PM -0700, Mark Wedel wrote: > This issue of checking the proper version of the header/library should now > be fixed in CVS. Hard for me to test this particular setup, so if you can > confirm that it does now do the right thing, that would be great. It seems your solution is very broken. It assumes python library is sattic, and that has extension ".a". This will be wrong on many systems! You should never check for a library as a file. Your check will probably also break libtool plugin support (when it will be done in the libtool way), as libtool may need "*.la" version of library. Greets, Jacek From temitchell at sympatico.ca Tue Sep 17 08:20:38 2002 From: temitchell at sympatico.ca (Todd Mitchell) Date: Thu Jan 13 18:02:54 2005 Subject: [CF-Devel] new cut 1.4.0 and realestate idea References: <000c01c25d41$ebaf8040$0a02a8c0@kameria> <3D86BDBB.9010207@sonic.net> <20020917065937.GC23816@serwus.bnet.pl> Message-ID: <000801c25e4d$0501ec20$0802a8c0@ott.ca.dmr> Just to clarify, the correct python libraries ARE located and put into the makefile for the plugin (if I build on the system with 2.1 it gets 2.1, if I build on the system with 2.2 it gets 2.2), BUT the 1.5 libraries are also detected and placed in the Makefile. Since the 1.5 lib path is placed infront of the 2.x lib path the plugin generates a mismatch since the header file is from 2.x and the first path is for 1.5. When I manually edit the Makefile, I just remove the 1.5 lib entry, leaving the 2.x entry in place. From temitchell at sympatico.ca Tue Sep 17 09:02:42 2002 From: temitchell at sympatico.ca (Todd Mitchell) Date: Thu Jan 13 18:02:54 2005 Subject: [CF-Devel] new cut 1.4.0 and realestate idea References: <000c01c25d41$ebaf8040$0a02a8c0@kameria> <3D86BDBB.9010207@sonic.net> Message-ID: <001101c25e53$3bb7e840$0802a8c0@ott.ca.dmr> > As a side note, the preferred content for e-mail is text only, not text/html > combinations. Ya, I forget to set the mail client sometimes when I'm hopping around. Sorry. > > Three problems I can see so far - > > 1. you have to wait for the map to reset before you can see or enter > > your new pad. > > Presuming here you mean the parent map (/city/city), this is a bit of a > problem - difficult to know when, if any, that map may reset. > Ya this is the biggest problem. I could also create a temporary exit to the new maps the same way I create a 'deed' but don't know yet if I can create objects on maps in memory if the player is not on that map. Also what if someone is standing on the lot? That is the most complicated bit. I suppose it would be a good idea to only put lots on less travelled maps and perhaps create a portal to send the player to their new home (since they could leave with no problem). > > > anyone have thoughts on this? Am I missing anything vital? Someone > > have a better plan? > > How is the map exit updated? How is the ownership of these maps done? I > thought some of the idea of these lots would be that only the owner could do > something, yet anyone could visit them - more like the common apartment building. When a lot is purchased (for a hefty price), three thngs happen: 1.a 'deed' is issued using the activatorname and the lot number, which produces a unique object to check for. 2. the parent map is updated by writing an exit on the 'lot' on the map file, 3. the template maps are read, the inventory checkers and exits are rewritten based on the 'deed' and on the information in the 'lots' file (for the main exit), and a directory containing the modified copys of the maps is placed in the player's directory. The exits to the new home are updated by rewriting the parent map (to: /playerdir/player/housedir/), the maps are public with unique floors (mostly) and use inventory checkers to give access to some areas (for display cases and such). The homes are public access by invitation, the owner would have to let people in and many areas would be accessable only by the deed holder. > > Note that no one on the crossfire development team (that I know of at least) > is actually responsible for determining what OS's/kits crossfire gets bundled > with - rather, someone who works on that distribution decides to grab it. So we > don't have a lot of control on that. - Yes, of course - but I looked over the Sorcery crossfire 'spell' and probably can with a bit of help/thought make the proper spells for this (if this distro is gonna be around for a bit). By the way the default package format for this was bz2, but it should switch over to go for the gz files if those are no longer available. This was as more by way of community interest than anything else. From mwedel at sonic.net Tue Sep 17 23:15:40 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:54 2005 Subject: [CF-Devel] new cut 1.4.0 and realestate idea References: <000c01c25d41$ebaf8040$0a02a8c0@kameria> <3D86BDBB.9010207@sonic.net> <001101c25e53$3bb7e840$0802a8c0@ott.ca.dmr> Message-ID: <3D87FDEC.7030201@sonic.net> Todd Mitchell wrote: > > Ya this is the biggest problem. I could also create a temporary exit to the > new maps the same way I create a 'deed' but don't know yet if I can create > objects on maps in memory if the player is not on that map. Also what if > someone is standing on the lot? That is the most complicated bit. I > suppose it would be a good idea to only put lots on less travelled maps and > perhaps create a portal to send the player to their new home (since they > could leave with no problem). Well, how do you 'update' the parent map? You can't modify the original copy of it (or really shouldn't, as bad things are likely to happen if you do, like losing all the information on them. Plus, there is no guarantee that the original maps are read/write). So the correct thing to do is update the 'unique' objects of the map. If the map is currently in memory, updating it shouldn't be that big a deal. If the map has been swapped out, that is a little more difficult - if you know that the spot your are putting this lot on the map will not have any other exit assigned to it, you could just append the appropriate information to the unique object version of the map - presuming that a unique object version has been created. > > When a lot is purchased (for a hefty price), three thngs happen: > 1.a 'deed' is issued using the activatorname and the lot number, which > produces a unique object to check for. > 2. the parent map is updated by writing an exit on the 'lot' on the map > file, > 3. the template maps are read, the inventory checkers and exits are > rewritten based on the 'deed' and on the information in the 'lots' file (for > the main exit), and a directory containing the modified copys of the maps > is placed in the player's directory. > > The exits to the new home are updated by rewriting the parent map (to: > /playerdir/player/housedir/), the maps are public with unique floors > (mostly) and use inventory checkers to give access to some areas (for > display cases and such). > The homes are public access by invitation, the owner would have to let > people in and many areas would be accessable only by the deed holder. Why put this map in the player directory? Is the plugins smart enough to see that if this player quits (and hense the playerdir is removed) that the deed is made available again? When you say the map is by invitation only, how so? If I buy a lot, can other people actually go to that map -even if most of it is not accessible, or if they tried to go to the exit where the lot is, would they get some message such that they can't even enter? Various thoughts I have: 1) Put the proper path for the exits in the parent map - just these maps don't exist until the deed is bought. When the deed is bought, the script copies for the maps to the appropriate place that the exit points - in this way, don't need to do anything about updating the parent map. 2) Not sure how doable this is, but use the scripts in the exit objects/lots. When the object is applied, the script runs, checks its database of information and updates the exit, as needed, as well as call the appropriate function to move the player to the new map. From mwedel at sonic.net Tue Sep 17 23:25:10 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:54 2005 Subject: [CF-Devel] Madhatter? (Python plugin automake) References: <002c01c2575d$9d9ecbc0$0a02a8c0@kameria> <3D7BD1C3.7080901@sonic.net> <001301c257b9$51eabde0$0302a8c0@kameria> <3D7C31C9.8020709@sonic.net> <000401c25805$64a968e0$0802a8c0@ott.ca.dmr> <3D86CC4C.5090900@sonic.net> <20020917070531.GD23816@serwus.bnet.pl> Message-ID: <3D880026.9050806@sonic.net> Jacek Konieczny wrote: > On Mon, Sep 16, 2002 at 11:31:40PM -0700, Mark Wedel wrote: > >> This issue of checking the proper version of the header/library should now >> be fixed in CVS. Hard for me to test this particular setup, so if you can >>confirm that it does now do the right thing, that would be great. > > > It seems your solution is very broken. It assumes python library is > sattic, and that has extension ".a". This will be wrong on many systems! > You should never check for a library as a file. > Your check will probably also break libtool plugin support (when it will > be done in the libtool way), as libtool may need "*.la" version of > library. Not sure what the ideal solution is. I notice taht on redhat systems, the python library is in /usr/lib/python../config (eg, the 'nonstandard location check'), and that check only looks for static libs also. Ideally, I'd like to use the AC_CHECK_LIB function. Unfortunately, after the first check for python, configure caches the result, so even if you pass different search options for the library check, it won't work. I'm not sure the correct approach. I note that this check is still in place: AC_CHECK_LIB($python, PyArg_ParseTuple,[PYTHON_LIB="-l$python"]) where python will be derived from the locatin of the include file. However, if the include file is in a standard place (/usr/include/), this won't work. I'm not sure the right approach - I can certainly put the old check in, but it still leaves it only searching for static libs. The problem with this check: PYTHON_LIB=`echo /usr/lib/python*/config/libpython*.a` Is that if you have multiple instances, it finds them all, which probably isn't what you want. From pstolarc at theperlguru.com Tue Sep 17 23:47:14 2002 From: pstolarc at theperlguru.com (pstolarc@theperlguru.com) Date: Thu Jan 13 18:02:54 2005 Subject: [CF-Devel] new cut 1.4.0 and realestate idea In-Reply-To: <3D87FDEC.7030201@sonic.net> References: <000c01c25d41$ebaf8040$0a02a8c0@kameria> <3D86BDBB.9010207@sonic.net> <001101c25e53$3bb7e840$0802a8c0@ott.ca.dmr> <3D87FDEC.7030201@sonic.net> Message-ID: On Tue, 17 Sep 2002 21:15:40 -0700, Mark Wedel wrote: > Various thoughts I have: >1) Put the proper path for the exits in the parent map - just these maps don't >exist until the deed is bought. When the deed is bought, the script copies for >the maps to the appropriate place that the exit points - in this way, don't need >to do anything about updating the parent map. > >2) Not sure how doable this is, but use the scripts in the exit objects/lots. >When the object is applied, the script runs, checks its database of information >and updates the exit, as needed, as well as call the appropriate function to >move the player to the new map. On a slightly related note, this idea cropped up in conversation. It's not my idea, but here it is anyway. A unique keyed exit. Similar to the per-player unique maps, but instead, per keyed object unique maps. In practice, this would work by: If the player has no key, the go to the "guild store" map. In the guild store map, they buy a key. Then they leave the guild store, and re-enter the same exit. This takes them to their new guild. In the guild, they can buy extra keys to this map, and if they give one of these keys to someone else, they can enter the same map. It may be too complex. But it would resolve the running out of real-estate issue which currently afflicts the guilds, and which would affect any other player castle idea. -Philip From mwedel at sonic.net Wed Sep 18 01:18:18 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:54 2005 Subject: [CF-Devel] button.c magic mouth suggestions References: Message-ID: <3D881AAA.30803@sonic.net> Kurt Fitzner wrote: > I'd like to make a suggestion for magic mouths. After struggling in a map > editor for an hour on an esoteric problem, I finally realized that a slight > code change makes more sense. The gist of the problem was that I needed a > magic mouth to be activated when a button was pushed, but not released. I > can't think of why someone would want to 'connect' a magic mouth and then have > it respond to both push and release signals. But, I'm sure that it happens, > so as not to break maps, I propose the following in button.c (line 75 or so) > > case SIGN: > if (!tmp->stats.sp || ((tmp->stats.sp > 0) && op->value) > || ((tmp->stats.sp < 0) && !op->value)) > if (!tmp->stats.food || tmp->last_eat < tmp->stats.food) { > (*info_map_func)(NDI_UNIQUE | NDI_NAVY,tmp->map,tmp->msg); > if (tmp->stats.food) tmp->last_eat++; > } > break; Just to come back to this - I've put the changes into CVS to do this. I've updated the arch's, so make sure you use the updated archetype file, or connected objects won't work (as there is now both a activate on push and activate on release). All the code in that function can be controlled by this. I wasn't all that clever when updating the archetypes - basically, all the affected archs have both values set - that keeps the old behaviour. given this is just 2 bits out of the FLAGS value (of which the memory is already there), I didn't do anything clever about putting it in an object subtype/substructure. That is a seperate conversation, but I think a more notable change/addition to the object structure would be in order before making such a change. From mwedel at sonic.net Wed Sep 18 01:19:14 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:54 2005 Subject: [CF-Devel] button.c, bug in multi-tile door animations References: Message-ID: <3D881AE2.2010600@sonic.net> Kurt Fitzner wrote: > Sorry for all the posts. I'll start making them in digest format to get it > all at once. :) > > I've noticed that mine_secret_1_1 and mine_secret_2_1, which are type 26 > (timed gate) multi-tile doors don't quite work properly. The issue is that > only one tile's animation seems to get used on the correct 'connected' value. I've put the change into CVS. I did it slightly different - the other parts of large objects key the various values of the head object - this should make it more likely for them to remain in sync. From mwedel at sonic.net Wed Sep 18 01:25:15 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:54 2005 Subject: [CF-Devel] new cut 1.4.0 and realestate idea References: <000c01c25d41$ebaf8040$0a02a8c0@kameria> <3D86BDBB.9010207@sonic.net> <001101c25e53$3bb7e840$0802a8c0@ott.ca.dmr> <3D87FDEC.7030201@sonic.net> Message-ID: <3D881C4B.9000005@sonic.net> pstolarc@theperlguru.com wrote: > On Tue, 17 Sep 2002 21:15:40 -0700, Mark Wedel wrote: > On a slightly related note, this idea cropped up in conversation. It's not > my idea, but here it is anyway. > > A unique keyed exit. Similar to the per-player unique maps, but instead, > per keyed object unique maps. > > In practice, this would work by: > If the player has no key, the go to the "guild store" map. In the guild > store map, they buy a key. Then they leave the guild store, and re-enter > the same exit. This takes them to their new guild. In the guild, they can > buy extra keys to this map, and if they give one of these keys to someone > else, they can enter the same map. > > It may be too complex. But it would resolve the running out of real-estate > issue which currently afflicts the guilds, and which would affect any other > player castle idea. I'm taking it that this means there could be many 'different' guilds linked off the same exit. Eg, a player does that above, but a new player decides he doesn't like the people in that guild, so goes to the shop and buys the guild key, and now a second guild is at the same location. One obvious question is - what do you do if a player has multiple keys that apply for that exit? On a more basic principle, the idea of per player unique maps is a bit odd - its necessary for convenience sake, but doesn't make a lot of realistic sense. Its unclear how many guilds/buildings there really should be. If you look at the maps-bigworld, running out of real estate should presumably not be much an issue - that world is a lot bigger - while I suppose it could become congested, I think the main cause of that would be the same player buying up all sorts of buildings - something to prevent that from happening might be more in order. From jajcus at bnet.pl Wed Sep 18 01:33:20 2002 From: jajcus at bnet.pl (Jacek Konieczny) Date: Thu Jan 13 18:02:54 2005 Subject: [CF-Devel] Madhatter? (Python plugin automake) In-Reply-To: <3D880026.9050806@sonic.net> References: <002c01c2575d$9d9ecbc0$0a02a8c0@kameria> <3D7BD1C3.7080901@sonic.net> <001301c257b9$51eabde0$0302a8c0@kameria> <3D7C31C9.8020709@sonic.net> <000401c25805$64a968e0$0802a8c0@ott.ca.dmr> <3D86CC4C.5090900@sonic.net> <20020917070531.GD23816@serwus.bnet.pl> <3D880026.9050806@sonic.net> Message-ID: <20020918063320.GC14370@serwus.bnet.pl> On Tue, Sep 17, 2002 at 09:25:10PM -0700, Mark Wedel wrote: > Ideally, I'd like to use the AC_CHECK_LIB function. Unfortunately, after > the first check for python, configure caches the result, so even if you > pass different search options for the library check, it won't work. Are you sure? My solution (which is included in 1.4.0) works for me and I have libpython in the second location tried. Maybe this was a problem for some buggy version of autoconf. Greets, Jacek From mwedel at sonic.net Wed Sep 18 02:25:50 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:54 2005 Subject: [CF-Devel] Madhatter? (Python plugin automake) References: <002c01c2575d$9d9ecbc0$0a02a8c0@kameria> <3D7BD1C3.7080901@sonic.net> <001301c257b9$51eabde0$0302a8c0@kameria> <3D7C31C9.8020709@sonic.net> <000401c25805$64a968e0$0802a8c0@ott.ca.dmr> <3D86CC4C.5090900@sonic.net> <20020917070531.GD23816@serwus.bnet.pl> <3D880026.9050806@sonic.net> <20020918063320.GC14370@serwus.bnet.pl> Message-ID: <3D882A7E.3050202@sonic.net> Jacek Konieczny wrote: > On Tue, Sep 17, 2002 at 09:25:10PM -0700, Mark Wedel wrote: > >> Ideally, I'd like to use the AC_CHECK_LIB function. Unfortunately, after >> the first check for python, configure caches the result, so even if you >>pass different search options for the library check, it won't work. > > Are you sure? My solution (which is included in 1.4.0) works for me > and I have libpython in the second location tried. > Maybe this was a problem for some buggy version of autoconf. > > Greets, > Jacek > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel Well, I tried to do something like: AC_CHECK_LIB(python2.2, ..., ... ) (search in default location) AC_CHECK_LIB(python2.2, ..., -L/usr/lib/python2.2/config) (search in odd location) In the configure output, it didn't find the first one, and when it went to try again, it didn't find that, and said the result was cached. Note the example above is simplified - it actually tried numerous versions. Now if you are searching for different libraries (different in this case means python2.1, python2.2, python2.0), it will not treat those as the same since the name is different. But if you pass different options to find it, it won't work right. From pstolarc at theperlguru.com Wed Sep 18 02:42:12 2002 From: pstolarc at theperlguru.com (pstolarc@theperlguru.com) Date: Thu Jan 13 18:02:54 2005 Subject: [CF-Devel] new cut 1.4.0 and realestate idea In-Reply-To: <3D881C4B.9000005@sonic.net> References: <000c01c25d41$ebaf8040$0a02a8c0@kameria> <3D86BDBB.9010207@sonic.net> <001101c25e53$3bb7e840$0802a8c0@ott.ca.dmr> <3D87FDEC.7030201@sonic.net> <3D881C4B.9000005@sonic.net> Message-ID: On Tue, 17 Sep 2002 23:25:15 -0700, Mark Wedel wrote: > I'm taking it that this means there could be many 'different' guilds linked >off the same exit. Eg, a player does that above, but a new player decides he >doesn't like the people in that guild, so goes to the shop and buys the guild >key, and now a second guild is at the same location. Exactly. > Its unclear how many guilds/buildings there really should be. If you look at >the maps-bigworld, running out of real estate should presumably not be much an >issue - that world is a lot bigger - while I suppose it could become congested, >I think the main cause of that would be the same player buying up all sorts of >buildings - something to prevent that from happening might be more in order. I'm not sure if this particular solution is the best, but the issue I'm trying to address is this: There are n guilds. All n guilds get bought by different sets of players. Time passes. The original purchasers of the guilds lose interest in crossfire, and stop playing. Now, you're stuck with a bunch of locked up guilds, and nobody accepting new members into the guilds. This issue is further pressed by individual players buying guilds for their own personal use using throw-away characters as the "other two players". (Is this an issue? Is it one worth addressing?) This solution would also address the (possible) problem of the landscape being littered with abandoned lots, in the real estate idea side of this thread. But, as you said, there is a lot more space in maps-bigworld. (Is this an issue? Is it one worth addressing?) -Philip From temitchell at sympatico.ca Wed Sep 18 08:17:02 2002 From: temitchell at sympatico.ca (Todd Mitchell) Date: Thu Jan 13 18:02:55 2005 Subject: [CF-Devel] Madhatter? (Python plugin automake) References: <002c01c2575d$9d9ecbc0$0a02a8c0@kameria> <3D7BD1C3.7080901@sonic.net> <001301c257b9$51eabde0$0302a8c0@kameria> <3D7C31C9.8020709@sonic.net> <000401c25805$64a968e0$0802a8c0@ott.ca.dmr> <3D86CC4C.5090900@sonic.net> <20020917070531.GD23816@serwus.bnet.pl> <3D880026.9050806@sonic.net> Message-ID: <000a01c25f15$aeb8e520$0802a8c0@ott.ca.dmr> > I'm not sure the right approach - I can certainly put the old check in, but it > still leaves it only searching for static libs. > > The problem with this check: > > PYTHON_LIB=`echo /usr/lib/python*/config/libpython*.a` > > Is that if you have multiple instances, it finds them all, which probably > isn't what you want. This is the exact problem I am having. The detection works fine, but this line is double dipping and putting in an entry to the python1.5a in front of the python2.1a. It is the python* that looks to me to be the problem here. From michael.toennies at nord-com.net Wed Sep 18 10:33:45 2002 From: michael.toennies at nord-com.net (Michael Toennies) Date: Thu Jan 13 18:02:55 2005 Subject: [CF-Devel] Madhatter? (Python plugin automake) In-Reply-To: <000a01c25f15$aeb8e520$0802a8c0@ott.ca.dmr> Message-ID: The problem is more worse. The damn.informatik server runs in a bigger network. There are several installed pythons, in usr/local, /usr and other directories. They range from 1.5 to 2.2.1. I had directed the python makefile to my local 2.2.1 installation because all 2.x in usr/local seems broken to me. Compile and link was fine and the scripts run fine for the first moment. The i tried the CFBoard.py script which imported shelves module. There i had a error in some system python scripts. Reason was, that the script tried to import the shelves.py module from a /usr/local/python2.2 installation and not from my local one. This /usr/local python was broken or 2.2.0 or something - so the script bugged. I was not able to find the reason why he tried the false directory first. On my private linux installation, all worked fine but in the university was to much weird settings i had no real control about. i solved the problem by recompile my private python and changing the version in configure.in to 2.p ... then i compiled the server again with looking for python2.p - now all was ok. > > > > I'm not sure the right approach - I can certainly put the old > check in, > but it > > still leaves it only searching for static libs. > > > > The problem with this check: > > > > PYTHON_LIB=`echo > /usr/lib/python*/config/libpython*.a` > > > > Is that if you have multiple instances, it finds them all, which > probably > > isn't what you want. > > This is the exact problem I am having. The detection works fine, but this > line is double dipping and putting in an entry to the python1.5a > in front of > the python2.1a. It is the python* that looks to me to be the > problem here. > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel From temitchell at sympatico.ca Wed Sep 18 08:54:19 2002 From: temitchell at sympatico.ca (Todd Mitchell) Date: Thu Jan 13 18:02:55 2005 Subject: [CF-Devel] new cut 1.4.0 and realestate idea References: <000c01c25d41$ebaf8040$0a02a8c0@kameria> <3D86BDBB.9010207@sonic.net> <001101c25e53$3bb7e840$0802a8c0@ott.ca.dmr> <3D87FDEC.7030201@sonic.net> Message-ID: <001701c25f1a$e376d740$0802a8c0@ott.ca.dmr> Mark said: > Well, how do you 'update' the parent map? You can't modify the original copy > of it (or really shouldn't, as bad things are likely to happen if you do, like > losing all the information on them. Plus, there is no guarantee that the > original maps are read/write). > Well...I was planning on writing to the parent map...it would have to be crossfire writable... > Why put this map in the player directory? Is the plugins smart enough to see > that if this player quits (and hense the playerdir is removed) that the deed is > made available again? > > When you say the map is by invitation only, how so? If I buy a lot, can other > people actually go to that map -even if most of it is not accessible, or if they > tried to go to the exit where the lot is, would they get some message such that > they can't even enter? I put the new maps in the player directory because I didn't want to write maps to the maps directory. They could go anywhere really, but it is easier to clean them up this way. Other players can go to these maps, there is a grounds or yard leading to the front door, but the front door is locked. You could go and gawk at the house if you like. > Various thoughts I have: > 1) Put the proper path for the exits in the parent map - just these maps don't > exist until the deed is bought. When the deed is bought, the script copies for > the maps to the appropriate place that the exit points - in this way, don't need > to do anything about updating the parent map. This is probably the best idea, this is why you get the big bucks! It is much better than writing to the parent map- the only thing was that I wanted to have a 'lot for sale - lot 34' message and then update the map to have a 'Joe's house' message. Maybe I could make a message that reads from a file to do this? Have to look into that. This would make it easier to recycle the lot as well - but I haven't given much though to recycling the lots yet since I wanted to get things working first to try it out. I did think about being able to sell property, but didn't want to go there yet. Anyway so far I have gotten about half the code done and half the templates done (haven't decided on most of the prices for the goodies altars yet - especially since I would like to make some quest items for some things)- I will pass it along for comment soon. I haven't done anythng for guilds yet - I was not planning on using this method for guild creation but you certainly could. I was going to try to subclass the CFBank that Joris wrote to make a guild bank and member list manager however. In MHO the idea of guilds is not the same as the idea of castles: castles/homes are personal shared space- you don't want many guilds and have people create a guild as their personal shared space (they should be cost prohibative requiring the efforts of many to sustain them). The features of a home are for personal storage/display, the features of a guild would have to be for player benefit (like a charging room, a library, and advantageous or convienent shops and converters). There would have to be a benefit to joining a guild and a cost associated to make them work as a game dynamic - I don't want to tackle too many things at once however. From mwedel at sonic.net Thu Sep 19 00:31:54 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:55 2005 Subject: [CF-Devel] new cut 1.4.0 and realestate idea References: <000c01c25d41$ebaf8040$0a02a8c0@kameria> <3D86BDBB.9010207@sonic.net> <001101c25e53$3bb7e840$0802a8c0@ott.ca.dmr> <3D87FDEC.7030201@sonic.net> <3D881C4B.9000005@sonic.net> Message-ID: <3D89614A.9050905@sonic.net> pstolarc@theperlguru.com wrote: > > There are n guilds. All n guilds get bought by different sets of players. > Time passes. The original purchasers of the guilds lose interest in > crossfire, and stop playing. Now, you're stuck with a bunch of locked up > guilds, and nobody accepting new members into the guilds. This issue is > further pressed by individual players buying guilds for their own personal > use using throw-away characters as the "other two players". > (Is this an issue? Is it one worth addressing?) Well, hopefully people aren't buying guilds jsut for themselves - if they are buying guilds, hopefully they will follow what the idea is behind them. If they want a private spot for their own, they can still get the private apartment. Now, there aren't a lot of guilds now, but I think that is somewhat intentional - if there were 20 guilds in each town, it sort of diminishes the need of the guilds. > This solution would also address the (possible) problem of the landscape > being littered with abandoned lots, in the real estate idea side of this > thread. But, as you said, there is a lot more space in maps-bigworld. > (Is this an issue? Is it one worth addressing?) The issue might be the abandoned guilds. As of now, there isn't a very good way to reclaim these lost keys. It certainly wouldn't be too hard to look through the player files (via grep) to see where/who owns the keys. You could then see when these players were last played, and reclaim the keys as necessary. However, as of now, that would all have to be done by hand. OTOH, if it became known that that was standard practice, then perhaps people who knew they wouldn't play for a while might give their keys to someone else. From mwedel at sonic.net Thu Sep 19 00:42:39 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:55 2005 Subject: [CF-Devel] new cut 1.4.0 and realestate idea References: <000c01c25d41$ebaf8040$0a02a8c0@kameria> <3D86BDBB.9010207@sonic.net> <001101c25e53$3bb7e840$0802a8c0@ott.ca.dmr> <3D87FDEC.7030201@sonic.net> <001701c25f1a$e376d740$0802a8c0@ott.ca.dmr> Message-ID: <3D8963CF.80003@sonic.net> Todd Mitchell wrote: > Well...I was planning on writing to the parent map...it would have to be > crossfire writable... Probably a bad idea in general - its always been assumed in the past that you can overwrite the original maps at any time without losing data. > Other players can go to these maps, there is a grounds or yard leading to > the front door, but the front door is locked. You could go and gawk at the > house if you like. Ok. In that case, I would put the maps someplace a bit more generic. I could see an odd case where a deed is transferred (eg, A give it to B), and A then quits, causing the house to get removed - that would be pretty unfriendly. > This is probably the best idea, this is why you get the big bucks! It is > much better than writing to the parent map- the only thing was that I wanted > to have a 'lot for sale - lot 34' message and then update the map to have a > 'Joe's house' message. Maybe I could make a message that reads from a file > to do this? Have to look into that. This would make it easier to recycle > the lot as well - but I haven't given much though to recycling the lots yet > since I wanted to get things working first to try it out. I did think about > being able to sell property, but didn't want to go there yet. Not sure about having context sensitive messages. There are lots of room for improvment for what exits can do (one exmaple would be maps open/closed at certain times of day, payment to activate an exit, and so forth). If you set the unique flag on the exit object, at least in the case, if you do update the exit objects attributes, they will be persistent. It may be possible to have the 'lot for sale messages' as the starting point, and then have a script change it - probably easiest to do it so that when the player with the deed uses the exit, the message gets updated. The script would have to get called everytime someone uses the exit, so would have to do checking for the object each time someone uses it. From temitchell at sympatico.ca Thu Sep 19 19:52:41 2002 From: temitchell at sympatico.ca (Todd Mitchell) Date: Thu Jan 13 18:02:55 2005 Subject: [CF-Devel] Python plugin function question Message-ID: <001401c26040$06a8e2a0$0a02a8c0@kameria> Anyone know the proper way to use the CFPython.RemoveObject() I have this but it is giving me problems. I python is looking for an integer here. CFPython.RemoveObject('Deed Lot %s' %(v[0])) I tried using it like the reverse of this below, but was informed the RemoveObject function only took one argument id = CFPython.CreateObject('diploma', (x, y)) CFPython.SetName(id, 'Deed, Lot %s' %(v[0])) CFPython.SetMessage(id, 'This Deed confers...') I am thinking now that it is looking for the object number? Should I be using another function to get the item's number here? Actually if anyone can give me a brief example of adding and removing a hidden object from a players inventory using the plugin I would be appreciative. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://shadowknight.real-time.com/pipermail/crossfire/attachments/20020919/a64978e1/attachment.htm From temitchell at sympatico.ca Thu Sep 19 23:06:34 2002 From: temitchell at sympatico.ca (Todd Mitchell) Date: Thu Jan 13 18:02:55 2005 Subject: [CF-Devel] pluralism Message-ID: <002301c2605b$1be86260$0a02a8c0@kameria> Sorry about the HTML, just did a settings sweep of all my mail clients on different systems to fix that. anyhow, I just noticed that many items in the 1.4.0 release are plural in the singular (like bags of holding, or staves of banishment - even when only one is present.) I also noticed the second last post I sent seems to have gotten lost in the aether - in a nutshell this is what I sent: I decided to simplify the script I was doing for realestate. Have a lot file with entries like this: 1,Scorn,house,100000,vacant Made a Lots folder in the maps directory and made subfolders like so: lot1, lot2, lot3...run off a bunch of copies of some standard houses and keeps for starters but easy for map builders to add new varieties and update the housing market. The maps are to be linked to places in the main maps and manually updated in the lots file. Needless to say you would have to keep the lots file and the unique-items folders and any custom maps backed up or you would get some irate players (WHERE IS MY HOUSE!!!!) Wrote a script that lets players check a lot (returns location, type, cost and if vacant or sold), buy a lot (updates the vacant entry with player name), and sell a lot (updates the lot file, gives back half the price and -still working on this:-> removes the deed and removes the unique-items copies of the map so it is available for resale) Deeds are currently just regular items but would it would probably be best to make them invisible inventory items. (If only I could get more information on the script functions...) How about that? I guess a trap for the quit command is in order as well. Thanks for the input - this is simpler and probably easier to build off of than what I outlined before. And of course all this only works with the plugin and Python 2.1 or better. Still working on this and the templates and if anyone has advice for the costs (how much for a house, how much to add a basement or a second floor, how much for a keep... or anything else I've overlooked (not including an in game editor...) - please let me know. The whole package is up at http://abraxis.sytes.net/maps if you want a peek but it's not finished yet (works as an example however, it's pretty easy to figure out). Hmmm, I wonder how hard it would be to make a (java applet?) that displayed a crossfire 'webcam'...? From temitchell at sympatico.ca Wed Sep 18 12:27:17 2002 From: temitchell at sympatico.ca (Todd Mitchell) Date: Thu Jan 13 18:02:55 2005 Subject: [CF-Devel] new cut 1.4.0 and realestate idea References: <000c01c25d41$ebaf8040$0a02a8c0@kameria> <3D86BDBB.9010207@sonic.net> <001101c25e53$3bb7e840$0802a8c0@ott.ca.dmr> <3D87FDEC.7030201@sonic.net> Message-ID: <000c01c25f38$a438fa40$0802a8c0@ott.ca.dmr> > Why put this map in the player directory? Is the plugins smart enough to see > that if this player quits (and hense the playerdir is removed) that the deed is > made available again? > Various thoughts I have: > 1) Put the proper path for the exits in the parent map - just these maps don't > exist until the deed is bought. When the deed is bought, the script copies for > the maps to the appropriate place that the exit points - in this way, don't need > to do anything about updating the parent map. > Ok, thinking on this I have a new plan. Much less fiddling around less to go wrong :) 1. create a map folder called lots 2. take the find and replace bits out of the realestate script and make it into a utility for generating a map from a template (or you could use your own favorite tool) 3. run a bunch of these off to make 20 or so homes for distribution 4. rework the script I wrote to generate the 'deed' using the lot number for personalizing the map checkers and exits (and not the player name) 5. add in a price field into the lots file. 6. add in something to handle recycling of lots (perhaps to sell the deeds as well if you wanted to trade up). It would work like this: Mapmakers (or admins) can put exits to the lots directly on their maps, they can also add in new lots and either make a custom map for the lot or generate one from one of the templates. They would also have to make an entry in the lots file for their new map(s). The maps are only personalized in unique-items , flushing this would reset the property back to it's original form. This is a lot simpler, I also think there is a hook in the plugin for global events (like quit?) which could be used to reset the map and to remove the player ownership entry in the lots file. Bonus-no worries about map refreshes, writing to maps directly or urban sprawl- also custom maps at custom prices would be available and it would be very simple to add new kinds of housing. Also the lots would be visitable to everyone to ogle and to dream about buying. A sign placed on Also is easier to code - in which case I am almost finished. -only question should the deed be transferrable or not? From temitchell at sympatico.ca Sat Sep 21 18:24:06 2002 From: temitchell at sympatico.ca (Todd Mitchell) Date: Thu Jan 13 18:02:55 2005 Subject: [CF-Devel] Weird Python behaviour Message-ID: <000901c261c5$fb613aa0$0a02a8c0@kameria> I have noticed some weird occurances involving items created using the CFPython.CreateObject() function First thing it does not use the name of the arch to create an arch, but uses the name flag in the arch (e.g. you have to use 'strange key' instead of 'key2'). This is somewhat of a problem in my way of thinking since it is confusing. Secondly and more importantly - items created tend to screw up the maps and player files (large patches of the file are messed up from the point the item was located - also the item, if it survives sometimes this adds the missing code to it's message field.) they are sitting in. I noticed this as more of my maps were getting buggered up as I tested my script. Granted this could be my script, but the items are created properly and are functional for a while - then seem to mess things up when I leave the game. if (CFPython.PayAmount(activator, price*50)): message = 'Excellent choice. Here is the key to your new %s' %(v[2]) id = CFPython.CreateObject('strange key', (x, y)) CFPython.SetName(id, 'Key Lot %s' %(v[0])) CFPython.SetMessage(id, 'This is the key to a %s located on registered lot #%s' %(v[2],v[0])) #CFPython.SetSlaying(id, 'Key Lot %s' %(v[0])) I was hoping it was my script and not the CreateObject since this is used in the IPO scripts as well and thus could be causing problems for others. I don't think has to do with the SetSlaying() since things were getting messed before I added that bit in. -tm From mwedel at sonic.net Sat Sep 21 23:45:07 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:55 2005 Subject: [CF-Devel] Weird Python behaviour References: <000901c261c5$fb613aa0$0a02a8c0@kameria> Message-ID: <3D8D4AD3.606@sonic.net> Todd Mitchell wrote: > I have noticed some weird occurances involving items created using the > CFPython.CreateObject() function > First thing it does not use the name of the arch to create an arch, but uses > the name flag in the arch (e.g. you have to use 'strange key' instead of > 'key2'). This is somewhat of a problem in my way of thinking since it is > confusing. It also poses potential problems in that there are archetypes that have the same object name. arch names are guaranteed to be unique. > > id = CFPython.CreateObject('strange key', (x, y)) > CFPython.SetName(id, 'Key Lot %s' %(v[0])) > CFPython.SetMessage(id, 'This is the key to a %s > located on registered lot #%s' %(v[2],v[0])) > #CFPython.SetSlaying(id, 'Key Lot %s' %(v[0])) Make sure you put a \n at the end of the message you set. Arguably, the plugin should do this for you if you don't, but it doesn't. From muehlber at fh-brandenburg.de Mon Sep 23 10:58:11 2002 From: muehlber at fh-brandenburg.de (Jan Tobias Muehlberg) Date: Thu Jan 13 18:02:55 2005 Subject: [CF-Devel] Problems running the latest CVS Message-ID: <20020923175811.A23986@zeus.fh-brandenburg.de> Hi, after spending four hours in eating two bags of Chinese 'Soft Melon Candy' and compiling the latest CVS of crossfire on SunOS 5.5.1 I am not very satisfied with what I did. It was quite hard to get this Python stuff compiled but now the server does not start properly, which shouldn't have anything to do with Python. Startup fails with the following messages: --------------------------------- [...] Questions and bugs should be mailed to above address. Reading artifacts from /home9/user/muehlber/crossfire/server/share/crossfire/artifacts...Object NULL seems to have too low item power? 5 > 1 Object NULL seems to have too low item power? 9 > 3 SIGSEGV received. Abort --------------------------------- gdb says: --------------------------------- Program received signal SIGSEGV, Segmentation fault. 0xef5a93bc in strlen () (gdb) where #0 0xef5a93bc in strlen () #1 0xef5e9000 in _doprnt () #2 0xef5f20f8 in vsprintf () #3 0x7e8c4 in LOG (logLevel=llevDebug, format=0xbb0a0 "calc_item_power got %d enchantments for %s\n") at logger.c:56 #4 0x6e834 in calc_item_power (op=0x438d68, flag=0) at item.c:209 #5 0x75cd8 in check_loaded_object (op=0x438d68) at loader.l:146 #6 0x766a0 in lex_load (op=0x438d68, map_flags=0) at loader.l:278 #7 0x7d208 in load_object (fp=0xe3b40, op=0x438d68, bufstate=-268438664, map_flags=0) at loader.l:1044 #8 0x90714 in init_artifacts () at treasure.c:1162 #9 0x3d194 in init_beforeplay () at init.c:467 #10 0x3cf40 in init (argc=1, argv=0xeffff93c) at init.c:400 #11 0x41900 in main (argc=1, argv=0xeffff93c) at main.c:1149 --------------------------------- Any ideas? Beside this: When I ran configure I was somewhat happy to see that you are checking for snprintf() now. But you are not using the result of the check, at least in server/spell_effect.c the function was still used. I fixed it by inserting: --------------------------------- #include int __vsnprintf(char *str, int size, const char *format, va_list ap); int snprintf(char *dest, int max, const char *format, ...) { va_list var; int ret; va_start(var, format); ret = __vsnprintf(dest, max, format, var); va_end(var); return ret; } --------------------------------- Perhaps this schould be default for SunOS without having snprintf(). Thanks in advance, J. Tobias -- PGP/GnuPG public key: http://zeus.fh-brandenburg.de/~muehlber From temitchell at sympatico.ca Mon Sep 23 23:13:54 2002 From: temitchell at sympatico.ca (Todd Mitchell) Date: Thu Jan 13 18:02:55 2005 Subject: [CF-Devel] plugin and events Message-ID: <000501c26380$cba13a60$0a02a8c0@kameria> Reading the python plugin code... Local Events are: ATTACK, APPLY, DEATH, DROP, PICKUP, SAY, STOP, TELL, TIME, THROW, TRIGGER, CLOSE these can have code linked to specific objects (by putting an event call in the object) Global events are: BORN, CRASH, LOGIN, LOGOUT, REMOVE, SHOUT, MAPENTER, MAPLEAVE, CLOCK, MAPRESET these can not have code linked to specific objects This did dash my hopes for putting in a map reset event call into certain exits to have the object name and message read from a file on reset. (although I am still thinking how to use one of the local event hooks...say time) I don't know the wisdom of creating a local event hook for a map reset but here are some things you could do if there was one: -place statues that read in a players name as their name from an entry in the highscore table -have houses named after the current owner (like Bob's house) -Since the plugin can override the event you could also have maps that did not reset if there was a player on a linked map (this would let some maps have a shorter default reset time as well I suppose...) -have other objects in some maps that could change (or not change) based on events external to the map reset cycle like a file (local or net), or a condition (player count?) --this would be better than using unique floors (and the associated files in Unique-items) for small object scale semi-permanences. probably a lot more I haven't thought of yet since I barely grok how the server works yet. The plugin.c side of the code looks to have a lot more possible events that could be hooked (I think). just some thoughts. From mwedel at sonic.net Tue Sep 24 01:01:38 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:55 2005 Subject: [CF-Devel] plugin and events References: <000501c26380$cba13a60$0a02a8c0@kameria> Message-ID: <3D8FFFC2.5060901@sonic.net> Todd Mitchell wrote: > Reading the python plugin code... > Local Events are: > ATTACK, APPLY, DEATH, DROP, PICKUP, SAY, STOP, TELL, TIME, THROW, TRIGGER, > CLOSE > these can have code linked to specific objects (by putting an event call in > the object) > Global events are: > BORN, CRASH, LOGIN, LOGOUT, REMOVE, SHOUT, MAPENTER, MAPLEAVE, CLOCK, > MAPRESET > these can not have code linked to specific objects There is probably some good reasons that global events can not be linked to local objects. First, the number of objects that need to be examined for one of these events could be prohibitive - even if only 20 objects currently in memory use it, all objects in memory (thousands, or tens of thousands) would need to get examined. Second, the objects listening for these events may not be in memory when the event happens. IF a map is reset, it is likely in most cases that the objects for the map that is being reset is not in memory. Some, like mapenter and mapleave could be perhaps be tied to the specific exits (although, apply can be used for that). It would perhaps be interesting to have plugins based on the map's themselves. Eg, be able to say something like '/city/city' have mapenter and mapleave plugins associated with it. > This did dash my hopes for putting in a map reset event call into certain > exits to have the object name and message read from a file on reset. > (although I am still thinking how to use one of the local event hooks...say > time) I don't know the wisdom of creating a local event hook for a map reset > but here are some things you could do if there was one: Have to be careful about plugging things into objects, as you can never be sure the objects are going to be in memory when some of the events are called, as I mention above. > -Since the plugin can override the event you could also have maps that did > not reset if there was a player on a linked map (this would let some maps > have a shorter default reset time as well I suppose...) This is probably a different issue - scripts could be used to do this, but it'd be better if it was somehow simpler, like the map header having a list of related maps, eg, something like: related_maps: tower1 tower2 tower3 tower4 This is an old discussion - the problem typically isn't the reset times on linked maps, the problem is that a player doesn't know the status of the map, wanders in, sees it been cleared out, but that means the reset time is once again extended. > -have other objects in some maps that could change (or not change) based on > events external to the map reset cycle like a file (local or net), or a > condition (player count?) --this would be better than using unique floors > (and the associated files in Unique-items) for small object scale > semi-permanences. As said, problem is these objects may not be in memory at the time of the event. In any case, what's the problem with using unique-item files? you can make individual objects unique, and they will persist no matter where they are dropped. Now it would be useful to attach scripts to most unique objects - in particular to the pickup and drop - if someone drops a unique item in a shop (tries to sell it), it goes back to its starting location for example - pickup could be used for it to store away where it was picked up. From mwedel at sonic.net Tue Sep 24 01:36:43 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:55 2005 Subject: [CF-Devel] Problems running the latest CVS References: <20020923175811.A23986@zeus.fh-brandenburg.de> Message-ID: <3D9007FB.8070701@sonic.net> Jan Tobias Muehlberg wrote: > Hi, > Startup fails with the following messages: > > --------------------------------- > [...] > Questions and bugs should be mailed to above address. > Reading artifacts from > /home9/user/muehlber/crossfire/server/share/crossfire/artifacts...Object > NULL seems to have too low item power? 5 > 1 > Object NULL seems to have too low item power? 9 > 3 Fixed in CVS. code was passing a null value to a %s printf. Some OS's will detect that a null was passed and substitute an appropriate values. Others don't. > Beside this: When I ran configure I was somewhat happy to see that you > are checking for snprintf() now. But you are not using the result of the > check, at least in server/spell_effect.c the function was still used. > I fixed it by inserting: I put code in common/porting.c that will define a snprintf if configure doesn't detect one. Since __vsnprintf is probably not very portable, my implementation was to juse call vsprintf, and check ret against max - if ret is bigger, just abort. Arguably, this could be a better replacement is most all cases - I'd have to look at all of waht snprintf is currently being used for, but I would guess that there are some cases where the code is presuming that the buffer will be fully copied, and if the buffer is only partially formed, things may not work right anyways. From mwedel at sonic.net Tue Sep 24 01:51:18 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:56 2005 Subject: [CF-Devel] pluralism References: <002301c2605b$1be86260$0a02a8c0@kameria> Message-ID: <3D900B66.6020702@sonic.net> Todd Mitchell wrote: > I just noticed that many items in the 1.4.0 release are plural in the > singular (like bags of holding, or staves of banishment - even > when only one is present.) Have to double check those. The plural code is sort of a pain because it wasn't done from the start, and instead added a while back. The problem with this that then there all the objects floating around from before the plural code was added (in maps, player save files, whatever) which need to get a new value. However, I don't see this issue with my client. What client are you using? It could be your client doesn't support the singular/plural names properly, and so it always displays the plural names. The server basically sends both names to the client when the object shows up - it is then up to the client to display the appropriate name depending on how many there actually are. > > 1,Scorn,house,100000,vacant So what is the format of that? 1: Lot number Scorn: Descriptive location of where the lot is? house: Type of lot? 100000: cost? vacant: status (so a player name could also be here) > > Made a Lots folder in the maps directory and made subfolders like so: lot1, > lot2, lot3...run off a bunch of copies of some standard houses and keeps for > starters but easy for map builders to add new varieties and update the > housing market. The maps are to be linked to places in the main maps and > manually updated in the lots file. Needless to say you would have to keep > the lots file and the unique-items folders and any custom maps backed up or > you would get some irate players (WHERE IS MY HOUSE!!!!) > Wrote a script that lets players check a lot (returns location, type, cost > and if vacant or sold), buy a lot (updates the vacant entry with player > name), and sell a lot (updates the lot file, gives back half the price > and -still working on this:-> removes the deed and removes the unique-items > copies of the map so it is available for resale) > Deeds are currently just regular items but would it would probably be best > to make them invisible inventory items. (If only I could get more > information on the script functions...) I don't see too much issue of the deed being visible - we already have lots of current visible tokens (library cards, gate passes, port passes, etc). Maybe someone should make a 'wallet' container. In some sense, the deed can arguably not be important - one could argue that realistically, the player should be able to give out keys to his house, and the deed really isn't that important. In terms of the subfolders - are the different lot's somehow different? Or are they mostly done that way so that the exits are up to date? > Still working on this and the templates and if anyone has advice for the > costs (how much for a house, how much to add a basement or a second floor, > how much for a keep... or anything else I've overlooked (not including an in > game editor...) - please let me know. The whole package is up at > http://abraxis.sytes.net/maps if you want a peek but it's not finished yet > (works as an example however, it's pretty easy to figure out). One thought might be to limit home ownership - since you record what players own what lots, perhaps put a limit of no more than X houses - in this way, rich/powerful players couldn't buy up everything. This also means that if they decide to upgrade to a better residence, they need to sell some of their old residences. From pstolarc at theperlguru.com Tue Sep 24 03:33:10 2002 From: pstolarc at theperlguru.com (pstolarc@theperlguru.com) Date: Thu Jan 13 18:02:56 2005 Subject: [CF-Devel] plugin and events In-Reply-To: <000501c26380$cba13a60$0a02a8c0@kameria> References: <000501c26380$cba13a60$0a02a8c0@kameria> Message-ID: Here's an idea. Player buys a house. A marker gets placed on the player. The player walks onto the map, a checkinv gets triggered, dropping a sign saying, "Your house is under construction, It will be completed tomorrow." -Philip From temitchell at sympatico.ca Tue Sep 24 10:18:11 2002 From: temitchell at sympatico.ca (Todd Mitchell) Date: Thu Jan 13 18:02:56 2005 Subject: [CF-Devel] plugin and events References: <000501c26380$cba13a60$0a02a8c0@kameria> <3D8FFFC2.5060901@sonic.net> Message-ID: <000801c263dd$99cd8360$0802a8c0@ott.ca.dmr> ----- Original Message ----- From: Mark Wedel > There is probably some good reasons that global events can not be linked to > local objects. > > First, the number of objects that need to be examined for one of these events > could be prohibitive - even if only 20 objects currently in memory use it, all > objects in memory (thousands, or tens of thousands) would need to get examined. > > Second, the objects listening for these events may not be in memory when the > event happens. IF a map is reset, it is likely in most cases that the objects > for the map that is being reset is not in memory. > > Some, like mapenter and mapleave could be perhaps be tied to the specific > exits (although, apply can be used for that). It would perhaps be interesting > to have plugins based on the map's themselves. > > Eg, be able to say something like '/city/city' have mapenter and mapleave > plugins associated with it. > > As said, problem is these objects may not be in memory at the time of the > event.... Yes, I didn't want to be able to hook local objects to the global map reset event, I was thinking that a new local map refresh event could be useful (and not too prohibitive since it would only have to check objects on that map). Then you would not have a problem that objects would not be in memory since it would only be objects going into memory that could hook the event. I don't know if this is possible but it sounds (to the non-expert here) possible... (what is the CFWreadymapname wrapper?) (BTW - I also noticed one wrapper - GETARCHBYOBJNAME, is this why the plugin uses the object common name and not the arch name?) >In any case, what's the problem with using unique-item files? you can > make individual objects unique, and they will persist no matter where they are > dropped. no problem with using unique-item files, but for some things you wanted to do it would be more (dynamic? straightforward? simple?) if there was a local map refresh hook. Thinking more of non pickable objects - or intercepting the arch that is placed on a map (like creatures who are tougher depending on how many players are on the server when the map is created/refreshed.) > Now it would be useful to attach scripts to most unique objects - in > particular to the pickup and drop - if someone drops a unique item in a shop > (tries to sell it), it goes back to its starting location for example - pickup > could be used for it to store away where it was picked up. This is a good idea too, I remember on the Abermud there was a pit where you dumped quest items and other garbage and got some xp for them - presumably doing you could then return some items into circulation or kick off a refresh(?) of that quest. Again just an idea. From mwedel at sonic.net Wed Sep 25 01:40:57 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:56 2005 Subject: [CF-Devel] plugin and events References: <000501c26380$cba13a60$0a02a8c0@kameria> <3D8FFFC2.5060901@sonic.net> <000801c263dd$99cd8360$0802a8c0@ott.ca.dmr> Message-ID: <3D915A79.8050407@sonic.net> Todd Mitchell wrote: > ----- Original Message ----- > Yes, I didn't want to be able to hook local objects to the global map reset > event, I was thinking that a new local map refresh event could be useful > (and not too prohibitive since it would only have to check objects on that > map). Then you would not have a problem that objects would not be in memory > since it would only be objects going into memory that could hook the event. > I don't know if this is possible but it sounds (to the non-expert here) > possible... (what is the CFWreadymapname wrapper?) Normally, when a map is reset, it has already been swapped out (no objects in memory). When the map resets, its temp file is removed, and its entry from the list of linked maps is removed. It would certainly be possible to re-load the map before resetting it, but this is a bit odd, and certainly not the most efficient. Updating values on a such a map may be of limited use (since the changes are going to be lost). Now I suppose the map could be loaded, the map searched for objects with map reset scripts, then the map get saved out again, and then reset, but the efficiency of this is terrible. Crossfire is single threaded. disk i/o can be a real killer in terms of performance - ideally, you want each tick to process in the same amount of time. Doing all that above is very likely to stretch out the time it takes to process that tick. Its unclear to me why you really need to wait for the map reset event to do what you want > no problem with using unique-item files, but for some things you wanted to > do it would be more (dynamic? straightforward? simple?) if there was a local > map refresh hook. Thinking more of non pickable objects - or intercepting > the arch that is placed on a map (like creatures who are tougher depending > on how many players are on the server when the map is created/refreshed.) Sounds what you are really looking for is a 'call my script the first time this map is loaded into memory'. That is very different than when a map resets - when the server first starts, for example, you would get a lot of the former, but none of hte later - the maps aren't being reset, they are just being loaded in. It shouldn't be too hard to 'fake' this behaviour with very minor code changes - the server already has logic that goes through newly loaded map looking for objects with the auto_apply flag set (only a few specific types, like random treasures). It would be possible to extend this (additional plugin type, or to do something like use the auto_apply flag (or some other new flag) to tell it to run a script. > > >> Now it would be useful to attach scripts to most unique objects - in >>particular to the pickup and drop - if someone drops a unique item in a > > shop > >>(tries to sell it), it goes back to its starting location for example - > > pickup > >>could be used for it to store away where it was picked up. > > > This is a good idea too, I remember on the Abermud there was a pit where you > dumped quest items and other garbage and got some xp for them - presumably > doing you could then return some items into circulation or kick off a > refresh(?) of that quest. this could be much more useful for things like guild house keys, common apartment keys, etc. Right now, there aren't too many objects that have unique set, so this isn't too big an issue. You can't uniqueness too much for objects - after all, you don't want the good items gone forever because the player who accumlated then just stored them away, so most objects will need to remain non unique. From mwedel at sonic.net Wed Sep 25 01:12:20 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:56 2005 Subject: [CF-Devel] Various exp refinements. Message-ID: <3D9153C4.3040805@sonic.net> To stop some abuses in experience, and just some general problems, various ideas to refine exp some more: When a player kills another player, he does not get any exp. A player gets no exp when doing a drain attack against another player. Rationale for the above - best I know of, no servers really condone players killing other players. Removing the exp reward for killing another player would reduce incentive even more. I'm uncertain what to do for the recipient of such attacks - its impossible to seperate the accident death (eg, working as a party and wander in front of your friends lightning bolt, vs something malicious player killing). Arguably, having no effect on players draining other players may be reasonable - as a an agressive action, draining could be as nasty or nastier than death. From pc-crossfire at crowcastle.net Wed Sep 25 10:54:55 2002 From: pc-crossfire at crowcastle.net (pc-crossfire@crowcastle.net) Date: Thu Jan 13 18:02:56 2005 Subject: [CF-Devel] Various exp refinements. Message-ID: <200209251554.g8PFst506613@lol1120.lss.emc.com> >When a player kills another player, he does not get any exp. >A player gets no exp when doing a drain attack against another player. That's good. > I'm uncertain what to do for the recipient of such attacks - its impossible to >seperate the accident death (eg, working as a party and wander in front of your >friends lightning bolt, vs something malicious player killing). > > Arguably, having no effect on players draining other players may be reasonable >- as a an agressive action, draining could be as nasty or nastier than death. Interesting. If a player killing another player had no negative impact on the dead character, then when you get in trouble, have someone else kill you before the monster does. No, there needs to be a penalty for all forms of death. But you're talking about draining, not killing. That's really a separate issue, isn't it? As to killing, how about splitting the experience loss between the character killed and the character doing the killing? If you lost experience for killing other players, it would be even less of a problem. --PC From root at garbled.net Wed Sep 25 13:03:19 2002 From: root at garbled.net (Tim Rightnour) Date: Thu Jan 13 18:02:56 2005 Subject: [CF-Devel] Various exp refinements. In-Reply-To: <200209251554.g8PFst506613@lol1120.lss.emc.com> Message-ID: On 25-Sep-02 pc-crossfire@crowcastle.net wrote: > If a player killing another player had no negative impact on the dead > character, then when you get in trouble, have someone else kill you before > the monster does. If you can plan out having someone else kill you at the right time.. why couldn't you have just avoided death? I mean.. usually I don't know I'm doomed long enough in advance to tell anyone a complex scheme of how they need to off me. Usually, it's a complete surprise, or preceeded by .5 seconds of panic. However.. The idea of "you can slaughter eachother with no penalties" does bring up a more evil thought. Lets say I wanted to be a PITA to newbies. So I run around following them, and kill them back to the inn every time they step outside of town. It doesn't affect them.. just that they never get anywhere. You could also kill someone back to the inn who was doing an area you wanted to play in, to get them out of the way. Worse.. it might just turn into a free-for-all, with everyone treating the whole world like one giant arena. --- Tim Rightnour NetBSD: Free multi-architecture OS http://www.netbsd.org/ NetBSD supported hardware database: http://mail-index.netbsd.org/cgi-bin/hw.cgi From mwedel at sonic.net Wed Sep 25 22:32:53 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:56 2005 Subject: [CF-Devel] Various exp refinements. References: Message-ID: <3D927FE5.70708@sonic.net> Tim Rightnour wrote: > On 25-Sep-02 pc-crossfire@crowcastle.net wrote: > >>If a player killing another player had no negative impact on the dead >>character, then when you get in trouble, have someone else kill you before >>the monster does. > > > If you can plan out having someone else kill you at the right time.. why > couldn't you have just avoided death? I mean.. usually I don't know I'm doomed > long enough in advance to tell anyone a complex scheme of how they need to off > me. Usually, it's a complete surprise, or preceeded by .5 seconds of panic. > > However.. The idea of "you can slaughter eachother with no penalties" does > bring up a more evil thought. > > Lets say I wanted to be a PITA to newbies. So I run around following them, and > kill them back to the inn every time they step outside of town. It doesn't > affect them.. just that they never get anywhere. You could also kill someone > back to the inn who was doing an area you wanted to play in, to get them out of > the way. Note that if the player is a real newby (just came from the hall of selection), currently killing him has no real negative impact, as he doesn't have any experience to use. I didn't mention this, but I did figure that if a player was killed, he'd still get depleted in whatever stats. That probably isn't a very big penalty at high levels (you have the money, so the cost of potion of life probably isn't a really big deal). Note that the player who killed the other player does lose a point of luck, which will have some effects. Perhaps a more clever approach would be to record the number of players another player has killed (in the player object itself) - if above some number, assume it is an abusive pk'er, and add additional penalties (ideally, there would be some aging to this, eg, killing 10 players over the course of playing for 8 months isn't nearly so bad as if you killed 5 players in a single day, but to enforce that/prevent people from easily fooling that would be tricky). Now I suppose you could make killing another player result in not as heavy as a loss for the player killed (instead of the 20%, maybe 5% or a max of 1 level or something?). I'm not sure that if there was no exp gain/loss for killing players if it would change behaviour much - I don't think a bunch of people who are currently not pker's will become ones on the basis of 'there really isn't a penalty'. It seems that generally, pker's are there just to be annoying. From temitchell at sympatico.ca Thu Sep 26 00:23:56 2002 From: temitchell at sympatico.ca (Todd Mitchell) Date: Thu Jan 13 18:02:56 2005 Subject: [CF-Devel] Python again Message-ID: <3D9299EC.3030904@sympatico.ca> The CreateInvisibleInside() python plugin function does not seem to be getting built in the plugin although the code is there. Whenever I try to use this function I get the module has no attribute error. I have tried using SetInvisible which kinda works, but only when the object is dropped out of player inventory (where I am creating it initially with CreateObjectInside). All the functions I have tried out seem to work except this one (although I have by no means tried them all out). Since I don't want the object to be seen (except by the inventory checkers and the remove function in the script) just to simplify this housing thing for the moment. I suppose I will try using a force or something instead of a key (although I did like the key - any ideas on making it non pickable but visible in the inventory?) I looked for the old Guile plugin functions documentation since the python functions are supposed to cover them off and there is scant documentation for the python - but I could not find any. Other than this I am pretty impressed by it in general. it is pretty easy to figure out large parts of it (when you can pull apart someone else's code (thanks Joris). Good stuff I rank it up there with the Java editor for extreme usefulness to content development. From temitchell at sympatico.ca Thu Sep 26 19:39:26 2002 From: temitchell at sympatico.ca (Todd Mitchell) Date: Thu Jan 13 18:02:56 2005 Subject: [CF-Devel] CVS Message-ID: <000501c265be$54f18060$0a02a8c0@kameria> Got an error when making todays CVS in the librandom_map.a function 'rmap_lex_read': reader.l:109:undefined reference to 'yyerror' From tanner at real-time.com Thu Sep 26 19:54:44 2002 From: tanner at real-time.com (Bob Tanner) Date: Thu Jan 13 18:02:57 2005 Subject: [CF-Devel] CVS In-Reply-To: <000501c265be$54f18060$0a02a8c0@kameria>; from temitchell@sympatico.ca on Thu, Sep 26, 2002 at 08:39:26PM -0400 References: <000501c265be$54f18060$0a02a8c0@kameria> Message-ID: <20020926195444.G11476@real-time.com> Quoting Todd Mitchell (temitchell@sympatico.ca): > Got an error when making todays CVS in the librandom_map.a > function 'rmap_lex_read': > reader.l:109:undefined reference to 'yyerror' Try installing flex and bison -- Bob Tanner | Phone : (952)943-8700 http://www.mn-linux.org, Minnesota, Linux | Fax : (952)943-8500 http://www.tcwug.org, Minnesota, Wireless | Coding isn't a crime. Key fingerprint = AB15 0BDF BCDE 4369 5B42 1973 7CF1 A709 2CC1 B288 From temitchell at sympatico.ca Thu Sep 26 20:11:01 2002 From: temitchell at sympatico.ca (Todd Mitchell) Date: Thu Jan 13 18:02:57 2005 Subject: [CF-Devel] CVS References: <000501c265be$54f18060$0a02a8c0@kameria> <20020926195444.G11476@real-time.com> Message-ID: <000c01c265c2$be613e60$0a02a8c0@kameria> do I have to? ----- Original Message ----- From: "Bob Tanner" To: Sent: Thursday, September 26, 2002 8:54 PM Subject: Re: [CF-Devel] CVS > Quoting Todd Mitchell (temitchell@sympatico.ca): > > Got an error when making todays CVS in the librandom_map.a > > function 'rmap_lex_read': > > reader.l:109:undefined reference to 'yyerror' > > Try installing flex and bison > -- > Bob Tanner | Phone : (952)943-8700 > http://www.mn-linux.org, Minnesota, Linux | Fax : (952)943-8500 > http://www.tcwug.org, Minnesota, Wireless | Coding isn't a crime. > Key fingerprint = AB15 0BDF BCDE 4369 5B42 1973 7CF1 A709 2CC1 B288 > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > From yann.chachkoff at mailandnews.com Fri Sep 27 03:21:37 2002 From: yann.chachkoff at mailandnews.com (Yann Chachkoff) Date: Thu Jan 13 18:02:57 2005 Subject: [CF-Devel] Python again Message-ID: <3D94128A@mailandnews.com> Some notes about CFPython... RemoveObject() -------------- RemoveObject() expects an integer representing an object. An object ID can be obtained by functions like CreateObject or WhoAmI, for example. CreateObject() -------------- CreateObject() was supposed to allow an archetype name or a 'full name' to be given. Due to a typo (around line 4566), it doesn't work as expected. It looks like CreateObjectInside should work as expected. I'll check this and correct as appropriate. Two wrappers are used by those functions: CFWGetArchetype() (returning an object, given its arch name); CFWGetArchetypeByObjectName() (returning an object, given its 'clear' name); The reason why CreateObject and CreateObjectInside were created to handle both cases was to allow creating objects from what a player could say - and a player is more likely to say 'strange key' than 'key2'. CFWReadyMapName() wrapper ------------------------- This is a wrapper for ready_map_name(), which is used here to attempt to load a map, given its name. The Python function returns a handle (pointer) to the loaded map. CreateInvisibleInside() ----------------------- Browsing through the plugin_python.h file, it appears that the correct name for this one is CreateInvisibleObjectInside(). The same applies to CheckInvisibleObjectInside(). CLOCK Global event ------------------ The CLOCK Global event handling is disabled by default in CFPython. If you need such an event, remove the comment marks around lines 6899-6901 in plugin_python.c source file. TIME Local event ---------------- TIME was created to allow a specific action to trigger 'whenever the object gets an opportunity to move'. TIME could be used to create random-bomb-like devices, or monsters with time-based abilities. TIMER Local event ----------------- A timer is a kind of "clock" associated with an object. When the counter of a timer reaches 0, it is removed from the list of active timers and an EVENT_TIMER is generated for the target object. TIMER and TIME events are not the same thing: the first one is called when a timer delay has reached 0 while EVENT_TIME is triggered each time the object gets the opportunity to move. TIMER could be used to create bomb-like objects. See timers.h for more informations about timers. The global vs local event scheme -------------------------------- I think some clarification is required about those. The base idea is that the Crossfire world is made of object entities 'influencing' each other in the same game environment. Note that what is called 'object' here doesn't cover maps (because maps were considered as part of the environment, not an entity the player could carry or directly interact with - the player can only interacts with the objects inside the map). So, local events are events 'that can be bound to a specific object': When you kill a monster for example, it is clear that a DEATH event is triggered for him, and only him. Local events have a well definite 'target'on which they should apply. Global events, on the other hand, are events that cannot easily be tied to a specific game object, or are outside the scope of CF inner point-of-view (That's why LOGIN and LOGOUT are global - they could be caused by external problems, like a broken connection). They're 'general informative' events. You may object that they could (and should) have been implemented as local events. Well, performances are an important obstacle. Informing all loaded objects of MAPENTER/MAPLEAVE events would have been quite difficult (even if you create a small map, this could become a problem - what if a player throws a lot of equipment on the floor ?). Hope this helps, Y. Chachkoff ------------------------------------------------ Help supporting JXFire ! (http://jxfire.sf.net) ------------------------------------------------ From mwedel at sonic.net Fri Sep 27 01:31:23 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:57 2005 Subject: [CF-Devel] Python again References: <3D9299EC.3030904@sympatico.ca> Message-ID: <3D93FB3B.8000704@sonic.net> Todd Mitchell wrote: > The CreateInvisibleInside() python plugin function does not seem to be > getting built in the plugin although the code is there. You may want to try calling the function name (python) CreateInvisibleObjectInside. I have no idea why there is a mismatch (the function it calls is CFCreateInvisibleInside). I found this out by looking in plugin/include/plugin_python.h in the server source distribution. Hopefully, that works out for you. Looking at the code, it creates a permanent force object that has the slaying set to the passed string. If this doesn't work, I'll address some of the other issues. My guess is that the 'setinvisible' doesn't work because the code never assumed something like that would happen (eg, and object would become invisible after being picked up). My guess is that if you logged out with that character and then logged back in, you wouldn't see the object anymore - its just that changing the status doesn't result in it from disappearing from the players visible inventory. From mwedel at sonic.net Fri Sep 27 01:35:25 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:57 2005 Subject: [CF-Devel] CVS References: <000501c265be$54f18060$0a02a8c0@kameria> <20020926195444.G11476@real-time.com> <000c01c265c2$be613e60$0a02a8c0@kameria> Message-ID: <3D93FC2D.2070204@sonic.net> Todd Mitchell wrote: > do I have to? What you can try: rm random_map/reader.c cvs update random_map/reader.c touch random_map/reader.c And try to recompile and see if that works. My guess is what happened is that the date for reader.l was later than that of reader.c, so it decided to rebuild reader.c. However, the lex/flex you have on your system requires and external library or something. the reader.c/reader.l have not changed in more than a year, so there certainly isn't any issue with the files themselves. From temitchell at sympatico.ca Fri Sep 27 10:56:02 2002 From: temitchell at sympatico.ca (Todd Mitchell) Date: Thu Jan 13 18:02:57 2005 Subject: [CF-Devel] Python again References: <3D94128A@mailandnews.com> Message-ID: <001201c2663e$62baa5c0$0802a8c0@ott.ca.dmr> ----- Original Message ----- From: Yann Chachkoff > Some notes about CFPython... > > RemoveObject() > -------------- > RemoveObject() expects an integer representing an object. An object ID can be > obtained by functions like CreateObject or WhoAmI, for example. > > CreateObject() > -------------- > CreateObject() was supposed to allow an archetype name or a 'full name' to be > given. Due to a typo (around line 4566), it doesn't work as expected. It looks > like CreateObjectInside should work as expected. I'll check this and correct > as appropriate. > Two wrappers are used by those functions: > CFWGetArchetype() (returning an object, given its arch name); > CFWGetArchetypeByObjectName() (returning an object, given its 'clear' name); > The reason why CreateObject and CreateObjectInside were created to handle both > cases was to allow creating objects from what a player could say - and a > player is more likely to say 'strange key' than 'key2'. I changed my code to use CreateObjectInside instead of Create object and it worked exactly the same way (I just remaned the function and replace the x,y coords with the activator (the player). It seems to use the object name (strange key) as well rather than the arch - but then again I didn't try it with 'key2' - anyway no problems with this function. > CreateInvisibleInside() > ----------------------- > Browsing through the plugin_python.h file, it appears that the correct name > for this one is CreateInvisibleObjectInside(). The same applies to > CheckInvisibleObjectInside(). Great - will try it out. Looking in the plugin code it is called CreateInvisibleInside however which could be confusing. I like the longer name myself and would suggest it be renamed in the code rather than in the header. > > The global vs local event scheme > -------------------------------- > I think some clarification is required about those. > The base idea is that the Crossfire world is made of object entities > 'influencing' each other in the same game environment. Note that what is > called 'object' here doesn't cover maps (because maps were considered as part > of the environment, not an entity the player could carry or directly interact > with - the player can only interacts with the objects inside the map). > So, local events are events 'that can be bound to a specific object': When you > kill a monster for example, it is clear that a DEATH event is triggered for > him, and only him. Local events have a well definite 'target'on which they > should apply. > Global events, on the other hand, are events that cannot easily be tied to a > specific game object, or are outside the scope of CF inner point-of-view > (That's why LOGIN and LOGOUT are global - they could be caused by external > problems, like a broken connection). They're 'general informative' events. You > may object that they could (and should) have been implemented as local events. > Well, performances are an important obstacle. Informing all loaded objects of > MAPENTER/MAPLEAVE events would have been quite difficult (even if you create a > small map, this could become a problem - what if a player throws a lot of > equipment on the floor ?). > Just to avoid misunderstanding - I don't want to link global events to specific objects or change the global events. The scheme makes a lot of sense to me as it is and I am sure is better as is because of timing and processing requirements. Forgive my 'newby' terminology. I think Mark summed it up when he said I was looking for a new local event to hook to specific objects on a map when that map is loaded (when the object is loaded?) to allow for some more control over the objects on the maps, like changing the message field or name of an object or checking an external file or environmental condition or some such. > Hope this helps, > > Y. Chachkoff yes it does thanks. From temitchell at sympatico.ca Fri Sep 27 19:25:06 2002 From: temitchell at sympatico.ca (Todd Mitchell) Date: Thu Jan 13 18:02:57 2005 Subject: [CF-Devel] Python again References: <3D9299EC.3030904@sympatico.ca> <3D93FB3B.8000704@sonic.net> Message-ID: <000601c26685$7f5d4e20$0a02a8c0@kameria> > You may want to try calling the function name (python) > CreateInvisibleObjectInside. I have no idea why there is a mismatch (the > function it calls is CFCreateInvisibleInside). > > Looking at the code, it creates a permanent force object that has the slaying > set to the passed string. It works great and is as you say it creates a force in who (object number) with slaying (string): CFPython.CreateInvisibleObjectInside(who, string). Thanks. From kbulgrien at att.net Thu Sep 26 08:23:43 2002 From: kbulgrien at att.net (kbulgrien@att.net) Date: Thu Jan 13 18:02:57 2005 Subject: [CF-Devel] Various exp refinements. Message-ID: <20020926132343.MDRR28665.mtiwmhc23.worldnet.att.net@mtiwebc15> Why is it that stats like luck and magic are not discussed or displayed in clients? Or am I missing something? Are there others? I see little point in stats like Luck if you aren't given the tools to figure out their effect or guage the effect of wearing an item of Luck +x or Magic +y. The existance of rings of luck or magic is what implies to me that the player should be able to find out what his settings are and what they do. If there is a good reason to keep them hidden, ok, but not even knowing what luck is, how is one to know that you lose it when you kill a player? > Note that the player who killed the other player does lose a point of luck, > which will have some effects. From jshelley at ictransnet.com Mon Sep 30 02:07:04 2002 From: jshelley at ictransnet.com (Johnny Shelley) Date: Thu Jan 13 18:02:58 2005 Subject: [CF-Devel] split window saved positions (patch) Message-ID: This patch fixes split window saved sizes. Previously, each window would default to a rather ugly width and height unless the default height was exceeded, at which point user specified width would be respected. johnny PGP Public Key available from: http://www.keyserver.net:11371/pks/lookup?op=get&search=0x17BF1DD3 -------------- next part -------------- Index: gx11.c =================================================================== RCS file: /cvsroot/crossfire/client/gtk/gx11.c,v retrieving revision 1.20 diff -c -r1.20 gx11.c *** gx11.c 22 Aug 2002 12:36:42 -0000 1.20 --- gx11.c 30 Sep 2002 06:59:27 -0000 *************** *** 4879,4910 **** else fprintf(stderr,"Found bogus line in window position file:\n%s %s\n", buf, cp); } else { if (!strcmp(buf,"win_game:")) { ! gtk_widget_set_uposition (gtkwin_root, wx, wy); ! gtk_widget_set_usize (gtkwin_root, w, h); } if (!want_config[CONFIG_SPLITWIN]) { fprintf(stderr,"Found bogus line in window position file:\n%s %s\n", buf, cp); continue; } if (!strcmp(buf,"win_stats:")) { ! gtk_widget_set_uposition (gtkwin_stats, wx, wy); ! gtk_widget_set_usize (gtkwin_stats, w, h); } if (!strcmp(buf,"win_info:")) { ! gtk_widget_set_uposition (gtkwin_info, wx, wy); ! gtk_widget_set_usize (gtkwin_info, w, h); } if (!strcmp(buf,"win_inv:")) { ! gtk_widget_set_uposition (gtkwin_inv, wx, wy); ! gtk_widget_set_usize (gtkwin_inv, w, h); } if (!strcmp(buf,"win_look:")) { ! gtk_widget_set_uposition (gtkwin_look, wx, wy); ! gtk_widget_set_usize (gtkwin_look, w, h); } if (!strcmp(buf,"win_message:")) { ! gtk_widget_set_uposition (gtkwin_message, wx, wy); ! gtk_widget_set_usize (gtkwin_message, w, h); } } /* else if split windows */ } /* while fgets */ --- 4879,4904 ---- else fprintf(stderr,"Found bogus line in window position file:\n%s %s\n", buf, cp); } else { if (!strcmp(buf,"win_game:")) { ! gdk_window_move_resize(gtkwin_root->window, wx, wy, w, h); } if (!want_config[CONFIG_SPLITWIN]) { fprintf(stderr,"Found bogus line in window position file:\n%s %s\n", buf, cp); continue; } if (!strcmp(buf,"win_stats:")) { ! gdk_window_move_resize(gtkwin_stats->window, wx, wy, w, h); } if (!strcmp(buf,"win_info:")) { ! gdk_window_move_resize(gtkwin_info->window, wx, wy, w, h); } if (!strcmp(buf,"win_inv:")) { ! gdk_window_move_resize(gtkwin_inv->window, wx, wy, w, h); } if (!strcmp(buf,"win_look:")) { ! gdk_window_move_resize(gtkwin_look->window, wx, wy, w, h); } if (!strcmp(buf,"win_message:")) { ! gdk_window_move_resize(gtkwin_message->window, wx, wy, w, h); } } /* else if split windows */ } /* while fgets */ From temitchell at sympatico.ca Sun Sep 22 22:59:30 2002 From: temitchell at sympatico.ca (Todd Mitchell) Date: Thu Jan 13 18:02:58 2005 Subject: [CF-Devel] terrain and styles Message-ID: <000a01c262b5$9ed5a780$0a02a8c0@kameria> What's the deal with the terrain folder and the maps in there? Looks like random encounters. What is this linked to? I have started to play with some of the random map styles (adding in a snowy floor and decor, adding bears and wolves to the animal monster styles. Is there anything I should be aware of in doing this (like don't do it because soandso is in charge of that or suchandsuch depends on that.) I am trying to make them a bit more balanced for the level they represent as well and increase the variety a bit. Things like axing the unicorn from animal styles 7-12... Is is necessary to have a map for each level (topping out at the highest level map, or is is ok to have maps like 1,3,5,9,15,20...) since the documentation says that the closest level map will be used. Any problem with adding in some new monster styles? From muehlber at fh-brandenburg.de Tue Sep 24 08:37:56 2002 From: muehlber at fh-brandenburg.de (Jan Tobias Muehlberg) Date: Thu Jan 13 18:02:58 2005 Subject: [CF-Devel] Problems running the latest CVS In-Reply-To: <3D9007FB.8070701@sonic.net>; from mwedel@sonic.net on Mon, Sep 23, 2002 at 11:36:43PM -0700 References: <20020923175811.A23986@zeus.fh-brandenburg.de> <3D9007FB.8070701@sonic.net> Message-ID: <20020924153756.A23874@zeus.fh-brandenburg.de> Mark Wedel: [snprintf()] > I put code in common/porting.c that will define a snprintf if configure > doesn't detect one. Since __vsnprintf is probably not very portable, my > implementation was to juse call vsprintf, and check ret against max - > if ret is bigger, just abort. Well, it works this way. Thanks for fixing. At least for compiling on Sun you'll need to add '#include '. I'm not sure but it should be the same for other unix-like OSs including Linux? J. Tobias -- PGP/GnuPG public key: http://zeus.fh-brandenburg.de/~muehlber From temitchell at sympatico.ca Tue Sep 24 08:54:27 2002 From: temitchell at sympatico.ca (Todd Mitchell) Date: Thu Jan 13 18:02:58 2005 Subject: [CF-Devel] pluralism References: <002301c2605b$1be86260$0a02a8c0@kameria> <3D900B66.6020702@sonic.net> Message-ID: <000601c263d1$e78a2420$0802a8c0@ott.ca.dmr> > > However, I don't see this issue with my client. What client are you using? > It could be your client doesn't support the singular/plural names properly, and > so it always displays the plural names. > It very well could be the client since I noticed this in the DX client. > > > > > 1,Scorn,house,100000,vacant > > So what is the format of that? > > 1: Lot number > Scorn: Descriptive location of where the lot is? > house: Type of lot? > 100000: cost? > vacant: status (so a player name could also be here) Yes , lot number is the primary key, location is reported back to narrow down the search for a particular lot, house is the type of arch that is on the lot (could be a hut, a house a keep a castle a cave, whatever arch is physically on the map), the price I added in to make it easy to include custom maps and the vacant is replace with a player name when the lot is purchased. If you wanted to have a cave on lot 34 you come up with a map in /Lots/Lot34/cave1, cave 2; make an appropriate linking exit on the world map; and put the following info into the Lots file: 34,outside Scorn,cave,30000,vacant > > I don't see too much issue of the deed being visible - we already have lots > of current visible tokens (library cards, gate passes, port passes, etc). Maybe > someone should make a 'wallet' container. > > In some sense, the deed can arguably not be important - one could argue that > realistically, the player should be able to give out keys to his house, and the > deed really isn't that important. I didn't want to have the 'deed' (now a key arch so I can use the SetSlaying easier) transferable since it would be a pain if the lot was sold to collect all the keys. I was thinking one key in inventory, non transferable, and this is removed when the lot is sold. There is a global hook to quit which will also be used to search the lots file and reset any entries to the quiting player and to delete the related maps in unique-items - which would get messy if there were other keys out there. The way I am placing the inventory checkers on the map make it easy to allow others to enter certain areas if the owner is standing by the door, and I am thinking of putting in doorbells. > > In terms of the subfolders - are the different lot's somehow different? Or > are they mostly done that way so that the exits are up to date? The lots are different but I imagine that like the guilds there will be some basic templates used for many of them. If anyone wanted to make a few fancy houses it would just require an update to the lots file and adding an exit to an existing map to connect it. It would be nice to be able to change the name of the exit (still trying to figure out how th do that) so that you can see LOT 34 on an exit and then when it is bought you would see Bob's cave (and when sold again it would revert to LOT 34 again). But I suppose this could be done using activate hook on some sign on the lot itself (but it would be cooler to do it on the object name on the parent map). > One thought might be to limit home ownership - since you record what players > own what lots, perhaps put a limit of no more than X houses - in this way, > rich/powerful players couldn't buy up everything. This also means that if they > decide to upgrade to a better residence, they need to sell some of their old > residences. It wouldn't be hard to do this by putting in an inventory check to count the player's 'deed-keys' when buying a house. This would make it a kinder world than our own I guess. From temitchell at sympatico.ca Tue Sep 24 15:04:39 2002 From: temitchell at sympatico.ca (Todd Mitchell) Date: Thu Jan 13 18:02:58 2005 Subject: [CF-Devel] unique-map recycling Message-ID: <000a01c26405$9ef0f200$0802a8c0@ott.ca.dmr> I have an question about trying to clean up unique maps. I added a function that will delete the relevant map files in unique items when someone sells a lot (or when they quit...) and that works well, but since these maps could be in memory, when they are swapped out the files are recreated in unique-items (this is also a pain when testing maps with unique floors, I find I have to stop the server, then delete the unique item maps). Is there a way to axe the maps in memory or otherwise refresh the map so that a new version is taken from the maps directory? Also what if someone else is on the map when it is sold (could check for this I guess, but would be a pain for the player selling the lot.) or when a player quits (can't stop them from quiting). Geez, it all seemed so simple at the outset... From root at garbled.net Wed Sep 25 12:06:26 2002 From: root at garbled.net (Tim Rightnour) Date: Thu Jan 13 18:03:06 2005 Subject: [CF-Devel] Various exp refinements. In-Reply-To: <3D9153C4.3040805@sonic.net> Message-ID: On 25-Sep-02 Mark Wedel wrote: > I'm uncertain what to do for the recipient of such attacks - its impossible > to > seperate the accident death (eg, working as a party and wander in front of > your > friends lightning bolt, vs something malicious player killing). People will probably hate me for suggesting this.. but why not make a config variable that a DM can set, that makes players immune to one another's attacks, including magic. (if you wanted to keep the same flavor of the game, we could allways allow one to be damaged by his own magic). The rationale here is.. it's difficult for newer players to adventure together, because they are allways stomping on one another. Even just random encounters between two newish players sometimes ends in one of them getting smooshed. If we make it less dangerous: 1) Mages will have a better time working together with other players and not being crippled. 2) It will encourage more grouping and whatnot.. which is the primary draw of a multiplayer RPG. It's not fun to hang out with other players if you are constantly getting whacked in the head, or having your skin melted off. --- Tim Rightnour NetBSD: Free multi-architecture OS http://www.netbsd.org/ NetBSD supported hardware database: http://mail-index.netbsd.org/cgi-bin/hw.cgi From mwedel at sonic.net Sun Sep 1 01:46:32 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:04:28 2005 Subject: [CF List] strange comportments with large creature summoning References: <1027713028.3d41a80456ecb@imp.free.fr> <3D44C55B.4070000@sonic.net> Message-ID: <3D71B7C8.80708@sonic.net> Mark Wedel wrote: > huet.o@free.fr wrote: >> With that "large" creature, I had a lot of display refresh problems >> (gtk client) >> : it's quite like the wyvern don't "visualy" move, but it apear like >> it really >> move on the server. (but changes on the pixmap seems to work well : >> wyvern >> sometimes look on the right, and sometimes on the left). I've fixed several problem with big pet monsters - the changes are in CVS. I didn't get any display problems with the changes. >> >> >> And another problem (but it's perhaps a normal behavior) : with "one >> square >> summoned creature", it's possible to go "throught" : you can walk even >> if a pet >> is on your way : it automaticaly go behind you. With Wyvern, it don't >> work : it >> can sometimes block the way. I haven't fixed this - that is more problematic. At issue is that it is pretty easy to know that 2 one spaced objects can swap places. However, for 2 spaced objects, this is much more difficult. Think of the scenario like: WW. |P| |.| Where WW is the wyverns to spaces, P is the player, and | are walls. The wyvern obviously won't fit into the passage, so the swap won't work. But there is also some odd issue like: ----- .PWW. ----- For the player to swap with the wyvern, either the player has to hop two spaces, or the wyvern has to swap two spaces. Now at least the push code does work now, so in that second example, if you move into the wyvern, you should end up pushing him a space to the right. Thus, if your big pet isn't moving down the passage, you can sort of push him there. I'm not sure what to do with this long term. One could certainly make the argument this is a disadvantage of big pet monsters (or the ability to swap places is an advantage with small pet monsters). I looked at the code to do the swap position - it isn't as straight forward - the check to see if space is available sort of needs to be custom written for this - first, you need to see if the space the monster is moving into has a wall, the player, or a piece of the monster. But then you need to check the space the player wants to move into to see if it is free. This gets pretty tricky - in the second case above, all of those would initially seem to check (wyvern would get moved to place player current is and place a peice of it currently is). The player is also trying to move to a piece the wyvern is currently in. However, that space will still be occupied after the wyvern moves. So now you need to do the logic that the player would swap multiple spaces. However, the player should still get effected by any bad things on any of those spaces (eg, pits, spikes, etc). From kf_bulk at excelcia.org Sun Sep 1 20:56:34 2002 From: kf_bulk at excelcia.org (Kurt Fitzner) Date: Thu Jan 13 18:04:28 2005 Subject: [CF List] Player building (was Re: Castles and houses) In-Reply-To: <3D71124E.60209@sonic.net> Message-ID: On 31-Aug-2002 Mark Wedel wrote: > Steven Lembark wrote: >> >> One way to handle people building things where maps to >> is to invoke eminent domain: community projects displace >> deeded ones. > Perhaps. But I think the biggest issue is player makes house, and then > new > maps are added to CVS that are on the place the house is. As Crossfire becomes aimed at a more and more immersive experience and diverts away from Moria, it is encroaching in an area where people have already gone. I've spoken to some of you about this already, but really, Crossfire is becoming a graphical MUSH. MUSHes are text-based role-playing games. They grew out of the old Unix MUD (multi-user-dungeon). The MUD was the text-based equivalent to Moria. Like playing Moria with the interface from Zork. MUSHes grew from this, took the MUD system and changed the paradigm from hack and slash to a more immersive role-playing experience. The MUSH servers became object based. Rooms, players, etc, are all objects in the database. The interesting thing about MUSHes, is that they are constructed in-situ. People install the MUSH server and then dig all the rooms and create all the objects they need for their environment. And once the MUSH opens, construction never stops. What I am hearing (and what I have been encouraging myself) is a move towards more in-situ creation of Crossfire maps and objects. A move to letting the players expand and grow the place. Why do this? Because life is dynamic, and if we want an immersive experience on Crossfire, it should be dynamic too. The MUSH servers support scripting heavily, and players on them can create objects and script them to perform incredibly complex tasks. I've toyed with merging in the code from Pennmush to Crossfire as a plugin simply because of how useful this is. In the end it would be too much work, but I think we can learn a LOT from history and progression of MUSHes. Because this is Crossfire, we are all looking at ways of bulding areas that are automated. Scrolls that do this or that, altars, etc. And this is good, it would add a new element to the game. Building houses is neat. People are right now talking about using this ability to build new quests in-situ. This is great! But with the methods that are being discussed, you'll never be able to take advantage of the real power of crossfire maps. Why? Because most of the interesting things that happen on maps are not in-character constructs. They are behind-the-scenes mechanisms that make things happen. Let's do this, but let's add a new class of player to Crossfire. There would be nothing special about a builder. It would be like a DM, just someone who gets access to new building commands. Let them @dig a new map, @create objects, @set variables, and add scripting code. Anyone who has used a MUSH will recognize those commands. MUSHes have already gone down the road we're walking. Gone from the hack and slash MUDs to the more immersize environment. Let's learn from their example. Once this is done, if a person wants a new house, he ICly (in-character-ly) approaches someone with the authority to offer a house and arranges it. They arrange a price and then someone who is an OOC (out-of-character) builder does the work. Trying to make IC objects that do everything will never give as good a result, because half of what goes into the good maps are not IC constructs. And, as things go, less and less of the map making will involve IC constructs, as scripting becomes more and more the rule rather than the exception. There are a million details to discuss about this. Who has the authority, how is that coded, how can we prevent builder A from altering builder B's stuff, and so forth. These are all details that MUSHes have solved. I'd encourage the development team to look seriously at the MUSH paradigm... download a mush server (www.pennmush.org) look at what they do and how, and then let's see how we can make Crossfire into the same immersive environment. One where the Crossfire maps are only the starting point for the individual server, and where the players and builders grow it from there. The neat thing about this, is that if we then want to make automated systems where people can make houses, then we can. Once the support is in the game for digging maps and better support for creating objects, setting variables, writing scripts, and so forth, then it will be trivial to make systems to create scrolls that do subsets of this sort of thing automagically. But, we'll also have the ability to set up people with @zone authority over a city or region, and let them build houses or dungeons, administer quests, and make the game more fluid. Kurt. From mwedel at sonic.net Mon Sep 2 02:12:43 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:04:28 2005 Subject: [CF List] Re: Improved invis spell and stealing skill broken in newest cvs? References: <200208270501.g7R516M21679@sprite.real-time.com> <29393.1030543505@www12.gmx.net> Message-ID: <3D730F6B.3060105@sonic.net> Erhard Sanio wrote: >>Wyverns have 'see invisible', so its not too surprising invisibility > > doesn't > >>work on them. > > > This ist true, but only for bright rooms, or dark rooms when a fireball, > a torch or something similar is ignited. In dark rooms, wyverns don't > see you when you have improved invisibility (they lack infravision afaik), > so yo may pass or even hit them. This may have been broken before, but it appears the new (as well as old) code was such that if a creature has see invisible, they ignore darkness. Obviously, this portion of the code now works properly. This probably goes on the basis that the creature does not have a magical ability to see invisible, but rather keen senses to hear/smell where you are. > > Well true. That's why improved invis only works on a limited number of > maps. It is a pity anyway that it is brokenr. Well, I tried it on latest CVS and it seemed to work in my limiting testing. But I only tested against wimpy monsters (orcs/goblins). > > Right. Maybe the handful of CF players adapt to the punishment somehow, > the fact remains it hits them, not the network operators. Much worse, > without access to homepage and metaserver it will be hard if not > impossible to motivate new players. I can't really comment on the specifics, as I didn't set up the block - I'm only repeating what I have heard from Bob Tanner on irc (Rick might also have provided information). My understanding is that many sites from the german netblock were performing a DDOS against the real-time sites. This was the cause of the long mail delay a few weeks back. The obvious problem is that without the block, no one can get to the metaserver or other crossfire information. I'd have to say that if I was in a similar situation, I would do the same thing. I'm not sure what a workable solution would be - perhaps the most realistic would be a mirror of the information someplace else. From mwedel at sonic.net Mon Sep 2 02:33:27 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:04:28 2005 Subject: [CF List] The 'dis'economy of crossfire] References: <3D6D8C18.3070101@sonic.net> <20020830115338.62de6d6a.mathwizard@gmx.de> Message-ID: <3D731447.5060507@sonic.net> Christoph Bergemann wrote: > About leveling: There are a few things here. First, it seems indeed to be > a good idea to let level gaps increase more. I think Crossfire is the only > RPG I know in which these gaps are so low, even with experience gained by > killing monsters getting smaller. On the other hand you should remember > that levelling is one of the motivations to keep on playing. If it takes > me an eternity to get from 100 to 101 most people probably wouldn't play > further, which is certainly not our hope. Note that currently, the converse is true - players get to level 110 and say 'whats next to do'. Note that I think the most powerful monsters is worth 2 million? The max gap at high level is still 80 million. That means if you kill one of those, your 1/40th of your way to next level. Yes, it means you need to kill a bunch of those, but probably not so many that it seems completely insurmountable. > About monster experience: I don't think if level gaps are to be increased > monster experience needn't be reduced, though I don't quite understand why > Jessy should give so much more experience than other monsters, as there > are many monsters in the game which I consider much tougher. My dragon can > easily kill Jessy without quaffing potions, yet died last time I tried to > kill a Beelzebub I died, without having any kind of a chance. Demon lords > and Gerater Demons also, if approached from the wrong direction. this is a tricky issue - different race/class combinations find some things much easier/difficult than others. A character that has high natural fire resistance (due to religion, class, and race) will find most fire attacking monsters much easier. Jessy's may be overvalued. But to determine this, we really need input from a variety of players saying 'I find this hard, and this easy', and also get the class/race info from them and try to adjust accordingly. From andi.vogl at gmx.net Mon Sep 2 07:37:48 2002 From: andi.vogl at gmx.net (Andreas Vogl) Date: Thu Jan 13 18:04:28 2005 Subject: [CF List] Player building (was Re: Castles and houses) References: Message-ID: <12425.1030970268@www36.gmx.net> The idea of in-game map development for Crossfire keeps coming up here lately. From my experience with development on the CFJavaEditor (Crossfire map editor) I've got a few things to say on this topic: In-game map development, certainly a cool idea, but how to realize? I'll assume we can rule out the option to merge an entire editor interface into every CF client. In fact, it would be alot easier to merge a client into an editor, given the proportions of complexity. So, how do MUDs deal with the problem? They can be edited with command line. And yes, this concept is successfull, in MUDs. That's because MUDs are text-only, and the object structure in MUDs is usually rather trivial. Can we do the same thing for CF? - NO, definitly not. Crossfire has graphics. It has a very complex object structure and an even more complex arch (/map) syntax. Learning the entire Crossfire arch syntax is about as "easy" as learning Fortran 95, or C++. Don't believe it? Try to write a 10x10 Crossfire map in plain ascii, out of your head, without using a map editor. The map should contain floor, walls and monsters. Impossible, is it? Look at the CFJavaEditor. It is an immensly complex program that does nothing but aiding people to create maps. So they do *not* have to write it in plain ascii. And still, even with all that help and those interface-gizmos, most people find it difficult enough. Believe me, a command-line editor for Crossfire maps is outright impossible. I mean you can create one, sure, but it won't work. AndreasV -- GMX - Die Kommunikationsplattform im Internet. http://www.gmx.net From andi.vogl at gmx.net Mon Sep 2 08:38:03 2002 From: andi.vogl at gmx.net (Andreas Vogl) Date: Thu Jan 13 18:04:28 2005 Subject: [CF List] The 'dis'economy of crossfire References: <3D731447.5060507@sonic.net> Message-ID: <13801.1030973883@www36.gmx.net> Christoph Bergemann wrote: > [...] you should remember that levelling is one of the > motivations to keep on playing. Exactly. And this is also the reason why we so much need to increase the level gaps. A maxed-out player lacks motivation to keep on playing. We lenghthen the process, so people can enjoy the game for a longer time. > If it takes me an eternity to get from 100 to 101 most people > probably wouldn't play further, which is certainly not our hope. First, as Mark said: It won't take an eternity. Even if it did take too long, we could balance it by creating high-level maps/monsters with more experience in them. I'd estimate that this will hardly be necessary though. Second, aside from leveling, there's also the aspect of players improving their equipment. This will not be spoiled in any way, but rather get better: There is more time to look for low/medium equipment before your level is so high that all you need and want is the top stuff. > About monster experience: I [don't ?] think if level gaps are to be > increased monster experience needn't be reduced, [...] In my opinion the amounts of monster's exp is not terribly broken, it is just the level gaps being too low. Of course not all monsters have balanced exp, but a lot depends how those monsters are put in the maps. A trapped Jessy placed at the entrance of a map is certainly way too easy to kill for 2 million exp. OTOH, in "wiztower" or "nine gates of hell", the Jessys are placed after a long line of other monsters. So the experience from the Jessys is like a reward for getting there. Mark's point about different races/classes applies as well. After all, I feel we have a common consens for increasing the experience gaps. I am totally convinced that it would improve the game. Unfortunately, a few players will sure be upset when overnight their level has decreased. :-) Neverthless, IMHO we should do it. We do it with the best intentions and the change will pay off in the long run. AndreasV -- GMX - Die Kommunikationsplattform im Internet. http://www.gmx.net From lembark at wrkhors.com Mon Sep 2 09:18:34 2002 From: lembark at wrkhors.com (Steven Lembark) Date: Thu Jan 13 18:04:28 2005 Subject: [CF List] The 'dis'economy of crossfire] In-Reply-To: <3D731447.5060507@sonic.net> References: <3D6D8C18.3070101@sonic.net> <20020830115338.62de6d6a.mathwizard@gmx.de> <3D731447.5060507@sonic.net> Message-ID: <437490000.1030976314@[192.168.200.4]> -- Mark Wedel > Jessy's may be overvalued. But to determine this, we really need input > from a variety of players saying 'I find this hard, and this easy', and > also get the class/race info from them and try to adjust accordingly. Also has a lot to do with knowing what the monster is vulnerable to. Once you know ball lightning many otherwise difficult areas become a simple matter of zapping everything inside from a safe distance. -- Steven Lembark 2930 W. Palmer Workhorse Computing Chicago, IL 60647 +1 800 762 1582 From temitchell at sympatico.ca Mon Sep 2 14:52:05 2002 From: temitchell at sympatico.ca (Todd Mitchell) Date: Thu Jan 13 18:04:28 2005 Subject: [CF List] The 'dis'economy of crossfire References: <3D731447.5060507@sonic.net> <13801.1030973883@www36.gmx.net> Message-ID: <002901c252ba$370d2c00$0a02a8c0@kameria> Andreas Vogl wrote: > Christoph Bergemann wrote: > > > [...] you should remember that levelling is one of the > > motivations to keep on playing. > > Exactly. And this is also the reason why we so much need to > increase the level gaps. A maxed-out player lacks motivation > to keep on playing. We lenghthen the process, so people can > enjoy the game for a longer time. > I say : Amen to this. > > Second, aside from leveling, there's also the aspect of > players improving their equipment. This will not be spoiled > in any way, but rather get better: There is more time > to look for low/medium equipment before your level is so > high that all you need and want is the top stuff. > Testify brother. More players will increase their weapons and armour if they know they won't have outgrown it or found something better in a few hours playtime. > > About monster experience: I [don't ?] think if level gaps are to be > > increased monster experience needn't be reduced, [...] > > In my opinion the amounts of monster's exp is not terribly > broken, it is just the level gaps being too low. > I don't think we should get off this easy - monster xp might not be too bad and changing the xp tables is great fix for the game but there is still some tweeking that needs to be done. 'dis'economy isn't just a money problem and removing money isn't the answer, neither is jacking up the prices or adding in big ticket items- the answer lies between. I really think it is a problem that you can buy skill scrolls like magic and praying with the proceeds of just one random treasure room in a level 4 or 5 map. This contributes to the inflated speed of xp gain as well. I understand one of the great pieces of the game is the ability to grow your character, but by level 15 you could have picked up the majority of skills and where is the character growth then? Everyone starts looking a lot like everyone else and playing the same way (cast a spell, do some praying, big sword, nasty armour...). Dito for permenant stat increasing. Since you can keep 'rolling' stats until you get them quite high, then you add racial modifiers - you can max out your stats very quickly. These things should be the result of some pretty major adventuring (either in cost or better yet in questing). Of course your level 60 character will be quite well rounded, but at level 12? It kinda takes some of the fun out of it. It also hurts the multi player aspect since everyone is a one man show. Some of the magic items you can buy in shops seem a bit on the cheap side as well - you have level 7 players saying 'geez I guess I'll pick up that ring of combat and that amulet of reflection since I have the spare change and maybe a few dozen spell books for later on". Changing these things makes it harder on the new guys - but hey the most fun I have had has been that hard grind to level 15. (and yes I did buy whatever I could to expand my abilities rather than role-play my class). Changes like this also would require map changes and new maps - it would be a long haul - it will never get perfected (but it could be better right?) - people will cheat and trick their way around it - that's part of the fun too. From temitchell at sympatico.ca Mon Sep 2 15:54:29 2002 From: temitchell at sympatico.ca (Todd Mitchell) Date: Thu Jan 13 18:04:29 2005 Subject: [CF List] castles and guilds Message-ID: <002d01c252c2$eec64720$0a02a8c0@kameria> I am surprised no one has commented on ongoing costs for guilds. I think this is a good idea, not so much for taking money out of the game as for building community. The need for a shared semi-permanent space is obvious by the rousing commentary about castles - and as in real life every one wants to carve out their own place and show it off. Guilds are nice but I expect they are a bit too communal to satisfy that territory urge. I think if you have castles people will forgo the guilds pretty quickly. Especially if the castles have all sorts of perks like charging rooms and banks and smithies. I would like to see this sort of thing avoided for castles and have them stick to more homey kind of perks to obtain like display cases and servants and extra levels (perhaps even a random dungeon below?) and portals. I can invision a variety of houses from a small keep to a large castle with creators for things like servants and guards, display cases, additional levels, guardian beasts (for show), portals and other permanent furniture. I am not too keen on having these structures available to thieves - it seems like that idea might look good but I expect it would be pretty unpopular in practice, not to mention throw the game out. I suspect that some thieving will occur at any rate as people are always looking for exploitable 'features' in the game. Now guilds with the charging room and other perks such as discount smithies, private money exhange, discount item repair shops they do/could become more like a private club. Of course for these things it would be good to have an ongoing costs to belong. The best way to do this AND grow a guild mentality is to have ongoing costs for the founders. Leave it up to them to come up with the cash - and they will organize membership drives and chase down debtors. The current price for a guild is not enough to make it more than an exclusive club. If the costs had to be defrayed however there would be incentive to get more members. Perhaps a guild bank account could be created and guild founders could have some way to add or remove players from the member list and allow or bar access. You could also skim off the top for services so that the more people use them the less the overall cost becomes. I have almost finished a template for a mid sized keep and look forward to making some other similar structures and improvements to the guild houses (some of those names are a bit fluffy for my taste). Finding the java editor was fantastic - and humbling when I found out how long it took to build something that worked properly (not just looked nice) - even with this powerful tool. One of the first things I made on my server was a 'club house' - before guilds were available - so I know it is a popular idea. I just think it would be simpler and faster to use the tools already available for designing these structures and perhaps spend the effort on other system enhancements to make them work well in the game (like guild banks and castle taxes). I can see the attraction for building (I was enthralled by the Post Modern MOO a long time ago) but think it a bit excessive for crossfire when there is such a good tool for creating maps and such a derth of new maps being made and submitted. Also, there is a huge need for cataloging and automating the documentation of the existing items in the game, that an ingame editor would just make huge problems right now. I think that improvements to the arch collection and the documentation (in game as books and out game as documentation) would be a good first step in the direction (I mean dm's can create lots of stuff, but you still need to know how specify what to create.) I can even see a 'deed' that will create a pre-made structure somewhere on the map - but to have people digging out maps all over seems to be somewhere way way way over the horizon. I seem to have exceeded my two cents here... -tm -------------- next part -------------- An HTML attachment was scrubbed... URL: http://shadowknight.real-time.com/pipermail/crossfire/attachments/20020902/041b9e7c/attachment.htm From mwedel at sonic.net Mon Sep 2 15:54:37 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:04:29 2005 Subject: [CF List] Player building (was Re: Castles and houses) References: <12425.1030970268@www36.gmx.net> Message-ID: <3D73D00D.2060007@sonic.net> Andreas Vogl wrote: > Believe me, a command-line editor for Crossfire maps is > outright impossible. I mean you can create one, sure, > but it won't work. If 'in map' design was really desirable, it would probably make more sense to add a facility for players to to be able to upload maps. How you charge the players for those maps get tricky. Presumably, this feature would only be available to wiz players or the like. Of course, why go to that effort of doing it in game? Why not just say 'make a map with the editor, and send it to ...' Your point was one reason why I suggested that if you buy a house, it at least has the basic layout (walls, staircases, etc), as doing those with in game gets tricky. While I think it may be somewhat possible to make a basic interface to create maps, I have a feeling that anyone using it would get quickly frustrated. I have a feeling that we have gotten caught in creeping features to this idea. The original idea of people being able to buy residences isn't that hard to implement. The idea to allow some customizations isn't very hard easier. But the idea of being able to create an entire map becomes much more complicated. IMO, this is mostly because of what details a properly made dungeon needs - monsters, treasures, items, gates, buttons, etc, which require trickier support - in many cases, much trickier. That is probably one major difference between MUDS and crossfire - as said, MUDS are created from the inline tools, as the layout can pretty easily be abstracted, and being able to 'merge in' dungeons may be tricky. Crossfire is very different - each map is largely standalone. As has been seen, if a user can design some maps, and except for the linking into the other maps to make them accessible, these maps don't need/rely on any other maps in any way. From mathwizard at gmx.de Mon Sep 2 16:05:04 2002 From: mathwizard at gmx.de (Christoph Bergemann) Date: Thu Jan 13 18:04:29 2005 Subject: [CF List] The 'dis'economy of crossfire In-Reply-To: <002901c252ba$370d2c00$0a02a8c0@kameria> References: <3D731447.5060507@sonic.net> <13801.1030973883@www36.gmx.net> <002901c252ba$370d2c00$0a02a8c0@kameria> Message-ID: <20020902230504.01f0efb2.mathwizard@gmx.de> Hi, Ok, I agree to the idea of increasing level gaps. Though the discussion is becoming a bit offtopic I think it is kind of useless that a player can get every skill just by buying a scroll. Remember that a lot of work would have to be done to become a magician, yet this can be learned from just a scroll without taking any time - from the hero's virtual viewpoint. One obvious way would be to allow a hero to learn just one skill per level (if his level should be 110 maybe every few million exp), which would then be attained at the end of that level. Somewhat similar to the way in which ancient para elemental's residues change a dragon's metabolism. This would make low level players think of what skill they should learn at their actual level and prevent level 10 players having every skill. I imagine this might be a not too difficult to implement first solution. A better solution would on the long run be to introduce some guilds for the various professions. There might for example be the alchemists' guild, which one can join for some fee (higher than scroll price), thereby attaining the rank of an apprentice of alchemy. Now he might have to fulfill some quests - maybe like the castle Scorn quests - to rise the guild and learn some skills (to be introduced) related to alchemy. A player might be locked from joining into other guilds while he has only some low rank in another (like he can be apprentice of only one guild at a time). Regards, Christoph Bergemann -- "Do not meddle in the affairs of Wizards, for they are subtle and quick to anger." From jsegarraf at terra.es Tue Sep 3 06:33:33 2002 From: jsegarraf at terra.es (Juan Segarra) Date: Thu Jan 13 18:04:29 2005 Subject: [CF List] Player building (was Re: Castles and houses) References: <12425.1030970268@www36.gmx.net> <3D73D00D.2060007@sonic.net> Message-ID: <3D749E0D.9070406@terra.es> Mark Wedel wrote: > [...] > If 'in map' design was really desirable, it would probably make more > sense to add a facility for players to to be able to upload maps. > [...] I agree with this, and also think that creating things anywhere could be quite chaotic. Even "unstable" if you get caugth on some maps without exits or something like that. I would prefer the initial idea of a castle. Why don't just use the castle of scorn for that? A simple way could be, for example, moving the hall of quests to the entrance of the castle stronhold (something like the access to the port). Then, adding also grates, a guy could say "people in scorn is looking for a new king, only who passes all the quests will have that honour"... Thus, only "kings" could enter the castle zone, and there could be constructed the "building area". This could be an initial test for all this stuff. -- Juan Segarra From andi.vogl at gmx.net Tue Sep 3 07:22:56 2002 From: andi.vogl at gmx.net (Andreas Vogl) Date: Thu Jan 13 18:04:29 2005 Subject: [CF List] castles and guilds References: <002d01c252c2$eec64720$0a02a8c0@kameria> Message-ID: <9201.1031055776@www11.gmx.net> > I am surprised no one has commented on ongoing costs > for guilds. It's certainly a good idea and I don't think many people (if anyone) would object to guilds being more costly. The point about an ongoing cost (tax?) system is it nees some special code and simply somebody has to do that work. > I think this is a good idea, not so much for taking > money out of the game as for building community. [...] > I would like to see [...] homey kind of perks to obtain > like display cases and servants and extra levels (perhaps > even a random dungeon below?) and portals. I can invision > a variety of houses from a small keep to a large castle > with creators for things like servants and guards, display > cases, additional levels, guardian beasts (for show), portals > and other permanent furniture. All of these ideas are very nice. I'm not sure how exactly you envision to realize them, but I think you could create much of that without the need for real game/code-changes. You could extend the existing guild houses, or add new ones. Raise the prices, add new rooms, always charging a good fee of course. Even the guardian beast idea could be realized with a few teleporters and stuff. The big advantage about this is you could do it right away. > I am not too keen on having these structures available > to thieves [...] I completely agree. This can cause much more trouble than it's worth. > [...] Of course for these things it would be good to have > an ongoing costs to belong. The best way to do this AND > grow a guild mentality is to have ongoing costs for the > founders. Fees for guilds could really work out fine. Unfortunately, it is very difficult to implement IMO, and the real impact on the CF economy is probably small. So, the main problem might just be motivating somone to code this fee system... ;-) Maybe just having many "expanding-features" for sale inside the guild houses would do well enough? The price can be insane high, so that players really have to work a while in order to afford it. > I have almost finished a template for a mid sized keep > and look forward to making some other similar structures > and improvements to the guild houses Well, this sounds good... :-) Thanks a lot for your compliments about the JavaEditor btw. Andreas -- GMX - Die Kommunikationsplattform im Internet. http://www.gmx.net From huet.o at free.fr Tue Sep 3 15:22:07 2002 From: huet.o at free.fr (Olivier HUET) Date: Thu Jan 13 18:04:29 2005 Subject: [CF List] strange comportments with large creature summoning References: <1027713028.3d41a80456ecb@imp.free.fr> <3D44C55B.4070000@sonic.net> <3D71B7C8.80708@sonic.net> Message-ID: <000501c25387$c16f9180$0101a8c0@grosgede> Hello, > Mark Wedel wrote: > I've fixed several problem with big pet monsters - the changes are in CVS. > I didn't get any display problems with the changes. > Thanks ! I didn't get any display problem too. > >> > >> > >> And another problem (but it's perhaps a normal behavior) : with "one > >> square > >> summoned creature", it's possible to go "throught" : you can walk even > >> if a pet > >> is on your way : it automaticaly go behind you. With Wyvern, it don't > >> work : it > >> can sometimes block the way. > > I haven't fixed this - that is more problematic. > > At issue is that it is pretty easy to know that 2 one spaced objects can swap > places. > > However, for 2 spaced objects, this is much more difficult. Think of the > scenario like: > > WW. > |P| > |.| > > Where WW is the wyverns to spaces, P is the player, and | are walls. The > wyvern obviously won't fit into the passage, so the swap won't work. But there > is also some odd issue like: > > ----- > .PWW. > ----- > > For the player to swap with the wyvern, either the player has to hop two > spaces, or the wyvern has to swap two spaces. > > Now at least the push code does work now, so in that second example, if you > move into the wyvern, you should end up pushing him a space to the right. Thus, > if your big pet isn't moving down the passage, you can sort of push him there. > > I'm not sure what to do with this long term. One could certainly make the > argument this is a disadvantage of big pet monsters (or the ability to swap > places is an advantage with small pet monsters). > > I looked at the code to do the swap position - it isn't as straight forward - > the check to see if space is available sort of needs to be custom written for > this - first, you need to see if the space the monster is moving into has a > wall, the player, or a piece of the monster. But then you need to check the > space the player wants to move into to see if it is free. > > This gets pretty tricky - in the second case above, all of those would initially > seem to check (wyvern would get moved to place player current is and place a > peice of it currently is). The player is also trying to move to a piece the > wyvern is currently in. However, that space will still be occupied after the > wyvern moves. So now you need to do the logic that the player would swap > multiple spaces. However, the player should still get effected by any bad > things on any of those spaces (eg, pits, spikes, etc). > > For this second problem, reading your drawing and descriptions, I think it's perhaps more logic to keep the push system you write. But the lack of swapping can sometime really block, with, for example, this map : (P is the player, G is the ground and W is the Wivern) --------- |PWW| |GWW| ------|G| (It can apear, for example, where there is stairs under P) You would like to go to the exit on the bottom-right, and the wyvern is blocking you... In this case, swapping would work fine, but if the ground on the bottom-left where a wall, you where really blocked. So I had an idea that could work around, and that could be helpfull elswhere : What do you think of a command, a spell, a saying, a skill or something else to "Banish" your pets : --> so when you don't need anymore a pet, you could get out of it. --> so when a pet is blocking your way, you could get out of it too. Yes I know you can kill it, but it's perhaps not really a good idea to be forced to kill a pet when it has well helped you and you don'need it anymore... What do you thing of something like that ??? Olivier. From temitchell at sympatico.ca Tue Sep 3 15:18:05 2002 From: temitchell at sympatico.ca (Todd Mitchell) Date: Thu Jan 13 18:04:29 2005 Subject: [CF List] castles and guilds References: <002d01c252c2$eec64720$0a02a8c0@kameria> <9201.1031055776@www11.gmx.net> Message-ID: <001401c25387$041d13a0$0802a8c0@ott.ca.dmr> > > I think this is a good idea, not so much for taking > > money out of the game as for building community. [...] > > I would like to see [...] homey kind of perks to obtain > > like display cases and servants and extra levels (perhaps > > even a random dungeon below?) and portals. I can invision > > a variety of houses from a small keep to a large castle > > with creators for things like servants and guards, display > > cases, additional levels, guardian beasts (for show), portals > > and other permanent furniture. > > All of these ideas are very nice. I'm not sure how > exactly you envision to realize them, but I think you > could create much of that without the need for real > game/code-changes. Actually ALL of these design ideas I can currently do with the CFJavaEditor. I have a four level keep (six maps counting the grounds and the roof) and just have to find time to add in the guards, servants, a few more perks here and there and set the altars and test it out. I started it before the guilds were introduced, as a club house for my players (the Royal Order of Kameria) but incorporated/expanded a lot of what I saw on the guild maps - but with a different focus. The only need for code changes for castles would be to automate placing the castles and changing the keys and exits to work. Since this can be gotten around by running the maps files through a find and replace and dropping a bunch around the world maps for the meanwhile - castles can be done pretty fast. - this was my point. No need to wait/hope for a in game editor. I could have something polished up in a week or so. Biggest pain is setting the prices for things (how much for castle, for each extra floor, for a guard, for a fancy doodad...should make some things quest items instead of cash...) > You could extend the existing guild houses, or add new ones. > Raise the prices, add new rooms, always charging a good fee > of course. Even the guardian beast idea could be realized > with a few teleporters and stuff. > The big advantage about this is you could do it right away. Exactly. > Fees for guilds could really work out fine. > Unfortunately, it is very difficult to implement IMO, > and the real impact on the CF economy is probably small. > So, the main problem might just be motivating > somone to code this fee system... ;-) Ya but I think there is something in python that has been done which could be extended for this. I am going to look at the stuff Joris Bontje has done since it sounds promising- but my coding abilities are sparse still. It can wait a bit - better not to rush things- still a lot of conversation to do on this. It would be a lot easier to do this than to build an in game editor however and the posts were flying around already about taxes and banks and scroll to build castles and stuff. Anyway this message was more a philosophical one about creating differences between guilds and castles. I was won over about the pain for gain arguments and personal taxes and dont' like the idea anymore, but do think that there are some things shouldn't be sold outright (like a guild) - but which should come with an ongoing burden of upkeep. It won't fix the economy but it would provide some community atmosphere and add some goals if you go for that sort of thing. > Maybe just having many "expanding-features" for sale > inside the guild houses would do well enough? > The price can be insane high, so that players really > have to work a while in order to afford it. Yes, this will certainly suffice for now. I can see jacking up the price for guilds as a good first start. (I have one player who has footed the bill for an entire guild - roping in two others just to stand on the platforms - and solved almost all the addon features already and only took him a couple weeks of playing. This illustrates the problem I think. -tm From mathwizard at gmx.de Tue Sep 3 14:52:16 2002 From: mathwizard at gmx.de (Christoph Bergemann) Date: Thu Jan 13 18:04:29 2005 Subject: [CF List] castles and guilds In-Reply-To: <9201.1031055776@www11.gmx.net> References: <002d01c252c2$eec64720$0a02a8c0@kameria> <9201.1031055776@www11.gmx.net> Message-ID: <20020903215216.26dc49c7.mathwizard@gmx.de> Hi, > Fees for guilds could really work out fine. > Unfortunately, it is very difficult to implement IMO, > and the real impact on the CF economy is probably small. > So, the main problem might just be motivating > somone to code this fee system... ;-) I would, if I could code. But maybe if somebody helped me via IRC - somewhere in Europe possibly for reasons of time - I might learn. > Thanks a lot for your compliments about the JavaEditor btw. Though being completely OT, my JRE doesn't seem to support .jar files (using Linux and got java 1.1.8 and jre1.3.1), what is wrong? (Cannot use JavaEditor therefore) Regards, Christoph Bergemann -- "Do not meddle in the affairs of Wizards, for they are subtle and quick to anger." From mwedel at sonic.net Tue Sep 3 23:09:23 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:04:29 2005 Subject: [CF List] strange comportments with large creature summoning References: <1027713028.3d41a80456ecb@imp.free.fr> <3D44C55B.4070000@sonic.net> <3D71B7C8.80708@sonic.net> <000501c25387$c16f9180$0101a8c0@grosgede> Message-ID: <3D758773.6030904@sonic.net> Olivier HUET wrote: > For this second problem, reading your drawing and descriptions, I think > it's perhaps more logic to keep the push system you write. > > But the lack of swapping can sometime really block, with, for example, this > map : > > (P is the player, G is the ground and W is the Wivern) > --------- > |PWW| > |GWW| > ------|G| > > (It can apear, for example, where there is stairs under P) > > You would like to go to the exit on the bottom-right, and the wyvern is > blocking you... > In this case, swapping would work fine, but if the ground on the bottom-left > where a wall, you where really blocked. There are certainly many cases where swapping would work with big monsters - especially monsters that are 1x2 or 2x1. It's just doing the necessary checking for such cases would get quite tricky. > What do you think of a command, a spell, a saying, a skill or something else > to "Banish" your pets : > --> so when you don't need anymore a pet, you could get out of it. > --> so when a pet is blocking your way, you could get out of it too. > > Yes I know you can kill it, but it's perhaps not really a good idea to be > forced to kill a pet when it has well helped you and you don'need it > anymore... I'm presuming when you banish your creature, it just disappears? I see no reason not to add such a command - it would be easy enough to do - especially if a banish got rid of all your pets. It could also be useful when your gone from the dungeon and are back in town - may not need your pets anymore, but having them dance around you can be annoying. From andi.vogl at gmx.net Wed Sep 4 02:26:53 2002 From: andi.vogl at gmx.net (Andreas Vogl) Date: Thu Jan 13 18:04:29 2005 Subject: [CF List] JavaEditor JRE problem (was RE: castles and guilds) References: <20020903215216.26dc49c7.mathwizard@gmx.de> Message-ID: <13223.1031124413@www41.gmx.net> Christoph Bergemann wrote: > Though being completely OT, my JRE doesn't seem to support .jar files > (using Linux and got java 1.1.8 and jre1.3.1), what is wrong? > (Cannot use JavaEditor therefore) I can't be sure, but I suspect the java version 1.1.8 somehow gets executed when you attempt running the jar. 1.1.8 is of course too old and wouldn't get the editor running in any case. Hence, what you may try first is execute the jar with the full path to jre1.3.1. Like this: > /usr/.../java/jre1.3.1/bin/java -jar CFJavaEditor.jar Java runtime environment 1.3 should always "support" jar files and get the editor running. I for myself have been using the editor in linux with java 1.3 for a good while. In case your version of the CFJavaEditor itself is not current, it can't hurt the update that one and try again, even though this will most likely not be the source of your problem. See . If that fails, you should try to download and install a full java environment of version 1.4 (or 1.3 if that is easier for some reason). See . You can replace the 1.1.8 version by the new downloaded version. If you manage to do that, I'd be most surprised if it still doesn't work. In case you have troubles with the java installation you can ask for support on IRC in one of the linux- or java-help channels. If you prefer the #crossfire channel you probably will find help there too. AndreasV -- GMX - Die Kommunikationsplattform im Internet. http://www.gmx.net From olle at viksten.com Wed Sep 4 04:15:15 2002 From: olle at viksten.com (Olle Viksten) Date: Thu Jan 13 18:04:29 2005 Subject: [CF List] JavaEditor JRE problem (was RE: castles and guilds) In-Reply-To: <13223.1031124413@www41.gmx.net> References: <20020903215216.26dc49c7.mathwizard@gmx.de> <13223.1031124413@www41.gmx.net> Message-ID: <200209041115.15452.olle@viksten.com> onsdagen den 4 september 2002 09.26 skrev Andreas Vogl: > If that fails, you should try to download and install a full > java environment of version 1.4 (or 1.3 if that is easier for > some reason). See . > You can replace the 1.1.8 version by the new downloaded version. > If you manage to do that, I'd be most surprised if it still doesn't work. > In case you have troubles with the java installation you > can ask for support on IRC in one of the linux- or java-help > channels. If you prefer the #crossfire channel you probably > will find help there too. I had trouble with the java editor until I installed the latest java from Sun. Now it works just fine. To avoid the hassle of all the typing I made this small script and save it as jcrossedit. -------- #/bin/bash cd /usr/local/CFJavaEditor /usr/lib/SunJava2-1.3.1/bin/java -jar CFJavaEditor.jar ---- Change the paths according to your setup. Olle -- MicroSoft Network may not carry this message without license to do so. License to carry this message requires a fee of $1000, payable within 30 days to Olle Viksten. Appearance of this message on MicroSoft Network constitutes an agreement to terms. From huet.o at free.fr Wed Sep 4 05:37:03 2002 From: huet.o at free.fr (huet.o@free.fr) Date: Thu Jan 13 18:04:29 2005 Subject: [CF List] strange comportments with large creature summoning In-Reply-To: <3D758773.6030904@sonic.net> References: <1027713028.3d41a80456ecb@imp.free.fr> <3D44C55B.4070000@sonic.net> <3D71B7C8.80708@sonic.net> <000501c25387$c16f9180$0101a8c0@grosgede> <3D758773.6030904@sonic.net> Message-ID: <1031135823.3d75e24f101bc@imp.free.fr> En r?ponse ? Mark Wedel : > I'm presuming when you banish your creature, it just disappears? > Yes, it's exactly what I was thinking. > I see no reason not to add such a command - it would be easy enough to > do - > especially if a banish got rid of all your pets. It could also be > useful when > your gone from the dungeon and are back in town - may not need your pets > > anymore, but having them dance around you can be annoying. Yes, I see no reason to banish only one pet : to banish all your pet at a time would be usefull in lots of cases. -- Olivier. From mathwizard at gmx.de Wed Sep 4 06:28:22 2002 From: mathwizard at gmx.de (Christoph Bergemann) Date: Thu Jan 13 18:04:29 2005 Subject: [CF List] JavaEditor JRE problem (was RE: castles and guilds) In-Reply-To: <13223.1031124413@www41.gmx.net> References: <20020903215216.26dc49c7.mathwizard@gmx.de> <13223.1031124413@www41.gmx.net> Message-ID: <20020904132822.25bdf5a7.mathwizard@gmx.de> Hi, thanks, got it working now! Looks fine, when I'm back from school I will probably try it a bit more. I am using these Java versions because my $#?!@ distro provided them and the online update did not exactly return newer versions (tried it when it failed for the first time). Thanks, Christoph Bergemann -- "Do not meddle in the affairs of Wizards, for they are subtle and quick to anger." From mwedel at sonic.net Sat Sep 7 16:40:19 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:04:29 2005 Subject: [CF List] strange comportments with large creature summoning References: <1027713028.3d41a80456ecb@imp.free.fr> <3D44C55B.4070000@sonic.net> <3D71B7C8.80708@sonic.net> <000501c25387$c16f9180$0101a8c0@grosgede> <3D758773.6030904@sonic.net> <1031135823.3d75e24f101bc@imp.free.fr> Message-ID: <3D7A7243.6050309@sonic.net> huet.o@free.fr wrote: > > Yes, I see no reason to banish only one pet : to banish all your pet at a time > would be usefull in lots of cases. Added to CVS - command is 'killpets'. From huet.o at free.fr Mon Sep 9 15:35:17 2002 From: huet.o at free.fr (Olivier HUET) Date: Thu Jan 13 18:04:30 2005 Subject: [CF List] strange comportments with large creature summoning References: <1027713028.3d41a80456ecb@imp.free.fr> <3D44C55B.4070000@sonic.net> <3D71B7C8.80708@sonic.net> <000501c25387$c16f9180$0101a8c0@grosgede> <3D758773.6030904@sonic.net> <1031135823.3d75e24f101bc@imp.free.fr> <3D7A7243.6050309@sonic.net> Message-ID: <000001c25842$0e209f60$0101a8c0@grosgede> ----- Message d'origine ----- De : "Mark Wedel" ? : Envoy? : samedi 7 septembre 2002 23:40 > > Added to CVS - command is 'killpets'. > Thanks, it's great ! But since your last checkin (this one), there is a problem with monsters : They don't attack you at all !!! You can attack them all you want, they won't punch you ;o) -- Olivier. From mwedel at sonic.net Tue Sep 10 00:44:05 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:04:30 2005 Subject: [CF List] strange comportments with large creature summoning References: <1027713028.3d41a80456ecb@imp.free.fr> <3D44C55B.4070000@sonic.net> <3D71B7C8.80708@sonic.net> <000501c25387$c16f9180$0101a8c0@grosgede> <3D758773.6030904@sonic.net> <1031135823.3d75e24f101bc@imp.free.fr> <3D7A7243.6050309@sonic.net> <000001c25842$0e209f60$0101a8c0@grosgede> Message-ID: <3D7D86A5.7040706@sonic.net> Olivier HUET wrote: > ----- Message d'origine ----- > De : "Mark Wedel" > ? : > Envoy? : samedi 7 septembre 2002 23:40 > >> Added to CVS - command is 'killpets'. >> > > > > Thanks, it's great ! > > > But since your last checkin (this one), there is a problem with monsters : > They don't attack you at all !!! > You can attack them all you want, they won't punch you ;o) Now fixed - had a typo in the code. From quinet at gamers.org Tue Sep 10 04:34:26 2002 From: quinet at gamers.org (Raphaël Quinet) Date: Thu Jan 13 18:04:30 2005 Subject: [CF List] strange comportments with large creature summoning In-Reply-To: <3D758773.6030904@sonic.net> References: <1027713028.3d41a80456ecb@imp.free.fr> <3D44C55B.4070000@sonic.net> <3D71B7C8.80708@sonic.net> <000501c25387$c16f9180$0101a8c0@grosgede> <3D758773.6030904@sonic.net> Message-ID: <20020910113426.2ccf5ebc.quinet@gamers.org> On Tue, 03 Sep 2002 21:09:23 -0700, Mark Wedel wrote: > There are certainly many cases where swapping would work with big monsters - > especially monsters that are 1x2 or 2x1. It's just doing the necessary checking > for such cases would get quite tricky. I just thought about another way to solve this problem: instead of forcing the player to banish the pets when they are blocking the way and they cannot be pushed, why couldn't they disappear for a while? The summoned monsters appear out of nowhere. They could probably make some round-trips to this nowhere and come back a bit later. Here is how it would work: when a player tries to move towards a square that is occupied by a pet, try to see if the pet can move out of the way. If not, then remove the pet from the map and insert it in a list of pets that are waiting to re-materialize. After a few game ticks and/or when the player moves, the list is checked and one or more monsters from that list are put back into the map. The same list of "pets that should come back" can be used for the monsters that were blocking the player and for those that have to come back after the player enters a different map. -Rapha?l From huet.o at free.fr Sat Sep 14 19:08:18 2002 From: huet.o at free.fr (Olivier HUET) Date: Thu Jan 13 18:04:30 2005 Subject: [CF List] strange comportments with large creature summoning References: <1027713028.3d41a80456ecb@imp.free.fr><3D44C55B.4070000@sonic.net><3D71B7C8.80708@sonic.net><000501c25387$c16f9180$0101a8c0@grosgede><3D758773.6030904@sonic.net> <20020910113426.2ccf5ebc.quinet@gamers.org> Message-ID: <005701c25c4c$00008860$0101a8c0@grosgede> ----- Message d'origine ----- De : "Rapha?l Quinet" ? : Envoy? : mardi 10 septembre 2002 11:34 Objet : Re: [CF List] strange comportments with large creature summoning > I just thought about another way to solve this problem: instead of > forcing the player to banish the pets when they are blocking the way > and they cannot be pushed, why couldn't they disappear for a while? > I think it would be problematic too : see this case : P is the player M is monsters W is a pet -------------------------------------------------- PWWMMMM WWMMMM ----------------------------------------------- And now, imagine you accidentaly press the right key : your pet will disapear, and perhaps reapear few second after.... Generaly, pets are usefull to protect you, so in this case, it's better that the pet stay here to continue protecting you. And the other solution have a great advantage : the new command killpets is very usefull elsewhere ! Pets are generaly usefull only for a while : when monsters are hard or specials. After, they sometimes do something you don't want, so at this time, it's great to be able to kill them. -- Olivier. From mwedel at sonic.net Sun Sep 15 01:22:41 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:04:30 2005 Subject: [CF List] Crossfire 1.4.0 released Message-ID: <3D842731.8060709@sonic.net> Crossfire 1.4.0 has been released. The main change is the use of automake. The addition of abstracting body locations for equipment is included - this allwos for finer granularity in controlling what different races can put on. The experience for different levels is now moved to a configuration file, making it easier to tune the differeing values. There are also lots of bugfixes. NOTE: With the automake changes, the location of the configuration files has changed. See the NEWS file in the server directory. I packed up gnuzip (.gz) versions of the files. Looking at the download stats on sourceforge, these are more popular, and for the most part, are not that much larger than the .bz2. Only doing one such method also makes it easier on me to distribute the files. Files released for this version: sums (bsd) filename 61293 1464 crossfire-1.4.0-arch.tar.gz 63480 4523 crossfire-1.4.0-maps.tar.gz 21772 3477 crossfire-1.4.0.tar.gz 13017 394 crossfire-client-1.4.0.tar.gz 11454 1304 crossfire-client-images-1.4.0.tar.gz 06374 253 crossfire-client-sounds-1.4.0.tar.gz Sums (md5) 5df9f8981afdd4e6c174b49e8e3c0db2 crossfire-1.4.0-README dd54ea16b98d0bb95a6ed176e0046013 crossfire-1.4.0-arch.tar.gz 788381affd5b29d6601dd4371314bb80 crossfire-1.4.0-maps.tar.gz 999b7a1a678e8ffa075fed45545a6ef6 crossfire-1.4.0.tar.gz 6ab310b8d2ea80e7fae246775dc819e2 crossfire-client-1.4.0.tar.gz 7b8ea870de491cf5070f05ae876bcbf2 crossfire-client-images-1.4.0.tar.gz 1b33401d9d2af0d391fee7ad04282cfd crossfire-client-sounds-1.4.0.tar.gz crossfire-client-1.4.0 is the client (X11) distribution - standard X11 and gtk interfaces are provided. A major bug related to image caching is fixed. Better handling of configuration options was done. Stat bars can now be drawn in graduated colors. crossfire-client-images.1.4.0.tar.gz is a prebuilt image file for the client - downloading this file will reduce the amount of download that needs to happen during play if the -cache option is used. This file should be untarred in the ${prefix}/share/crossfire-client directory, where ${prefix} is the --prefix option given when configure is run. The default path is /usr/local/share/crossfire-client/. crossfire-client-sounds-1.4.0.tar.gz contains sound files for the client. The change was to increase the volume of the sound files so that they are more in line with other sounds played on the system. crossfire-1.4.0.tar.gz contains the server code with prebuilt archetype and image files. crossfire-1.4.0.arch.tar.gz contains the unpacked archetype changes. This is not needed if you only want to compile the server and play the game. Several monsters were tuned, and new ones added. crossfire-1.4.0-maps.tar.gz contains the maps. This is needed with the server distribution. FOR FIRST TIME USERS: You will only need the appropriate server, map and client file. You do not need the arch file. You may wish to get a copy of the doc file. If you just want to play the game at some remote server, you need the client and perhaps the image archive file. Crossfire is avaible on the following ftp sites Primary: ftp://ftp.sourceforge.net/pub/sourceforge/crossfire (64.28.67.101) Secondary: ftp://ftp.real-time.com/pub/games/crossfire ftp://ftp.cs.city.ac.uk/pub/games/crossfire/ ftp://ftp.cs.titech.ac.jp/pub/games/crossfire ftp://mirror.aarnet.edu.au/games/roguelike/crossfire/ ftp://crossfire.futt.org//pub/crossfire The initial upload of this release is only made to sourceforge - it should show up on the mirrors shortly. Mark Wedel mwedel@sonic.net Complete changelog: server: server/disease.c: Change move_disease() somehwat - before, if you were not susceptible to a disease, it would never run its course. Yet you would still get stuck with the symptoms. there was a case on metalforge where a character had a symptom with no disease, and had immunity, yet was still getting stuck with the symptoms. Not sure if this change will help prevent that in the future or not. include/player.h: Change item_power in player structure to be 16 bits - 8 bit values were getting overflowed. MSW 2002-09-14 INSTALL: Update directions with new automake method. common/Makefile.am, common/Makefile.in: Fix code for building the libproto.h file - it was including loader.l and not loader.c common/exp.c: Add init_experience() and dump_experience() functions - init_experience() loads the experience table from a file. Add default experience table into this file common/init.c: Add call to init_experience() common/living.c: Remove experience tables - players can select the one they want by changing the exp_table file. Remove reference to new_levels[] - only levels[] is used now for the formentioned reason. include/config.h: Update notes about SIMPLE_EXP system. include/libproto.h: rebuilt. lib/Makefile.am, lib/Makefile.in: Add exp_table to list of files. lib/exp_table: New file that contains experience information. server/c_object.c: Modify command_take() to look for objects above the player to pick up, then objects below. This fixes the bug with not being able to use the take command on items from a chest the player opens without moving off the space. server/init.c: Add -mexp dump switch to dump the experience table. Allow the simple experience system to be set in the settings file. server/skill_util.c: Fix oddness in calc_skill_exp() which could result in add amounts of exp given. MSW 2002-09-10 include/sproto.h: rebuilt lib/help/killpets: New file lib/Makefile.in: Add help/killpets file. server/c_misc.c: Add command_kill_pets(). server/commands.c: add killpets command which kills your pets. server/monster.c: Add some code in check_enemy so that the enemy has to be a monster/generator/player to be considered valid - I was seeing things like arrows ending up as target enemies. MSW 2002-09-07 More bugfixes: common/loader.l, loader.c: Fix up the handling with speed with respect to style maps - the objects were still getting put on the active list. common/map.c: Fix up blocked_link() to behave more like the blocked_two() function - inventory checkers and door handling. Comment out blocked_two since it isn't used anymore. Modify load_objects to remove objects on style maps from the active list. Remove some of the debug messages about map loading. common/object.c: Add remove_from_active_list() function for use in map.c to remove objects from active list. common/porting.c: Comment out debug message if open_and_uncompress() can open a file - caller of the function should print out messages, and it really isn't much of an error in any case. include/libproto.h: rebuilt. random_maps/special.c: Modify place_special_exit() - this should fix bug of very large treasure maps - problem was if the generated map size was too small, when generate_random_map was called, it would generate a newly sized map that was much larger. Code was also re-arranged some to make it a little more readable. server/attack.c: Fix crash when creature may not have an owner and it kills something else. server/move.c: comment added - no code change. socket/request.c: Fix off by one error in esrv_send_animation() - rare condition as it only showed up when trying to send the last animation (zombie) - only an issue if the player is put on top of a zombie for some reason (no other space for them) - observed when leaving the random dungeon in the undead church in scorn without clearing out all the zombies first. MSW 2002-09-06 CHANGES: Update build instructions for the plugin. random_maps/square_spiral.c: Fix bug that could cause the search function to go off the edge of the map looking for a clear space. Doesn't happen often, but one crash did happen here. server/monster.c: Fix some bugs with monsters and wakeup - remove check for friendly that could never be true, and also fix logic so that monsters will now find the players. MSW 2002-09-05 common/button.c: Fix do_mood_floor() to look at all objects on space for something to effect, not just things above the moodfloor. server/attack.c: Add missing check to make sure the plugin exists before we try to access the plugin function. common/readlable.c: Fix crash caused by passing null value to mon_desc - check for non null was at end of { } do loop - check should be at the start. server/monster.c: Make it so that monsters with see invisible are not immune to blind - monster can be given appropriate resistance to make it so it is not effected by blind. MSW 2002-09-04 server/main.c: Move #endif in crypt_string to more proper place. server/monster.c: Fix bad if statement that may have been waking up monsters when they shouldn't have been. MSW 2002-09-03 This change mostly deals with improving behaviour of pet monstes. Most of the code is from K. Reinert - however, I did some code cleanup/ fixes related to pet monsters, so it is difficult to note where each piece of code came from. One thing this does fix is handling of multipart pets - these now work properly. common/map.c: Update comment for get_rangevector() - no code change. common/object.c: Add get_search_arr() which is used in pet monster code. This returns a semi random scrambling of the freearr array. doc/Developers/protocol: Update documentation about map1a protocol command. include/libproto.h, include/sproto.h: rebuilt. server/attack.c: Have drain attacks return 1 damage so that it is clear that you are actually hitting your opponent. Otherwise, you would get messages that 'you missed xyz', even though you are draining it. This extra point of damage shouldn't change balance in any significant way. server/monster.c: Update hnadling of enemies for pet monsters. It should more intelligently choose the monsters and not switch/clear the enemy field for no reason anymore. Change find_nearest_living_creature to use the get_search_arr() to more randomly choose direction of target - before, there was a proclivity to always look in the north direction. Modify can_hit() to look for closes part of enemy - otherwise, monsters may not attack opponents even if they were right next to them because they couldn't get to the enemies head. Remove move_object from this function - merged with move_ob in move.c server/move.c: Fix move_ob to use 'cleaner' code of move_object, but also have specific features that move_ob had (player handling). Before move_ob didn't handle multipart objects correctly, and the two functions were largely the same. Now move_object() just calls move_ob - the only difference in the functions is that move_ob() takes 3 parameters instead of 2 of move_object() (added parameter is originator). I think this should now mean multipart player objects may now work. server/pets.c: get_pet_enemy enhanced to be much smarter about selecting/finding things for the pet to attack. server/player.c: Remove commented out line of init_beforeplay MSW 2002-08-31 server/attack.c: Modify drain attack code so that if some agent of the player is doing the drain (eg, avatar, summoned monster, or even spell), player gets exp added to his total. Otherwise, the agent could suck all the exp out of the monster, resulting in no gain for the player. Also, fix bug in drain code where uninitialized value was being used if enemy had 0 protection to drain. MSW 2002-08-30 Various bugfixes: common/map.c: Change so that same logic is used to determine pclose/fclose that is used to determine popen/fopen - otherwise, compressed map files probably don't work properly. common/treasure.c: Do a memset to make sure entire treasureslist is set to sane values. lib/archetypes: Fix 'slaying' field (which determines spell name) in god_spelldirect_face_of_death and god_spelldirect_finger_of_death server/apply.c: Fix infinite loop if the player had cursed items that needed to be unapplied to apply an item - setting up next item iteration was inside if check when it shouldn't be. Also, print message to player if this is the case. server/monster.c: Better format some of the code for improved readability. Fix indentation of can_see_enemy. Clean up invisiblity check - may have fixed a bug - old code should have worked, but wasn't very readable. server/move.c: Fix some bad code from last checkin - didn't fix the crash on no floor for door type, and instead removed check type from next line by accident. server/player.c: Remove call for init_beforeplay - this is already properly called, and re-calling it resulted in some things being redone when they shouldn't be. server/skills.c: Add message if there is nothing to steal form the monster. server/spell_effect.c: Improve message when invisiblity duration is maximized. socket/init.c: change O_NDELAY to O_NONBLOCK of fcntl. MSW 2002-08-25 doc/Developers/objects: Update with new (better) information from Todd Mitchell. Doc is more complete, and now has an index which should make it easier to find things. server/move.c: Fix dereferencing NULL problem - was looking at op->above, but op could be NULL if the map had no objects on a space (typically not the case, but...) No reason I can see that we care about the object above - just process in normal order. MSW 2002-08-21 server/time.c: Possible fix for bug seen on metalforge - in move_player_mover, make sure we are working with the head of the monster. MSW 2002-08-13 More spoiler-html fixes - was not including attacktype information, but also fixed some formatting issues. common/item.c: Include attacktypes in describe_monster. doc/scripts/Makefile.in: Add monsters-extract.pl file. doc/spoiler-html/Makefile.in: Update to use ../scripts/monster-extract.pl file, remove monster-extract file. doc/spoiler-html/spoiler.html: rebuilt. MSW 2002-08-11 Fix spoiler-html generation to show resistances. Need to do normal spoiler next. Add a new docs/scripts directory to hold the common scripts, instead of spoiler, spoiler-html, playbook, and playbook-html each having their own copies. configure, configure.in: Add doc/scripts directory. doc/spoiler-html/Makefile.in: Update build directions to use ../scripts/items-extract.pl doc/spoiler-html/spoiler.html: Rebuilt with updated information. doc/scripts/Makefile.in: Makefile for directory. doc/scripts/items-extract.pl: perl version of the items-extract file. doc/spoiler-html/items-extract: awk version - no longer used. MSW 2002-08-02 common/item.c: Have describe monster show resistances of monsters - useful for spoiler output, as well probe spell. server/disease.c: Fix typo. MSW 2002-08-02 include/global.h: add FREE_AND_CLEAR_STR macro, relocate DELETE_STRING by the other macros. server/c_misc.c: Fix string printout in applymode function. server/disease.c: Update name_pl in diseases. server/player.c: replace FREE_AND_CLEAR with FREE_AND_CLEAR_STR - was freeing data that shouldn't be freed. MSW 2002-08-01 Various fixes: INSTALL: Update with note about --with-includes configure option. common/loader.c, common/loader.l: Add comment about flag_invis_undead include/define.h: Add FLAG_INVIS_UNDEAD lib/adm/map_info: Modify to not follow symbolic links. server/monster.c: Modify can_detect_enemy to be a bit more straightforward in its logic. Also, modify detection of invisible creatures - don't reduce duration, just return that the monster can detect the player. There were also spurious messages about the player being seen. Modify can_see_enemy to check FLAG_INVIS_UNDEAD, also fix broken comparison server/player.c: Clear FLAG_INVIS_UNDEAD when invisibility ends. Fix action_makes_visible() - had reverse logic on FLAG_MAKE_INVIS check, and a typo in the printed message. server/spell_effect.c: cast_invisible() to use FLAG_INVIS_UNDEAD - also check for maximum duration, and only search active objects when clearing enemy. server/weather.c: Fix off by one on comparision when intializing maps darkness when loading map from disk. In dawn_to_dusk, don't do further processing if the light hasn't changed. MSW 2002-07-29 Various bug fixes, add glyph spell: TODO: Updated common/map.c: Fix change_map_light() - if darkness was reduced to zero, it wouldn't properly notify the players or update the maps they are on. Also, make it more robust to handle changes by more than one. include/define.h: Increase NROFREALSPELLS include/spellist.h: Add glyph spell. include/spells.h: Add SP_GLYPH entry. server/attack.c: Fix up kill_object() - it has had some many various additions that it was difficult to follow the logic. It should also now do better check on skill objects when awarding experience. server/player.c: Add some checks/addition to properly deal with freeing the name_pl in the player object. Fix it so that if you are braced, you still won't attack friendly creatures. server/rune.c: Add cast_generic_rune() to handle the glyph and rune spell. server/spell_effect.c: Fix up some pointers in cast_cause_disease() - needed so that it works properly when embedded in a glyph. Have it return 1 even if no one caught anything - you still cast the spell, so you should lose the grace for it. server/spell_util.c: Fix some formatting. Break out the code dealing with rune into cast_generic_rune() socket/loop.c: Add flag to player command mapping, and update structure - if flag is set, command can only be issued when player is in play, and not when waiting at the quit or login prompt - fixes crashes where players could wait for the map to get swapped out (after quitting), and then looking at a space. socket/request.c: Fix map2cmd so that invisible players are drawn. MSW 2002-07-24 Add dm command 'freeze' which freezes a player from doing anything for some amount of time. include/sproto.h: rebuilt. lib/Makefile.in: Add freeze to wizhelp files. lib/wizhelp/freeze: New file. server/c_wiz.c: Add command_freeze(). Also, break out get_other_player_from_name() - several functions need the same logic of getting a player named X that is not us - making it a function reduces the duplicate code. Fix some formatting for some functions. server/commands.c: Add command_freeze to the dispatch table. MSW 2002-07-17 lib/Makefile.in: add a 'archonly' directive that only collects archetypes and doesn't collect images. lib/archetypes: rebuilt for fixes made to arches. lib/collect.pl.in: modified to take second parameter -ARCHONLY, that causes it not to save out animation, bmaps and faces file. server/apply.c: Change order of print when applying/unapplying - print out the 'you apply/unapply' before we print out the changes that applying the item does. It seems odd for it to be 'you feel stronger. you apply xyz'. Fix can_apply_object() so that if a player needs to unapply several items, the right return code is returned and we don't say the player has a choice. server/player.c: Fix missing clearing of player->next. MSW 2002-07-15 -- Start body commit notes -- Major commit. This adds body locations which is used for equipping items. Equipment has information which body part it gets equipped to, and monsters have information on how which body locations they can have. As part of this work, I also did a lot of code cleanup. To use this, you must use up to date archetypes - the ones included in this commit are fine - just make sure you install them. If you don't, players will not be able to equip items. common/arch.c: Initialize body_used to be same as body_info for archetypes - this way when monsters are created, they can start equipping items right away. common/exp.c: update new_exp() - some flags it checked for before no longer exist or have new names. common/info.c: describe_item() now takes second parameter - update dump_abilities to use new calling convention. common/item.c: Add table that describes the body_info locations and their names. Add functions that calculate item power for objects that don't have it set. Update display functions to show item_power in items. Update describe_monster() - use_horn/wand/rod merged into just use_range. Modify describe_item() to take second paramater - who the item is being described for. Show item_power in describe_item. common/living.c: Pull out MAXLEVEL from being defined in this file - define in in define.h, since other files use it. Add NUM_STATS define - replace hard coded values of having just 7 stats with it. Update change_abil to not display that the player has a new attacktype when equipping a bow that has it - fix_player() ignores the attacktype of the bow, so it was incorrect information. fix_player(): Initialize player ranges structure to null - will get filled in by code in function, updated to deal with updating the body_used data from body_info in the objects. Replace instances of last_heal with gen_sp_armour. Rearrange some code to make function more readable. common/loader.c, common/loader.l: Remove the variable_const information - no longer needed and confusing for new people when adding in new object elements. Add set_body_info() - parses the string from the load file and sets the appropriate array element. Add check_loaded_object() - does sanity checking for an object after finished loading - replaces need for long processing directive in the actual rules by having seperate function. Remove unused flags from load directives (apply_once, no_pretext, can_apply), add some new ones (item_power, gen_sp_armour), update others to can_use_range. Replace flag_links with simple array that contains the name for each corresponding flag. Update get_ob_diff to not use the V_ values and just include the actual string name - all recent changes have done this, just updated for old stuff. Update get_ob_diff to save new values that have been added. common/object.c: clear_object: Modify to use memset to clear the structure to zero - this is less error prone than listing all the specific values, and probably faster. Also, makes it easier to add new elements - no need to update object.c in most cases. common/player.c: Remove get_player_ob routine - this is now merged in with get_player_ob in server/player.c. Remove generate_ext_title - not used. common/readable.c: Update to pass second argument to describe_item. common/treasure.c: Update to calculate item_power of generated items. Clean up a lot of code formatting. Update add_abilities to use gen_sp_armour values, not last heal (note, it appears the last_heal values weren't being used before). Update calls to describe item to take second parameter. doc/Developers/objects: Update will_apply notes, add note about item_power, body location. include/define.h: Comment out unused flags (flag_apply_once, flag_paralyzed, flag_no_pretext, flag_ready_rod, flag_read_horn). Add flag_use_shield. rename flag_use_wand to flag_use_range. rename flag_ready_wand to flag_ready_range. Add flag_ready_scroll. Update ARMOUR_SPELLS access macro. Add AP_PRINT flag to apply flags. Add CAN_APPLY_.. return types for can_apply_object function. include/includes.h: add strftime, mktime checks to this file. include/libproto.h: rebuilt. include/living.h: Add NUM_STATS define, update extern declarations to use it for sizing. include/loader.h: remove the V_.. info and xbm_.. externs that were not used. include/newserver.h: Remove ext_tile information. include/object.h: Add Body_Locations structure, NUM_BODY_LOCATIONS define. Add definitions for WILL_APPLY values. Clean up object structure - formatting is now consistent, ordering of values groups values together more logically. Update all types to use the int8/int16/int32 types. Several unused fields removed. include/player.h: Update rangetype enum. Add unapplymode enum. Clean up player structure - type updates, unused fields removed, formatting fixed up. include/spells.h: remove range_name extern. Update SpellTypeFrom field to combine wand/rod/horn into spellMisc - none of the spell casting code was differentiating these. include/sproto.h: rebuilt. lib/Makefile.in: Add new help files (applymode, bind, brace) lib/archetypes: rebuilt for body_info, gen_sp_armour, item_power, can_use_shield information. lib/artifacts: updated for item_poer and gen_sp_armour changes. lib/treasures: remove unused _force for player treasure. plugin/plugin_python.c: Change FLAG_USE_WAND to FLAG_USE_RANGE. server/apply.c: Move stftime, mktime to include/includes.h. Remove draw_find() - one line function can just as easly be in the code itself. Update calls to long_desc to pass second parameter. move gravestone_text() to player.c file. Add direction parameter to apply_scroll() - in this way monsters can use it properly. Remove dead code. Update apply_special function. Add unapply_special(), get_item_from_body_location(), unapply_for_ob(), and can_apply_object() functions. server/attack.c: Remove SET_FLAG(op, FLAG_PARALYZED) line - no code was ever checking status of FLAG_PARALYZED. server/c_misc.c: add command_body() which dumps body information for player. Update who as idle element in player structure removed - was not being used by anything. Add command_applymode() to set players prefered unapply method. Remove calls to unlock_player() in various functions - unlock_player() has not done anything meaningful for a while. server/c_object.c: Modify long_desc to take a second parameter which is who is examing the object. this is needed so that we can pass it down to some of the lower level functions. Update calls to describe_item to pass this second parameter. remove FLAG_NO_PRETEXT code - no archetyps were using it. When examining objects, also tell player where to put them on. server/c_range.c: Update legal_range() - we now store the object that is responsible for a range in the player object, so code is much simpler. Update change_spell() to not destroy golem just by readying another spell - we now let players regain control of golems after switching to another range. Update change_spell to use item name of object for range description. server/c_wiz.c: remove reference to count_left from player object - field removed from structure. server/commands.c: add new commands (applymode, body) to command dispatch table. server/login.c: Remove unlock_player() and lock_player() and calls to it - current checking of names at login should be sufficient to prevent duplicates. Remove dead code from check_name. Update load/save code for unapply mode value. Add set_flag(op, FLAG_USE_SHIELD) if player is allowed to use armor - needed since flag_use_shield is really a class feature and so is not automatically updated for old player files. server/main.c: Remove references to count_left. memset marker object to NULL - seems to increase stability on metalforge server. server/monster.c: Many updates related to the body info - monsters follow some rules as players. Add monster_should_cast_spell function - monsters will use this for all spellcasting related actions (abilities, scrolls, wands, etc). Update for merged rod/horn/wand ranges. Update bow use by monsters - they don't actually need to equip it to fire - this way we don't need to constantly swap the monsters weapons between the bow and melee item. Use fire_bow from player.c for most of the work. Modify scroll usage - monster will use it when player is near, not when it first picks it up. Add FLAG_READY_SCROLL to denote the monster has a scroll to use. Also, monster now casts it in appropriate direciton. Merge the monster_use_wand/rod/horn into monster_use_range. Modify check_good_weapon and check_good_armour to just look at the stats of the two items without needing the monster to apply it first. server/player.c: Print motd in green so it is more noticable. Update get_player function to do work it did before as well as that of get_player_ob. Have get_player take a parameter which is the object of the player if he has one. Modify to use memset to clear the player structure - more sure fire than explicitly listing values to initialize. Remove calls to unlock_player. Modify fire_bow so that monsters can also use the function. Add fire_misc_object() to fire_wand/rod/horn - removes code from fire(). Add gravesetone_text() to this file. server/shop.c: Update to pass second parameter to describe_item(). server/skill_util.c: Update check_skill_to_fire since there are fewer rangetypes now. change range_scroll name to range_golem, as that is a bit more accurate for what it actually does. Modify show_skills() to show player his item power and total of items he has equipped. server/skills.c: Add second paramater to long_desc, remove references to count_left. server/spell_effect.c: Add second paramater to long_desc, remove references to count_left. Update range_scroll to range_golem server/spell_util.c: remove references to count_left. Update messages if player trying to cast where he can't with new range names. socket/info.c: Update range information and how we display what it is - we will use the object name of the range if available. Remove reference last_known_spell, last_shoot, last_spell, last_value player structure fields. socket/init.c: Remove ext_title information. socket/request.c: Add element for life_stealing in the resistance array. Remove references to idle, count_left in player structure. remove ext2 title information. MSW 2002-07-14 -- End body commit notes -- common/anim.c, common/button.c, common/friend.c, common/glue.c, common/init.c,common/logger.c, common/los.c, common/porting.c, common/time.c, common/utils.c, crossedit/png.c, crossedit/xutil.c, include/attack.h, include/config.h, include/map.h, include/material.h, include/newclient.h, include/skills.h, include/treasure.h, random_maps/decor.c, random_maps/door.c, random_maps/floor.c, random_maps/monster.c, random_maps/special.c, random_maps/standalone.c, random_maps/style.c, random_maps/wall.c, server/alchemy.c, server/c_chat.c, server/c_party.c, server/gods.c, server/hiscore.c, server/init.c, server/pets.c, server/resurrection.c, server/rune.c, server/time.c, socket/metaserver.c: Update banner copyright with proper contact information. MSW 2002-07-14 server/disease.c: Fix propogation of diseases with negative damage (these do a percent of the creatures damage). The new disease was getting a damage rating of 1 in all cases because we were passing a negative value to random_roll for the top end of the range. MSW 2002-07-08 common/arch.c: Add 'unlocked' match for item_matched_string. lib/help/drop, lib/help/dropall: Help files for these commands. lib/Makefile.in: Update to include help commands above. server/spell_effect.c: Fix formatting of summon_pet() function. Modified so that it no longers sucks player spellpoints when casting it via scroll - scrolls should not cast the player spellpoints. No idea why that code was there - in fact, casting off a scroll used more sp than casting from memory. Modify cast_cause_disease() function so that if the passed direction is 0, we refer to the facing and cast in that direction - this means spells of cause disease now work. Also perform some minor formatting changes in the function. TODO: Add not about inscription. MSW 2002-07-05 common/arch.c: Fix bug in item_matched_string which was matching all values (inverse in fact) when passed with count > 1 in matching string - missing ! operator. README: Update - remove note about windows client, since it is currently unsupported and could stop working in some future release. MSW 2002-07-05 client: common/image.c: Fix bug of not fulling clearing the cache entry data after allocation. This resulted in various random crashes when using cached image mode. x11/x11.c: Add note about -facset. CHANGES, Makefile.in, configure, configure.in: Update for 1.4 release MSW 2002-09-14 common/item.c: Update comment about possible sorting improvements. gtk/gx11.c: Add missing foodbeep functionality to GTK client. MSW 2002-08-13 gtk/config.c: Fix crash when trying to apply config changes when compiled with SDL support but user is not using it. Fix bug where settings were not being properly updated. gtk/sound.c: initialize sound_pipe to NULL, and have init_sounds close the sound pipe if there is currently one open - fixes bug when switching sound control many times in that multiple cfsndserv processes could get started. MSW 2002-07-25 Makefile.in: if no makedepend, don't run make depend directive. README: Add not about ALSA revisions and possible problems compiling. MSW 2002-07-10 This commit adds graduated colored statbars to the gtk client. What this means is that the color of the statbar goes smoothly from red to yellow to green depending on what percentage of your hp/sp/grace/food is compared to your maximum. To use this, you need to go to the config pane and hit the 'gradually change stat bar color' button. common/client.h: Add CONFIG_ value for this, increase CONFIG_NUMS. common/init.c: Add "grad_color_bars" to config_names array. gtk/config.c: Add button to select this behaviour. Move all the special config checks to beyond the for loop that checks the values in apply_config(). There is no need to check all the values on each loop. gtk/gtkproto.h: Rebuilt for inclusion of reset_stat_bars() gtk/gx11.c: Add two styles to the Vitals (stat bar) structure so we can alternate between them. Default is to initialize one for green and the other for red (in non graduated color mode). This should be more efficient then allocating a new one each time we need to change the value. add reset_stat_bars() to reset the colors of the styles to red and green - needed because the graduated color code will change the colors of these. Remove code that freed these styles. Modify draw_stat_bar() to draw them in color or simple mode, in simple mode, we now just need to use the appropriate style and not allocated a new one. Modify draw_message_window() to pass bar values greater than 1 to the draw_stat_bar() function - in graduated color mode, we draw such values with a blue tinting (more blue the more over it is). draw_stat_bar() knows how to properly deal with these higher values. MSW 2002-07-04 gtk/config.c: Fix setting of radio button set state - it was always setting the same (last) radio button as the active button, which did not match state - now it sets the proper button active - this is for the lighting control toggle. gtk/map.c: Add/subtract 2 to the need_recenter_map function - in this way, code that checks known display position +/-1 will still be within map array. gtk/sdl.c: Fix per pixel (fastest and best) lighting code - this got broken quite a while - it was looking to see if the coordinates for the map structure where within range, and not the real coordinates. Since the map coordinates would almost never be within range, the effect was that the per pixel effects more ore less looked like the per tile effects. MSW 2002-07-03 From mathwizard at gmx.de Sun Sep 15 03:32:42 2002 From: mathwizard at gmx.de (Christoph Bergemann) Date: Thu Jan 13 18:04:30 2005 Subject: [CF List] First bug (was: Crossfire 1.4.0 released) In-Reply-To: <3D842731.8060709@sonic.net> References: <3D842731.8060709@sonic.net> Message-ID: <20020915103242.30f1e515.mathwizard@gmx.de> Hi, I find myself unable to enter a guildhouse. I got the right key, the grate seems to open, but remains impassable, though it doesn't block the view anymore. Tried this with two heroes getting both the same results with both. I compiled without any extra options and installd the server, client, arch und maps file and used the gtk-client. Regards, Christoph Bergemann -- "Do not meddle in the affairs of Wizards, for they are subtle and quick to anger." From mwedel at sonic.net Sun Sep 15 23:05:59 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:04:30 2005 Subject: [CF List] First bug (was: Crossfire 1.4.0 released) References: <3D842731.8060709@sonic.net> <20020915103242.30f1e515.mathwizard@gmx.de> Message-ID: <3D8558A7.8080802@sonic.net> Christoph Bergemann wrote: > Hi, > > I find myself unable to enter a guildhouse. I got the right key, the grate > seems to open, but remains impassable, though it doesn't block the view > anymore. Tried this with two heroes getting both the same results with > both. I compiled without any extra options and installd the server, > client, arch und maps file and used the gtk-client. Fixed in CVS.