[CF-Devel] Re: [CF-Devel] Patch submission: item renaming

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

     nicolas.weeger at laposte.net
     
      wrote:

>
     
      also we could imagine having both control-rightclick in client and the 
     
     >
     
      'rename command (as far as i know, the only thing you can't do easily 
     
     >
     
      without the mouse is object locking/unlocking)
     
     >
     
      that would also mean doing a dialog box to ask for the new name
     
     >
     
     
     >
     
      it's imo easier to first implement 'basic' rename with a simple 
     
     >
     
      interface, then add a custom client implementation like 
     
     >
     
      control-click. which would just use that rename function (like the apply 
     
     >
     
      works, right?) 
     
     
  Well, it should be smarter than that.

  Your current rename function requires that the player mark an object first, 
and then the rename renames that object.

  IMO, this could be quite error prone.

  If there is a mouse combination that says 'rebind this item', the client could 
easily send along the item tag as well as its new name.  With the way things are 
now, for it to use the current rebind command, it would have to send a mark 
command for that object, and then a rename for that object.  That probably isn't 
good (as the player using the client may not realize that the item he has 
previosly mark is now something different because he did a rename).

  Since the client can certainly know the item tag based on the command, there 
is no reason for there not to be a rename command that takes a tag as well as 
new item name.

  I have no problems with the existing rename command that uses marked objects 
(useful for clients in which perhaps it is more pain than it is worth to put in 
a 'good' rename interface, say the x11 client).  But there should be provision 
for a better rename interface.  This could still be a command the user types if 
(if they know the item tag), like rename_tag <tag> <new_name> type of thing.

  However, as I think about this, I start to wonder if a better interface for 
gtk client object interaction may be desirable.

  With the number of different actions available, knowing if it is shift click, 
control click, whatever, is getting out of hand.

  My thought would be this:
Left Click: this selects and object.
middle click: apply/unapply like now
right click: drop item/pick up, like now.

  Now for selected objects, we have some other glue.  Like a row of buttons at 
the top of the inventory pain for different operations - examine, rename, lock, 
mark, drop, apply (redundant with the last two above, but if you say were 
playing on a system that had only 1 or two mouse buttons, could still be useful).

  For the selected object, in fact, it could get sent along as basically the 
marked object for any object command.  Eg, you select the torch, apply the flint 
and steel (middle mouse click), and the server acts as if the torch as marked, 
so ignites it.  This would probably be a better improvement now.

  Note that I'm not saying you should write this - I'm just expressing that this 
would be a nice improvement to the interface IMO.


>
     
     
     >
     
      true, didn't think about that. My mistake.
     
     >
     
      (on the other hand the client, at least gtk, too has buffer overruns 
     
     >
     
      issues sometimes... try to bind a key to a hundred 'use_skill praying' :-))
     
     
  I actually care about buffer overflows on the client a whole bunch less than 
on the server.

  If you find an exploitable buffer overflow in the client, chances are you 
aren't going to use it as an exploitation.

  But a buffere overflow in the server can be more convenient.  I beleieve there 
are known abuses about crashing the server lets you get something nicer (I think 
item duplication being the bigger one.)  But also an exploitation with user 
supplied data could perhaps be used as a way to let a user log into the server 
system, which certainly wouldn't be good (this probably isn't all that likely, 
since I'd bet most people run and compile there own servers, so for a hacker to 
know the appropriate data to toss in the buffer to get an overrun would probably 
be very tricky to figure it out).



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