Crossing passages with dynamic lighting

I'm trying to make a kobold warren map. Ideally, I want to make it a confusing labyrinth of passages that cross over and under each other, but I have no idea how to make this work with dynamic lighting. Multiple pages isn't going to cut it because it's not distinct "levels" and I'd end up switching pages constantly which would be a nightmare.

At the moment the only thing I can think of is some sort of fiendish script that stuffs an elevation value into the controlledby field of the DL paths. You could then have a command to set the current elevation. It would look for paths that had an elevation value (ones without would be assumed to valid for all levels) and only show those which matched the desired elevation. I guess you could bump them to the GM layer when they weren't wanted, or just delete and redraw later.

It all sounds like more work than I have time or motivation to deal with right now. Anyone have a simpler solution (or a script that already works!)?

Fun idea. It's not just an issue of DL, it's an obstacle of 2D top-down mapping in general. Even pencil-and-graph-paper mapping struggles with how to represent an underpass / overpass situation (it's usually a dashed-line - - - - - representing the underpass). The problem being similar in paper or digital mapping, same with DL, when PC's pass over the underpass they are going to see it exists (even when it might actually be a totally disconnected subway tunnel). And then there's the corollary problem when the PC's travel the underpass road, they run into the appearance of walking over the walls of the overpass.  The whole problem is even worse if they have an encounter (monsters) in the criss-cross area.

API script to handle this: Don't know of one, what's the vision for how that would work anyway? I guess it would flip-flop the Z-order of the floor/wall-tile and toggle block/unblock of the corridors of overpass/underpass alternately.

Manual ways of handling it by-hand during-gameplay (Granted this slows down gameplay) --- 2 things normally have to change, the Dynamic Light blockades and the underlying floor-tunnel-hallway graphic that has walls.  SPECIAL NOTE: If you construct your dungeon entirely out of DL walls with background-page-color, no battlemap or wall tile set, then this whole process would be easier, you would only need to contend with switching the DL. But yeah, assuming you need to switch the "z-order" of the floor-wall-tiles (Bring To Front --- while this will wrongfully appear to the GM as creating an overpass, it is effectively revealing the underpass for purposes and perspective of the players/PC's), and then switch the DL walls (unblock the east-west underpass, block off the north-south overpass).

Workaround method that I personally use --- maybe unconventional but I sometimes do Sub-Levels "off to the side" in my Map Page of Roll20. Sometimes I even construct a "chutes-and-ladders style" DL pathway that leads (long walk distance) to another wing of the map where the sub-level is represented. I just tell the players "Walk your token waaaay down that tunnel to the left, it's not really that far, it just represents the ladder/stairs you climbed to get into the sub-level / underpass area." This works more for side-rooms / basements / cellar / attic, doesn't work so great for warrens with dozens of underpasses or even triple-quadruple subway layers.

Side-view map is another alternative to consider. Like a cutaway-map. Unfortunately we sacrifice seeing your PC's side-by-side in depth (Y-axis) in the rooms, but it's great for mapping elevation changes (z-axis).

Looking forward to see what you come up with.

Yeah, I do want something pretty so your bare-bones solution isn't going to work for me. I'm moving away from using tiles for a lot of my maps now because it ends up being too restrictive and it's hard on players' computers/connections if you really go to town with it. So I think I'd probably have a flat battlemap with dynamic lighting done  for everywhere that isn't a "crossing"; and then little tiles that can be bumped in for the alternate views of the crossings. I guess it would something like this:

• Drop in main battlemap
• Draw/import dynamic lighting paths for everywhere that isn't a crossing
• !define-elevation 1
• Draw dynamic light paths for the 'default view' (i.e. the passages shown on top by the battlemap) Script would save these as dynamic light for elevation "1"
• !define-elevation 2
• Drop tiles over the crossings to show the underneath paths. Draw dynamic lighting paths for these. Script would save both the tiles and the dynamic light paths
• !set-elevation 1 - script bumps all DL and tiles for elevation 2 to the GM layer
• !set-elevation 2 - script bumps all DL for elevation 1 to GM layer, bumps tiles and DL from GM layer to relevant layers for elevation 2

It's not actually a particularly complex script to write, I'm just not sure I have time right now. Maybe if it pours with rain for the next 3 days and I can't get outside I'll have a stab.

Nice, I like the idea/method of the Fix-It tiles coming in, for intersections only, on an otherwise flat-map.

Here's to a good early spring rainfall! Happy coding, if you undertake it.

I know a lot of people are interested in "one way dynamic lighting walls" for purposes of elevations -- but they usually mean for Cliffs, staircases, overlooks, rather than tunnels/underpass. There are Suggestions requesting that feature; and workaround ideas for accomplishing that (on the forum), letting players see "the other side" with a Torch token for example. That just does not apply neatly to underpass tunnel situations where you want them to see what they're moving through and not see the overlapping area.

So as far as I know it would probably be a novel new script idea. I'm sure others from the community will be joining in with more feedback here soon.

For this sort of thing, I've used many teleport pads to shift players about on the page.  I have an updated version of the old Teleport Script that will do this without players seeing all the intervening places. (also has some other enhancements... =D )

• One benefit of doing it that way is it does give a sense of confusion that would otherwise be missing. 
• One downside of doing it that way is it does give a sense of confusion that would otherwise be missing.

=D

I recently had a similar situation with a passage leading above a second passage where the party was walking.
So I made two versions of the map. One version without the top passage, where the party was walking, and a cut-out of that area, including the top passage, with the goblins ambushing the party. That cut-out was hidden from view with FoW until the encounter started. Then I switched between the two views back and forth.

The disadvantage was that I had to use copies of the party's tokens and needed to move the "clones" to the exact same position as the original tokens on the main view.

(I have a Twins script for things like that...)

The Aaron said:

(I have a Twins script for things like that...)

I was just about to edit my posting to add "I believe The Aaron has a script that could handle that, but I didn't ask him for it".

Ever thought about having a self-updating overview for all your scripts with a short description etc? 

I have, actually.  I've got a script for that... but it's not done yet. =D

I'm not surprised that you have a script for that as well... ;)

Ok, I assume it is this one? I'll check it out.

Yup.  It's written to twin across pages, but people have modified it to twin in all sorts of interesting ways (mirroring, offsetting, etc).  PM me or Post a new thread if you run into issues. =D

Will do. Thanks!

Yeah, for this map there are going to be so many crossing passages that the idea of flipping between maps is just not going to work - going to be way too slow and clunky. So I just went ahead and wrote the script. You can pick it up here: https://raw.githubusercontent.com/symposion/roll20-api-scripts/master/Elevation/Elevation.js

You do !elevation-define <level> and then start drawing stuff that should go on a custom elevation level. It will record graphics you put on the map layer and paths you draw on the dynamic light layer. When you're done, send !elevation-set <level> to show a particular elevation level. Level should be a number, by the way. Currently it just bumps everything that shouldn't be shown to the GM layer because that's easy; it makes the gm layer a bit of a mess, buy hey.

It has no help, no error handling, no feedback, nadda. It's barer bones than a skeleton in an acid bath. Use at your own risk. Maybe at some point when it annoys me enough I'll get round to polishing it up... but I wouldn't hold your breath!