temnix Posted September 19, 2019 Share Posted September 19, 2019 Chests have this field. Quote Link to comment
Endurium Posted September 19, 2019 Share Posted September 19, 2019 If you check the IESDP this flag is colored as an "unknown, but maybe it does this?" value. Looks like the devs were playing with it in IWD classic and it was ported into IWDEE; AR1008 has a container with Erevain's name on it but no flag. Another container there has an unused dwarf's name and a script to hide him if a lockpick attempt failed on the container. I've gone through looting containers and nobody reacted, and the containers didn't do anything special. *shrug* Quote Link to comment
temnix Posted September 20, 2019 Author Share Posted September 20, 2019 I've gone through looting containers too, haven't we all, but has anyone tried to make that function work? Quote Link to comment
Endurium Posted September 20, 2019 Share Posted September 20, 2019 I have, by ensuring I had valid owner names, having said owner standing nearby, using flags. Otherwise I wouldn't have posted on the subject. Feel free to test it yourself. Quote Link to comment
temnix Posted September 21, 2019 Author Share Posted September 21, 2019 (edited) On 9/20/2019 at 12:27 PM, Endurium said: I have, by ensuring I had valid owner names, having said owner standing nearby, using flags. Otherwise I wouldn't have posted on the subject. Feel free to test it yourself. What flags? Anyway, what I'm interested in is whether that field can take a token. And work. Do you want to try it? Put there one of the existing ones, like <GABBER>, then have someone run a script that does SetGabber(Player1) and have Player1 open the container. I could try it myself, but you seem already set up. Edited September 21, 2019 by temnix Quote Link to comment
Endurium Posted September 21, 2019 Share Posted September 21, 2019 (edited) Container flags, according to IESDP and NI anyway " bit 1: Disable if no owner " for EE. The name field is 32 bytes, same as scriptnames in other structures, so I doubt it will take dialog tokens like <GABBER> which are reserved for strings in the TLK file. I suppose I could fiddle with it again this weekend since my IWDEE game is set up for playing and I have a new character standing in the tavern. ... I did some additional testing in both IWD Complete (GoG) and IWDEE (GoG) with no discernible results. Owner name doesn't matter, owner's scriptname doesn't matter; container flags pertaining to owner have no effect. The "owner" who was standing nearby didn't react either. Sure, I could have used a script to cause him to do something after I took the gem from the container, but that's what all the other games do too; no owner name necessary. Even the other container in the inn with a name (for the dwarf who isn't in the Inn) uses a script to cause the dwarf to take action if a lockpick attempt failed. Again, the owner name is irrelevant. On the other hand, the owner name could have merely been a clue to the developer's world builders that the container belonged to someone, so add a script or something if action was deemed necessary.. Edited September 21, 2019 by Endurium Update after further testing Quote Link to comment
Endurium Posted September 21, 2019 Share Posted September 21, 2019 (edited) Amended my post with an update, and posting this because edits don't update the forum's activity list. Edited September 21, 2019 by Endurium Quote Link to comment
temnix Posted September 21, 2019 Author Share Posted September 21, 2019 (edited) 5 hours ago, Endurium said: Amended my post with an update, and posting this because edits don't update the forum's activity list. So the owner name does nothing at all. All right, thank you for clearing that up. The chest I tested with let me type in the token, but I'm sure it wouldn't do anything. Now what someone ought to do is fashion a skeleton key that will suit all chests' Lock field, if it's empty. Or possibly randomize that field for chests to accept one of several keys and then put them up for sale in stores. This is an idea I got from playing Faery Tale Adventure 2 recently, where there are about 8 different keys (Bronze key, Brass key, Obsidian key, Gold key, Rusty Iron Key and so on) that open different doors in dungeons around the world, not to mention special keys for plot doors, but only one store sells them. And you don't know which will match which door, if any. But how to use Weidu to give only some of the containers particular keys? Does anybody want to come up with code for this? Like this: if area has container 1, if it is enabled, if it is locked, if the Key field is empty, enter SMAKEY and a message in the Lockpick string field (displayed on failure) with a hint "This lock has a very small keyhole"; move to container 2, enter ELAKEY, hint "This is an elaborate lock" and so on for the rest of them in the area. Since nobody knows which container numbers refer to what in an area, this would be a pretty random distribution. Then we could hide those keys in treasure in remote dungeons or just put them up for sale here and there. Unfortunately, it only takes anyone in the party to have the keys in the inventory to open all of the locks, but hunting for keys could be fun by itself. And using a key bypasses traps. Ditto for doors, in principle, but doors are too easy to bash. By the way, can doors have traps? I mean, working traps? The flags can be said and the difficulty, but there doesn't seem to be a place for a trap script. Like an alarm script calling in the Flaming Fist. Edited September 22, 2019 by temnix Quote Link to comment
Gwendolyne Posted September 22, 2019 Share Posted September 22, 2019 15 hours ago, temnix said: By the way, can doors have traps? There is indeed a door script field : 0x0080 Quote Link to comment
temnix Posted September 23, 2019 Author Share Posted September 23, 2019 (edited) 9 hours ago, Gwendolyne said: There is indeed a door script field : 0x0080 I know, but I thought it had to react to the TrapTriggered() field. It turns out it reacts to Opened(). I just made the door of the Candlekeep Inn kill Charname when he pulled at the handle without using his thieving first. Well, I still can't do anything with this without partnering with someone who can take on the Weidu code. The mod would look for locked doors in CITY areas and trap them with a script summoning burlies. I can write up the burlies, or maybe the usual alarm patrols would do. The scripts could react to an attempt to unlock if the character is seen by (sees and is not invisible) a neutral. Speaking of crime, is it possible to override pickpocket response? Invoke PickPocketFailed() from outside a creature's script? From BALDUR, maybe? I wonder if it would be possible to go through all trapped containers the same way, fetch their scripts and replace "Opened([ANYONE])" with "OR(2) Opened([ANYONE]) DisarmFailed([ANYONE])" to make it so that failure to disarm a trap sets it off? It would be better to have this as a random chance, but I don't know if that's possible without knowing what the script below says. A RESPONSE with some empty probability could be attached on top to them all by the same patch, but that would make the trap trigger only some of the time, too. Edited September 23, 2019 by temnix Quote Link to comment
Endurium Posted September 23, 2019 Share Posted September 23, 2019 I don't know how you'd override default pickpocket behavior in the older games (been over a decade since I last modded them), but in the EE there is a 2DA file called PPBEHAVE which lets you control the default pick pocket response behavior. Turn Hostile = 1 means they'll turn hostile when you pick their pockets; set to zero to disable that. Same with the Report Failure and Break Invisibility flags. That would allow you to control things more specifically using script. Quote Link to comment
temnix Posted September 23, 2019 Author Share Posted September 23, 2019 13 hours ago, Endurium said: I don't know how you'd override default pickpocket behavior in the older games (been over a decade since I last modded them), but in the EE there is a 2DA file called PPBEHAVE which lets you control the default pick pocket response behavior. Turn Hostile = 1 means they'll turn hostile when you pick their pockets; set to zero to disable that. Same with the Report Failure and Break Invisibility flags. That would allow you to control things more specifically using script. That's good to know, but I would still need a trigger to detect the event of pickpocketing. This 2DA shows that the engine doesn't notice theft as an interaction between objects overhead. Maybe PickPocketFailed() works inside a creature's script, but clearly that's no good for anything. Quote Link to comment
Recommended Posts
Join the conversation
You are posting as a guest. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.