So, I've been thinking, and wading around through my modded EMud code, and looking at all the functions calling for get_eq_char or a variant thereof, and looking at all the instances it means looping through a character's inventory just to check for an object on a specific wear_loc, and it got me wondering…
Is it just that it's a relic of the original Diku, that a character's equipment is tagged on the objects in the character's inventory list? It seems to me, that the same thing could be accomplished with a pointer array in char_data - one pointer per wear location (example mud.h declare in char_data: OBJ_DATA *equipment[MAX_WEAR];). Thus, equip_char, instead of putting a numeric wear_loc on the object, would tag the object worn on the head, for example, to ch->equipment[WEAR_HEAD] == obj. The benefit, as I see it, would mean any call to get_eq_char or get_wield or related functions would then just directly call the pointer, not loop the inventory list until it found a match - thus reducing the amount of looping.
Is it such a minimal benefit on execution time that it's not worth the effort? Perhaps one of the reasons that artificial limits are set on character inventory to keep the loops small? Or are there other potential consequences I'm not seeing that has caused it to remain a field on the object, rather than the character?
I don't know stock Diku that well, but in my CircleMUD (early Diku-rivative) there's an array of obj pointers, just like the one you're describing. You can see it in tbaMUD today. Maybe what you're describing, wear positions on an inv object, is specific to EMud?
Whichever the case, there's a lot to be said about having a separate list for equipment. Inventories are usually a lot larger than equipment slots and have to be elastic. Since slots are by definition limited in number, an array that gives you a way to access a slot directly is very close to mind. In any game where a worn item is a very different beast from a carried item (I venture a guess that this is 99% of games) it makes even more sense to keep the two separated.
'Is it such a minimal benefit on execution time that it's not worth the effort?' If the reason is only execution time, yep not worth the effort of changing that as it already works and you probably already have a method to access a wear obj in the slot you want. Do that if you get bored and cannot think of (or want to do) anything else :) Check your code if the flag is not used for other stuff. Mine has a ITEM_WEAR_TAKE on the item wear flags to specify it can be took when on the ground. I have no idea why it has been put in that field to begin with…but heh not a priority to me.
Oh yeah, I just checked out circle and it does exactly that. I've only worked in Merc-based Diku, so I guess the Circle devs had the same thought I did. Though computer processing speeds were way slower when Circle was coded, so it probably yielded a much better benefit than it would with the gigabits that get shoved around now. I think yeah, I've got way more creative things to do with the code than the wear locations. I'll leave it as is for now.
Though computer processing speeds were way slower when Circle was coded, so it probably yielded a much better benefit than it would with the gigabits that get shoved around now.
I don't know what this means. If your application sleeps 4 times a second like those mentioned codebases do to get the timing for a pulse, and it's mostly idle between those cycles, how much better of an outcome is increasing your idle time without noticeable difference to users, or wrt your hardware quota? In other words, I think it for the most part won't matter to you.
Oh yeah, I just checked out circle and it does exactly that. I've only worked in Merc-based Diku, so I guess the Circle devs had the same thought I did.
Actually, no. Circle did not change it at all, the old Diku code did it like that and circle just never changed it. The merc rewrite is where the equitment being in the carry list was started. There are a number of advantages to having all the objects in one list. Equitment layering and ordering issues when equitment is worn/removed come to mind.