[CF-Devel] More patches and things to consider

[crossfire-devel at archives.real-time.com]

  Catching up on old mail and patches.

Kevin C. Rudat wrote:
>
     
      Patches I uploaded to Sourceforge patch tracker
     
     >
     
      ==================================================
     
     >
     
     
     >
     
      Oops. I forgot to say that I think these could go into CVS.
     
     >
     
     
     >
     
       * 1001086: Say something when script not found (Unix) 
     
     >
     
     
     >
     
           Doesn't appear on front page, perhaps because it's for the client? :S
     
     >
     
     
     >
     
       * 1001081: Crossedit: copy script events when copying.
     
     >
     
       * 1001079: Make "alchemy" books say which skill.
     
     
  Looking at the comments on the bug, there is a note that perhaps not saying 
what skill is part of the game.  I'm convinced of that argument (should we 
similarly hide spellbooks such that player doesn't know?)  A lot of alchemy has 
been more friendly - at one point, you didn't even know what recipe you were 
buying until you could decipher it, because the title of the book didn't contain 
that.  But that basically made buying recipes useless.  I personally think we 
should probably make things a bit easier - there is already so many items in the 
game, you really want to have some idea if it is of any use or not.


>
     
      Server
     
     >
     
      -------
     
     >
     
     
     >
     
      Modify the value of any generated spellbook that currently has the value of
     
     >
     
      its clone, rather than only ones with a random spell.:
     
     >
     
     
     >
     
         This means you can plonk a spellbook and the spellarch on a map, and let
     
     >
     
         the arch writers worry about how much its worth.
     
     
  I'm not sure what you mean by this - I'm guessing that have the value 
calculated when the player tries to sell it/look it/whatever, based on the spell 
it contains?

  could be done - I don't really see the point - the current mechanism is quite 
easy to figure out (if anything, have the editor do the math if necessary).  But 
it also creates the problem of how do you know the spellbook should calculate 
its value or already been set?  You can do the book->value != book->clone.value, 
but that fails if you in fact want to set book->value to the clone value (eg, 
make a spell cheaper than it perhaps should be).  I personally think this would 
probably add more complication to various areas of code when the problem 
shouldn't be that hard to fix.

  I also note that for all other objects, it is the responsibility of the map 
maker to set appropriate value.  If the map maker puts a sword on the map, and 
then gives it all sorts of special abilities, it is up to him to also put in a 
proper value - I see that no different for spellbooks.



>
     
      Looking at a spellbook: 
     
     >
     
     
     >
     
         Rather than "foo is a 9 level bar spell", "foo is a ninth level bar
     
     >
     
         spell". There turned out to be a function for that sort of thing in
     
     >
     
         common/item.c, I think.
     
     
  Yes, that could easily be changed, and I can't think of any bad side effects 
of doing so (in some cases, there can be where things are sorted alphabetically, 
but even that fails because 10 would come before name in an alphasort)

>
     
     
     >
     
      Argh! Void pointers!
     
     >
     
     
     >
     
         Last time I looked there's a couple of places in the Python plugin that
     
     >
     
         possibly assume ints and longs were passed by reference rather than by
     
     >
     
         value, causing '*(int *)' to have unexpected values.
     
     >
     
     
     >
     
         I'm not sure which way around's the one intended by the plugin system's
     
     >
     
         author, though.
     
     
  Should probably point out specifically which ones these are.

>
     
     
     >
     
      Documentation:
     
     >
     
     
     >
     
         I added a few lines to two of the player-help documents in my local CVS
     
     >
     
         tree. Should I share them?
     
     
  Sure - can't hurt.

>
     
     
     >
     
      Client
     
     >
     
      -------
     
     >
     
     
     >
     
      "-nometaserver" option:
     
     >
     
     
     >
     
        It's useful for testing the client offline. However, my implementation
     
     >
     
        can't change the flag during runtime.
     
     
  I find if that's the case, you could just do a '-client 127.0.0.1' or the 
like.  I'm not convinced the wide spread usage of a nometaserver option.

>
     
     
     >
     
      local-command table and fnu help system:
     
     >
     
     
     >
     
        I got a bit carried away, and now my local client source tree has an 
     
     >
     
        array of the client-local commands, *and* functions for getting help
     
     >
     
        on them. 
     
     >
     
     
     >
     
        This allows the list of client commands ('help commands') to be 
     
     >
     
        generated, and to keep the help for each command with the command.
     
     >
     
     
     >
     
        I even changed the GTK help dialog so you can type a command name
     
     >
     
        in.
     
     
  Would be worth seeing.

>
     
     
     >
     
      Inventory filter:
     
     >
     
     
     >
     
        * Describe different filters in one place in the code.
     
     >
     
        * Filter your inventory in different ways.
     
     >
     
     
     >
     
          For GTK users, this means you can redefine the tabs. 
     
     >
     
     
     >
     
        * Get a client-script to filter your inventory! (One beat behind the
     
     >
     
          game, though. :( )
     
     >
     
     
     >
     
        * Untested: custom sorting inventory, too.
     
     >
     
     
     >
     
      This one I'm particularly unsure of. I have a working implementation,
     
     >
     
      but it's complicated to use. If you *do* like the idea, I'd like to hear
     
     >
     
      how you think it should work.  
     
     
  Well, what is probably most needed is a custom tag that can be applied to the 
items to dictate how they show up.

  I see limited value in being able to sort objects by type.  So being able to 
say 'this tab is all my money type objects' could be nice

  However, I see more value of being able to do something like 'these 15 items 
go in tab 1, these 11 go in tab 2, these 22 go in tab 3, etc'.  And there could 
be overlap in the tabs (some may appear in all the tabs, some appear in tab 2 
and 3, etc.

  I had once suggested the idea that each object could be given an int (4 bytes) 
that the client is free to store whatever info it wants in it.  A basic protocl 
command could be added that the client can update the server with the tag, and 
the other commands from the server to client would have to be updated to send 
that tag also.

  The idea is that this tag is persistant accross server restarts, or player 
logins and logouts.  In that way, the client can do things like say 'tag 6' 
means it should appear in tabs 2&3, or whatever else the client things it could 
use the tag for (in theory, it could use it for all sorts of stuff, but most 
likely would just be for varios flags) - the main idea is that the server 
doesn't really care what is in that tag - it is just providing some space for 
the client to be able to store info that will remain there.

  This tag would have to get cleared when the object is dropped, thrown, etc, 
but that already has to happen for some other values that get stored away anyways


_______________________________________________
crossfire-devel mailing list
     
     crossfire-devel at lists.real-time.com
     
     
     https://mailman.real-time.com/mailman/listinfo/crossfire-devel