Item Stacking

Page: 1 2
ID:152598
 
May 13 2006, 5:31 am
I was wondering. What would be the best way to make an item statcking system? I've had a few ideas.

1. A list containing types or names of the items that can be stacked. I plan on sending a text string to the item stacking procedure so I don't have to create and delete an object to stack it. I could just check in the list to see if it can eb stacked. (Less items can be stacked than can't, and it becomes vive versa, I can always make a list of the items that can't be stacked.)

2. Variables would work, but they would require me to actually create the object to check upon it's stackability. parent_types were another option, but again, they'd require me to actually create the object.
May 13 2006, 5:33 am
Why would you need to stack something that doesn't exist?
May 13 2006, 5:57 am
In response to Crashed
Well, when you get an item through mining or something, the first item you get won't be stacked. It will be created and added to your inventory. The second item you get of the same type will be added to the suffix of the item you have. It's a very simple idea actually. And it should hopefull reduce lag that statpanels and excessive amounts of objects cause.
May 13 2006, 5:59 am
In response to CaptFalcon33035
Okay, then instead of having a list of stackable objects, have a variable. Search for all stackables of the same time and add the amount.
May 13 2006, 6:22 am
In response to Crashed
But I only want want item in the user's inventory of the same type. The list was to check if the items were stackable or not. Your idea seems incredibly inefficient.
May 13 2006, 6:58 am
In response to CaptFalcon33035
... CaptFalcon. That was the most idiotic thing I have ever heard.

How do you handle inventory? Do you set the obj's loc to the mob?

If you do, which is how it's handled in most ORPG's on BYOND, then just loop through the inventory for the stackable item, like he said. Add the amount like he said, and delete the object that's being stacked into another object.
May 13 2006, 7:16 am
In response to D4RK3 54B3R
That would be a bit better, actually. He never said delete the item. It would also be way easier, but it'd call extra procedures every 8 ticks, generating more lag than I'd want. I think I'll just got with option 1.

The monsters will contain a list of text strings for their inventory. When they die and you loot their bodies, the text strings will be sent through a procedure to see if you have the item to the text string is relating to.

If you don't, it creates the object. If you do, it simply adds to the suffix. It saves us from constantly calling a procedure to stack the inventory, creating new objects, and delelting old objects. I'm going to squeeze the best performance I can through this RPG.
May 13 2006, 7:33 am
In response to CaptFalcon33035
No that wouldn't call procedures every eight ticks.

Ugh... What you're saying is too complex!

You just need the item and give it an amount var!

Whenever a player picks up an item, use for() to loop through the damn inventory and do the appropiate things to the amount vars! Understand?
May 13 2006, 7:44 am
In response to D4RK3 54B3R
Yes, I understand.
May 13 2006, 7:50 am
In response to D4RK3 54B3R
D4RK3 54B3R wrote:
Whenever a player picks up an item, use for() to loop through the damn inventory and do the appropiate things to the amount vars! Understand?

Ungh.
var/obj/item/a=locate() in usr
// VS
for(var/obj/item/a in usr)


What'd be best? o.O
May 13 2006, 7:52 am
CaptFalcon33035 wrote:
I was wondering. What would be the best way to make an item statcking system?

Not saying it's the best, but here's the approach I used for L&D:

atom/movable
    proc/AddToInventory(atom/movable/incoming)
        // By default I can't carry anything.
        return 0


obj
    var
        _stack_count = 1

    var/tmp
        is_stackable = 0 // Can one object represent several objects?

    AddToInventory(obj/O)
        // If I'm stackable and this is my type, increment my count and delete it.
        // Not using istype() here because I only want exact type matches.
        if (is_stackable && type == O.type)
            var/incoming_count = O.StackCount()
            if (incoming_count > 0)
                AddToStack(incoming_count)
            del(O)
            return 1
        return ..()

    proc/AddToStack(amount)
        var/count = StackCount()
        SetStackCount(count + amount)

    proc/SubtractFromStack(amount = 1)
        var/count = StackCount()
        SetStackCount(count - amount)

    proc/StackCount()
        return _stack_count

    proc/SetStackCount(amount)
        if (amount < 1)
            del(src)
            return

        _stack_count = amount
        suffix = "[amount]"
        return


I'd be happy to release this as a library if anyone wants it that way.
May 13 2006, 8:59 am
CaptFalcon33035 wrote:
I was wondering. What would be the best way to make an item statcking system? I've had a few ideas.

1. A list containing types or names of the items that can be stacked. I plan on sending a text string to the item stacking procedure so I don't have to create and delete an object to stack it. I could just check in the list to see if it can eb stacked. (Less items can be stacked than can't, and it becomes vive versa, I can always make a list of the items that can't be stacked.)

