From crossfire-devel at archives.real-time.com Fri Jul 2 00:11:48 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:51 2005 Subject: [CF-Devel] three patches to look over Message-ID: <1088745108.2797.6.camel@oberon.kameria> Been working on some things and have three patches ready to be looked over. They are available at the sourceforge patch tracker. http://sourceforge.net/tracker/?func=browse&group_id=13833&atid=313833 983716 speeds up random map generation and removes the slew of error messages when generating random maps with single arch walls. 983780 adds a method of disabling the return exit from random maps to the final map (if there is one). 983864 adds two new global events to the python plugin for kick and for toggle_shout (to be used for logging purposes). _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Fri Jul 16 17:18:48 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:51 2005 Subject: [CF-Devel] Windows server release Message-ID: <40F85448.2020108@laposte.net> Hello. There is apparently a bug in latest (1.6.0) official Windows server release, making it worthless to sell items. I think this bug had been fixed in cvs after the release. Given that many Windows users don't have tools/skills to build server, I plan on releasing a bug-fix version. Probably release 1.6.1, if no one objects. Maybe a linux release too? Nicolas Ryo _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Sun Jul 18 05:01:42 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:51 2005 Subject: [CF-Devel] Client crash, money quantity Message-ID: <40FA4A86.6010605@laposte.net> Hello. This morning, a player converted 500M plat to gold, using the converters. The result was a *negative* gold coin count. This is bad in itself, and also would crash the client right away when stepping on the pile :) Extract from the evil function: (in common/item.c) char *get_number(int i) { static char numbers[21][20] = { "no","a","two","three","four","five","six","seven","eight","nine","ten", "eleven","twelve","thirteen","fourteen","fifteen","sixteen","seventeen", "eighteen","nineteen","twenty" }; if(i<=20) return numbers[i]; Obviously, with a *negative* i, it gives weird results, and the sprintf using the result has, err, some issues ;p Client itself isn't too hard to fix. But what'd need fixing is the server code, too :) Maybe in the plugin part? Nicolas 'Ryo' _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Sun Jul 18 22:36:45 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:51 2005 Subject: [CF-Devel] crossfire -detach command-line option In-Reply-To: <200406262120.47638.kbulgrien@worldnet.att.net> References: <200406232200.38208.kbulgrien@worldnet.att.net> <40DA5656.40809@sonic.net> <200406262120.47638.kbulgrien@worldnet.att.net> Message-ID: <40FB41CD.3030505@sonic.net> Kevin R. Bulgrien wrote: > > > Ok. Did not even know about them. crossloop does not seem to > handle stuff like "service crossloop stop". Is there any issue with > a server going down too fast so that crossfire would not go down > cleanly? Not having enough time to do it's save when it gets > killed? Unlikely - it doesn't do that much cleanup when going down: 1) saves at all player files who are currently on line. 2) saves out any unique map information. 3) saves out some small amount of other data. Now this obviously depends on the system, but in my cases, I'd say that from the time the process receives the hup signal to it exiting is less than a second. > (Shrug) Ok. -detach was nice because it was easy to plainly > set up a script to do simple start/stop/status type stuff on a > local homebrew server that isn't necessarily run 24/7. I used > to do this with crossfire a year and a half or so ago. From > what I can see, the crossloop scripts are pretty basic except > that they do handle restarts/cores, nicely. Maybe I can work > one of them over and get what I was looking for. yes - that is the main advantage of the crossloop scripts - the restart on crash. I'd imagine it wouldn't be too hard to have the crossloop script write out a /var/run/crossfire.pid file, and keep updating it as it restarts the server (or maybe just have crossfire do it itself, as then it has all the configure information and might have a better idea where to write it). Then at least the stop functionality is easy to do. One could of course do this with pkill/pgrep, but there are potential issues if there are other process that might have crossfire in their name (eg, usernames or whatever else). _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Sun Jul 18 23:00:08 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:51 2005 Subject: [CF-Devel] Client crash, money quantity In-Reply-To: <40FA4A86.6010605@laposte.net> References: <40FA4A86.6010605@laposte.net> Message-ID: <40FB4748.90800@sonic.net> Nicolas Weeger wrote: > Hello. > > This morning, a player converted 500M plat to gold, using the converters. > > The result was a *negative* gold coin count. > This is bad in itself, and also would crash the client right away when > stepping on the pile :) > Extract from the evil function: (in common/item.c) > > char *get_number(int i) { > static char numbers[21][20] = { > > "no","a","two","three","four","five","six","seven","eight","nine","ten", > > "eleven","twelve","thirteen","fourteen","fifteen","sixteen","seventeen", > "eighteen","nineteen","twenty" > }; > > > if(i<=20) > return numbers[i]; > > Obviously, with a *negative* i, it gives weird results, and the sprintf > using the result has, err, some issues ;p > > Client itself isn't too hard to fix. But what'd need fixing is the > server code, too :) > Maybe in the plugin part? Taking a quick look, what I see is that the client uses 'sint32' for the nrof field, and the server uses 'uint32'. So the overflow will causes issues for the player (basically, losing some amount of gold) but otherwise shouldn't cause any issues. Other than going to a 64 bit type for nrof, there is no real fix (well, one could add code in to check for overflows here and there, but there are potentially lots of places this could happen). bigger issue is how a player gets 500 million in platinum, but we've had that discussion before. The fix for the client is to probably change it to also use uint32. Taking a very quick look at the client, I don't see any cases where it needs to be a negative values (my thought was that there could be a case where it might do something like that to note the object is cleared or special meaning, but that doesn't appear to be the case). _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Tue Jul 20 20:43:30 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:51 2005 Subject: [CF-Devel] python setquantity() Message-ID: <1090374210.2891.5.camel@oberon.kameria> After hearing of a player having trouble exchanging a large sum of imperials I asked Leaf to track the error message and found that the python code that handles quantity has an arbitrary cap of 100000 here is the code: /* I used an arbitrary bound of 100k here */ if (value > 100000) { printf( "(set-quantity): Value must be lower than 100000\n"); return NULL; } I would like to raise this up a bit if there are no issues - it is limiting whan dealing with making change for money especially. also 'value' here is an int - hopefully this is large enough but perhaps it is not? _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Fri Jul 23 01:44:44 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:51 2005 Subject: [CF-Devel] python setquantity() In-Reply-To: <1090374210.2891.5.camel@oberon.kameria> References: <1090374210.2891.5.camel@oberon.kameria> Message-ID: <200407230844.44739.yann.chachkoff@myrealbox.com> Skipped content of type multipart/signed-------------- next part -------------- _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Fri Jul 23 10:26:58 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:51 2005 Subject: =?iso-8859-1?Q?Re:_Re:_[CF-Devel]_python_setquantity()?= Message-ID: ---Woosh--- I changed the 'value' variable from an int to a uint in python_plugin.c and it fixed the problem, however I had some concerns about introducing all sorts of evil I didn't understand. I sent the patch in for review anyway. I was also wondering about the money routines (other object references?) in the plugin and if they should be using a uint as well. While I have your attention - I was also trying to figure out how to add the {}/maps/python path to the python plugin system path so it looks there for modules first. This would be great so we can access them easier as well as override existing library modules. I can't find a good example of this in the embedding python documentation. > An 'int' values is encoded (on 32bit-based machines) using 32bits, so you can > safely increase that upper limit. > > I have to admit that I don't remember anymore why I put an arbitrary limit - > probably that was just a workaround for an obscure bug involving large > quantities of a single object. > > The clean way to correct it is to: > > - Include system header (you can do it in the plugin.h specific > plugin header. Since it is theorically part of the ANSI-C definition, it > should exist on Win32 as well); > > - Test value against INT_MAX, which holds the maximum acceptable value for the > integer type. > -- > Yann Chachkoff > ----------------------- > Garden Dwarf's Best Friend > ----------------------- _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Fri Jul 23 21:28:05 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:51 2005 Subject: [CF-Devel] v1.7.0 client for Debian Message-ID: v1.7.0 of the Crossfire clients for Debian are awaiting testing and approval before making it out in the unstable release. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=260328 I spent a little over 2 hours testing the client tonight and didn't find any issues. Is anyone else interested in testing? If so, please do and report your findings to: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=260328 Hopefully this can get rolled out, soon. -- _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Sun Jul 25 04:17:58 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:51 2005 Subject: [CF-Devel] v1.6.0 and CVS server failed to compile. Message-ID: <200407250917.i6P9HxVY025755@coffee.exoss.net> While compiling the 1.6.0 and CVS Crossfire server versions, it failed to compile on Mac OS X. The following errors appeared: Making all in random_maps /bin/sh ../libtool --mode=link gcc -g -O2 -o random_map standalone.o ../common/libcross.a librandom_map.a -lm gcc -g -O2 -o random_map standalone.o ../common/libcross.a librandom_map.a -lm ld: Undefined symbols: _atoll make[1]: *** [random_map] Error 1 make: *** [all-recursive] Error Any ideas on how to fix this? -- Ketche _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Sun Jul 25 03:55:46 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:51 2005 Subject: [CF-Devel] CF 1.6.0 and CVS compilation errors Message-ID: <200407250855.i6P8tle2025567@coffee.exoss.net> Errors while compiling crossfire server 1.6.0 and CVS: /bin/sh ../libtool --mode=link gcc -g -O2 -o random_map standalone.o ../common/libcross.a librandom_map.a -lm gcc -g -O2 -o random_map standalone.o ../common/libcross.a librandom_map.a -lm ld: Undefined symbols: _atoll make: *** [random_map] Error 1 Any idea on how to fix this? -- Ketche _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Tue Jul 27 11:53:45 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:51 2005 Subject: [CF-Devel] Looking for Redhat/Fedora maintainer? In-Reply-To: <200405022220.48521@join.the.twin.cities.linux.users.group.at.www.mn-linux.org> References: <200405022220.48521@join.the.twin.cities.linux.users.group.at.www.mn-linux.org> Message-ID: <200407271153.45532.tanner@real-time.com> On Sunday 02 May 2004 10:20 pm, Bob Tanner wrote: > Given that Redhat 9 was deprecated on 04/30/2004 and the consumer > version of Redhat linux no longer exists, I've switched to Debian and will > no longer be maintaining the .spec file and RPMs for Redhat/Fedora Linux. > > I'm looking for someone to take over maintaining the aspect of crossfire. Repost, since I didn't get anyone interested in maintain the RPMs for crossfire. -- Bob Tanner | Phone : (952)943-8700 http://www.mn-linux.org, Minnesota, Linux | Fax : (952)943-8500 Key fingerprint = AB15 0BDF BCDE 4369 5B42 1973 7CF1 A709 2CC1 B288 _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Sun Jul 25 04:14:53 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:52 2005 Subject: [CF-Devel] v1.6.0 server and CVS server failed to compile Message-ID: <200407250914.i6P9Es2M025728@coffee.exoss.net> The 1.6.0 and CVS verions of the crossfire server failed to compile on Mac OS X. The following errors appeared: Making all in random_maps /bin/sh ../libtool --mode=link gcc -g -O2 -o random_map standalone.o ../common/libcross.a librandom_map.a -lm gcc -g -O2 -o random_map standalone.o ../common/libcross.a librandom_map.a -lm ld: Undefined symbols: _atoll make[1]: *** [random_map] Error 1 make: *** [all-recursive] Error 1 Any idea how to fix this, guys? -- Ketche _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Sun Jul 25 13:39:04 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:52 2005 Subject: [CF-Devel] 1.6.0 and CVS server compilation erorrs Message-ID: <200407251839.i6PId5wZ028554@coffee.exoss.net> While compiling the 1.6.0 and CVS versions of crossfire on Mac OS X, I received the following errors: Making all in random_maps /bin/sh ../libtool --mode=link gcc -g -O2 -o random_map standalone.o ../common/libcross.a librandom_map.a -lm gcc -g -O2 -o random_map standalone.o ../common/libcross.a librandom_map.a -lm ld: Undefined symbols: _atoll make[1]: *** [random_map] Error 1 Any ideas on how to fix this? (If there are duplicates of this message, it's because the mailman hates me. :P) -- Ketche _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Tue Jul 27 12:49:26 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:52 2005 Subject: [CF-Devel] CF 1.6.0 and CVS compilation errors In-Reply-To: <200407250855.i6P8tle2025567@coffee.exoss.net> References: <200407250855.i6P8tle2025567@coffee.exoss.net> Message-ID: <200407271249.29619.tanner@real-time.com> On Sunday 25 July 2004 03:55 am, ketche@coffee.exoss.net wrote: > Errors while compiling crossfire server 1.6.0 and CVS: > > /bin/sh ../libtool --mode=link gcc -g -O2 -o random_map standalone.o > ../common/libcross.a librandom_map.a -lm gcc -g -O2 -o random_map > standalone.o ../common/libcross.a librandom_map.a -lm ld: Undefined > symbols: > _atoll > make: *** [random_map] Error 1 > > Any idea on how to fix this? What operating system? What version of the operating system? -- Bob Tanner | Phone : (952)943-8700 http://www.mn-linux.org, Minnesota, Linux | Fax : (952)943-8500 Key fingerprint = AB15 0BDF BCDE 4369 5B42 1973 7CF1 A709 2CC1 B288 _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Tue Jul 27 12:50:42 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:52 2005 Subject: [CF-Devel] v1.7.0 client for Debian In-Reply-To: References: Message-ID: <200407271250.42767.tanner@real-time.com> On Friday 23 July 2004 09:28 pm, Rick Tanner wrote: > v1.7.0 of the Crossfire clients for Debian are awaiting testing and > approval before making it out in the unstable release. > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=260328 > > I spent a little over 2 hours testing the client tonight and didn't find > any issues. Is anyone else interested in testing? > > If so, please do and report your findings to: > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=260328 > > Hopefully this can get rolled out, soon. Couple pieces of info are left out. Just need to add the following to your /etc/apt/sources.list file # Real Time custom repository deb ftp://ftp.real-time.com/linux/real-time unstable custom deb-src ftp://ftp.real-time.com/linux/real-time unstable custom Then # apt-get update # apt-get install crossfire-client-gtk OR # apt-get install crossfire-client-x11 I have i386, powerpc, and sparc .deb available. -- Bob Tanner | Phone : (952)943-8700 http://www.mn-linux.org, Minnesota, Linux | Fax : (952)943-8500 Key fingerprint = AB15 0BDF BCDE 4369 5B42 1973 7CF1 A709 2CC1 B288 _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Wed Jul 28 00:37:22 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:52 2005 Subject: [CF-Devel] CF 1.6.0 and CVS compilation errors In-Reply-To: <200407271249.29619.tanner@real-time.com> from "Bob Tanner" at Jul 27, 2004 12:49:26 PM Message-ID: <200407280537.i6S5bOBt013069@coffee.exoss.net> > > On Sunday 25 July 2004 03:55 am, ketche@coffee.exoss.net wrote: > > Errors while compiling crossfire server 1.6.0 and CVS: > > > > /bin/sh ../libtool --mode=link gcc -g -O2 -o random_map standalone.o > > ../common/libcross.a librandom_map.a -lm gcc -g -O2 -o random_map > > standalone.o ../common/libcross.a librandom_map.a -lm ld: Undefined > > symbols: > > _atoll > > make: *** [random_map] Error 1 > > > > Any idea on how to fix this? > > What operating system? Sorry about that, the mailman hates me, I wrote multiple messages. :P Mac OS X 10.2 I've compiled 1.5.0 on this OS before, the latest client compiled fine, though. :P > > What version of the operating system? > > -- > Bob Tanner | Phone : (952)943-8700 > http://www.mn-linux.org, Minnesota, Linux | Fax : (952)943-8500 > Key fingerprint = AB15 0BDF BCDE 4369 5B42 1973 7CF1 A709 2CC1 B288 > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Wed Jul 28 02:01:21 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:52 2005 Subject: [CF-Devel] CF 1.6.0 and CVS compilation errors In-Reply-To: <200407280537.i6S5bOBt013069@coffee.exoss.net> References: <200407280537.i6S5bOBt013069@coffee.exoss.net> Message-ID: <41074F41.3020205@sonic.net> ketche@coffee.exoss.net wrote: >>On Sunday 25 July 2004 03:55 am, ketche@coffee.exoss.net wrote: >> >>>Errors while compiling crossfire server 1.6.0 and CVS: >>> >>>/bin/sh ../libtool --mode=link gcc -g -O2 -o random_map standalone.o >>>../common/libcross.a librandom_map.a -lm gcc -g -O2 -o random_map >>>standalone.o ../common/libcross.a librandom_map.a -lm ld: Undefined >>>symbols: >>>_atoll >>>make: *** [random_map] Error 1 >>> >>>Any idea on how to fix this? >> >>What operating system? > > > Sorry about that, the mailman hates me, I wrote multiple messages. :P > > Mac OS X 10.2 > > I've compiled 1.5.0 on this OS before, the latest client compiled fine, though. :P You need to see what macos X uses for it's 64 bit version of atoi. It seems windows uses _atoi64. You might be able to look at the documentation/man page for atoi/atol and see if it references what to use to get back a 'long long'. IT might be atoq - at least on my linux system, it says that call is no longer used, anymore, but perhaps some platforms still use it. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Thu Jul 29 19:05:21 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:52 2005 Subject: [CF-Devel] Weather needs smoothing Message-ID: Dynamic (level 5) generated tiles of snow etc need smoothing... they do not smooth it looks bad and makes the players sad and hate dynamic weather. Also the puddles need to be redone possibly as player complain about them too. IMHO they look too cartoony, and not crossfire like. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Thu Jul 29 21:34:25 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:52 2005 Subject: =?iso-8859-1?Q?Re:=20[CF-Devel]=20Weather=20needs=20smoothing?= Message-ID: I'm not sure they can be smoothed since I am not sure they can be floors. If they can be floors without breaking anything then they should be able to be smoothed. > > Dynamic (level 5) generated tiles of snow etc need smoothing... they do not smooth it > > looks bad and makes the players sad and hate dynamic weather. > > > > Also the puddles need to be redone possibly as player complain about them too. IMHO > > they look too cartoony, and not crossfire like. > > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Thu Jul 29 21:57:32 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:52 2005 Subject: [CF-Devel] Weather needs smoothing Message-ID: Perhapse new code is needed? >I'm not sure they can be smoothed since I am not sure they can be floors. = >If they can be floors without breaking anything then they should be able to= >be smoothed. ---- Original Message ---- From: Todd Mitchell Date: Thu 7/29/04 22:37 To: crossfire-devel@lists.real-time.com Subject: Re: [CF-Devel] Weather needs smoothing I'm not sure they can be smoothed since I am not sure they can be floors. = If they can be floors without breaking anything then they should be able to= be smoothed. >=20 > Dynamic (level 5) generated tiles of snow etc need smoothing... they do n= ot smooth it >=20 > looks bad and makes the players sad and hate dynamic weather. >=20 >=20 >=20 > Also the puddles need to be redone possibly as player complain about them= too. IMHO >=20 > they look too cartoony, and not crossfire like.=20 >=20 >=20 > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Thu Jul 29 23:10:05 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:52 2005 Subject: [CF-Devel] No-Smooth tile arch needed Message-ID: Mapmakers need a tile that specifies no smoothing for the tile it is placed on... I need such an arch on some of my maps... _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Fri Jul 30 07:30:49 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:52 2005 Subject: [CF-Devel] Weather level 5 (Re: Weather needs smoothing) In-Reply-To: References: Message-ID: <20040730123048.GA11198@laranja.org> The reason *I* don't run level 5 is that it eats RAM like crazy. I know it's supposed to, but if someone could check for leaks, I'd feel better. Recipe for crashing your server: 1. run with 128Mb or less 2. run with weather on lvl 5 3. open a client (if possible in the same machine to eat more RAM) ;-) 4. go to Wolfsburg 5. crash No, I don't know why Wolfsburg :-) I suppose it is (IIRC) an equatorial climate, very humid, so the server has to manage pools and plants and whatnot *PLUS* the town itself... []s, |alo +---- -- Those who trade freedom for security lose both and deserve neither. -- http://www.laranja.org/ mailto:lalo@laranja.org pgp key: http://garfield.laranja.org/~lalo/gpgkey-signed.asc GNU: never give up freedom http://www.gnu.org/ _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Fri Jul 30 09:50:27 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:52 2005 Subject: [CF-Devel] Weather level 5 (Re: Weather needs smoothing) Message-ID: One thing that is a problem is that it seems the weather is the same all over. The equator should be at the bottom of the map IMO instead of in the middle so we get more temprature extreems. Also we need a no-smooting tile for map devs to disable smootHing on a tile by tile basis (I need this for some rocky-cliff-to-water trasitions... the water should'nt climb up the cliff!) ---- Original Message ---- From: Lalo Martins Date: Fri 7/30/04 8:27 To: crossfire-devel@lists.real-time.com Subject: [CF-Devel] Weather level 5 (Re: Weather needs smoothing) The reason *I* don't run level 5 is that it eats RAM like crazy. I know it's supposed to, but if someone could check for leaks, I'd feel better. Recipe for crashing your server: 1. run with 128Mb or less 2. run with weather on lvl 5 3. open a client (if possible in the same machine to eat more RAM) ;-) 4. go to Wolfsburg 5. crash No, I don't know why Wolfsburg :-) I suppose it is (IIRC) an equatorial climate, very humid, so the server has to manage pools and plants and whatnot *PLUS* the town itself... []s, |alo +---- -- Those who trade freedom for security lose both and deserve neither. -- http://www.laranja.org/ mailto:lalo@laranja.org pgp key: http://garfield.laranja.org/~lalo/gpgkey-signed.asc GNU: never give up freedom http://www.gnu.org/ _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Fri Jul 30 12:53:12 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:52 2005 Subject: =?iso-8859-1?Q?Re:=20[CF-Devel]=20No-Smooth=20tile=20arch=20needed?= Message-ID: Set smoothlevel to 254 and the arch will be on top of the surrounding arches. I recall the plan was that smooth level 0 would disable smoothing for the arch but am not sure this was implemented in the code. > > Mapmakers need a tile that specifies no smoothing for the tile it is placed on... I > > need such an arch on some of my maps... > > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Fri Jul 30 13:03:07 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:52 2005 Subject: =?iso-8859-1?Q?Re:=20[CF-Devel]=20Weather=20level=205=20(Re:=20Weather=20needs=20smoothing)?= Message-ID: Level 5 weather is not just weather but erosion/climate as well I think - it is a lot to process on the maps beacuse it would change ground arches such as swamp to desert as well as do 'weather'. There are still a few places (mostly cities) where there are no elevation of the landscape as well which may or may not be a problem for the code. In the least it will result in very active weather as it will be a big hole in the elevation map. Weather is still somewhat experimental (and anything above level 3 I had problems with in the past) I believe so there could be leaks or whatnot as well I suppose. There may be problems with the feathering code as well but I would have to check the archives to remember that. > The reason *I* don't run level 5 is that it eats RAM like > crazy. I know it's supposed to, but if someone could check for > leaks, I'd feel better. > > Recipe for crashing your server: > 1. run with 128Mb or less > 2. run with weather on lvl 5 > 3. open a client (if possible in the same machine to eat more > RAM) ;-) > 4. go to Wolfsburg > 5. crash > > No, I don't know why Wolfsburg :-) I suppose it is (IIRC) an > equatorial climate, very humid, so the server has to manage > pools and plants and whatnot *PLUS* the town itself... > > []s, > |alo > +---- > -- > Those who trade freedom for security > lose both and deserve neither. > -- > http://www.laranja.org/ mailto:lalo@laranja.org > pgp key: http://garfield.laranja.org/~lalo/gpgkey-signed.asc > > GNU: never give up freedom http://www.gnu.org/ > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Fri Jul 30 13:09:18 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:52 2005 Subject: [CF-Devel] CF 1.6.0 and CVS compilation errors In-Reply-To: <200407280537.i6S5bOBt013069@coffee.exoss.net> References: <200407280537.i6S5bOBt013069@coffee.exoss.net> Message-ID: <200407301309.21427.tanner@real-time.com> On Wednesday 28 July 2004 12:37 am, ketche@coffee.exoss.net wrote: > > On Sunday 25 July 2004 03:55 am, ketche@coffee.exoss.net wrote: > > > Errors while compiling crossfire server 1.6.0 and CVS: > > > > > > /bin/sh ../libtool --mode=link gcc -g -O2 -o random_map > > > standalone.o ../common/libcross.a librandom_map.a -lm gcc -g -O2 -o > > > random_map standalone.o ../common/libcross.a librandom_map.a -lm ld: > > > Undefined symbols: > > > _atoll > > > make: *** [random_map] Error 1 > > > > > > Any idea on how to fix this? > > > > What operating system? > > Sorry about that, the mailman hates me, I wrote multiple messages. :P > > Mac OS X 10.2 > > I've compiled 1.5.0 on this OS before, the latest client compiled fine, > though. :P When you say latest, you mean 1.7.0? Just want to be clear, so when people google for the answer they get all the info they need. -- Bob Tanner | Phone : (952)943-8700 http://www.mn-linux.org, Minnesota, Linux | Fax : (952)943-8500 Key fingerprint = AB15 0BDF BCDE 4369 5B42 1973 7CF1 A709 2CC1 B288 _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Fri Jul 30 13:11:31 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:52 2005 Subject: [CF-Devel] v1.7.0 client for Debian In-Reply-To: <200407271250.42767.tanner@real-time.com> References: <200407271250.42767.tanner@real-time.com> Message-ID: <200407301311.31655.tanner@real-time.com> On Tuesday 27 July 2004 12:50 pm, Bob Tanner wrote: > Just need to add the following to your /etc/apt/sources.list file > > # Real Time custom repository > deb ftp://ftp.real-time.com/linux/real-time unstable custom > deb-src ftp://ftp.real-time.com/linux/real-time unstable custom > > Then > > # apt-get update > # apt-get install crossfire-client-gtk > OR > # apt-get install crossfire-client-x11 > > I have i386, powerpc, and sparc .deb available. IF you are not running unstable you will need to set a target to get these RPMs. apt-get -t unstable install Thanks Todd for the info. -- Bob Tanner | Phone : (952)943-8700 http://www.mn-linux.org, Minnesota, Linux | Fax : (952)943-8500 Key fingerprint = AB15 0BDF BCDE 4369 5B42 1973 7CF1 A709 2CC1 B288 _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Fri Jul 30 12:34:10 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:53 2005 Subject: [CF-Devel] Weather level 5 (Re: Weather needs smoothing) In-Reply-To: <20040730123048.GA11198@laranja.org> References: <20040730123048.GA11198@laranja.org> Message-ID: <200407301934.24538.tchize@myrealbox.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Weather code, IMO, need a complete redo. The guy who coded this, i think had too great ambitions for a MORPG. When you look at code you see it simulate seasons, humidity, temperature, wind, gulf stream (no you are not dreaming), altitude, and am not sure but probably earth rotation. All this to tell you the code is far too heavy and has become to complicated to manage. Already tried to fix leaks, improved speed, but i ended up breaking some other things. Yes this code use memory, and a lot of CPU, and in the end you end up with problems like duplicating object (hope this has been fixed since) and crashes. But i think there were great things in this code that should be kept! 1) terrain change as climate change (eg snowed mountains) 2) plants are growing (a good tihng to make the world alive) 3) snow and rain change as you change location (but current calculation is too complicated, all i need as player is too see climate change and perhaps moutians area colder and mor humid than sandy areas). This could be complete random player won't see difference. No need for climate predicitons. 4) Day/Night. Also important on a RPG But the following could be changed/added 1) No gulfstream (simply reducing speed of climat echange at seaside is enough to simulate) 2) Better drawing for rain (I have seen player trying to fight those blops) Some small circles would be enough, perhaps adding smoothing to this would be good (you just need to set a good smoothlevel (say big case on top of most things) and draw the smooth picture. No need to make it floor as smoothing isn't restricted to floor (any visible arch can be smoothed!!!) 3) No large scale calculation, i think creating randmoly some clouds and then moving the smoothly along the land until they are empty would be good enough to simulate some small climate. 4) need some way to tell client 'hey it's raining' or 'hey it's snowing' so it can do some special effect (sound of water drop, snowflakes, etc...) And we can make the difference between 'it's snowing' and 'snow has dropped here a few minutes ago, it's full on ground' 5) Perhaps create a life cycle for plant (a rose is not suppose to survive on full snow ground, grass starts to die put in sun for too long) The last 2 points are not the most important and may need lots of work, but the rest could be done quite easily (easy to say, difficult to do, like usual). Anyway, i dunno what's your opinion but mine is current weather code is jeopardy to activate on server and personnaly i don't want to touch it anymore (too difficult to maintain). Ok, time to rush to the theater for king arthur movie, bye all! Le vendredi 30 Juillet 2004 14:30, Lalo Martins a ?crit : The reason *I* don't run level 5 is that it eats RAM like crazy. I know it's supposed to, but if someone could check for leaks, I'd feel better. Recipe for crashing your server: 1. run with 128Mb or less 2. run with weather on lvl 5 3. open a client (if possible in the same machine to eat more RAM) ;-) 4. go to Wolfsburg 5. crash No, I don't know why Wolfsburg :-) I suppose it is (IIRC) an equatorial climate, very humid, so the server has to manage pools and plants and whatnot *PLUS* the town itself... []s, |alo +---- - -- Those who trade freedom for security lose both and deserve neither. - -- http://www.laranja.org/ mailto:lalo@laranja.org pgp key: http://garfield.laranja.org/~lalo/gpgkey-signed.asc GNU: never give up freedom http://www.gnu.org/ _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel - -- - -- Tchize (David Delbecq) tchize@myrealbox.com Public PGP KEY FINGERPRINT: ? ? F4BC EF69 54CC F2B5 4621 ?8DAF 1C71 8E6B 5436 C17C Public PGP KEY location: ? ? http://wwwkeys.pgp.net/pgpnet/wwwkeys.html -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBCoaaHHGOa1Q2wXwRAjKwAKCVVRAeIFKhSG1BQm9zb71xXUe5TACfRLzh XhVqZp1pqjdFJsDZDRQvFyw= =FPQ9 -----END PGP SIGNATURE----- _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Fri Jul 30 12:34:32 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:53 2005 Subject: [CF-Devel] No-Smooth tile arch needed In-Reply-To: References: Message-ID: <200407301934.33179.tchize@myrealbox.com> Skipped content of type multipart/signed-------------- next part -------------- _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Sat Jul 31 01:35:19 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:53 2005 Subject: [CF-Devel] Weather level 5 (Re: Weather needs smoothing) Message-ID: <1091255719.d644639cyann.chachkoff@myrealbox.com> Just my two cents on the topic of weather... > Weather code, IMO, need a complete redo. The guy who coded this, i think had too great ambitions for a MORPG. When you look at code you see it simulate seasons, humidity, temperature, wind, gulf stream (no you are not dreaming), altitude, and am not sure but probably earth rotation. Well, I basically agree with the idea of a redo. The code seems to have been written without any planification of some sort. This resulted in a somewhat patchy code that became a bit hard to follow and eventually improve. The question of too high ambitions is different, though, IMHO. The parameters included in the weather simulated model weren't different from what you could find in some computer Wargames of the early 90ies. And if programmers and computers of those barbarian dark ages were able to manage them, I suppose it should still be possible today. Yet the question of usefulness of some parameters needs to be asked - it may be more accurate to simulate the gulfstream effect, but if it has no significant impact on the game itself, it is a bit useless. >But i think there were great things in this code that should be kept! > 1) terrain change as climate change (eg snowed mountains) Definitely a good idea. > 2) plants are growing (a good tihng to make the world alive) Again, an interesting one, but that needs some refining. The current implementation is basically incomplete (trees aren't included in the system, plants grow but - AFAICT - never die, etc.) > 3) snow and rain change as you change location (but current calculation is too complicated, all i need as player is too see climate change and perhaps moutians area colder and mor humid than sandy areas). This could be complete random player won't see difference. No need for climate predicitons. My objection to this is that a (somewhat) deterministic system allows interesting game manipulations (which are not used ATM): adventurers could for example prepare themselves for an expedition in the Nagora Ice Desert by asking a Wizard to tell them if the weather will be good or bad. Weather forecasting may give you a tactical advantage in a couple of situations, so I'm not sure it should be thrown out of the window too quickly. Now it is true that computation definitely needs to be improved in a way or another. > But the following could be changed/added > 1) No gulfstream (simply reducing speed of climat echange at seaside is enough to simulate) I'd say "better gulfstream" - which covers the idea of simplifying the concept. > 2) Better drawing for rain (I have seen player trying to fight those blops) Some small circles would be enough, perhaps adding smoothing to this would be good (you just need to set a good smoothlevel (say big case on top of most things) and draw the smooth picture. No need to make it floor as smoothing isn't restricted to floor (any visible arch can be smoothed!!!) My idea is that rain shouldn't appear on the tiles below the player - I think it would be much better if a topmost layer was used to represent rainfall (or snowfall). This way, it wouldn't be confused with items lying on the floor. Now, one could object that you need to represent the fact that the floor is becoming wet, something my proposal wouldn't display. Well, do we represent the fact that a floor is dusty or covered with blood ? My own opinion is that an graphically non-intrusive representation would be far than enough for what's mostly a secondary parameter. Just adding an adjective to the description of the floor should suffice for most (if not all) purposes. > 3) No large scale calculation, i think creating randmoly some clouds and then moving the smoothly along the land until they are empty would be good enough to simulate some small climate. Agreed, but again with a reserve against a completely random system. You should be able to explicitely define areas producing the clouds, as well as the quantity of those (either directly or through the combination of the various weather parameters). > 4) need some way to tell client 'hey it's raining' or 'hey it's snowing' so it can do some special effect (sound of water drop, snowflakes, etc...) And we can make the difference between 'it's snowing' and 'snow has dropped here a few minutes ago, it's full on ground' See point 2) above. > 5) Perhaps create a life cycle for plant (a rose is not suppose to survive on full snow ground, grass starts to die put in sun for too long) Agreed. I think it was the initial intempt, but for some unknown reason, it never got finished. > The last 2 points are not the most important and may need lots of work, but the rest could be done quite easily (easy to say, difficult to do, like usual). 4) and 5) are mostly consequences of a weather system rather than part of it, so it definitely gets lower priority IMO. > Anyway, i dunno what's your opinion but mine is current weather code is jeopardy to activate on server and personnaly i don't want to touch it anymore (too difficult to maintain). So you already reached the point of making it work ? You went further than me, then :) Seriously, the current weather code is unstable and nearly unusable. At best, it can probably gives clues on how to (re)implement it properly. > Ok, time to rush to the theater for king arthur movie, bye all! Not really a great movie, wasn't it ? :) _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Sat Jul 31 01:41:33 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:53 2005 Subject: [CF-Devel] More patches and things to consider Message-ID: <20040731064132.GA2573@kevin> Patches I uploaded to Sourceforge patch tracker ================================================== Oops. I forgot to say that I think these could go into CVS. * 1001086: Say something when script not found (Unix) Doesn't appear on front page, perhaps because it's for the client? :S * 1001081: Crossedit: copy script events when copying. * 1001079: Make "alchemy" books say which skill. Other things I'm not sure of ============================== These are ideas, some with code. What do you think of them? Server ------- Modify the value of any generated spellbook that currently has the value of its clone, rather than only ones with a random spell.: This means you can plonk a spellbook and the spellarch on a map, and let the arch writers worry about how much its worth. If you've set the value of the spellbook, on the other hand, it won't be touched. Looking at a spellbook: Rather than "foo is a 9 level bar spell", "foo is a ninth level bar spell". There turned out to be a function for that sort of thing in common/item.c, I think. Argh! Void pointers! Last time I looked there's a couple of places in the Python plugin that possibly assume ints and longs were passed by reference rather than by value, causing '*(int *)' to have unexpected values. I'm not sure which way around's the one intended by the plugin system's author, though. Documentation: I added a few lines to two of the player-help documents in my local CVS tree. Should I share them? Client ------- "-nometaserver" option: It's useful for testing the client offline. However, my implementation can't change the flag during runtime. local-command table and fnu help system: I got a bit carried away, and now my local client source tree has an array of the client-local commands, *and* functions for getting help on them. This allows the list of client commands ('help commands') to be generated, and to keep the help for each command with the command. I even changed the GTK help dialog so you can type a command name in. Inventory filter: * Describe different filters in one place in the code. * Filter your inventory in different ways. For GTK users, this means you can redefine the tabs. * Get a client-script to filter your inventory! (One beat behind the game, though. :( ) * Untested: custom sorting inventory, too. This one I'm particularly unsure of. I have a working implementation, but it's complicated to use. If you *do* like the idea, I'd like to hear how you think it should work. -- Thanks, -- Kevin "Third Time's a Rotten Black Pudding" Rudat Has been bitten by semantics before. Sci-Fi/Fantasy ... type. Pretends to know a bit of programming. Very bad manners. Terrible posture and co-ordination. A forgetful ... wha? Humans are an example of a species rushed to life without proper testing... they have LOTS of bugs to fix. ;> _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Sat Jul 31 04:02:08 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:53 2005 Subject: [CF-Devel] More patches and things to consider Message-ID: <1091264528.d638ea3cyann.chachkoff@myrealbox.com> >Argh! Void pointers! > Last time I looked there's a couple of places in the Python plugin that possibly assume ints and longs were passed by reference rather than by value, causing '*(int *)' to have unexpected values. > I'm not sure which way around's the one intended by the plugin system's author, though. Yes, void pointers. A bit of explanation is probably needed about them. In its initial version, the plugin was simply a dynamically shared library calling the Crossfire functions directly. This wasn't working on a couple of implementations, because functions from the 'common' part ended out-of-context (the plugin and the server accessed two different 'copies' of those, resulting in bad results). The solution was to provide wrappers to those functions from the server context itself (I admit it, it is not the most elegant solution - I'd have scrapped the whole common/server split away myself, but I'm not the only one to decide such drastical changes). That's what you can find in server/plugins.c and include/plugin.h. Because of the dynamical binding requirements, it was easier and cleaner to export only one function prototype for all wrappers: it gets one CFParm* as parameter, and returns one CFParm* as a result. And since it had to hold various data types, CFParm.Value is defined as an array of void*. Most void* data conversions made in the plugin context belong to that category. The same holds true for the event calls. Another common occurence of a strange typecasting in the plugin may be found when passing game objects from/to the plugin. This was simply to avoid the need of custom types handling in the Python interface - by wrapping pointers into long values, PyArg_ParseTuple() could be used directly without the need of further code. Admittedly, this is fundamentally unclean programming - but it worked in a way that was compatible with both 32 and 64-bit architectures. The Python plugin itself isn't supposed to modify that value manually - it should always rely on the internal functions of the server to manage objects. It is now very well possible that mistakes were made in some places between references and values; if you give me pointers to the problematic section(s) of the code, it would be a pleasure to correct them. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Sat Jul 31 04:33:47 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:53 2005 Subject: [CF-Devel] Windows server 1.6.1 release. Message-ID: <410B677B.1090406@laposte.net> I've gone ahead and released server 1.6.1 for Windows, which fixes the items worthless bug. Accidentally made a 'crossfire-server' release 1.6.1 (and sent notice), sorry to users monitoring that release. Nicolas 'Ryo' _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Sat Jul 31 08:40:15 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:53 2005 Subject: [CF-Devel] Ghosting problem, weather thoughts Message-ID: Ghosting is a big problem still. Especially when using special-case map-tiling: Spiral tower. M1 M2 M4 M3 M5 M6 M4 M7 Also I think having gulfstream etc is a nice touch, ancient games had it. What should be done is the original author should be contacted and comment his code. A reworking could work too though... (just keep all the features please, I run my server with dynamic level 5 (cat2.ath.cx) but it does have a fair amount of ram). _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Sat Jul 31 10:58:17 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:53 2005 Subject: [CF-Devel] Building Message-ID: About building. Where can I build. And im thinking about making lots in one of my maps to be purchased. What do I set on the tiles so they are buildable?. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Sat Jul 31 11:25:12 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:53 2005 Subject: [CF-Devel] Building In-Reply-To: References: Message-ID: <410BC7E8.7000104@laposte.net> > About building. Where can I build. And im thinking about making lots in one of my > > maps to be purchased. What do I set on the tiles so they are buildable?. To make a spot buildable, you need to make the floor 'unique', and set 'is_buildable' to 1 (isn't listed in properties, set it manually) on all items on the square. Nicolas 'Ryo' _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Sat Jul 31 08:51:55 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:53 2005 Subject: [CF-Devel] CF 1.6.0 and CVS compilation errors In-Reply-To: <200407301309.21427.tanner@real-time.com> from "Bob Tanner" at Jul 30, 2004 01:09:18 PM Message-ID: <200407311351.i6VDpuN4004259@coffee.exoss.net> > > On Wednesday 28 July 2004 12:37 am, ketche@coffee.exoss.net wrote: > > > On Sunday 25 July 2004 03:55 am, ketche@coffee.exoss.net wrote: > > > > Errors while compiling crossfire server 1.6.0 and CVS: > > > > > > > > /bin/sh ../libtool --mode=link gcc -g -O2 -o random_map > > > > standalone.o ../common/libcross.a librandom_map.a -lm gcc -g -O2 -o > > > > random_map standalone.o ../common/libcross.a librandom_map.a -lm ld: > > > > Undefined symbols: > > > > _atoll > > > > make: *** [random_map] Error 1 > > > > > > > > Any idea on how to fix this? > > > > > > What operating system? > > > > Sorry about that, the mailman hates me, I wrote multiple messages. :P > > > > Mac OS X 10.2 > > > > I've compiled 1.5.0 on this OS before, the latest client compiled fine, > > though. :P > > When you say latest, you mean 1.7.0? Yes... 1.7.0.... > > Just want to be clear, so when people google for the answer they get all the > info they need. > > -- > Bob Tanner | Phone : (952)943-8700 > http://www.mn-linux.org, Minnesota, Linux | Fax : (952)943-8500 > Key fingerprint = AB15 0BDF BCDE 4369 5B42 1973 7CF1 A709 2CC1 B288 > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel