Talk:Items.reld
TMC (talk) 20:07, 7 May 2016 (PDT): (Wow, great to see this getting worked on!)
What about Plan for improved items#Equipment options? It seems like it would be versatile. Previously it seemed ambitious, but with editedit it seems like supporting it in the item editor would be pretty easy. The only change needed to Items.reld (to leave us the option to implement this in future) is just to move equip_slots, equip_by, stat_bonuses, elemental_resist, tags/is_equipped, tags/is_equipped_by_active_hero, weapon/attack nodes beneath a equipment/equip_entry parent node. The weapon graphic stuff doesn't really need to be duplicated. As for implementing this in the rest of the engine, it doesn't seem too bad (loop over equip entries until you find a matching one), except I don't know how to display the stat bonuses in shops. The ability to set tag conditions to equipment, which would be very nice, is actually a totally separate feature with its own headaches (auto unequip a weapon in-battle if a tag gets set?)
Also, I suggest "attack" instead of "cure_attack". And I suggest having separate "consumed_by_use" items for in-battle and out-of-battle use, because the effects can be different. For example in-battle could consume the item, while OOB shows a textbox saying "Use this on an enemy!". IIRC items are currently always consumed by use in-battle, but that we could want to change that in future when other in-battle effects, like triggering a script, are added.
Bob the Hamster (talk) 07:15, 9 May 2016 (PDT): I can make those changes. I had not thought of having different stat bonuses when equipped in different slots-- but I like it.
For shop display, I would probably just show the first set of bonuses. Can't handle everything :)
> "IIRC items are currently always consumed by use in-battle"
Yikes! If that is true, it is definitely not intended! A 19-year-old unnoticed bug? Well, this is the OHRRPGCE!
TMC (talk): Oh, sorry, no, that was my assumption; I just tested and Not-consumed and Not-droppable/sellable items don't get consumed in-battle.
Bob the Hamster (talk) 14:56, 11 May 2016 (PDT): re-reading your suggestion, I don't want to move those nodes to be subnodes of the equipment slots. If an item is equippable in multiple slots, I do not want to need to re-enter every bit of equip data about it.
Now having the option to override all those things on a slot-by-slot basis would be cool, but I still need to have a single set of default equipment data for the whole item regardless of which slot it is in.
TMC (talk) 16:46, 14 May 2016 (PDT): You misunderstood; each "equip entry" (better name needed) would still have a bitvector of multiple equipment slots it can apply to, so you wouldn't ever need more than one equip entry when translating item data from an existing .ITM file. I was not suggesting moving all those things to be subnodes of an equip slot node, but to be subnodes of a new equip entry node. But switching to defaults and overrides would avoid having to duplicate stuff when you only want to make a minor change like changing which tag gets set depending on who equips it. But would the extra complexity of the UI be worth it? And does editedit make it easy?