[CF-Devel] Client side improvements

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

Nicolas Weeger wrote:

>
     
      What I had in mind, but it may change based on what is discussed here, are
     
     >
     
      things like:
     
     >
     
     
     >
     
      * conditions based on inventory's items' name, like: if ( has_item( 'scroll
     
     >
     
      of word of recall' ) ) 'apply word of recall' else 'invoke word of recall'
     
     >
     
      <- pretty easy to understand i guess
     
     
  Yeah - basic item checking code wouldn't be hard in any scripting method.

>
     
     
     >
     
      * macros recording: ie just exit Scorn, 'record s2n', move to Navar, 'end'.
     
     >
     
      Now you have a macro you can run with for instance 'run s2n' -> duplicates
     
     >
     
      your trip from Scorn to Navar... Also something like 'runinv s2n' -> runs
     
     >
     
      macro backwards (ie takes you from Navar to Scorn). Note this works because,
     
     >
     
      right now, there is no random element involved in the trip....
     
     
  This to me isn't really script related, or could easily be done without it.
Eg, you could do something like 'begin_script far_trip' and the client just
captures all the commands (basically, just appends them like a very long
binding) until player does end_script.

  Lack of random element is sort of relative, eg, while there aren't monsters,
there certainly could be players that get in the way.

>
     
     
     >
     
      * maybe stuff based on tiles. Like 'road follower' helper. When you move,
     
     >
     
      checks the square you are on, and if square you are directing to isn't the
     
     >
     
      same arch, look around for the same arch, and change direction as found (lets
     
     >
     
      you follow roads easily)
     
     
  Ok, that requires a bit more work than any basic scripting thing, because now
you need to start examining the spaces around the player to look for things of
the same face.


>
     
      Well yes, except it's easier to bind 'apply food' than 'apply apple or booze
     
     >
     
      or cake or...' And, unless i'm mistaking, apply code for items on the floor
     
     >
     
      takes the first appliable item. IE you can't say which item to apply - thus
     
     >
     
      the exit fun things... How many died because they thought they had applied
     
     >
     
      the exit, only to eat food / body part there was on the square? <grin>
     
     

  It would be a trivial change to have an apply_below.  In fact, if the client 
tells the object to apply, it can apply any object on the ground (just like if 
you click on the exit object, you apply that and not the objects on top of it).

  Thus, if the client actually interperted the string given to apply and found 
an item of appropriate name, it could apply whatever properly.  In fact, that 
has other advantages, in that if you apply something you don't have (or isn't 
around), the client can immediately tell you that, vs it going to the server and 
the server then telling you that you don't have it.

>
     
     
     >
     
      Could be based on item's type, probably...
     
     >
     
      Of course that'd require server-side implementation. 
     
     
  The client gets a client_type field - the client knows that field, as the name 
suggests, and can thus know that object X is of an edible nature.  This can all 
be done on the client.

  I strongly suggest you read the protocol file, so you can see what the client 
knows and what it doesn't know.




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