Jump to content


Photo

Matchlock-type item restrictions, thoughts


  • Please log in to reply
No replies to this topic

#1 temnix

temnix
  • Member
  • 983 posts

Posted 21 February 2018 - 06:30 PM

The Restrict Item effect, 319, is specific, but it's only good if you know the particulars of the creature to whom you want to restrict an item. If you have a script name in mind, just a regular name of an NPC, or if you want general restrictions to class, gender and so on, then it's satisfactory. But if you want the item to be usable only by one person without knowing in advance who that will be, and if you want only him to be able to use the item afterwards, if you want the item bound to him, so to speak, then you need some way to mark ownership. Now, I'm open to suggestions, but I don't see any way to use 319 to mark wearer A to be able to wear, say, ring A (this instance of the ring, not the strref), except possibly changing his SPECIFIC value to something utterly custom and then swapping the ring for a B usable only by that custom type. With the news that SPECIFIC gets used much more often than I expected, though, this may not be a good option. Maybe it's worth discussing for a bit, though.

 

It would work like this: we update SPECIFIC with, say, 15 extra values. We create 15 random spells that change the wearer's SPECIFIC to one of those and phase out the ring for one of the 15. This would be relatively reliable as a matchlock, but the problem is that SPECIFIC would be changed forever, or in any case as long as he wore the ring. Now, this may not be so fatal, because becoming ineligible to wear an item through some AI change or such wouldn't unequip the ring. I take it, Ardanis' AI system doesn't change the values permanently, so that's an option.

 

But there may be better ways. The one really unique identifier in these games is a local variable on a creature. So how about this: furnish ring A with a global effect summoning an invisible minion and let the minion run a script with a list of RESPONSE blocks choosing a value from a long random list and setting the variable on the summoner to that value. Set another local variable to the same value. Then put a list of checks in one of the scripts of the engine creature - BCLASS, BDEFAULT and so on, as I named them, to keep BALDUR unclogged. These checks, run in real time, would force the creature to take off the ring if the local variable did not match the global. Example.

 

In the script of the invisible minion:

 

IF

 

TriggerOverride(LastSummonerOf,Global("RING_DEFINED","LOCALS",0))

 

THEN

 

RESPONSE #1

 

SG("RING_4798",1)

ActionOverride(LastSummonerOf,SetGlobal("RING_WEARER","LOCALS",4798))

ActionOverride(LastSummonerOf,SetGlobal("RING_DEFINED","LOCALS",1))

 

END

 

And in the script of the engine creature:

 

IF

 

HasItemEquipped("ring",Player1) /// By the way, missing from my standard list of triggers for BG:EE, had to be added

Global("RING_4798","GLOBAL",1)

!TriggerOverride(Player1,Global("RING_WEARER","LOCALS",4798))

 

THEN

 

RESPONSE #1

XEquipItem("ring",Player1,SLOT_RING_RIGHT,UNEQUIP)

XEquipItem("ring",Player1,SLOT_RING_LEFT,UNEQUIP) /// Since we don't know on which hand he's wearing it

 

END

 

That's all it takes. Populate the engine script and the script of the original minion with enough random numbers for the matchlock combination, and no one but this character will be able to keep the ring on his finger for longer than a second. If you are wondering why not simply set the local to 1 instead of a random value - after all, we just need a marker for the engine to pull off the ring when it's 0 - then the answer is that random choices will let others use other instances of the same strref. The characters will be able to find or make more of these rings, identical before the setting of the local, and each will be bound to the first wearer.