ID:1163551
 
Keywords: get, items, proc
Hi,

I am currently working out kinks in my inventory system and decided to ask this question.

What is the best way to handle picking up/dropping of items?

I have seen two ways this is done the first way is done via mob procs and when the item is clicked it is sent to the clickers "get" proc with the item as an argument, the second way is the usual way where the proc is inside the object.

What is the benefits of each way and which way should i handle this?
There are a few discrepencies between letting the obj have the verb and letting the mob have the verb.

First of all, from a design aspect, you are either going to be telling the mob to pick it up, or telling the obj that the mob is picking it up. Intuitively, you might say the first option is best. But sometimes the second option is the best route to take, based on what you want to do. As a matter of principle, I would personally never let the obj have the verb chiefly concerned in interacting with it, just for the fact that it is not intuitive design. You can argue that as long as the end result is the same, it doesn't matter, but I'd still not suggest it.

As for why it's used on BYOND, I have to guess it's only ever used because it allows for proximity-based access to verbs. At a point this was probably the most feasible way to stop the verb list from being a huge mess.

Now, as for benefits, one of the main ones I can think of is gonna be separation of functionality. Putting functionality on the object allows for unique functionality between objects. This is one of the major aspects in the object-oriented paradigm you want to take advantage of.

Unfortunately, I don't think this is gonna have many practical applications in this scenario, or most any scenario, since you will essentially have to redefine the verb every time.

So basically, put the verb on the object if you have to use verbs, and you have to have them be proximity based, and you don't want a "get" verb clogging up the mob's verb list. Otherwise, don't.

[EDIT]
Another case to be made for object-based interactions is object-unique verbs. This isn't necessarily part of the topic, but it is a decent case for object-based proximity-based verbs.
Arr ok. Well i am not going to be using a statpanel or anything like that..

using a statpanel currently while debugging and as it stands right now i have 2 verbs. a save verb since i wanted to check my savefiles during runtime for savefile sizes and a namechange verb since i was also testing something.

i will ideally be using clicking procedures and popout menus and whatnot that will just launch the proc inside the mob/item.

e.g. currently my items contain the grab and drop procs and are simply launched by 1. Moving the item into my Hudinventory (FA's HUDGroup) or removing said item from invent. or 2. clicking it will also pick it up (no click function as of yet for dropping)

so was just trying to see if there was any real benefit of it being inside a mob or inside the item. cpu/code wise
From a multiplayer standpoint you would also have to address the issue of other players "stealing" items that aren't rightfully theirs.
Verbs are dead. Clicking verbs as your primary means of interaction in your game is absolutely going to ensure that no one outside of byon will ever play your game.

The key to success on byond is not to depend on the standing audience we have here on the site. As such, design your game to use interface elements properly, mouse interaction, and keyboard macros. The only things you should have verbs for are input elements, and interface buttons.

Otherwise, you are wasting your time.
In response to Ter13
Exactly :)
As i said i dont have any verbs other then for debugging purposes currently which are all saved in the one .dm file atm so that when im done with them i either 1. Delete the entire .dm file or 2. delete each verb when i no longer need it i currently have 7 verbs setup.. all of which have no purpose to the game other then to change stupid things as i dont have a char create screen so its to change like... hair, body, race, values and what not till such time as i am done testing those features

As i stated in my above posts i want to use mainly interface things so a popup "admin" control panel for moderating. or quick click commands of a player name in chat for mutes and such.

The main purpose of this entire topic was not verbs at all considering i do not even have a get "VERB" inside anything they are all procs. my item on leftclick launches the Get proc.

Simply i wanted to know if it was more efficient to have.

Get, Drop, Add, Remove etc inside Mob/Proc or Item/proc (they are located in item/proc currently)

e.g.

item
proc
get(mob/human/m)
//or

mob
proc
get_item(item/item)


the code i use can easily be run exactly the same for either mob or item (with small modifications) i was simply wondering if a certain way was more efficient or not.

I intend to have -NO- Visible "verb" clicks that is seen in the old byond days of statpanels. EVERYTHING is being handled by interface using a secondary map interface that will be somewhat recreating a statpanel type thing but more akin to lets say Runescape in terms of viewing.
I'd say use a system of callbacks similar to enter()/exit()/entered()/exited()

mob
var
encumbrance = 0
max_encumbrance = 100
proc
pick_up(var/obj/item/i)
if(get_dist(i,src)<=1)
if(src.encumbrance + i.weight>src.max_encumbrance)
return 0
return 1
picked_up(var/obj/item/i)
src.encumbrance += i.weight
drop(var/obj/item/i,var/atom/newloc)
if(!newloc)
newloc = src.loc
if(get_dist(src,newloc)<=1)
return 1
else
//or we could throw the item toward the place the mouse is hovering.
return 0
dropped(var/obj/item/i)
src.encumbrance -= i.weight

obj
item
var
weight = 10
proc
pick_up(var/mob/m)
. = m.pick_up(src)
if(.)
src.picked_up(m)
picked_up(var/mob/m)
src.Move(m)
m.picked_up(src)
drop(var/mob/m,var/atom/newloc)
. = m.drop(src,newloc)
if(.)
src.dropped(m,newloc)
dropped(var/mob/m,var/atom/newloc)
src.Move(newloc)
m.dropped(src)


This way, you can set up items that certain people can't pick up, or drop. For instance, a cursed sword that only paladins can resist the allure of but anybody else who tries to drop it finds themselves unable, or a holy book that will not be picked up for evil characters.

In addition, you can create player-specific limitations to picking things up, like we did with the encumbrance system.

We can also make it so that certain players can pick things up from more than one tile away, without having to tell the items that the player is using telepathy.

I like the four-proc system a lot because of its flexibility. You will catch me using it pretty often if you see enough of my code.


As for how to trigger picking up and dropping items, I prefer using MouseDrag procs to trigger pick up and drop. Drag an item over yourself to pick it up, or drag an item over a turf to drop it. Optionally, you can put a single verb on an item, that when right-clicked can be selected from the context menu, that will allow you to drop the item at the player's feet, but I'd prefer to use a modifier like shift+right click, or ctrl+click to notify a drop.
Hmm i like the idea of the drag to yourself to pick up.

As it stands currently i use mouse drag for some of the picking up, but i also allow them to pick up using Click functions to.

as it stands they can obtain an item by.

1. Clicking it
2. Dragging it onto an item already in inventory (if its the same item and canstack it stacks) otherwise moves to blank spot
3. Dragging it onto a blank slot in inventory will cause the item to be added in that position

so its fairly flexible to allow for people to do what they want as i the invent hud is (currently) always open unless you swap out the HUD with say equipment view or skills view.
In response to Ter13
You're making these check procs but you're not actually checking them.
You're also adding an atom to a numeric variable.

In response to Kaiochao
Kaiochao wrote:
You're making these check procs but you're not actually checking them.
You're also adding an atom to a numeric variable.

Good catch. Was writing code from the hip.