[Feature]: Elevation Support

[ColdAnkles]

Describe the Problem

Token elevation is a core part of many tabletop systems, and as the improvement in VBL features has improved the trickiness of dealing with maps of multiple elevations has become exacerbated over time. Related to #3638, and #2004

The Solution you'd like

1. Add Elevation and Height variables to Token, so Token properties no longer needed for these. Additionally, add a Head/Feet vision toggle.
2. Add functions for getElevation(tokenID), setElevation(tokenID, z), getZ(tokenID), setZ(tokenID, z), getHeight(tokenID), and setHeight(tokenID, h) to MTScript and JS API. Additionally, anything that accepts or returns an (x,y) pair should also accept/return an (x,y,z) tuple instead. And also viewFromHead(tokenID), viewFromFeet(tokenID), getVisionSource(tokenID).
3. Separate Maps into "levels" - the default being "Ground" at elevation "0". Each level within a Map has it's own independant VBL and MBL. When determining what VBL to use when performing vision tests and rendering the map, the selected level is used, or the level immediately below the selected token. Should no level exist below them (token is below the lowest level), treat them as having no vision, but still visible to their owner. Token Height and the Head/Feet toggle is used to determine what elevation is immediately below them. (See Illustration 1)
4. Add functions for addLevel(name, elevation, copyVBLFrom), removeLevel(levelNameOrID), changeToLevel(levelNameOrID), setLevelElevation(levelNameOrID, z), and getLevelElevation(levelNameOrID) to MTScript and JS API.
5. Create widget for displaying relative token elevations to selected level, or selected token (if any) - Options of symbols (^: Above, - : On Level, V: Below), or numerical ( +O: O units above, -B: B units below).
6. All the rendering has to be client side, to avoid the biggest problem with the otherwise amazing Lib:Elevation by Melek - the fact that the current VBL is global, so switching elevations can cause players to lose all vision.
7. New VBL Option: Floor VBL - implementing 1-6 leaves something of an issue with having vision on a room - and that counting as vision to lower/higher elevations when by rights those tokens should be invisible. Floor VBL can be used to prevent lower floors seeing into this floor, and this floor seeing into lower floors. (See Illustration 2)

Things unsaid:

• UI For adding/removing levels?
• Loading campaigns saved before this change? Since there's only one level, default to "Ground" at "0".
• Performance. Is this even feasible?

Alternatives that you've considered.

Melek's Elevation support is exceptional, and many of my ideas are borne out of using it - however I found I had severe performance issues with it, such that I had to go back to pretending elevation didn't exist.

Additional Context

Illustration 1

Illustration 2

This is a large and complicated proposition that I'm sure I can't bash out myself, even if it's a flawless idea and not rife with deficiencies as most of my ideas are.

[bubblobill]

You've been channeling my thoughts, you evil psychic; I was just thinking we should be introducing tuples as a step toward this. Melek's solution is a hack I've never been real happy with. Layering is probably the best we can do within a 2D paradigm. Done right we should model things in 3D and let the 3D engine handle everything, we have a 3D engine in JavaFX. Many systems allow for multiple postures which change the point of view; standing, prone, crouched, etc. Not sure I see the value in viewFromHead/Feet() as it oversimplifies sensory perceptors. I would rather be able to define a footprint as a volume with points for receptors. A snake has tremor-sense for its full length but only one end gets vision and heat sensors. Step 1 should probably be VB volumes with VB objects just being an extruded shape having a start and end height, followed by a head height for to allow calculating vision. Whatever path we go down, I would like to see any steps taken be moves toward ultimately implementing proper 3D concepts.

[ColdAnkles]

You could go full 3D behind the scenes - Tokens have x/y defined by footprint and z based on height to give you a simple volume. VBL is much the same, since we have the x/y already, and the z is just the difference between the level of the VBL and the next level up.

I take your point on viewFromHead/Feet() - perhaps better to have a distinct visionHeight alongside height? or always have visionHeight==height? I'm unsure how this would dovetail with things like having multiple vision types applied given tokens are already abstracted as a single flat entity.

[adventuremagic123]

D20Pro appears to be the only VTT that supports elevation natively. Foundry VTT does, but it requires add-ons. Fantasy Grounds when I checked some time ago doesn't appear to have any support. Lib:Elevation by Melek on MapTool is better, easier to use than the feature available anywhere else.

It would be a good investment to add native support to MapTool. This request seems carefully thought out. I'd support taking a careful look at it.

Consider find team members who have the skills if missing from the current team. Maybe, advertise skills you're looking for on the RPTools website?

[cwisniew]

I have started already on implementing elevation loosely following what Melek has, but have paused it to wait for the current refactor of rendering to complete (or get to a point where it pauses) due to the number of merge conflicts.

[bubblobill]

I'm wondering if we would benefit from having a plan to prevent us from working at cross-purposes. A picture of the desired end result and intermediate steps for partial functionality. (My inner bureaucrat is screaming right now)

[cwisniew]

I'm wondering if we would benefit from having a plan to prevent us from working at cross-purposes. A picture of the desired end result and intermediate steps for partial functionality. (My inner bureaucrat is screaming right now)

