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

Mon Aug 11 08:11:40 CDT 2003

>

      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.

Exactly like the 'enchant armor', 'improve weapon', or 'flint & steel' behaviours.
I am not saying this is the way way to implement. Just seeing so many commands using marked items, i simply used marked items for rename...

>

      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 type of thing.

I have no opposition to rename_tag command, quite the opposite.
I think that's how apply/examine work both, no? Either the player clicks in list with mouse, and then the tag is used, or you can type 'examine ring of Thieves' and the name is used.

I must also say that i almost never use the mouse (except to lock/unlock items, and sometimes to sort stuff), so i simply implemented the command the easiest way for me (via keyboard and not mouse)

>

      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.

Improving the interface would sure be nice. Even though as it is now is fine for me, i'm sure many people want to improve it...

>

      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).

True on that, shouldn't have mentioned client overflows...
Btw, speaking of server overflows, i'm wondering about the inscription skill, if you couldn't use it to hack some things... i'll experiment someday, but right now i'm not at home, and thus don't have sources or such...
Also are there characters that shouldn't be in custom names? (or in text you write in books/scrolls). Obviously things like line feed/line break shouldn't be allower, but are there other characters that should be removed for satefy concerns?

Nicolas 'Ryo'

Accédez au courrier électronique de La Poste : www.laposte.net ; 
3615 LAPOSTENET (0,34€/mn) ; tél : 08 92 68 13 50 (0,34€/mn)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

     http://shadowknight.real-time.com/pipermail/crossfire/attachments/20030811/89dc6771/attachment.htm