Nicolas Weeger | 1 Nov 2011 17:07
Favicon

Re: Proposal for artifacts changes

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
_______________________________________________
crossfire mailing list
crossfire@...
http://mailman.metalforge.org/mailman/listinfo/crossfire
James Lopeman | 6 Nov 2011 23:34

New server crashing today - trunk

Entering the Scorn and Navar World maps crashes the server. Invidious and 
Leaf's test server.

[15:28] <meflin> (gdb) bt full
[15:28] <meflin> #0  0x002c0866 in ?? ()
[15:28] <meflin> No symbol table info available.

Not sure what to make of it.

Meflin
James Lopeman
David McIlwraith | 7 Nov 2011 00:57
Picon

Re: New server crashing today - trunk

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 <meflin <at> meflin.net> wrote:
> Entering the Scorn and Navar World maps crashes the server. Invidious and
> Leaf's test server.
>
> [15:28] <meflin> (gdb) bt full
> [15:28] <meflin> #0  0x002c0866 in ?? ()
> [15:28] <meflin> 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
James Lopeman | 7 Nov 2011 01:02

Re: New server crashing today - trunk

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@...>
> 
> On Mon, Nov 7, 2011 at 9:34 AM, James Lopeman <meflin@...> wrote:
> > Entering the Scorn and Navar World maps crashes the server. Invidious and
> > Leaf's test server.
> > 
> > [15:28] <meflin> (gdb) bt full
> > [15:28] <meflin> #0  0x002c0866 in ?? ()
> > [15:28] <meflin> No symbol table info available.
> > 
> > Not sure what to make of it.
> > 
> > Meflin
> > James Lopeman
> > _______________________________________________
> > crossfire mailing list
> > crossfire@...
> > http://mailman.metalforge.org/mailman/listinfo/crossfire
> 
(Continue reading)

David McIlwraith | 7 Nov 2011 01:06
Picon

Re: New server crashing today - trunk

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 <meflin <at> meflin.net> 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 <meflin <at> meflin.net> wrote:
>> > Entering the Scorn and Navar World maps crashes the server. Invidious and
>> > Leaf's test server.
>> >
>> > [15:28] <meflin> (gdb) bt full
(Continue reading)

Alex Schultz | 7 Nov 2011 01:06
Picon
Favicon

Re: New server crashing today - trunk

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 <meflin@...> 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@...>
> > 
> > On Mon, Nov 7, 2011 at 9:34 AM, James Lopeman <meflin@...>
> > wrote:
> > > Entering the Scorn and Navar World maps crashes the server.
> > > Invidious and Leaf's test server.
> > > 
> > > [15:28] <meflin> (gdb) bt full
> > > [15:28] <meflin> #0  0x002c0866 in ?? ()
(Continue reading)

Nicolas Weeger | 12 Nov 2011 22:04
Favicon

Multilinguism support

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.<code>" 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
(Continue reading)

Mark Wedel | 14 Nov 2011 07:49
Favicon

Re: Multilinguism support

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.<code>" 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.
(Continue reading)

Nicolas Weeger | 14 Nov 2011 19:23
Favicon

Re: Multilinguism support

>   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
(Continue reading)

Rick Tanner | 17 Nov 2011 21:09
Favicon

Re: New server crashing today - trunk


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


Gmane