[Script Idea] GM Door Management.

Hello! I was checking for Door scripts and found  Matt's script and  Aaron's modification of said script. It looks pretty neat, but not exactly what I was looking for (if I understand correctly how it works), so I was wondering if something like this could be done: Make a script to send the selected images to the GM Layer (or the back of the map layer), and a command to send it back to the DL Layer. Like so: Switch the player to Dynamic Lighting. Wait for a 'target' (Select a line). Send the target to a different layer. Switch the player back to the Token Layer (or where he was). This would simply make the doors disappear, instead of moving the lines, which could be troublesome if "Restrict Movement" is selected (or just because of the extra 'wall' that would appear in the room). Also it would require no token to be present in the token layer to make the switch. To send them back, the command could do the same but starting with the GM layer (or wherever the lines are being sent to) and send them to the DL layer. Additionally, if it's possible to select all drawings or lines from any given layer, it would be possible to add a command to restore all doors to their original positions (Which is fantastic if you run many one-shots with the same maps). I hope the idea is not too messy, is it possible to do such a thing? Are there any limitations from the API side, or improvements to the idea? Cheers, Nick

If I understand what you're saying, I think Matt's Door script already does that.

Assuming I understand Matt's script, which I've never used and only read his post about it, you need an image to display as a door closed and open, and also a token in the token layer a player perform rolls against (or you can just open). It needs time to setup and link each door to each token. What I want is for the script to, in essence, simply move the line from the dynamic lighting to a different layer, and then move it back when done, automating most of the process. No need for actual tokens for doors, or for tokens for 'handles' that need to be linked to work. I seem to be quite terrible at explaining it, so my apologies for that!

Matt's (Aaron's modification) door script (and again, TY Aaron, as I was going insane) does use tokens in a rollable table - little bit of time to set up - but totally worth it and does what you want. 1. It provides a handle for players to access and 'open a door'. Alternately, you CAN move the handle to 'GM Layer' and only have the GM be able to open the door.  !OpenDoor and !CloseDoor.  I have actually added those two token actions so when a player clicks on a door handle, they see what they can do. (of course, traps and locks and hidden doors are available too). 2. It requires to you create a line/path which is to represent the door in the Dynamic Lighting Layer, and *links* this path to the handle, and the door token. 3. It uses a door token graphic from a rollable table - so you can provide graphic images for open and closed doors, and use the bar 3 value and max numbers to specify which images are 'open' and 'closed'. You can have 20 different doors in the table for images - 0 and 1 would be the first door. or use 18/19 for the last one. 4. It move the Dynamic Lighting line you specified from the dynamic lighting layer (where it can restrict movement - as a closed door should) to the GM Layer when a door is opened. Light flows now as if the door wasn't there (assuming there is light) .. but - even if its dark, the door no longer restricts movement - and from a GM perspective, you can see the yellow line where the door belongs - and the token graphic changes to show the door is open. I've seen a variant of the script where someone added squeaking and slamming noises to their doors, but cut/paste didn't help me and I don't understand the language well enough to do it myself - but take a walk through the instructions on Matt's original post - and use the modification that Aaron cleaned up for me - its pretty awesome.  (also, if Aaron offers to join a game for you, and you are at work, remember to stop broadcasting/receiving. unless your boss is super cool like mine).

Yeah, I get what you are asking - You want to strip out the rollable token part. You could just use blank tokens in the rollable table , or just use the same token number , or no number at all, for bar 3 values for the token.  I'm not sure how you're going to represent the whole thing without a token to provide a handle for control

The idea is that without using a token you can drag and drop the script on any campaign and use it without any prior work. In order for it to work, what it does is basically automate what you would normally do manually. Keep in mind I have no idea how to do it, or if it's even possible at all, but in broad strokes it should be doing this or something similar: Click the Macro or type !doorgm (for example) Automatically move the GM to the Dynamic Lighting layer Listen/wait on the GM to select an image (or many in one go if needed, holding click and dragging) After an image is selected, automatically move that image to the GM layer After the image has been moved, automatically move the GM back to the token layer (or wherever he was). So basically you only need to perform 2 very quick actions: Click macro Click the line that represents the door.  Done. That would move the door to the GM layer and you'll keep going through with your campaign in 2 seconds. To put the doors back you can do the same in reverse (Click a second macro or type !doordl, select the door, puts it back in DL layer), or if you want to put everything back the way it was, click a third macro that selects ALL lines/drawings in GM layer and puts them in DL layer. An alternative would be to send the lines to the BACK of the map layer, and then to put them back select all but the topmost image in the map layer (or all drawings) and send all that to the DL layer. Different options, same effect. I hope that makes it even a bit clearer, I realize I may not be the best at explaining the way it should work, but I think like this you can add the script to any campaign, and without preparation you can quickly move doors around. From what you tell me it seems Matt's script would be a good alternative, but if what I explain here is possible, I think it might be better (at least in my case) to use something much simpler like this. Cheers!