This is entirely the wrong way to go. It's a nice idea that you could simply avoid creating an item that already exists, but then the process of looking for a string in a list is in the end identical to looking for an item of the same type in a container. The only difference is, your way requires a lot of maintenance with a long list of strings or type paths.

2. Variables would work, but they would require me to actually create the object to check upon it's stackability. parent_types were another option, but again, they'd require me to actually create the object.

Actually you're only half right. In situations where you want to see if you can simply add onto an existing stack, you don't have to create an object at all. Simply look for the item of the appropriate type, and check if it is stackable. If so, then obviously a new item of the same type would be the same.

Crashed proposed the very same thing in [link]. In [link] you dismissed it saying it's too inefficient. On the contrary, it's no less efficient than your string list search, and it has the advantage of being easy to work with and scalable. It is, moreover, robust. Maintaining a giant list of strings is not robust, nor scalable.

Lummox JR
May 13 2006, 9:01 am
In response to Mysame
In stacking systems, locate() is the wrong choice. Hard-coding the type is also the wrong choice. In fact, neither statement you proposed is right.

What you do need is a for() loop, a type check, and then any further checking to see if items of the same type are in fact identical. For ordinary items that are basically all alike, this latter check is unnecessary.

Lummox JR
May 13 2006, 1:48 pm (Edited on May 13 2006, 1:54 pm)
In response to Lummox JR
I was only getting at the item stacking procedure check being too inefficient. I was under the impression that he wanted the procedure to be called under Stat() (I don't really know why I thought that, I think it's because someone else also posted about item stacking and was sort've glacing over it.)
hence saying that it would be called every 8 ticks, which would be inneficient.

And for half the statement only being right, how would I know if the item I'm trying to send is stackable and the same type as the item inside the contents? It's making no sense. I can always add onto an existing stack, I never stated otherwise.

[Edit]
And the list would only contain the types of a few items. Let's say I only want to stack metals. Ores and Ingots would be under /obj/Metals/ and would be stackable. But for a total of 8 types each of ingots and ores, only one type entry will be present.

But, I think I'll stick with the variable way. I realised with help from you guys that all the procedures and stuff I'd be calling would be equivalent to the generation of lag (if not worse) as the system you guys proposed. Thanks for the help.
May 13 2006, 2:35 pm
In response to CaptFalcon33035
CaptFalcon33035 wrote:
I was only getting at the item stacking procedure check being too inefficient. I was under the impression that he wanted the procedure to be called under Stat() (I don't really know why I thought that, I think it's because someone else also posted about item stacking and was sort've glacing over it.)
hence saying that it would be called every 8 ticks, which would be inneficient.

Apparently you didn't think this through. A stacking system operates on items when they change locations. It does not operate continuously. Stacking isn't about display, but about manipulating items. That's pretty easy to figure out.

And for half the statement only being right, how would I know if the item I'm trying to send is stackable and the same type as the item inside the contents? It's making no sense. I can always add onto an existing stack, I never stated otherwise.

Obviously, by comparing the type path you're trying to create by the type paths of objects already in the container. If you find one the same type that's stackable, and that is a match for the item you want to create, there you go.

Lummox JR
May 13 2006, 3:05 pm
In response to Lummox JR
Lummox JR wrote:
Apparently you didn't think this through. A stacking system operates on items when they change locations. It does not operate continuously. Stacking isn't about display, but about manipulating items. That's pretty easy to figure out.

I recall a certain someone saying there is no one way to code something, and a stacking system can be visual and can operate continuously. The general meaning of the term would go against my argument, though.
May 13 2006, 3:10 pm
In response to CaptFalcon33035
Sure, you COULD re-stack the item every time you updated the display.

You could also slam your head into a brick wall repeatedly. That doesn't mean it's a good idea. =)
May 13 2006, 4:17 pm
In response to Crispy
LOL

Says you. =D
May 13 2006, 5:47 pm
In response to CaptFalcon33035
The analogy holds - if you want to go and slam your head into a brick wall I'm not going to stop you. =P
May 13 2006, 7:03 pm
In response to CaptFalcon33035
CaptFalcon33035 wrote:
Lummox JR wrote:
Apparently you didn't think this through. A stacking system operates on items when they change locations. It does not operate continuously. Stacking isn't about display, but about manipulating items. That's pretty easy to figure out.

I recall a certain someone saying there is no one way to code something, and a stacking system can be visual and can operate continuously.

The latter part of that makes no sense, and the former should be taken with a grain of salt. Sometimes there really is only one right way to do something. Whether this is one of those times is just conjecture, but as you've seen there are definitely wrong ways of doing this.

Lummox JR
Page: 1 2