[CF-Devel] More patches and things to consider

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

Kevin C. Rudat wrote:

>
     
      Being able to see what item you're buying a recipie for, or 
     
     >
     
      *not* being able to see which item it tells you how to make?
     
     
  I agree that the recipe books should tell you what it is for - I think I 
omitted a few words in my original response that didn't make that clear..

  If you think of it in modern day, one could probably figure out what skill 
(woodworking, cooking, mechanic, etc) a book is for simply by looking at its 
title, and same makes sense for crossfire.


>
     
      I agree. I like the editor being able to calculate it. The patch was for
     
     >
     
      a lazy mapmaker like me. (Perhaps a special server-dump-information mode
     
     >
     
      that looks for oddly priced spellbooks, so mapmakers can tell if they should
     
     >
     
      change prices.)
     
     
  Well, there are some map check scripts in the lib/adm directory I think which 
goes through and tries to find errors in the maps (exits that lead no place 
being the most common, but also things like missing archetypes).  Certainly, a 
sanity checker for value could be added to those.

  I just wonder how many people actually look at all the messages the server 
spits out - there is some problem that it potentially spits out so many that 
they are sort of become meaningless.


>
     
      However, I dunno if Yann Chachkoff wanted ints pass by value or by
     
     >
     
      reference.
     
     
  Hopefully, he can pipe up.

>>
     
      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.
     
     >
     
     
     >
     
     
     >
     
      Neither am I. In my compile of the client, when disconnected from the
     
     >
     
      network: After leaving a server, the client appears to block for half a
     
     >
     
      minute before giving up on the metaserver. It was just mildly annoying to
     
     >
     
      wait for the old client to go away so I could try the next compile.
     
     
  I wonder if that is the timeout for nameservice, or the timeout for the 
connection attempt - or maybe a combination of both.  One would think that if 
truly disconnected from the network, the OS would realize that and just quickly 
return host unreachable or the like - but I suppose it depends on how the 
connection is set up and whehter the route information remains after 
disconnecting from the network.

  OTOH, I do notice there is a METASERVER define in the config file for the 
client - if there is a config, having a command line switch to toggle it makes 
some amount of sense.


>>
     
      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
     
     >
     
     
     >
     
     
     >
     
      Just to be clear: 
     
     >
     
     
     >
     
      The patch I made was originally to do things like redefine the tab with the
     
     >
     
      gold coins on it to have all the money-type objects in it. (*Sorting* your
     
     >
     
      stuff differently was an afterthought.)
     
     
  So presumably, the original tab reselection was based on types of the object 
and/or flags on the object?

>
     
     
     >
     
      It doesn't filter every view of the inventory the same way.
     
     >
     
     
     >
     
      <snip: details about storing four octets for each item player carries>
     
     >
     
     
     >
     
      That sounds useful. I should check the archives for earlier discussion about
     
     >
     
      it. Given the discussion about a better map command, agreeing on what way to
     
     >
     
      extend the protocol could be complicated.
     
     
  Note that for this 4 bytes of data, it isn't the map command that needs to get 
updated, but rather the itemcmd and updateitem protocl commands - only if the 
object is in the players inventory, or where the player is standing, do we care 
about this extra data.  Note that right now, any object not where the player is 
standing is just sent as a face in the map command.

  Updating the item commands shouldn't be to hard - add another setup command 
that the client sends to the server (setup itemoctet) - If the server sees this, 
it knows to send those bytes to the client.  If the client gets the affirmative 
that the server knows the command, it would then know to expect those bytes.

  The protocol bit actually isn't that hard - potentially harder is the issues 
related to pickup/drop/merge (those bytes should get cleared when and object is 
dropped to the ground (but not a container), and when a player picks up an 
object, it should get merged with objects that have these bytes set - but that 
isn't a simple thing to CAN_MERGE, because you want the flags not to be cleared. 
  Perhaps looking at the inventory lock would cover how that is done (you pick 
up objects and they merge with your locked objects, but the lock flag isn't 
cleared).


>
     
     
     

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