[CF-Devel] Item sorting

[Mark Wedel]

     pstolarc at theperlguru.com
     
      wrote:

>
     
      I've been working on trying to get the SDL client to use the common
     
     >
     
      client files.  It's rather a bit of work, as stuff has been renamed
     
     >
     
      and moved around to different files.  And I'm not going to mention the
     
     >
     
      added functionality.
     
     

  Yes - it was a while since the SDL client was originally done.


>
     
     
     >
     
      Anyway,...
     
     >
     
     
     >
     
      Looking at common/item.c right now, and noticed something in
     
     >
     
      update_item_sort():
     
     >
     
     
     >
     
      #if 0
     
     >
     
      	    /* This could be a nice idea, but doesn't work very well if
     
     >
     
      you
     
     >
     
      	     * have a few unidentified wands, as the position of a wand
     
     >
     
      	     * which you know the effect will move around as you equip
     
     >
     
      others.
     
     >
     
      	     */
     
     >
     
     
     >
     
      	    /* applied items go first */
     
     >
     
      	    if (itmp->applied) continue;
     
     >
     
      	    /* put locked items before others */
     
     >
     
      	    if (itmp->locked && !it->locked) continue;
     
     >
     
      #endif
     
     >
     
     
     >
     
      If you sort by itmp->tag first, then everything will appear in a very
     
     >
     
      consistent order.  But if you equip the "unIDed wand that you know
     
     >
     
      what it does", then unequip it, you may still lose track of it.  But
     
     >
     
      though it will move back to exactly the same place it was before you
     
     >
     
      applied it.  It would even sort stuff consistently if you drop stuff,
     
     >
     
      then pick it back up, as the tag stays the same.
     
     

  Good point.  This point may be more worthwhile depending on the client 
interface - the gtk client already has convenient ways to show the equipped vs 
non equipped items.

  It would probably be best that any such 'equip items at start of group' be a 
configurable option.  Even for items identified, it can be a little odd/annoying 
that when you equip/unequip item, it disappears from the immediate inventory 
view as it is put someplace else.

  The ideal solution which is a bit more work to do is to let the player rename 
their items (so if you fire that wand, and see a fireball explode, you rename it 
to be 'wand of fireball'

  I had sent some e-mail on that quite a while ago on doing something like that. 
  My idea is that this would largely be handled by the client.  Probably the 
easiest way would be to make the tags truly persisent (so for example, the 
client sees that player wants to rename item with tag 45678 to something, and 
makes a note of it.  Player logs out, and then sometime later (maybe days), log 
back in.  The item has the same tag, so the client knows it can use the custom 
name for it.

  My original idea had the idea that the client could send a 32 bit value that 
it wanted the server to store with that object, and that would persist.  The 
client could use that 32 bit value as a pointer to the name, but could also use 
it for things like favorite lists and whatnot.  However, this is obiously a more 
complex approach (client has to tell server to store tag with object, protocol 
needs to get updated, need to deal with cases if one player drops it and another 
picks it up, it may have a bogus id respective to that new players client, so 
when something is dropped, that id needs to get cleared, etc).

  Making the tags persistent would actually be quite easy to do.  Fairly trivial 
to save them to disk and set to the same value when loaded.  Also fairly easy to 
make a checkpoint file that stores the last tag used (so if the server 
exits/crashes, it looks at that as the starting point, increasing it a bit just 
to cover any items that may have been created since the last update).  The 
advantage is that this doesn't require any extension to the protocol, and don't 
need to worry about a different player picking up some item (eg, player a drops 
what he calls 'my awesome sword'.  Player 2 picks it up, and the client 
recognizes that tag and sees that it should display it as 'doofus' sword'.

  The only problem with this approach is that eventuall the tags would wrap 
(this eventually could end up being very large, like months or years, but since 
the tag count would persist across runs, we're not talking about the server 
continually being up that long - just running on the same system).  I'll need to 
look at metalforge after its been running for a while and see what its tag count 
is to extrapolate how long it would take for it to wrap).



>
     
     
     >
     
      Just an idea.  Not sure if it's worthwhile or not.
     
     >
     
     
     >
     
      -Philip
     
     >
     
      _______________________________________________
     
     >
     
      crossfire-devel mailing list
     
     >
     
     
      crossfire-devel at lists.real-time.com
      
      
     >
     
     
      https://mailman.real-time.com/mailman/listinfo/crossfire-devel
      
      
     >