Code:
mob/var/slot1
mob/var/slot2
obj/item/equip/var/EquipSlot = 0
obj/item/equip/proc/SlotCheck()
usr.slot[src.EquipSlot] = src
///^ Obviously this won't work, but I want to figure out something like this that will work.
Okay so I'm attempting to create a proc that checks and item's EquipSlot variable, determines what slot to equip the item in.
Code: mob/var/slot1 |
#define HEAD 1 |
Your 'data' list is entirely redundant, as are the associated values of your 'slot' list. This can be done with a single basic list.
mob This allows you to have a dynamic array of slots without having to update the slots list, and entirely removes the need for a second list (which I didn't see the use of in the first place). |
In response to Nadrew
|
|
Nadrew wrote:
Your 'data' list is entirely redundant, as are the associated values of your 'slot' list. How are the associated values redundant? something like: Equipment/Head/Helmet{slot=HEAD} won't work if it is done directly that way, without the help of the associative list (it gives me a runtime error) The reason I created the "data" datum was in order for admins and so forth to be able to monitor(if they pleased) which players had which items equipped, and which slot said item was located in and all that good stuff(once more things are added to the system itself) Not to mention that your approach just looks outright ugly to me(personal preference here, but w.e) |
Equipment/Head/Helmet{slot="Head"}
Would work perfectly fine with my example, there's no need to a numerical constant, you can use strings. Admins would easily be able to monitor equipment with mine too simply by viewing the contents of the 'equipment' list. This would show both the equipped item and the slot the item is equipped to. Your method seems complex for the sake of complexity, and keep in mind my approach was written on the fly as an example of a less complicated means of doing what the original poster wanted that accomplishes the same thing without limiting the slots to constant values. You can literally give any piece of equipment any slot value you want and it would still work correctly without having to add a new numerical constant for a new slot. |
In response to Nadrew
|
|
I would implement Unequip as a verb, not a proc, but allow it to be called as a proc by Equip. (usr would therefore still be valid.) It should not be assumed however that usr is the person wearing the equipment, nor that it's actually equipped.
The holder does not need to be an argument in Unequip(), because equipment you're carrying should be in the wearer's contents. Therefore, if src.loc is a mob, they're the holder. Otherwise, it should be assumed that src is not equipped at all. |
I had a little bit of time to go back to this and edit some things, and this is what I came up with: please don't flame me for the use of datums, specifically the "database" one, as I plan on expanding upon it when more things are added. I actually like the way it turned out, I'll save it and possibly use it in the distant future, with some obvious tweaks of course. The way the code is written is visually pleasing(for me) and I don't find it "complex" as Nadrew stated.
I'm just posting this here so that I have somewhere I can find this and in case somebody else likes my approach as well. Database datum: database Equipment: Equipment Also, please keep in mind that I did this in the spare time that I had, so there might be a lot of things that could be made more efficient. I'll get back to it some other time. EDIT: Made some changes to the "database" datum to make it more relevant to the system itself, along with some other (minor) changes on the Equipment side(to accommodate the database revamp) |
You can use that demo for reference. It does pretty much what you're looking for.