The problem with XEquipItem() and alternatives (there is one or two) is that they all require a definite item name. A strref. They are good for a scripted specific instance only. FillSlot() is the only action that is context-sensitive, it says "put whatever is appropriate in there." So, as I said, it's fine if there is only one suit of armor on a creature, one weapon and so on. I've used it successfully to get monsters to pick up equipment, from the ground, and put it on. It takes a combination of PickUpItem() and FillSlot(). Unfortunately, the former of these requires a strref, I dearly wish there was an action to pick up the nearest pile or an object of a type. But my purpose was to equip the monsters with items that are likely to be dropped, so I wrote in standard weapons, standard armors and so on.
You can script monsters directly, if they are custom-made, but I always like solutions that work on anyone. To get any monster to arm itself, create a spell that uses opcode 82, for give the monster a custom script, and insert it at the AREA script level (my old trick). Then either finish that script with ChangeAIScript("",AREA) or include another 82 opcode in the spell, delayed, setting the AREA script to a blank file. Either way the behavior will phase itself out. A delayed script change with 82, by the way, is a reliable way to pre-program a creature. It is true, you can give scripts to a creature with ChangeAIScript() and probably in other ways, but these commands get invoked either from within another script, as I just now suggested, or from ActionOverride(). If the launching script fails or the minion doing the overriding screws up, then the chain will be broken. A delayed 82 works if you leave the area and return, save and reload, and it is also unconditional - you do not have to look for a place to attach your script change to some other actions. In fact, it may be impossible in some cases. Let's say you have scripted a creature to go around healing people, but you want it to stop within six hours. What to do? Local timers don't work, and a global timer is no good if there are several such healers. But fix them with an 82 change to occur six hours later, and whenever each one starts making the rounds, he will change his mind and stop on time. If you return to the area a long time afterwards, then time will catch up with you on all delayed effects as you enter. So if one healer was just starting and another already coming to the end of his shift, and you left to come back a day later, both 82s will happen at once (or rather "will have happened" equally, by that point, strictly speaking). But this sort of thing, concurrence, is not a problem in practice.
I digress. Just wanted to lay that out. However you get the script onto a monster, you then write:
IF
True() /// There are no triggers for seeing stuff on the ground at all
PickUpItem("leat01") /// Basic leather
FillSlot(SLOT_ARMOR)
ChangeAIScript("",AREA)
END
This gets more difficult as you try to include more items that may be nearby, and there is no way to measure distance to the closest suit of leather, so the monster may cross the map in search of one, but I don't think impossible actions, when no one has dropped leathers, will break the rest of the sequence. More likely the monster will make do with what he can get his mitts on; but if you include a command to pick up a leather armor and, say, a chain mail, and both can be gotten, then the monster will pick up both, but only one will end up worn with FillSlot() - all other armors the monster grabs are going to get destroyed by that flawed action. Still, it is something to work with.
Edited by temnix, 19 August 2017 - 05:14 AM.