Short overview

• The ability to create layer groups, each group would have token,vbl,hidden,etc.
• Layer groups could be visible or non visible
• Layer groups can have -- but don't require -- an elevation.
• Action pad like functionality that can switch layers on and off, move tokens to other layers etc (plus other things not related to this)
• Visible layers would be determined client side (although GM/actions would have ultimate control of what is visible.
• Initiative actions that can hide/show labels (think tunnel cave in after 5 rounds type thing)

Initially it would all be done via UI not macros for a couple of reasons, 1 if it's only doable my macros and users can't do it without writing macros that defeats the point of replacing lib: Elevation, 2, UI is easy to fix without breaking people's campings based on feedback after it's been used, macros are not they are set in stone unless your want to break things.

This necessitated rewriting parts of the UI, I had redone the whole layer selection bit to be more like what Melek has, plus it can be minimized so that it is just a small semi transparent box when not in use. I had also added the bit to create new lawyer groups but that's where I paused so I only have to resolve conflicts once rather than every time I made a change.

[bubblobill]

Bwahaha, your autocorrect is evil. It wants to create lawyer groups. Layers will now be known as "work experience", "admin staff", "contract", "criminal", "family", "estate", "company", "partner" and "senior partner".

[ColdAnkles]

Personally I think "levels" vs "layers" should be separate.

The "layers", such as "Token", "Hidden", "Object", and "Background" should be more like coincident spacetimes - to use a common TTRPG Trope: The Material World and the Ethereal plane exist with the same X.Y,Z spacetime - but anything in the Ethereal plane is invisible to things in the material plane (though exceptions exist).

"Levels" would be distinct elevations with only VBL.

But now that I've written that - I've convinced myself out of that view, since why should the Ethereal plane have to have the same VBL as the material plane..., so now I'm unsure - though I definitely don't want to have to create the three elevations and related VBL for a mansion, and then have to do it again for other token layers.

Maybe layers can have "inherited" or "shared" VBL

Starting to move into a super-feature combining some of #4555 as well?

[Pmofmalasia]

If it's not already part of what you've been working on, I'd definitely push for adding in floor VBL in some capacity as a part of the elevation update. I remember having to worry about accidentally exposing areas of the map that the players shouldn't have been able to see yet because there wasn't really a true floor in Melek's implementation.

[FullBleed]

It might be nice to get @melek in here to provide his two-cents. I know he's not actively developing for MT anymore, but he has clearly spent a lot of time wrestling with how to get a functional illusion of elevation in MT's 2d environment.

[melek]

Thanks for the ping @FullBleed! I've been out of gaming for a stretch; I have a lot of faith in @cwisniew's implementation ideas since from what I can tell it is taking full advantage of the flexible nature of my original concept and leaning on some of the UI iteration I managed to do.

Melek's Elevation support is exceptional, and many of my ideas are borne out of using it - however I found I had severe performance issues with it, such that I had to go back to pretending elevation didn't exist.

Shucks! Yes, the elevation library is essentially an elaborate proof of concept (a monstrous hack, indeed ;) ) to pilot how handling elevations might feel from a UI perspective if it were a first-class feature. I'm excited about @cwisniew's work on the feature, and am confident that the UI I arrived at is a solid start for a fairly user-friendly system.

"Levels" would be distinct elevations with only VBL. [...] I've convinced myself out of that view, since why should the Ethereal plane have to have the same VBL as the material plane ...

I like the term 'levels' for elevations, but I prefer 'layer groups' as it is more technically accurate. The feature is useful for handling different cases such as time of day or map states, not only elevations, so whatever nomenclature gets adopted I'd hope it does a better job than my library of including these opportunities for the feature.

In other words, you could have a 'night/day' version of all three elevation layers of vertical map, and then further you could have 'pre-war' / 'post-war' versions of both; this could let a GM efficiently define and express 12 different map states on a single map. The UI I provided is focused on elevation, but the possibilities are pretty grand once you are storing map states and have a good UI for flipping switches between them. Your ethereal plane example is really excellent for a creative dimension of a map beyond time and space.

Action pad like functionality that can switch layers on and off, move tokens to other layers etc (plus other things not related to this)

I absolutely love this direction. So many things are essentially action pads; this kind of structure greatly assists low- and no-code GMs add dynamic functionality to maps. RPG maker really showcases this kind of map building, and I'm sure that a gridless version could be made to work well to make sure @bubblobill gets to use it. ;)

New VBL Option: Floor VBL

This is critical for properly supporting vertical encounter maps. I faked it by totally resetting fog of war when switching elevations.

If points of egress between layers were also definable like ramps & ladders, pathfinding could conceivably cross elevations as well - It would be neat to have the map fade to show the known / seen portion of the target elevation as you drag a token to a contact point between layers, for instance.

[ColdAnkles]

This is a good opportunity to use Github's project to track the "rendering rewrite" and then this elevation and related features. Both are sufficiently complicated that it's probably worth breaking them all out into separate issues and setting it up as a project.