[CF-Devel] Adding improvments

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

Todd Mitchell wrote:
>>
     
     I think Todd was trying to do something more specific, where a NPC would ask
     
     >>
     
     you a pointed question, and you would have to answer it.  I'm not sure I want
     
     >>
     
     NPC's locking me into conversation.
     
     >
     
     
     >
     
     
     >
     
      I was actually trying to get my mind around something more generic so
     
     >
     
      that I wouldn't have to write a new player state for every time you
     
     >
     
      wanted to query the player.  I don't want NPC's locking you into a
     
     >
     
      conversation per/se, but can think of times when you would want to
     
     >
     
      initiate getting input rather than having to doing everything
     
     >
     
      statelessly.  At he moment I don't know enough to see how it would work,
     
     >
     
      but my thought was that you would have a recieve_input function that
     
     >
     
      would be like a clearing house and just grab op->contr->write_buf and
     
     >
     
      put it somewhere that the calling function that initiated the query
     
     >
     
      could pick it up from...
     
     
  My take:

  If an NPC is awaiting input, that input should still come from a 'say' 
command.  I don't see any issue with NPC's having stateful conversations, nor 
initiating the conversation (presumably, both of these could pretty easily be 
done with scripts).  The npc script would determine what state it is in (simple 
variable).  It could also hold a variable for hte last time it was 'talked' to, 
so that if the player wander away for 5 minutes or whatever, the conversation 
would start from scratch.

  As far as your first statement about 'new player state every time you want to 
query the player', that won't get changed above.  I imagine this is because your 
working on the change player password stuff, which would entail new states. 
However, such changes are actually quite rare, and arguable could be handled 
mostly by the client.

  Eg, have something like a 'changepassword <old password> <new password>' 
command.  You could have a client dialogue for that - something that has three 
boxes - enter your old password, enter your new password, enter your new 
password (confirm).  Client would confirm that the new passwords do in fact 
match, and if so, then send that changepassword command.

  This may not fix everything, but would probably fix most of them - there will 
always be a few cases where you need to add a new state, but I really can't 
think of any.

  Giving the client more responsibility (for player creation) actually reduces 
the number of states.  And also provides a better interface to the user.


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


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