From nicolas.weeger at laposte.net Tue Nov 1 11:07:01 2011 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Tue, 1 Nov 2011 17:07:01 +0100 Subject: [crossfire] Proposal for artifacts changes In-Reply-To: <201110161321.39868.nicolas.weeger@laposte.net> References: <201110161321.39868.nicolas.weeger@laposte.net> Message-ID: <201111011707.05298.nicolas.weeger@laposte.net> Hello. I've committed changes to improve artifact support. A new field 'artifact' is added to 'object', to keep track of what optional artifact an item was created from. At save time, the 'bare' artifact is generated, and the item is saved compared to that artifact. At load time the loaded item gets the artifact values immediately after the archetype, to generate the artifact, then loads its potential custom values. This enables changing artifacts, including for existing items, for eg balance purposes. Regards Nicolas -- Mon p'tit coin du web - http://nicolas.weeger.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part. URL: From meflin at meflin.net Sun Nov 6 16:34:10 2011 From: meflin at meflin.net (James Lopeman) Date: Sun, 6 Nov 2011 15:34:10 -0700 Subject: [crossfire] New server crashing today - trunk Message-ID: <201111061534.10390.meflin@meflin.net> Entering the Scorn and Navar World maps crashes the server. Invidious and Leaf's test server. [15:28] (gdb) bt full [15:28] #0 0x002c0866 in ?? () [15:28] No symbol table info available. Not sure what to make of it. Meflin James Lopeman From 2c93e8f1 at gmail.com Sun Nov 6 17:57:07 2011 From: 2c93e8f1 at gmail.com (David McIlwraith) Date: Mon, 7 Nov 2011 10:57:07 +1100 Subject: [crossfire] New server crashing today - trunk In-Reply-To: <201111061534.10390.meflin@meflin.net> References: <201111061534.10390.meflin@meflin.net> Message-ID: You may want to recompile with -O0 (no optimisations) and -ggdb... that backtrace is not going to help much. Regards, - David McIlwraith <2c93e8f1 at gmail.com> On Mon, Nov 7, 2011 at 9:34 AM, James Lopeman wrote: > Entering the Scorn and Navar World maps crashes the server. Invidious and > Leaf's test server. > > [15:28] (gdb) bt full > [15:28] #0 ?0x002c0866 in ?? () > [15:28] No symbol table info available. > > Not sure what to make of it. > > Meflin > James Lopeman > _______________________________________________ > crossfire mailing list > crossfire at metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > From meflin at meflin.net Sun Nov 6 18:02:19 2011 From: meflin at meflin.net (James Lopeman) Date: Sun, 6 Nov 2011 17:02:19 -0700 Subject: [crossfire] New server crashing today - trunk In-Reply-To: References: <201111061534.10390.meflin@meflin.net> Message-ID: <201111061702.19138.meflin@meflin.net> Invidious is compiled with export CFLAGS="-O0 -ggdb3" Meflin On Sunday, November 06, 2011 04:57:07 PM David McIlwraith wrote: > You may want to recompile with -O0 (no optimisations) and -ggdb... > that backtrace is not going to help much. > > Regards, > - David McIlwraith <2c93e8f1 at gmail.com> > > On Mon, Nov 7, 2011 at 9:34 AM, James Lopeman wrote: > > Entering the Scorn and Navar World maps crashes the server. Invidious and > > Leaf's test server. > > > > [15:28] (gdb) bt full > > [15:28] #0 0x002c0866 in ?? () > > [15:28] No symbol table info available. > > > > Not sure what to make of it. > > > > Meflin > > James Lopeman > > _______________________________________________ > > crossfire mailing list > > crossfire at metalforge.org > > http://mailman.metalforge.org/mailman/listinfo/crossfire > > _______________________________________________ > crossfire mailing list > crossfire at metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire From 2c93e8f1 at gmail.com Sun Nov 6 18:06:18 2011 From: 2c93e8f1 at gmail.com (David McIlwraith) Date: Mon, 7 Nov 2011 11:06:18 +1100 Subject: [crossfire] New server crashing today - trunk In-Reply-To: <201111061702.19138.meflin@meflin.net> References: <201111061534.10390.meflin@meflin.net> <201111061702.19138.meflin@meflin.net> Message-ID: Hi, How very strange. Sounds like rather serious stack corruption, but that *should* be caught more readily than that... the offset is certainly well outside any real code, so there is a buffer overflow that has been introduced. Forgive me for being overly presumptuous re: compilation parameters. Regards, - David McIlwraith <2c93e8f1 at gmail.com> On Mon, Nov 7, 2011 at 11:02 AM, James Lopeman wrote: > Invidious is compiled with > > export CFLAGS="-O0 -ggdb3" > > Meflin > > On Sunday, November 06, 2011 04:57:07 PM David McIlwraith wrote: >> You may want to recompile with -O0 (no optimisations) and -ggdb... >> that backtrace is not going to help much. >> >> Regards, >> - David McIlwraith <2c93e8f1 at gmail.com> >> >> On Mon, Nov 7, 2011 at 9:34 AM, James Lopeman wrote: >> > Entering the Scorn and Navar World maps crashes the server. Invidious and >> > Leaf's test server. >> > >> > [15:28] (gdb) bt full >> > [15:28] #0 ?0x002c0866 in ?? () >> > [15:28] No symbol table info available. >> > >> > Not sure what to make of it. >> > >> > Meflin >> > James Lopeman >> > _______________________________________________ >> > crossfire mailing list >> > crossfire at metalforge.org >> > http://mailman.metalforge.org/mailman/listinfo/crossfire >> >> _______________________________________________ >> crossfire mailing list >> crossfire at metalforge.org >> http://mailman.metalforge.org/mailman/listinfo/crossfire > _______________________________________________ > crossfire mailing list > crossfire at metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > From agschult at ucalgary.ca Sun Nov 6 18:06:54 2011 From: agschult at ucalgary.ca (Alex Schultz) Date: Sun, 6 Nov 2011 17:06:54 -0700 Subject: [crossfire] New server crashing today - trunk In-Reply-To: <201111061702.19138.meflin@meflin.net> References: <201111061534.10390.meflin@meflin.net> <201111061702.19138.meflin@meflin.net> Message-ID: <20111106170654.7f33fc29@ucalgary.ca> Uggh... nasty stack corruption in that case I guess? Once upon a time, I saw the old weather code (now removed) having issues that prevented a useful backtrace from existing. Perhaps similar in this case... Regards, Alex On Sun, 6 Nov 2011 17:02:19 -0700 James Lopeman wrote: > Invidious is compiled with > > export CFLAGS="-O0 -ggdb3" > > Meflin > > On Sunday, November 06, 2011 04:57:07 PM David McIlwraith wrote: > > You may want to recompile with -O0 (no optimisations) and -ggdb... > > that backtrace is not going to help much. > > > > Regards, > > - David McIlwraith <2c93e8f1 at gmail.com> > > > > On Mon, Nov 7, 2011 at 9:34 AM, James Lopeman > > wrote: > > > Entering the Scorn and Navar World maps crashes the server. > > > Invidious and Leaf's test server. > > > > > > [15:28] (gdb) bt full > > > [15:28] #0 0x002c0866 in ?? () > > > [15:28] No symbol table info available. > > > > > > Not sure what to make of it. > > > > > > Meflin > > > James Lopeman > > > _______________________________________________ > > > crossfire mailing list > > > crossfire at metalforge.org > > > http://mailman.metalforge.org/mailman/listinfo/crossfire > > > > _______________________________________________ > > crossfire mailing list > > crossfire at metalforge.org > > http://mailman.metalforge.org/mailman/listinfo/crossfire > _______________________________________________ > crossfire mailing list > crossfire at metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > From nicolas.weeger at laposte.net Sat Nov 12 15:04:35 2011 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sat, 12 Nov 2011 22:04:35 +0100 Subject: [crossfire] Multilinguism support Message-ID: <201111122204.38926.nicolas.weeger@laposte.net> Hello. I've rewritten part of the i18n support the server had, to make it easier to figure what message is used in the source. When you need to find a string, to display or use in a buffer, please use i18n(who, "English version of the message, with the %d placeholders"); This will enable to write translations in various languages, through the "message." files. Note: currently, translations can't change the order of arguments, because snprintf doesn't support that in the C99 standard. I plan on thinking about archetype, map, quests and various translations, too :) Any idea or suggestions welcome, of course. For the record, I looked at gettext, but I'm not sure it can support multiple languages like we need (many languages at the same time). Regards Nicolas -- Mon p'tit coin du web - http://nicolas.weeger.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part. URL: From mwedel at sonic.net Mon Nov 14 00:49:10 2011 From: mwedel at sonic.net (Mark Wedel) Date: Sun, 13 Nov 2011 22:49:10 -0800 Subject: [crossfire] Multilinguism support In-Reply-To: <201111122204.38926.nicolas.weeger@laposte.net> References: <201111122204.38926.nicolas.weeger@laposte.net> Message-ID: <4EC0B9E6.8090403@sonic.net> On 11/12/11 01:04 PM, Nicolas Weeger wrote: > Hello. > > > I've rewritten part of the i18n support the server had, to make it easier to > figure what message is used in the source. > > > When you need to find a string, to display or use in a buffer, please use > > i18n(who, "English version of the message, with the %d placeholders"); > > > This will enable to write translations in various languages, through the > "message." files. Thanks - this makes reading those files much easier. Random question - could draw_ext_info_format() just default to using i18n() to passed in strings, or would that just be too costly since a lot of text may be automatically generated of which you can not have translations (shop listings, spell lists, etc). And thinking about it, that may not work very good if a string has already been translated and is coming from a different source (player chat, object msg, quest, etc - see notes below). OTOH, given those sources would be well known in the code, I then wonder if a new flag could be added, something like NDI_NOTRANSLATE to just tell the routine not to translate it. My only thought here is that if all the strings in the source are eventually translated (which I think would be the goal), then the use of i18n() just becomes extra work. I would presume that by default, if a proper translation can not be found, the message would then fall back to english also. The one optimization I could see here is require that all message strings are English (as is the case now), and have i18n() just returned the passed in string in the language setting is English. It appears (at a cursory glance) that if a user specifies English as their language, there language will get set to English, and while the locale file for english is empty, a call to bsearch would still be made, at which point it would fall back to default. > I plan on thinking about archetype, map, quests and various translations, too > :) > > Any idea or suggestions welcome, of course. For archetypes/maps, I think the way to go would be msg_, endmsg_, eg, msg_fr/endmsg_fr, msg_de/endmsg_de, etc. A nice effect of having the entire msg blob be localized is that any @match could also be localized to the correct language - having a question be localized to French by expecting an English answer would just be odd. If one wanted to carry on, name_pl_ could also be added. I'm not sure what to do about python scripts, since presumably the text is in the python script - while the i18n() would work just fine, since the scripts are in the map tree, having the localized strings in the server is a bit of a mismatch - I'm not sure if there would be some way to have the localized strings in the script itself (based around some standard framework, each script has the translation table declared in itself). From nicolas.weeger at laposte.net Mon Nov 14 12:23:00 2011 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Mon, 14 Nov 2011 19:23:00 +0100 Subject: [crossfire] Multilinguism support In-Reply-To: <4EC0B9E6.8090403@sonic.net> References: <201111122204.38926.nicolas.weeger@laposte.net> <4EC0B9E6.8090403@sonic.net> Message-ID: <201111141923.04686.nicolas.weeger@laposte.net> > Random question - could draw_ext_info_format() just default to using > i18n() to passed in strings, or would that just be too costly since a lot > of text may be automatically generated of which you can not have > translations (shop listings, spell lists, etc). Indeed, the call could be made at that point, it would probably make sense too. > And thinking about it, that may not work very good if a string has > already been translated and is coming from a different source (player > chat, object msg, quest, etc - see notes below). > > OTOH, given those sources would be well known in the code, I then wonder > if a new flag could be added, something like NDI_NOTRANSLATE to just tell > the routine not to translate it. That's possible, indeed. This would also need to be used for what players say, for instance - because you don't want random translation :) > My only thought here is that if all the strings in the source are > eventually translated (which I think would be the goal), then the use of > i18n() just becomes extra work. I would presume that by default, if a > proper translation can not be found, the message would then fall back to > english also. Yes, default translation is English. > The one optimization I could see here is require that all message strings > are English (as is the case now), and have i18n() just returned the passed > in string in the language setting is English. It appears (at a cursory > glance) that if a user specifies English as their language, there language > will get set to English, and while the locale file for english is empty, a > call to bsearch would still be made, at which point it would fall back to > default. True, but there's a reason for that, you may want to have a specific string to distinguish variants. Eg in English at two places it's the same text, but not in another language. So you do need to use a special string in one case, and have a "real" English translation looked up. Another optimisation I see is to add missing strings (as English) to a langage, so you only "fail" a bsearch once. But then you need to qsort() each insert, though only for each failure, so maybe not too bad. > For archetypes/maps, I think the way to go would be msg_, > endmsg_, eg, msg_fr/endmsg_fr, msg_de/endmsg_de, etc. Yes, makes sense too. > If one wanted to carry on, name_pl_ could also be added. *nods* > I'm not sure what to do about python scripts, since presumably the text > is in the python script - while the i18n() would work just fine, since the > scripts are in the map tree, having the localized strings in the server is > a bit of a mismatch - I'm not sure if there would be some way to have the > localized strings in the script itself (based around some standard > framework, each script has the translation table declared in itself). For NPC dialogs (hopefully a big part of the Python strings), the dialog itself (.msg file in maps) should contain the translations. For other things, we'll see when time comes, I think :) Regards Nicolas -- Mon p'tit coin du web - http://nicolas.weeger.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part. URL: From leaf at real-time.com Thu Nov 17 14:09:35 2011 From: leaf at real-time.com (Rick Tanner) Date: Thu, 17 Nov 2011 14:09:35 -0600 Subject: [crossfire] New server crashing today - trunk In-Reply-To: <201111061534.10390.meflin@meflin.net> References: <201111061534.10390.meflin@meflin.net> Message-ID: <4EC569FF.3030009@real-time.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The issue or cause for this crash was the plugins. To resolve the issue, remove the following plugins and then re-build the server. cfanim.so cfpython.so citylife.so -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFOxWn/hHyvgBp+vH4RAsgnAKCa7UvSuuOyiBcjG8nWTXsWf4MBzwCgwVwj ++RGePDi0+rlOYojYZkDzLY= =B/Zw -----END PGP SIGNATURE----- From leaf at real-time.com Thu Nov 17 14:09:36 2011 From: leaf at real-time.com (Rick Tanner) Date: Thu, 17 Nov 2011 14:09:36 -0600 Subject: [crossfire] New server crashing today - trunk In-Reply-To: <201111061534.10390.meflin@meflin.net> References: <201111061534.10390.meflin@meflin.net> Message-ID: <4EC56A00.10303@real-time.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The issue or cause for this crash was the plugins. To resolve the issue, remove the following plugins and then re-build the server. cfanim.so cfpython.so citylife.so -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFOxWn/hHyvgBp+vH4RAsgnAKCU4RWZ51xZ6nqy778EXtPOZmU77QCg6rW8 zx4yjlJxgmQSGXNva+VZUqI= =S4Dg -----END PGP SIGNATURE----- From archaios at archaios.net Fri Nov 18 05:35:22 2011 From: archaios at archaios.net (David McIlwraith) Date: Fri, 18 Nov 2011 22:35:22 +1100 Subject: [crossfire] [PATCH 0/1] GTK 2+ client: fix for locale dir. reference in Makefile.am; other autotools issues Message-ID: Hi, As of the newest trunk svn version (and prior versions), the locale directory is not properly referenced in 'gtk-v2/src/Makefile.am', leading to "$prefix/locale" (via an unset "$(DATADIRNAME), which should be "$datadir") being used instead of "$prefix/$datadir/locale" (noting that "$localedir", I believe, is the correct setting, and succeeds in my tests; see patch below), even though NLS is currently not employed. I propose the patch in the next message. As a secondary issue, as use of 'autogen.sh' is deprecated (per warning), and the included 'aclocal.m4' is out-of-date [if autoconf 2.61 is not used], I must advise that the package fails to build on (at least) the current ArchLinux distribution via use of 'autoreconf' alone, as 'utils/{config.guess,config.sub,install-sh,missing}' are not provided. The commands: aclocal automake --add-missing [to add the missing utils/ files] autoreconf are necessary to produce a working package. I am not sure if the latter problem is regarded as a major issue at this point or not, but the locale directory reference is definitely not correct with current autotools versions. Regards, - David McIlwraith ArchLinux AUR 'crossfire-client' / 'crossfire-client-svn' package maintainer From archaios at archaios.net Fri Nov 18 05:39:12 2011 From: archaios at archaios.net (David McIlwraith) Date: Fri, 18 Nov 2011 22:39:12 +1100 Subject: [crossfire] [PATCH 1/1] GTK 2+ client: fix for locale dir. reference in Makefile.am; other autotools issues Message-ID: Proposed fix for GTK 2+ Makefile.am reference to locale directory. "$(DATADIRNAME)" is not defined in newest autotools versions, and "$(localedir)" is preferred. Signed-off-by: David McIlwraith --- Makefile.am | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Index: gtk-v2/src/Makefile.am =================================================================== --- gtk-v2/src/Makefile.am (revision 15791) +++ gtk-v2/src/Makefile.am (working copy) @@ -21,7 +21,7 @@ INCLUDES = \ -DPACKAGE_DATA_DIR=\""$(datadir)"\" \ - -DPACKAGE_LOCALE_DIR=\""$(prefix)/$(DATADIRNAME)/locale"\" \ + -DPACKAGE_LOCALE_DIR=\""$(localedir)"\" \ -I$(top_builddir)/common \ -I$(top_srcdir)/common \ -I$(top_srcdir)/common/shared \ From archaios at archaios.net Fri Nov 18 05:59:45 2011 From: archaios at archaios.net (David McIlwraith) Date: Fri, 18 Nov 2011 22:59:45 +1100 Subject: [crossfire] [PATCH 1/1] GTK 2+ client: fix for locale dir. reference in Makefile.am; other autotools issues In-Reply-To: References: Message-ID: Sorry, Correct patch attached (whitespace issues). Otherwise, details as per message 0/1. Regards, - David McIlwraith ArchLinux AUR 'crossfire-client' / 'crossfire-client-svn' package maintainer On Fri, Nov 18, 2011 at 10:39 PM, David McIlwraith wrote: > Proposed fix for GTK 2+ Makefile.am reference to locale directory. > "$(DATADIRNAME)" is not defined in newest autotools versions, and > "$(localedir)" is preferred. > > Signed-off-by: David McIlwraith > --- > ?Makefile.am | ? ?2 +- > ?1 file changed, 1 insertion(+), 1 deletion(-) > > Index: gtk-v2/src/Makefile.am > =================================================================== > --- gtk-v2/src/Makefile.am ? ? ?(revision 15791) > +++ gtk-v2/src/Makefile.am ? ? ?(working copy) > @@ -21,7 +21,7 @@ > > ?INCLUDES = \ > ? ? ? ?-DPACKAGE_DATA_DIR=\""$(datadir)"\" \ > - ? ? ? -DPACKAGE_LOCALE_DIR=\""$(prefix)/$(DATADIRNAME)/locale"\" \ > + ? ? ? -DPACKAGE_LOCALE_DIR=\""$(localedir)"\" \ > ? ? ? ?-I$(top_builddir)/common \ > ? ? ? ?-I$(top_srcdir)/common \ > ? ? ? ?-I$(top_srcdir)/common/shared \ > -------------- next part -------------- A non-text attachment was scrubbed... Name: crossfire-client-svn-fix-gtk2-localedir.patch Type: text/x-patch Size: 749 bytes Desc: not available URL: From nicolas.weeger at laposte.net Sat Nov 19 15:27:06 2011 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sat, 19 Nov 2011 22:27:06 +0100 Subject: [crossfire] Graphism perspective Message-ID: <201111192227.16171.nicolas.weeger@laposte.net> Hello. I'm wondering what perspective we want to have in the game. Right now, for monsters themselves, it's quite incoherent: - some are top/bottom/left/right - some have the vertical line not vertical - some have yet other things. Random examples: http://crossfire.svn.sourceforge.net/viewvc/crossfire/arch/trunk/monster/animal/Bear/bear.base.x31.png?revision=13991&view=markup http://crossfire.svn.sourceforge.net/viewvc/crossfire/arch/trunk/monster/animal/Bear/polarbear.base.x31.png?revision=13991&view=markup http://crossfire.svn.sourceforge.net/viewvc/crossfire/arch/trunk/monster/animal/ape.base.131.png?revision=13991&view=markup http://crossfire.svn.sourceforge.net/viewvc/crossfire/arch/trunk/monster/animal/cobra.base.x12.png?revision=13991&view=markup http://crossfire.svn.sourceforge.net/viewvc/crossfire/arch/trunk/monster/animal/mushman1.base.151.png?revision=13991&view=markup http://crossfire.svn.sourceforge.net/viewvc/crossfire/arch/trunk/monster/angel/angel.base.112.png?revision=13991&view=markup http://crossfire.svn.sourceforge.net/viewvc/crossfire/arch/trunk/monster/angel/archangel.base.x12.png?revision=13991&view=markup http://crossfire.svn.sourceforge.net/viewvc/crossfire/arch/trunk/monster/angel/highangel.base.116.png?revision=13991&view=markup http://crossfire.svn.sourceforge.net/viewvc/crossfire/arch/trunk/monster/goblin/gnoll.base.111.png?revision=13991&view=markup http://crossfire.svn.sourceforge.net/viewvc/crossfire/arch/trunk/monster/goblin/goblin.base.171.png?revision=13991&view=markup http://crossfire.svn.sourceforge.net/viewvc/crossfire/arch/trunk/monster/goblin/orc_chief.base.112.png?revision=13991&view=markup http://crossfire.svn.sourceforge.net/viewvc/crossfire/arch/trunk/monster/undead/dave.base.113.png?revision=13991&view=markup http://crossfire.svn.sourceforge.net/viewvc/crossfire/arch/trunk/monster/undead/deathshead.base.113.png?revision=13991&view=markup http://crossfire.svn.sourceforge.net/viewvc/crossfire/arch/trunk/monster/undead/demilich.base.111.png?revision=13991&view=markup http://crossfire.svn.sourceforge.net/viewvc/crossfire/arch/trunk/monster/undead/nazgul.base.111.png?revision=13991&view=markup http://crossfire.svn.sourceforge.net/viewvc/crossfire/arch/trunk/monster/undead/vampire.base.111.png?revision=13991&view=markup http://crossfire.svn.sourceforge.net/viewvc/crossfire/arch/trunk/monster/undead/zombie.base.111.png?revision=13991&view=markup I admit that the "top/bottom/left/right" view is weird, considering the view is somehow top-down. On the other hand having a non-vertical vertical axis (like http://crossfire.svn.sourceforge.net/viewvc/crossfire/arch/trunk/monster/angel/archangel.base.x12.png?revision=13991&view=markup ) looks weird. So maybe something like a vertical axis "vertically exiting the screen" (if that makes sense :))... What do you think? Regards Nicolas -- Mon p'tit coin du web - http://nicolas.weeger.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part. URL: From mwedel at sonic.net Sat Nov 19 22:57:00 2011 From: mwedel at sonic.net (Mark Wedel) Date: Sat, 19 Nov 2011 20:57:00 -0800 Subject: [crossfire] Graphism perspective In-Reply-To: <201111192227.16171.nicolas.weeger@laposte.net> References: <201111192227.16171.nicolas.weeger@laposte.net> Message-ID: <4EC8889C.1040004@sonic.net> On 11/19/11 01:27 PM, Nicolas Weeger wrote: > Hello. > > > I'm wondering what perspective we want to have in the game. > > > Right now, for monsters themselves, it's quite incoherent: > - some are top/bottom/left/right > - some have the vertical line not vertical > - some have yet other things. There are a few potential different thoughts on this - one could take any/all of these as what should be done: - What looks best - What perspective most of the monsters/images currently have - What is easiest to draw Probably some others. I suspect the mix is because different artists decided to draw them in their own style. I also suspect that the slanted ones might have been a result of isomorphic tileset/display - those at a tilt would look proper if the walls/overall map had that same perspective, but not the flat display of crossfire. I note that the bears as an example have issue with lighting - from the README in the arch directory: Light should generally come from the right side, so the left side of buildings should be darker or shaded, as needed. But the bears have the light coming from the left, so their right is in shade. That is easy to fix - just flip it (so it faces left), but does illustrate that adding shadows to objects make it a bit harder to do different faces - for creatures with no shadows, like the ape, it is very easy to do a left/right facing - a simple flip, and it is done. While not really clear, I always took it that the bottom (south) of the map is closer to the viewer. Thus, creatures going north (away) should have a back view. I'm a bit old fashioned, but my vote would be the vertical access is vertical, not at a slant. But I prefer the look like they are 3D, and not flat - as examples, the bear and ape are what I would describe as 3D looking, where as highangle and dave appear flat. That may just have to do with the graphics themselves, but this could also extend to other objects. For example, a lot of the equipment could have a very flat look (symbolic), but I actually prefer the look that they are 3d. The problem I see with vertical access 'exiting the screen' is that all one should see in that case would be the top of most peoples head - not very exciting. It's also odd because things like town are clearly not a true top down perspective - if that was the case, all one would see is the roofs of the shops, and not the front. So while the game is top down, the viewing direction clearly isn't quite like that - it is more that one is at a 30 or 45 degree angle to the south and looking into the town, dungeon, whatever. From nicolas.weeger at laposte.net Sun Nov 20 04:17:20 2011 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sun, 20 Nov 2011 11:17:20 +0100 Subject: [crossfire] New server setting: special_break_map Message-ID: <201111201117.30208.nicolas.weeger@laposte.net> Hello. I've added a server setting, named "special_break_map", which controls whether submaps (eg alchemy rooms, altars, and such) in generated random maps can break the random map's walls or not. It is TRUE by default, to emulate the server's behaviour up to now. Regards Nicolas -- Mon p'tit coin du web - http://nicolas.weeger.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part. URL: From nicolas.weeger at laposte.net Sun Nov 20 04:47:14 2011 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sun, 20 Nov 2011 11:47:14 +0100 Subject: [crossfire] New server argument: -disable-plugin Message-ID: <201111201147.17787.nicolas.weeger@laposte.net> Hello. I've added a server argument, '-disable-plugin ', which disables a plugin from the filename, eg 'cfpython' or 'cflogger'. This argument can be used multiple times. 'All' means to disable all plugins. It makes easy to eg launch the server under Valgrind without having to mess with installed files (Python is especially bad for instance). Regards Nicolas -- Mon p'tit coin du web - http://nicolas.weeger.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part. URL: From om at iki.fi Sun Nov 20 19:05:43 2011 From: om at iki.fi (Otto J. Makela) Date: Mon, 21 Nov 2011 03:05:43 +0200 Subject: [crossfire] Graphism perspective In-Reply-To: <4EC8889C.1040004@sonic.net> References: <201111192227.16171.nicolas.weeger@laposte.net> <4EC8889C.1040004@sonic.net> Message-ID: <4EC9A3E7.1030907@iki.fi> On 20/11/11 06:57, Mark Wedel wrote: > It's also odd because things like town are clearly not a true top down > perspective - if that was the case, all one would see is the roofs of the shops, > and not the front. So while the game is top down, the viewing direction clearly > isn't quite like that - it is more that one is at a 30 or 45 degree angle to the > south and looking into the town, dungeon, whatever. I've mentioned this, but haven't checked svn to see if this has been changed: back when I was starting with Crossfire (oh, some time in the 90s), I found it quite confusing how in spite (or perhaps because) of the pseudo-isometric perspective walking past and entering "horizontally" oriented 2?2 houses is restricted to the two lower squares, whereas there is no such limitation in smaller, larger or "vertically" oriented 2?2 houses, or other buildings. -- /* * * Otto J. Makela * * * * * * * * * */ /* Phone: +358 40 765 5772, ICBM: N 60 10' E 24 55' */ /* Mail: Mechelininkatu 26 B 27, FI-00100 Helsinki */ /* * * Computers Rule 01001111 01001011 * * * * * * */ From mwedel at sonic.net Wed Nov 23 01:13:16 2011 From: mwedel at sonic.net (Mark Wedel) Date: Tue, 22 Nov 2011 23:13:16 -0800 Subject: [crossfire] plugin versioning Message-ID: <4ECC9D0C.2010003@sonic.net> It seems to be not that unusual that out of date plugins in the installed area result in system crashes. Now I've made a fairly simple change (not yet commited) that checks what the svn version was of the compiled plugin against that of the server, and if they don't match, it doesn't load the plugin. The nice bit here is that for old plugins, they will lack this symbol, and also will not get loaded. As that is another potential problem - a plugin that used to exist (and thus was installed), but has been renamed, is no longer active, etc. The one thing I'm not sure of is if any plugins exist from outside the source tree, in which case them having the right svn version would be an issue. I've also thought about adding in some other checks - sizeof(object) as when the plugin was compiled vs the server, and perhaps sizeof of player, map, etc. But these would seem to be much more developer scenarios - dev has made changes, but not done a commit, so svn number is unchanged. In those cases, the dev should hopefully be aware of what they have done. And the problem is that simple size checks may not be all that foolproof - if for example, I remove one field from the middle of the object structure, but add a new one to the end, the sizeof(object) may be the same, but the fact that the positioning of a bunch of interim fields has changed will result bad behavior. I'll commit this change in the next day or two, unless I hear of some reason not to - the plus side is that it is a pretty trivial change, and removing/disabling the logic from the plugin loader would be pretty easy if there are issues. From nicolas.weeger at laposte.net Thu Nov 24 12:00:13 2011 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Thu, 24 Nov 2011 19:00:13 +0100 Subject: [crossfire] plugin versioning In-Reply-To: <4ECC9D0C.2010003@sonic.net> References: <4ECC9D0C.2010003@sonic.net> Message-ID: <201111241900.14158.nicolas.weeger@laposte.net> Hello. > It seems to be not that unusual that out of date plugins in the installed > area result in system crashes. > > Now I've made a fairly simple change (not yet commited) that checks what > the svn version was of the compiled plugin against that of the server, and > if they don't match, it doesn't load the plugin. (snipped) Seems fine by me, thanks for the fix. Regards Nicolas -- Mon p'tit coin du web - http://nicolas.weeger.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part. URL: