From nicolas.weeger at laposte.net Sat Oct 2 04:02:55 2010 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sat, 2 Oct 2010 11:02:55 +0200 Subject: [crossfire] sound2 protocol and issues: sound_chance In-Reply-To: <4CA425C4.1060806@sonic.net> References: <201009252035.02891.kbulgrien@att.net> <201009291826.10750.nicolas.weeger@laposte.net> <4CA425C4.1060806@sonic.net> Message-ID: <201010021102.56294.nicolas.weeger@laposte.net> > Using a string for action name is probably fine, OTOH, there is > presumably a finite (and actually quite small) set of actions. Since > right now, all the play_sound calls are basically hardcoded on where they > get called, putting in an integer type would be fairly easy. What about plugins being able to send an arbitrary sound? > That would mean there is the potential for the client getting an event > type it doesn't know how to handle - but at the same time, if the client > doesn't know how to handle that event type, it would be equally likely it > would not have a matching sound file for that even either. Unless it can request it from some place. Nicolas -- Mon p'tit coin du web - http://nicolas.weeger.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20101002/ee9df2bd/attachment.pgp From nicolas.weeger at laposte.net Sat Oct 2 04:05:17 2010 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sat, 2 Oct 2010 11:05:17 +0200 Subject: [crossfire] Container dropping behaviour In-Reply-To: <4CA42BBF.6050102@sonic.net> References: <201009261248.41978.nicolas.weeger@laposte.net> <201009291838.23956.nicolas.weeger@laposte.net> <4CA42BBF.6050102@sonic.net> Message-ID: <201010021105.17707.nicolas.weeger@laposte.net> > Yes and no. Once the container has been opened, the client does know, > because it gets an inventory of that container, because the location > objects for it will have that container. Except you currently don't need to open a container to empty it. Which is good thing imo :) > I'm more in favor of re-doing all the mouse operations. > > singe left click = select (by itself, may not mean much) > double click == apply (mor standard behavior) > right click = bring up context menu of item actions (drop, lock, examine, > etc) > > Now one could allow other mousebindings as shortcuts, but I think right > now some of the control/shift/left click vs right click vs whatever is > really not a simple solution. > > I'm also thinking that at least for the gtk client, have a window like > the spell or other windows that can be brought up that provides much more > detailed (and easier to control actions) for objects could be nice - if > I'm in the shop, I don't really care about the map that much and care much > more objects objects in my inventory and being able to more easily see all > relevant information would be nice. No issue with that kind of changes :) Nicolas -- Mon p'tit coin du web - http://nicolas.weeger.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20101002/c6be0755/attachment.pgp From nicolas.weeger at laposte.net Sat Oct 2 04:03:46 2010 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sat, 2 Oct 2010 11:03:46 +0200 Subject: [crossfire] sound2 protocol and issues: sound_chance In-Reply-To: <20100929233401.3f78d16a@srv_10s.kbulgrien.att.net> References: <201009252035.02891.kbulgrien@att.net> <201009291832.36789.nicolas.weeger@laposte.net> <20100929233401.3f78d16a@srv_10s.kbulgrien.att.net> Message-ID: <201010021103.46801.nicolas.weeger@laposte.net> > The sound_chance feature prevents it from reaching the client. > > > The idea was to just send free-form strings, to enable clients to > > "override" sounds. > > Really, on trunk, sounds are entirely disabled at present due to these > changes. True. I guess I expected to work on that after changing the sound system, or hoping others would help :) Nicolas -- Mon p'tit coin du web - http://nicolas.weeger.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20101002/40a24814/attachment.pgp From mwedel at sonic.net Tue Oct 12 01:15:48 2010 From: mwedel at sonic.net (Mark Wedel) Date: Mon, 11 Oct 2010 23:15:48 -0700 Subject: [crossfire] broken configure on opensolaris Message-ID: <4CB3FD14.1050101@sonic.net> The following revision has broken the ability to build crossfire on opensolaris - now I admit that is probably a pretty small audience (me), but I also don't know if this might cause issues for other users if this is a minimum required version of aclocal/automake/autoconf for example (if this change was only done/tested on a system which had the latest versions of those utilities, that might also be an incomplete test). But I'm not sure if the error is in the actual changes/minimum versions, or if maybe something in my toolchain itself is broken. I suspect the issue is that my system has libtool 1.5.22 installed - fairly old, but I would guess that if libtool 2.x is needed, that should probably be noted someplace (I don't know if autogen.sh should perhaps be modified to do minimum version checking if needed?) I think we have run into this in the past with needing minimum version of automake also. I'm going to try and download latest libtool and see if that works (I suspect it will). But I guess at the same time, it would have saved me a bunch of time if autogen (or something) just spit out "you need > 2.0 of libtool" type of thing. The revision in question: --- r13979 | anmaster | 2010-10-09 14:14:22 -0700 (Sat, 09 Oct 2010) | 10 lines Do not make symbols globally visible by default on *nix (when supported), on Windows this is always the case. To prevent hidden errors (since most developers seem to test on *nix), use -fvisibility=hidden when GCC is used and make the MODULEAPI and CF_PLUGIN macros use __attribute__ to mark those as visible. This will not break on any compiler not supporting this, but will prevent future hidden errors of this type. A further advantage with this is that it reduces risk of symbol name collision between various dynamic objects. --- (If I change the macros and configure.ac to the version prior to that, all works fine). Below is output of running autogen.sh: [hugin:/export/home/crossfire/SVN/server/trunk] (54) % sh autogen.sh You should update your `aclocal.m4' by running aclocal. Putting files in AC_CONFIG_AUX_DIR, `utils'. /usr/share/aclocal/aalib.m4:12: warning: underquoted definition of AM_PATH_AALIB /usr/share/aclocal/aalib.m4:12: run info '(automake)Extending aclocal' /usr/share/aclocal/aalib.m4:12: or see http://sources.redhat.com/automake/automake.html#Extending-aclocal configure.ac:17: warning: AC_CACHE_VAL(lt_prog_compiler_pic_works, ...): suspicious cache-id, must contain _cv_ to be cached ../../lib/autoconf/general.m4:1974: AC_CACHE_VAL is expanded from... ../../lib/autoconf/general.m4:1994: AC_CACHE_CHECK is expanded from... macros/libtool.m4:615: AC_LIBTOOL_COMPILER_OPTION is expanded from... macros/libtool.m4:4815: AC_LIBTOOL_PROG_COMPILER_PIC is expanded from... macros/libtool.m4:2651: _LT_AC_LANG_C_CONFIG is expanded from... macros/libtool.m4:2650: AC_LIBTOOL_LANG_C_CONFIG is expanded from... macros/libtool.m4:80: AC_LIBTOOL_SETUP is expanded from... macros/libtool.m4:60: _AC_PROG_LIBTOOL is expanded from... macros/libtool.m4:25: AC_PROG_LIBTOOL is expanded from... configure.ac:17: the top level configure.ac:17: warning: AC_CACHE_VAL(lt_prog_compiler_static_works, ...): suspicious cache-id, must contain _cv_ to be cached macros/libtool.m4:660: AC_LIBTOOL_LINKER_OPTION is expanded from... configure.ac:17: warning: AC_CACHE_VAL(lt_prog_compiler_pic_works_CXX, ...): suspicious cache-id, must contain _cv_ to be cached macros/libtool.m4:2732: _LT_AC_LANG_CXX_CONFIG is expanded from... macros/libtool.m4:2731: AC_LIBTOOL_LANG_CXX_CONFIG is expanded from... macros/libtool.m4:1787: _LT_AC_TAGCONFIG is expanded from... configure.ac:17: warning: AC_CACHE_VAL(lt_prog_compiler_static_works_CXX, ...): suspicious cache-id, must contain _cv_ to be cached configure.ac:17: warning: AC_CACHE_VAL(lt_prog_compiler_pic_works_F77, ...): suspicious cache-id, must contain _cv_ to be cached macros/libtool.m4:3899: _LT_AC_LANG_F77_CONFIG is expanded from... macros/libtool.m4:3898: AC_LIBTOOL_LANG_F77_CONFIG is expanded from... configure.ac:17: warning: AC_CACHE_VAL(lt_prog_compiler_static_works_F77, ...): suspicious cache-id, must contain _cv_ to be cached configure.ac:17: warning: AC_CACHE_VAL(lt_prog_compiler_pic_works_GCJ, ...): suspicious cache-id, must contain _cv_ to be cached macros/libtool.m4:4001: _LT_AC_LANG_GCJ_CONFIG is expanded from... macros/libtool.m4:4000: AC_LIBTOOL_LANG_GCJ_CONFIG is expanded from... configure.ac:17: warning: AC_CACHE_VAL(lt_prog_compiler_static_works_GCJ, ...): suspicious cache-id, must contain _cv_ to be cached configure.ac:17: warning: AC_CACHE_VAL(lt_prog_compiler_pic_works, ...): suspicious cache-id, must contain _cv_ to be cached ../../lib/autoconf/general.m4:1974: AC_CACHE_VAL is expanded from... ../../lib/autoconf/general.m4:1994: AC_CACHE_CHECK is expanded from... macros/libtool.m4:615: AC_LIBTOOL_COMPILER_OPTION is expanded from... macros/libtool.m4:4815: AC_LIBTOOL_PROG_COMPILER_PIC is expanded from... macros/libtool.m4:2651: _LT_AC_LANG_C_CONFIG is expanded from... macros/libtool.m4:2650: AC_LIBTOOL_LANG_C_CONFIG is expanded from... macros/libtool.m4:80: AC_LIBTOOL_SETUP is expanded from... macros/libtool.m4:60: _AC_PROG_LIBTOOL is expanded from... macros/libtool.m4:25: AC_PROG_LIBTOOL is expanded from... configure.ac:17: the top level configure.ac:17: warning: AC_CACHE_VAL(lt_prog_compiler_static_works, ...): suspicious cache-id, must contain _cv_ to be cached macros/libtool.m4:660: AC_LIBTOOL_LINKER_OPTION is expanded from... configure.ac:17: warning: AC_CACHE_VAL(lt_prog_compiler_pic_works_CXX, ...): suspicious cache-id, must contain _cv_ to be cached macros/libtool.m4:2732: _LT_AC_LANG_CXX_CONFIG is expanded from... macros/libtool.m4:2731: AC_LIBTOOL_LANG_CXX_CONFIG is expanded from... macros/libtool.m4:1787: _LT_AC_TAGCONFIG is expanded from... configure.ac:17: warning: AC_CACHE_VAL(lt_prog_compiler_static_works_CXX, ...): suspicious cache-id, must contain _cv_ to be cached configure.ac:17: warning: AC_CACHE_VAL(lt_prog_compiler_pic_works_F77, ...): suspicious cache-id, must contain _cv_ to be cached macros/libtool.m4:3899: _LT_AC_LANG_F77_CONFIG is expanded from... macros/libtool.m4:3898: AC_LIBTOOL_LANG_F77_CONFIG is expanded from... configure.ac:17: warning: AC_CACHE_VAL(lt_prog_compiler_static_works_F77, ...): suspicious cache-id, must contain _cv_ to be cached configure.ac:17: warning: AC_CACHE_VAL(lt_prog_compiler_pic_works_GCJ, ...): suspicious cache-id, must contain _cv_ to be cached macros/libtool.m4:4001: _LT_AC_LANG_GCJ_CONFIG is expanded from... macros/libtool.m4:4000: AC_LIBTOOL_LANG_GCJ_CONFIG is expanded from... configure.ac:17: warning: AC_CACHE_VAL(lt_prog_compiler_static_works_GCJ, ...): suspicious cache-id, must contain _cv_ to be cached configure.ac:17: warning: AC_CACHE_VAL(lt_prog_compiler_pic_works, ...): suspicious cache-id, must contain _cv_ to be cached ../../lib/autoconf/general.m4:1974: AC_CACHE_VAL is expanded from... ../../lib/autoconf/general.m4:1994: AC_CACHE_CHECK is expanded from... macros/libtool.m4:615: AC_LIBTOOL_COMPILER_OPTION is expanded from... macros/libtool.m4:4815: AC_LIBTOOL_PROG_COMPILER_PIC is expanded from... macros/libtool.m4:2651: _LT_AC_LANG_C_CONFIG is expanded from... macros/libtool.m4:2650: AC_LIBTOOL_LANG_C_CONFIG is expanded from... macros/libtool.m4:80: AC_LIBTOOL_SETUP is expanded from... macros/libtool.m4:60: _AC_PROG_LIBTOOL is expanded from... macros/libtool.m4:25: AC_PROG_LIBTOOL is expanded from... configure.ac:17: the top level configure.ac:17: warning: AC_CACHE_VAL(lt_prog_compiler_static_works, ...): suspicious cache-id, must contain _cv_ to be cached macros/libtool.m4:660: AC_LIBTOOL_LINKER_OPTION is expanded from... configure.ac:17: warning: AC_CACHE_VAL(lt_prog_compiler_pic_works_CXX, ...): suspicious cache-id, must contain _cv_ to be cached macros/libtool.m4:2732: _LT_AC_LANG_CXX_CONFIG is expanded from... macros/libtool.m4:2731: AC_LIBTOOL_LANG_CXX_CONFIG is expanded from... macros/libtool.m4:1787: _LT_AC_TAGCONFIG is expanded from... configure.ac:17: warning: AC_CACHE_VAL(lt_prog_compiler_static_works_CXX, ...): suspicious cache-id, must contain _cv_ to be cached configure.ac:17: warning: AC_CACHE_VAL(lt_prog_compiler_pic_works_F77, ...): suspicious cache-id, must contain _cv_ to be cached macros/libtool.m4:3899: _LT_AC_LANG_F77_CONFIG is expanded from... macros/libtool.m4:3898: AC_LIBTOOL_LANG_F77_CONFIG is expanded from... configure.ac:17: warning: AC_CACHE_VAL(lt_prog_compiler_static_works_F77, ...): suspicious cache-id, must contain _cv_ to be cached configure.ac:17: warning: AC_CACHE_VAL(lt_prog_compiler_pic_works_GCJ, ...): suspicious cache-id, must contain _cv_ to be cached macros/libtool.m4:4001: _LT_AC_LANG_GCJ_CONFIG is expanded from... macros/libtool.m4:4000: AC_LIBTOOL_LANG_GCJ_CONFIG is expanded from... configure.ac:17: warning: AC_CACHE_VAL(lt_prog_compiler_static_works_GCJ, ...): suspicious cache-id, must contain _cv_ to be cached configure.ac:17: warning: AC_CACHE_VAL(lt_prog_compiler_pic_works, ...): suspicious cache-id, must contain _cv_ to be cached ../../lib/autoconf/general.m4:1974: AC_CACHE_VAL is expanded from... ../../lib/autoconf/general.m4:1994: AC_CACHE_CHECK is expanded from... macros/libtool.m4:615: AC_LIBTOOL_COMPILER_OPTION is expanded from... macros/libtool.m4:4815: AC_LIBTOOL_PROG_COMPILER_PIC is expanded from... macros/libtool.m4:2651: _LT_AC_LANG_C_CONFIG is expanded from... macros/libtool.m4:2650: AC_LIBTOOL_LANG_C_CONFIG is expanded from... macros/libtool.m4:80: AC_LIBTOOL_SETUP is expanded from... macros/libtool.m4:60: _AC_PROG_LIBTOOL is expanded from... macros/libtool.m4:25: AC_PROG_LIBTOOL is expanded from... configure.ac:17: the top level configure.ac:17: warning: AC_CACHE_VAL(lt_prog_compiler_static_works, ...): suspicious cache-id, must contain _cv_ to be cached macros/libtool.m4:660: AC_LIBTOOL_LINKER_OPTION is expanded from... configure.ac:17: warning: AC_CACHE_VAL(lt_prog_compiler_pic_works_CXX, ...): suspicious cache-id, must contain _cv_ to be cached macros/libtool.m4:2732: _LT_AC_LANG_CXX_CONFIG is expanded from... macros/libtool.m4:2731: AC_LIBTOOL_LANG_CXX_CONFIG is expanded from... macros/libtool.m4:1787: _LT_AC_TAGCONFIG is expanded from... configure.ac:17: warning: AC_CACHE_VAL(lt_prog_compiler_static_works_CXX, ...): suspicious cache-id, must contain _cv_ to be cached configure.ac:17: warning: AC_CACHE_VAL(lt_prog_compiler_pic_works_F77, ...): suspicious cache-id, must contain _cv_ to be cached macros/libtool.m4:3899: _LT_AC_LANG_F77_CONFIG is expanded from... macros/libtool.m4:3898: AC_LIBTOOL_LANG_F77_CONFIG is expanded from... configure.ac:17: warning: AC_CACHE_VAL(lt_prog_compiler_static_works_F77, ...): suspicious cache-id, must contain _cv_ to be cached configure.ac:17: warning: AC_CACHE_VAL(lt_prog_compiler_pic_works_GCJ, ...): suspicious cache-id, must contain _cv_ to be cached macros/libtool.m4:4001: _LT_AC_LANG_GCJ_CONFIG is expanded from... macros/libtool.m4:4000: AC_LIBTOOL_LANG_GCJ_CONFIG is expanded from... configure.ac:17: warning: AC_CACHE_VAL(lt_prog_compiler_static_works_GCJ, ...): suspicious cache-id, must contain _cv_ to be cached checking for a BSD-compatible install... /usr/bin/ginstall -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... utils/install-sh -c -d checking for gawk... gawk checking whether gmake -j4 sets $(MAKE)... yes ./configure: line 2623: syntax error at line 2627: `(' unexpected Line 2623 of configure on my system is: else enable_shared=yes fi _LT_DECL(build_libtool_libs, enable_shared, 0, Whether or not to build shared libraries) # Check whether --enable-static was given. if test "${enable_static+set}" = set; then From mwedel at sonic.net Tue Oct 12 01:36:13 2010 From: mwedel at sonic.net (Mark Wedel) Date: Mon, 11 Oct 2010 23:36:13 -0700 Subject: [crossfire] broken configure on opensolaris In-Reply-To: <4CB3FD14.1050101@sonic.net> References: <4CB3FD14.1050101@sonic.net> Message-ID: <4CB401DD.50008@sonic.net> On 10/11/10 11:15 PM, Mark Wedel wrote: > I'm going to try and download latest libtool and see if that works (I suspect > it will). But I guess at the same time, it would have saved me a bunch of time > if autogen (or something) just spit out "you need> 2.0 of libtool" type of thing. For the record, using version 2.4 of libtool fixed the problem (I don't know if 2.4 is needed, anything greater than 2.0, etc). But I would still maintain that it might be nice to put a minimum check in for libtool - while it looks like libtool 2.2.2 (first release) is a couple years old, I could also see systems that are not installed with a stable release and the maintainer just sticking with that having older versions of such utilities (I see this more an issue for servers which may be locked away in datacenters or other cohosting facilities than say machines the client is running on) From meflin at meflin.net Tue Oct 12 12:09:09 2010 From: meflin at meflin.net (James Lopeman) Date: Tue, 12 Oct 2010 11:09:09 -0600 Subject: [crossfire] broken configure on opensolaris In-Reply-To: <4CB401DD.50008@sonic.net> References: <4CB3FD14.1050101@sonic.net> <4CB401DD.50008@sonic.net> Message-ID: <201010121109.09683.meflin@meflin.net> This issue is the second time auto-junk has broken on invidious (up to date centos 5.x ). Its a common OS on rented colo/virtual servers. As an example centos uses libtool 1.5.22 ( June 2007 ). This is what invidious is using right now. I fixed mine with a new automake (1.11.1) and autoconf(2.6.3). I'm not sure how a developer is supposed to know what versions of things are on all long release server OS's are, or what combo's are needed to work. Meflin On Tuesday, October 12, 2010 12:36:13 am Mark Wedel wrote: > On 10/11/10 11:15 PM, Mark Wedel wrote: > > I'm going to try and download latest libtool and see if that works (I > > suspect > > > > it will). But I guess at the same time, it would have saved me a bunch > > of time if autogen (or something) just spit out "you need> 2.0 of > > libtool" type of thing. > > For the record, using version 2.4 of libtool fixed the problem (I don't > know if 2.4 is needed, anything greater than 2.0, etc). But I would still > maintain that it might be nice to put a minimum check in for libtool - > while it looks like libtool 2.2.2 (first release) is a couple years old, I > could also see systems that are not installed with a stable release and > the maintainer just sticking with that having older versions of such > utilities (I see this more an issue for servers which may be locked away > in datacenters or other cohosting facilities than say machines the client > is running on) > > > _______________________________________________ > crossfire mailing list > crossfire at metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire From mwedel at sonic.net Wed Oct 13 01:00:04 2010 From: mwedel at sonic.net (Mark Wedel) Date: Tue, 12 Oct 2010 23:00:04 -0700 Subject: [crossfire] broken configure on opensolaris In-Reply-To: <201010121109.09683.meflin@meflin.net> References: <4CB3FD14.1050101@sonic.net> <4CB401DD.50008@sonic.net> <201010121109.09683.meflin@meflin.net> Message-ID: <4CB54AE4.3030002@sonic.net> On 10/12/10 10:09 AM, James Lopeman wrote: > This issue is the second time auto-junk has broken on invidious (up to date > centos 5.x ). Its a common OS on rented colo/virtual servers. > > As an example centos uses libtool 1.5.22 ( June 2007 ). This is what invidious > is using right now. I fixed mine with a new automake (1.11.1) and > autoconf(2.6.3). > > I'm not sure how a developer is supposed to know what versions of things are > on all long release server OS's are, or what combo's are needed to work. Yes - that is really the problem. But I can also see where it is hard from a developer making these changes - he probably has recent versions of those utilities, and the changes made worked on that system, so it is hard to know what the minimum needs really are. In some cases, the documentation may state that information. The GTK documentation states pretty clearly when a particular function was added, so if you are using that, you can know the minimum version of GTK that is needed. I don't know if the auto tools and like do that. But even if they do, it could be tricky - you might see some configure file for some other project and say 'that is a good way of doing it' and copy/paste it - it is unlikely you are going to check the docs to see minimum revisions that are needed for those features. At one point, a decision was made not to include files that are automatically generated (makefiles, configure, etc) in SVN. That is a decision that is still the right one IMO, but does mean that these types of issues show up. I'm just not sure what a good solution is - but what we currently have right now doesn't seem that great. From mwedel at sonic.net Mon Oct 18 02:08:39 2010 From: mwedel at sonic.net (Mark Wedel) Date: Mon, 18 Oct 2010 00:08:39 -0700 Subject: [crossfire] heads up: advanced character creation commit Message-ID: <4CBBF277.7020009@sonic.net> In the next few days, I'll be committing changes for advanced character creation - that has been discussed, but in short summary, it lets player adjust stat points and choose race & class and switch between them before finalizing selection. It also allows them to select their starting map. These changes are to both server and arch area - if you are running a server, you will need to update *both* of them for things to work right. The simple reason behind this is that I added some new archetypes of type 'MAP', but there are different subtypes for that (to note if this is the 'old' starting map, choice of starting maps, etc). If you update the arch without updating the server, things may work, but this is relying on load/search order of the archetypes - most likely player will just not go to the nexus, and instead be taken to one of the starting maps. If you update the server without updating the archetypes, it just won't work - server should generate an error message and abort out. This could be bad if you are running an automated updated/restart script, as it will just cycle. From nicolas.weeger at laposte.net Mon Oct 18 15:09:45 2010 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Mon, 18 Oct 2010 22:09:45 +0200 Subject: [crossfire] heads up: advanced character creation commit In-Reply-To: <4CBBF277.7020009@sonic.net> References: <4CBBF277.7020009@sonic.net> Message-ID: <201010182209.50521.nicolas.weeger@laposte.net> Hello. > In the next few days, I'll be committing changes for advanced character > creation - that has been discussed, but in short summary, it lets player > adjust stat points and choose race & class and switch between them before > finalizing selection. > > It also allows them to select their starting map. Nice, thanks :) If there are client-side or protocol changes, could you commit that in advance, so clients can be updated too to take those new features into account? Nicolas -- Mon p'tit coin du web - http://nicolas.weeger.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20101018/d04966fc/attachment.pgp From mwedel at sonic.net Mon Oct 18 22:59:06 2010 From: mwedel at sonic.net (Mark Wedel) Date: Mon, 18 Oct 2010 20:59:06 -0700 Subject: [crossfire] heads up: advanced character creation commit In-Reply-To: <201010182209.50521.nicolas.weeger@laposte.net> References: <4CBBF277.7020009@sonic.net> <201010182209.50521.nicolas.weeger@laposte.net> Message-ID: <4CBD178A.3010405@sonic.net> On 10/18/10 01:09 PM, Nicolas Weeger wrote: > Hello. > > >> In the next few days, I'll be committing changes for advanced character >> creation - that has been discussed, but in short summary, it lets player >> adjust stat points and choose race& class and switch between them before >> finalizing selection. >> >> It also allows them to select their starting map. > > > Nice, thanks :) > > > If there are client-side or protocol changes, could you commit that in > advance, so clients can be updated too to take those new features into > account? Yes, there are, but the protocol changes are intertwined with other changes. So while having the protocol documentation, and client, would be available, there would be nothing to test against until the server changes are committed. Old clients will still work on the new server, they just won't be able to take advantage of the new features (clearly) - they will be stuck with the existing in-game character creation. So this change won't force folks to update clients to continue to play (or even make new characters) - it will if they want the new features. I can certainly check in the protocol file as well as the client changes and then delay the server and arch changes, I'm just not really sure if that gains anything. One thing I still have to do, which will probably be after this first commit, is selection of other abilities/skills. There is not per race/per class map selection - I just take the choices that were currently in the nexus (scorn, beginners house, navar city). However, dragon players have a special starting map where they can choose their focus - I want to make that part of this creation mechanism. And perhaps of greater value is letting character choose some degree of skills. For example, there are basically 4 wizard classes, all the same except for their starting magic skill - it would be simpler to just have one wizard class, and you just choose what starting skill you want (pyromancy, evocation, summoning, sorcery, etc). This could then, at some point, lead the way into more advanced character creation - don't even really have a class, but rather some ability to just select the skills you want. From mwedel at sonic.net Sun Oct 24 00:33:01 2010 From: mwedel at sonic.net (Mark Wedel) Date: Sat, 23 Oct 2010 22:33:01 -0700 Subject: [crossfire] coinage Message-ID: <4CC3C50D.4030207@sonic.net> So I will admit that it has been a little while since I last actually played crossfire, and so when I fired it up, went to a shop to buy something, I was a little mystified when it said: It would cost you 1 jade coin, 27 platinum coins, 4 gold coins and 9 silver coins. Not that it breaks it up, but rather being somewhat unsure how much that item really costs - how much gold do I really need to buy it? How many jade coins in a gold coin, etc. I could imagine this is also confusing for new players - while one will come across platinum coins in fairly short order, jade coins are not going to show up very quickly (if selling stuff to shops, you will only get them if what you are selling is greater than that amount). The bank does not have a money changer for jade coins. I had advocated in the distance past the coinage ceases to be an object type and basically becomes a stat like ability - this makes it easier for the server to communicate how much money the player has, and also simplifies a lot of code (all code that deals with updating coinage becomes much simpler) - that said, there would be some complications, like depositing money on objects that want coinage, but that could be handled (at least it would remove the need of having money changers in odd locations to cover that case) I'm not sure the ideal solution - having that price say 127 platinum, 4 gold, ... might be better, or 639 gold 9 silver might be better yet. I suppose a clever solution might be to look at the player and see the largest currency they have in their inventory and use that - if I only have gold coins, say 639 gold, 9 silver. If I only have silver, say 6399 silver coins. Alternatively, maybe only list the higher coins if it really high - eg, if more than 1000 units, go up, so if something is 1250 gold, it would be listed as 1250 gold, and not 250 platinum or 2 jade, 5 platinum. If one things about it, when one goes to the store, they don't say "that will be a 5 dollar bill, 2 1 dollar bills, 3 quarters, a dime, and 4 pennies", they just say it will be 7 dollars 89 cents. From nicolas.weeger at laposte.net Sun Oct 24 02:35:34 2010 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sun, 24 Oct 2010 09:35:34 +0200 Subject: [crossfire] coinage In-Reply-To: <4CC3C50D.4030207@sonic.net> References: <4CC3C50D.4030207@sonic.net> Message-ID: <201010240935.41987.nicolas.weeger@laposte.net> > Not that it breaks it up, but rather being somewhat unsure how much that > item really costs - how much gold do I really need to buy it? How many > jade coins in a gold coin, etc. For what is worth, the change that introduced those coins in price display is revision 13983 by yours truly. http://crossfire.svn.sourceforge.net/crossfire/?rev=13983&view=rev Nicolas -- Mon p'tit coin du web - http://nicolas.weeger.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20101024/d5735330/attachment.pgp From anmaster at tele2.se Sun Oct 24 09:31:04 2010 From: anmaster at tele2.se (AnMaster) Date: Sun, 24 Oct 2010 16:31:04 +0200 Subject: [crossfire] broken configure on opensolaris In-Reply-To: <4CB54AE4.3030002@sonic.net> References: <4CB3FD14.1050101@sonic.net> <4CB401DD.50008@sonic.net> <201010121109.09683.meflin@meflin.net> <4CB54AE4.3030002@sonic.net> Message-ID: <4CC44328.6000605@tele2.se> On 2010-10-13 08:00, Mark Wedel wrote: > On 10/12/10 10:09 AM, James Lopeman wrote: >> This issue is the second time auto-junk has broken on invidious (up to date >> centos 5.x ). Its a common OS on rented colo/virtual servers. >> >> As an example centos uses libtool 1.5.22 ( June 2007 ). This is what invidious >> is using right now. I fixed mine with a new automake (1.11.1) and >> autoconf(2.6.3). >> >> I'm not sure how a developer is supposed to know what versions of things are >> on all long release server OS's are, or what combo's are needed to work. > > Yes - that is really the problem. > > But I can also see where it is hard from a developer making these changes - he > probably has recent versions of those utilities, and the changes made worked on > that system, so it is hard to know what the minimum needs really are. I do indeed have recent versions of these tools, but it is more confusing that it broke at all. The test seemed pretty straight forward and I didn't find anything indicating that I used some unsupported feature, I based the new file on the python checking code we already had for this very purpose. I did not commit the updated aclocal.m4 for this very reason. Since it showed that lots of libtool code had changed. I don't have easy access to old versions of the tools. Installing those system wide would probably be quite tricky without completely breaking the system. Installing autotools/libtool stuff outside standard paths never worked for me before (the tools seemed to prefer calling the distro-installed ones anyway, even though the locally installed ones were first in $PATH). > In some cases, the documentation may state that information. The GTK > documentation states pretty clearly when a particular function was added, so if > you are using that, you can know the minimum version of GTK that is needed. > > I don't know if the auto tools and like do that. But even if they do, it > could be tricky - you might see some configure file for some other project and > say 'that is a good way of doing it' and copy/paste it - it is unlikely you are > going to check the docs to see minimum revisions that are needed for those features. Very rarely does autotools documentation state when something was added. > > At one point, a decision was made not to include files that are automatically > generated (makefiles, configure, etc) in SVN. That is a decision that is still > the right one IMO, but does mean that these types of issues show up. Then aclocal.m4, autoconf.h.in and a few more files should go away since they are auto-generated. > > I'm just not sure what a good solution is - but what we currently have right now > doesn't seem that great. /Arvid Norlander From mwedel at sonic.net Sun Oct 24 23:23:52 2010 From: mwedel at sonic.net (Mark Wedel) Date: Sun, 24 Oct 2010 21:23:52 -0700 Subject: [crossfire] coinage In-Reply-To: <201010240935.41987.nicolas.weeger@laposte.net> References: <4CC3C50D.4030207@sonic.net> <201010240935.41987.nicolas.weeger@laposte.net> Message-ID: <4CC50658.5030601@sonic.net> On 10/24/10 12:35 AM, Nicolas Weeger wrote: >> Not that it breaks it up, but rather being somewhat unsure how much that >> item really costs - how much gold do I really need to buy it? How many >> jade coins in a gold coin, etc. > > > For what is worth, the change that introduced those coins in price display is > revision 13983 by yours truly. > > http://crossfire.svn.sourceforge.net/crossfire/?rev=13983&view=rev I was hoping to start some discussion on what people think the best behavior would be. If folks think that giving quotes in high priced coins is fine, I can live with that. I guess I would also consider it odd that while shops will quote prices in amber and jade, they won't hand them out - I'd consider that better - if I sell something that would get me jade coins, it would seem to make sense that I get paid in that. I wonder if there could be a change, like it says something along the lines of: It would cost you 1 jade coin, 27 platinum coins, 4 gold coins and 9 silver coins or 639.9 gold coins (I'm making the presumption that crossfire is on the gold coin standard :) - that gives both, but makes it much simpler to figure out how much money I really need. I'm still in favor of making net worth just a stat, but that would involve a bit more work, but as said before, also simplify a lot of code. The only real disadvantage I can think would be that weight of coins would no longer be an issue. From mwedel at sonic.net Sun Oct 24 23:28:58 2010 From: mwedel at sonic.net (Mark Wedel) Date: Sun, 24 Oct 2010 21:28:58 -0700 Subject: [crossfire] broken configure on opensolaris In-Reply-To: <4CC44328.6000605@tele2.se> References: <4CB3FD14.1050101@sonic.net> <4CB401DD.50008@sonic.net> <201010121109.09683.meflin@meflin.net> <4CB54AE4.3030002@sonic.net> <4CC44328.6000605@tele2.se> Message-ID: <4CC5078A.9080606@sonic.net> On 10/24/10 07:31 AM, AnMaster wrote: > On 2010-10-13 08:00, Mark Wedel wrote: >> At one point, a decision was made not to include files that are automatically >> generated (makefiles, configure, etc) in SVN. That is a decision that is still >> the right one IMO, but does mean that these types of issues show up. > Then aclocal.m4, autoconf.h.in and a few more files should go away since they > are auto-generated. That probably makes sense - at some point all the Makefile.in's were removed since they are generated by automake - unclear why things generated by aclocal or libtool should be in the repository (and I have to admit that I get the problem of running autogen.sh on my system and those files being changed, despite the fact that I haven't made any changes, and svn wants to cmmit those files). That doesn't really help the issue of incompatible changes - my only thought there would be any time those files do get changed, perhaps note in the file or changelog what version of the tools were used, eg: update configure.ac for .., tested with autoconf 2.63, automake 1.10, libtool ... (and so on) That doesn't necessarily fix the problem, but perhaps at least makes it a little easier to figure out cause after the fact - if I see my versions are very old, I might be able to make a guess that is the cause vs something just broken in the file itself.