[Script] Door Control for Players, includes Locks and Traps

Ok, think i have it. Take a look at the chat log and tell me if this looks valid for the DC system. There is a variable that is set at the top of the script to determine checks are made by percentage. When set to true, the script works as it has been. Character attributes are the baseline for success, modified by the values in the door control, and compared to a d100 roll. A roll of or under the modified attribute score is considered a success. attribute + modifier >= d100 equals success When the variable is set to false, it uses a DC type approach. bar1_max becomes the DC rating for the lock, and bar2_max become the DC rating for the trap (both detection and removal). A d20 is rolled, modified by the attribute. A modified result that is greater than the DC rating of the door indicates success. d20 + attribute >= DC rating equals success The only check that is tricky would be hidden doors. Since there isn't a field used for a modifier against 'casual detection' (this isn't an active check roll), I had to add an additional variable to use as a DC check. This means that every hidden door is rolled against the same DC rating for detection. d20 + attribute >= global variable DC rating equals success Is this the implementation you were looking for? (I've not updated the OP with these code changes yet). Something else to consider as a whole... Do you think it would be better to save the values that are currently entered into the switch control as part of the state data? This would allow for more flexibility in choice of settings (for example, each door having a unique DC rating for detection), but the trade-off would be the ease of reviewing/changing the data. It's currently very easy to go in and change a door from locked to unlocked, or hidden, or see what the trap will display, etc... Moving this to state data means having to use api commands to see or change how a door is configured. I'm debating, but would be curious as to your opinions...

I really like how you added a toggle that decides how the script operates. That's really smart actually. It makes it more versatile for people using other rule systems. That being said, the DC system you have in place is exactly what I currently use. I'm not sure about other DMs, but it would work perfectly for me. In terms of switch control values being saved.. I think the benefits are situational. Both options have their benefits in different circumstances.. You'd probably want to simplify things with universal settings on a large map with many doors as it would be time consuming for you to go and change each individually. Having unique numbers, however , may be good for a smaller map representing something like a house of a politician where the doors may be simple to unlock, and untrapped, but a safe or vault may be more difficult to unlock.. And may be trapped. I'm wondering if it's possible to toggle the saving of settings like you did with the check system. That may give you both options. If it's possible that is.

Glad the DC option works. Was a little concerned about the detection being the same DC, not having used the DC approach myself. The idea of using state data wouldn't take away the unique settings for each door. I want to keep the doors unique regardless the approach, although I do like the idea of having some commands to set several doors' options at once. Once I make a decision on this, I'm going to look into some of those. Right now, each door's settings can be quickly viewed or changed by viewing the switch token's properties. To me, this is very convenient as all I need do is dbl-click the switch. All the options are there for me to see. The drawback to this is that I am limited on the number of fields I have. The DC value for detection is a good example. All of the fields on the token are being used for some function of the door: is it locked, is it trapped, is it directional or trapped... Now that I've added a DC system, I don't have a field to determine the DC detection rating of the door. If some doors are harder to detect than others, I have no way to distinguish them. This would be the same for any 'new' feature that I may add in the future. If I move the door information to state data, I wouldn't loose any of the current functionality. But instead of having a visual way to set the doors (ie with the switch token), I would have to rely on enterting !api commands, and displaying information in the chat windows. Should I choose to change if a door was locked, or the difficulty of a trap, I'd have to enter the appropriate !api command. Using this approach, it would be easy to add new features that were unique to each door, such as the new DC detection rating. Also, right now, the idea of flipping a switch token vertically or horizontally is a global setting. If I moved to state data, I would have the option of specifying which doors were to be flipped in which direction. I think I'm leaning to state data, but want to make sure I don't loose any of my current config. I don't want to have to re-setup 400 doors if I can avoid it. :) I have updated the code with the changes I've made this far. The text description in the OP hasn't been updated yet, thinking on a cleaner approach to the explanation. But for these recent changes, here's the info you need to know. There are four new variables near the top of the script. Two of them control if a switch is to be flipped vertically or horizontally when a door is opened. The last two control if the system should use percentage based checked, and what the DC rating of door detection would be if percentage checks are not used. statusDoors.hFlipOnOpen = true; // flip switch control horizontally when opened statusDoors.vFlipOnOpen = true; // flip switch control vetically when opened // usePercentageChecks determines how checks against skills are rolled // when true: attribute score + door modifier >= d100 equals success // when false: d20 + attribute score >= door modifier equals success statusDoors.usePercentageChecks = true; statusDoors.detectHiddenDC = 10; If usePercentageChecks is true, then the value of detectHiddenDC doesn't matter as it never gets used. The changes made in this update should have no impact on any current door configuration you may have. However, should you choose to use the DC system (set the usePercentageChecks to false), you will need to update all of your door controls to match the new system. I do not know of a way to convert doors from one type to another consistently between these two systems.

Well, the way I see it is like this: Currently you have it set up for simplicity and visual streamlining. You see the information in front of you, and can change it like that. If you want to switch to state data, which will give you more overall options for fields, you can also streamline it as well. One way you could do this is to have a section of code that creates macros with the proper api command for each of the thing you need to do (Such as Stephen did with his Geomorph script). That may simplify things quite a bit. I'm wondering if you could set a few different character sheets for switches to represent different types of doors or different properties. I know this approach would start to get kind of clutter-ific, but using tags It should make it easier to sort. That way you can have ease of access to just change something in a drop-down box rather than to have to go in and change multiple values. Also, I really can't blame you for not wanting to re-setup 400 doors.. I was starting to feel that 20 was tedious. I can't imagine having to go reset 400.. I think I'd just say "forget it, no doors!" lol. That actually brings up another point I was wondering about.. to make initial setup easier.. would it be possible to enter a url for an image (the switch) to create a switch, a path, and a token from the doors table on the token layer pretty much right on top of each other so that they can be mass produced and dragged where they need to go? I know that would probably mean a lot more lines in the code (and more of a headache for you).. but I'm wondering if that would make large dungeons a bit easier to build. I will say that I'm really happy with how this script is working, and how far it's come since I started using it.. there are a lot of little tweaks that end up improving performance and streamlining things so many times over. This is the type of community experience I love (mainly the "I don't know how this thing works, but here are some ideas" and the "oh, hey, that's an idea, could that work? Maybe.. let's see" part haha).

I've not found a way to quickly reproduce these with any more accuracy than I can do manually, I think mainly because not every door is aligned the same nor sized the same. However, it's still not too bad for me to add several doors at a time. Treat it like an assembly line, making use of copy/paste. (this may be obvious, apologies) 1. Place a door, name it 'Door. Copy/Paste this for each of your doors you want to add. 2. Position each door for orientation and size. 3. Add a wall to use for each door. 4. Add a switch. Name it 'Switch'. Copy/Paste for each of the doors. 5. Run !DoorsLink for each door grouping. 6. Run !DoorsAlign once to position the switches. 7. Optional. Go back and add locks, traps, direction, and hidden status unique to each door. It is time consuming to try and add a single door, then a single wall, then a single switch, the link them, then repeat. It is considerably faster to copy/paste, and do each type of object all at once.