Inventory and Itemised lists.

ID:151482
 
Sep 7 2010, 3:23 am
Allo, So after scrambling threw some documents i have come to question how i am currently doing my inventory system. (sending all things to usr contents and then outputting each "pocket zone" using an obj var to define what zone is what.

So basically my question is this:

Is it ok to be using contents for most things and then searching that contents list for a variable thats defined in an object to display certain "area" things for items such as equipment, clothing and crafting..

Or is it better to have multiple lists inside the mob that would contain a reference (or the entire object link itself inside that list to destroy contents all together).

Thoughts?
Sep 7 2010, 11:05 am
Midgetbuster wrote:
Allo, So after scrambling threw some documents i have come to question how i am currently doing my inventory system. (sending all things to usr contents and then outputting each "pocket zone" using an obj var to define what zone is what.

So basically my question is this:

Is it ok to be using contents for most things and then searching that contents list for a variable thats defined in an object to display certain "area" things for items such as equipment, clothing and crafting..

Or is it better to have multiple lists inside the mob that would contain a reference (or the entire object link itself inside that list to destroy contents all together).

Thoughts?


I ultimately use contents along side with my own various equipment lists just for simplicity of using Enter(), Entered(), and Exit() Exited() procs for easy handling of getting and dropping inventory and assigning them to the correct inventory list. It also makes it easy to distinguish a "user" by using the mobs contents list in an items procs or verbs. EX:

obj
   items
        proc
            Use()
                var/mob/user=src.loc
                if(ismob(user))
                    user<<"You suck!"
Sep 7 2010, 5:26 pm
All objects should go to contents. You should sort items into lists instead of relying on looping through them for a variable, because it simplifies things and will be faster.
Sep 7 2010, 6:06 pm (Edited on Sep 7 2010, 8:05 pm)
In response to Garthor
so something like this.

mob/var
  general[0]
  crafting[0]
items
  parent_type = /obj
  var/invent = "general" //default list
  equipment
    hat
      icon = bla
      bla bla bla.

  crafting
    stick
      bla bla bla
  verb/Get()
    set src in oview(1)
    if(src in oview(1))
      Move(usr)

  Move(mob/m)
    ..()
    m.vars[src.invent] += src


or something to that effect?

then when doing inventory simply output it like so?
mob/proc/update()
  for(var/items/o in crafting)
   //run usual invent output stuff


am i right on that thinking or is that incorrect?

EDIT: Pointed towards garthor some what since im using the code snippet he provided earlier for stacking and what not that uses the obj moving.
Sep 7 2010, 7:30 pm
In response to Midgetbuster
Midgetbuster wrote:
so something like this.

> mob/var
>   general[0]
>   crafting[0]
> items
>   parent_type = /obj
>   var/invent = "general" //default list
>   equipment
>     hat
>       icon = bla
>       bla bla bla.
> 
>   crafting
>     stick
>       bla bla bla
>   verb/Get()
>     set src in oview(1)
>     if(src in oview(1))
>       Move(usr)
> 
>   Move(mob/m)
>     ..()
>     m.vars[src.invent] += src
>         
>

or something to that effect?

then when doing inventory simply output it like so?
> mob/proc/update()
>   for(var/items/o in crafting)
>    //run usual invent output stuff
>

am i right on that thinking or is that incorrect?


You should be using mob/Enter() and mob/Exit() procs to handle that instead of obj/Move(). Here's a demo I made a couple years expressing this method.

http://www.byond.com/developer/Goku72/ EquipmentInventory_System
Sep 8 2010, 4:01 am
In response to Teh Governator
Teh Governator wrote:
You should be using mob/Enter() and mob/Exit() procs to handle that instead of obj/Move().

Entered(). The distinction between Enter()/Exit() and Entered()/Exited() is very important and often passes over the head of newbies because of some reasons, so pay more attention to which name you end up writing.
The purpose of Enter()/Exit() is to determine whether to allow or disallow a move. They shouldn't actually perform any action with a lasting effect; only calculations. Handling 'real' effects in them is a common mistake.
By default, turf/Enter() handles the density rulings (disallowing more than one dense object in a tile).
Entered()/Exited() are called after a move had already taken place, and are meant to be used to do actions in response to / after movement. By default, they don't do anything.
Sep 8 2010, 6:15 pm
In response to Teh Governator
Well i looked at your demo previously when deciding on my inventory systems anyway.

So.. Something like this would be the way to go?

mob
    Enter(items/A)
        if(istype(A,/items))
            return ..()
    Entered(atom/movable/A)
        ..()
        if(istype(A,/items))
            var/items/B = A
            B.stack(src)


Then as the B var suggests it runs the items proc named stack. (stack has a mob/m argument that allow for typecasting of the user)
Sep 8 2010, 10:17 pm
In response to Kaioken
The demo covers this. I wasn't gonna explain it all over again in a post.
Sep 8 2010, 11:31 pm
In response to Teh Governator
the demo covered adding to another inventory list, the thing i posted was confirming whether or not the current stack proc i used that was contained inside the obj move transferred into the correct coding terms for the mob entered an exit.
Sep 9 2010, 3:33 am (Edited on Sep 9 2010, 3:47 am)
In response to Teh Governator
I did forget to mention that I gave a glance at the demo to verify that you picked the right procs to override there and saw that it was fine there - but the demo is irrelevant. Your post is still misleading, at any case.
You told Midgetbuster to do what he was doing in items/Move() in "mob/Enter() and mob/Exit() procs" instead. Taken as presented, that's wrong, and what he did there should be placed in Entered() instead.
Linking to a demo that got it right doesn't help, as not every reader is going to even open that link (it's probably pretty safe to say that the majority won't, in fact), and the ones that do could get confused because your demo and your post contradict each other (a newbie could have a hard time choosing which is right).
The above prompted me to correct what you said and explain the difference between Enter()&Exit() and Entered()&Exited() in an attempt to prevent readers from getting potentially confused and make things clear.

Oh, and to expound on one more thing, while I'm at it:

Teh Governator wrote:
I wasn't gonna explain it all over again in a post.

There's a big difference between an explanation and a code example (even with comments), which is what a demo essentially is. You didn't actually explain anything about the language in the demo; like most demos, it basically assumes prior knowledge of the language.
Naturally, it's also pretty silly for you to use that excuse while you didn't explain anything (such as how Enter()/Exit() and return values work, and why you chose to do X in Entered() instead of Enter(), etc) in the first place, so you wouldn't end up explaining it again. ;)

@Midgetbuster: His reply was directed at me, not you.
Sep 9 2010, 3:54 am
In response to Kaioken
Yeah i kind of figured that out after re reading the thread but figured there was no real need in removing the post as it did somewhat convey a message either way so heh. +1 to unintentionally post
Sep 11 2010, 12:27 pm
In response to Kaioken
Kaioken wrote:
Teh Governator wrote:
I wasn't gonna explain it all over again in a post.

There's a big difference between an explanation and a code example (even with comments), which is what a demo essentially is. You didn't actually explain anything about the language in the demo; like most demos, it basically assumes prior knowledge of the language.
Naturally, it's also pretty silly for you to use that excuse while you didn't explain anything (such as how Enter()/Exit() and return values work, and why you chose to do X in Entered() instead of Enter(), etc) in the first place, so you wouldn't end up explaining it again. ;)

Point taken. Perhaps it's time to update that demo with some better explanation. It's only been 6 years. =)