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.

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.

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.

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.

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.

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.

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.

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.

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.

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.