[CF-Devel] gcfclient without dmalloc segfaults

[Mark Wedel]

"Pertti Karppinen (OH6KTR)" wrote:
>
     
     
     >
     
      It seems, that gcfclient will segfault at start, when compiled without
     
     >
     
      dmalloc lib, atleast on debian 2.2 system.
     
     >
     
      I think same problem is occuring with cfclient also.
     
     >
     
      The segfault comes about with -png graphics, so I suspect,
     
     >
     
      that png.c might be the root of this problem.
     
     >
     
      This sounds like a serious problem to me. Very serious.
     
     
 I've noticed this problem with running with purify at times.  The problem is
best I can tell the png.c file is correct now - the actual fault is happening
within the png library - I need to compile a debugged version of that and see
who is really at fault (ie, are we not passing an appropriately sized structure
to it, or is libpng broken in some obscure way)

>
     
     
     >
     
      And 2nd note:
     
     >
     
      We need a unique color for tell&say in gcfclient, as they trun white->black.
     
     >
     
      Perhaps we need to add color to our selection? I vote for magenta, which
     
     >
     
      displays with a lot of different background colors. (And is my favourite
     
     >
     
      color along with pink)
     
     
 What really needs to be done is change how the server communicates to the
client the messages.  Instead of hte server telling the client the color
(NDI_BLACK for example), this needs to be re-done so the server tell the client
the type of message it is (NDI_ATTACK, NDI_EXP_CHANGE, NDI_STAT_CHANGE, etc). 
The client can then choose the appropriate color (and a good/clever client might
even have a color selector so the player can easily choose the appropriate
colors they want).

 The other reason for this is that potentially, a client may want to have
several output windows with different data.  For example, you might want to have
a relatively small window for the attack messages (5 lines or something), 10
lines for player communications (chat/tell/shout), and 10 lines for other
interesting messages.

 In that way, you can easily carry on a conversation with other players without
the messages getting lost in all the attack messages (or id messages or
whatever).  Likewise, more important messages don't get mixed in with all the
attack messages.

 this can also be enhanced so the chat window may have an entry line which sends
the appropriate say/shout/tell command to the server so that you don't need to
bind commands to it.

 This can also be nice for quests where an npc tells you something - presuming
that chat window has a scrollbar, you will more easily be able to scroll back to
what you were told than you can currently.

 The server side of this is not hard, just a bit of work.  Basic client support
would not be hard either (basic support meaning it translate the NDI_ATTACK into
being black, stat change into another color, etc).  The addition of new windows
is a bit harder.  Basically, for the server it just means definining new tags
for the type of message data and going through updating all the draw info
commands to use the new tags.


>
     
      --
     
     >
     
      BSc. Pertti Karppinen <
      
      pjka at iki.fi
      
      >                   |'Bridge Players |
     
     >
     
      Systems Designer, University of Jyvaskyla, Finland    |      Do        |
     
     >
     
     
      http://www.iki.fi/~pjka/
      
       | Office  : +358 14 260 2088 |      It        |
     
     >
     
      HAM: OH6KTR QTH: KP22UF  | Cellular: +358 40 564 0786 | on the Table'  |
     
     >
     
      _______________________________________________
     
     >
     
      crossfire-devel mailing list
     
     >
     
     
      crossfire-devel at lists.real-time.com
      
      
     >
     
     
      https://mailman.real-time.com/mailman/listinfo/crossfire-devel