Might be easier if you use a transparent "door" token to put on the Tokens & Objects layer and then use an aura to show where the virtual door token is and whether it is open (green) or closed (closed). Then the script would be triggered with something like !toggle-door @{target|token_id} to toggle the DL in that square using the token's location info.

A few notes: • The API can't change the layer that the GM is on.  That's a Client Side UI thing, and the API can only modify the state of the Game by manipulating Game objects. • Dynamic Lighting is only blocked by Lines on the Dynamic Lighting Layer, not images.  I'm pretty sure you know that and are using image in a generic sense, but wanted to clarify to be sure. • Selection is also a part of the Client UI, see the first point above. So, given the above, the biggest issues are 2 things: • Interface: How will the script know what door the GM want's to manipulate? • Automatic Setup: How will the script know which Dynamic Lighting lines are doors and which are not? If we can answer those, then a script can be written. Some possible answers to the automatic setup would be: • Consider only rectangles are doors -- I usually make my doors on the DL a small rectangle with dark brown lines and light brown fill. • Consider everything to be a "door" and push the decision off to the interface... • Consider lines of a given color to be doors -- all the red lines, for example. Some possible answers to the interface. • The script could add a clear token with a colored aura only the GM can see (Ala Bump and Sky HB's suggestion) in the center of each line it determines is a door and provide a manipulation interface on that token. (since there are only 2 possible states, it could just trigger on the delete of that token, regenerating it after). • A script command could create a token that the GM can move about to manipulate the DL line that is under it.. Thoughts?

I personally like the idea of having a line of a specific color represent a door.  I also like the idea of creating a clear token automatically when a line of the specified color is created that allows you to "toggle" the line (maybe instead of deleting it and creating it, shifting it from DL to GM and vice versa). I think the issue with a command that creates a token that allows you to move it is that all doors are not of an equivalent size, so it seems like it would be a harder solution to properly customize to a users needs.  

The Aaron said: • The script could add a clear token with a colored aura only the GM can see (Ala Bump and Sky HB's suggestion) in the center of each line it determines is a door and provide a manipulation interface on that token. (since there are only 2 possible states, it could just trigger on the delete of that token, regenerating it after). • A script command could create a token that the GM can move about to manipulate the DL line that is under it.. Either one of those sound awesome.

The Aaron said: A few notes: • The API can't change the layer that the GM is on.  That's a Client Side UI thing, and the API can only modify the state of the Game by manipulating Game objects. • Dynamic Lighting is only blocked by Lines on the Dynamic Lighting Layer, not images.  I'm pretty sure you know that and are using image in a generic sense, but wanted to clarify to be sure. • Selection is also a part of the Client UI, see the first point above. So, given the above, the biggest issues are 2 things: • Interface: How will the script know what door the GM want's to manipulate? • Automatic Setup: How will the script know which Dynamic Lighting lines are doors and which are not? If we can answer those, then a script can be written. Some possible answers to the automatic setup would be: • Consider only rectangles are doors -- I usually make my doors on the DL a small rectangle with dark brown lines and light brown fill. • Consider everything to be a "door" and push the decision off to the interface... • Consider lines of a given color to be doors -- all the red lines, for example. Some possible answers to the interface. • The script could add a clear token with a colored aura only the GM can see (Ala Bump and Sky HB's suggestion) in the center of each line it determines is a door and provide a manipulation interface on that token. (since there are only 2 possible states, it could just trigger on the delete of that token, regenerating it after). • A script command could create a token that the GM can move about to manipulate the DL line that is under it.. Thoughts? Thanks for clearing up what can and can't be done Aaron! It's very difficult to think of the possibilities without that knowledge. I agree with Kevin, the color of a line IMO works best to determine whether it is a door or not. Just like in your example, I tend to use red poly/lines for doors (and bright green for walls, so I can easily see if I'm missing anything). As for the possible answer to the interface, both sound great. In the first example, would it be possible to "lock" the token in place in the token layer so that the GM can't accidentally move it? I don't know if it's possible, and it's simply another suggestion, but maybe if using something like @target where you have to click a token could target the ground instead and select the nearest red line could pass as a token-less approach to it. Basically target the ground near a door would erase the one that's closest, and since it wouldn't have a way to put it back that I can think of, then it can create a clear token where the door was that would recreate the door with a different command, and erase that token once that's done. (Might be complicated to do or impossible with the way it would target doors?) Cheers

The API doesn't really have a way to target a location, just tokens. There was a thread earlier this week or last week talking about that.  I wouldn't delete the lines, I'd either move them to the GM layer or off the map while they're open. 

In that case, both options you gave still sound great. I'd personally opt for the first one when setting up a new game probably.