melek / lib_elevation Goto Github PK

Unless I've missed something, while playing I frequently find a need to find out the status of which elevations my tokens are linked to -- and I don't see a way to do that through the overlay (UI).

I would really like to be able to select a token (one at a time, if needed) and find out which elevations it is linked to. Even better would be for me to see that for a group of selected tokens.

I don't want my players to see that information, though. Only GMs. Even better, only myself.

For 1.0a6, "Map Options" view renders so that I can't access its controls.

I have a display on Windows 10 set for Display resolution "3840 x 2160".

"Map Elevation Data" has a libVersion property, but when I look at Lib:Elevation, I can't tell what version it is.

Both using 1.06a and the new 1.0b (haven't tried earlier) I'm finding that clicking on the selection list only grays out the elevation options but doesn't actually switch elevation state. The selection list then gets stuck in that state until I click anywhere on the map with the interaction tool. I can switch elevation via the "Pick Tkn Elevation", or arrow up/down buttons below the list, or via the macro buttons visible upon selection of the library token.

All of this holds true both when putting the library token into a new map and when loading your demo campaign. Everything else seems to be working, at least under cursory testing, so it's not a gamebreaker.

I am running Maptool v1.9.3 on Linux.
Edit: I just tried it on the same computer running Windows and that works fine. Would be interesting if somebody else managed to run it on Linux without this bug.
EditEdit: Aaand, for the sake of completeness I tried it on a different computer (MacBookPro) running Big Sur 11.4 where it does not work - same problem as on Linux!

I'll update the issue if it resolves itself or I find out anything new, of course.

in addElevationDialog, the elevation.clearMapBL UDF is called but it has been removed in favor of the JavaScript version. It should be replaced with js.elevation.clearMapBL on line 50 of the macro to correct the error.

I have a scenario where there is a flying character, a wall, and ground level characters. When the elevation is "ground", even though the ground level characters and flying character can't see each other because of the interposing wall -- I would still like the higher elevation character to retain vision. However, when the elevation is "flying", I want the lower elevation characters to not have any vision.

If at all possible, could you check to see if TheDoors is running and adjust the location of the elevation control panel as to not overlap?

Context - https://discord.com/channels/296230822262865920/884448977976721431/955491122749276230

• When creating a new elevation (say 25), and selecting Link current elevation's tokens at their current positions (current elevation being 20), the new linked tokens on the new elevation don't have the isElevationToken state.
• In my scenario, all the newly linked tokens got the isBelow state because they probably still had the lower default elevation values (my default elevation was 10). Moving them to the current elevation (25) did not remove the isBelow state. This might be an edge case as when testing with unlinked npc tokens, the issue doesn't happen

There is a 'dev frame' that is checked for every UI update, but has been basically unused since the overlay was implemented early in development.

This should probably be removed/cleaned up, as the overlay covers all the features of the dev frame and more.

It would help me a lot to know what the purpose of each lib token is in your releases, whether I need all of them or if some are optional, and upgrade instructions for going from the previous version of your release to the current version. It would be nice to have this information in a README.txt (or whatever other name) file as part of the release.

The getMapDataToken JavaScript implementation doesn't correctly account for single quotes in map names. To maximize compatibility this should be corrected.

If it cannot be fixed without depleting performance, at least maps with a single quote in the name should display a notice instead of issuing an error.

When a new elevation layer is created using the default options, the following happens:

1. The new elevation layer is created.
2. The tokens are opaque. Seems the design is such that they should be semi-transparent.
3. Switch to the previous elevation layer.
4. The tokens are opaque as expected.
5. Switch to the new elevation layer.
6. The tokens are now semi-transparent as expected.

I had just gotten started creating a map and thought I'd clean up "Map Elevation Data". However, because my focus was on that token and it was so extremely far away from my map -- I couldn't find my map anymore. I tried zooming out and moving around. I would like it to be located near my map and let me position it where I would like it to be.

Switching elevations saves the appearance and position of all tokens linked to that elevation.

Currently in 1.0b2, if one of those linked tokens is missing (has been deleted), the switchElevation method completely halts and it is impossible to switch elevations.

To workaround this, the elevation token must be manual removed from the map data by ID, which is difficult and error prone.

Ideally the method should simply discard missing IDs when saving linked tokens.

Right now, there is an error when checking for updates if the client doesn't have External Access set.

Since checking for updates is automatic on campaign load, this can be really annoying.

The isExternalMacroAccessAllowed function should be used to prevent errors and let the user know how to enable update notifications.

I'm not sure if this is actually a bug or if the tool is simply not intended to support negative elevations and I was not aware. I recently tried having multiple levels of elevation with negative values for the first time, and although they did appear below elevation zero the negative elevations themselves were sorted in reverse order, with elevations with greater absolute values being listed as higher.
Stonegauntlet Landfill Site.rpmap.zip
.

When selecting the option "start fresh with no vbl," no new elevation is created. There is no error code or other indication that anything has gone wrong. This glitch cannot be reproduced outside of the campaign file in which it was found
sword coast elevation test copy.cmpgn.zip
.

How do you:

1. Create a PC token at ground level.
2. Have VBL block PC's view of an NPC also at ground level.
3. Create a flying elevation level at 60 feet.
4. Switch to fly elevation level while preventing PC token from being selected and revealing the NPC (because this elevation level doesn't have VBL blocking view of the NPC).

Seems like I want the PC and NPC to be faded tokens that are not selectable when I switch to the "Flying" elevation level.

Sorry, but I can't figure out how to get that behavior. Is there a way?

This issue doesn't matter when linking to the currently loaded elevation, but when linking a token to another elevation the current elevations tokens will be copied entirely to the destination elevation, totally wiping out the destination's elevation data.

To reproduce:

• Set up two key elevations, such a 0 - Ground and 100 - Sky.
• Create two tokens, such as Mage and Eagle from the default tokens.
• Switch to 0, click on the Mage token, and link it to elevation 0.
• Switch to 100, click on the Eagle token, and link it to elevation 100.
• Now, switch to view the 0 - Ground elevation and link the Mage token to 100 - Sky. This means the token will be visible at both elevations.
• Switch to the Sky elevation.
• See Error: The Sky elevation only has one token, the Eagle is not linked to either layer, and using the Map Explorer you can see it is far off-map in the area reserved for hidden elevation tokens.

Expected behavior:

• The Mage token should be added to the 100 - Sky key elevation so that both the Mage and Eagle are linked to it.

Discussion:
Being able to link to other key elevations is important during a game, so you don't have to disrupt the players' view of the map to attach objects (such as downed foes) to a particular elevation to de-clutter the map.

Unfortunately, the improvements to MapTool's UI has adjusted the positioning:

I'd like to fix this with a version-aware style rule, a campaign-level setting, or both.

Bug

When changing elevations in MapTool 1.12b3, all elevation data may be lost from the elevation you are switching from.

Cause

This is because the getVBL type functions used to return an empty shape object if there were no points to record. Now, instead, it returns an empty JSON array [].

The library needs to account for this case so it doesn't silently fail.

Workaround

On Lib:Elevation 1.0b8, you must add at least one point of every blocking layer type (VBL, Pit VBL, Hill VBL, and MBL) to a map elevation before switching away from it, or you will lose all of that elevation's data.

The "User Guide" macro says "a 'Map Elevation Data' token will be automatically created ...".

For clarity, I suggest being more specific. I've found that (and I think your video said) it is created the first time we use "Add Elev".

I'm not sure what the problem is. The player owns this token but it doesn't show up in their view.

Here, I'm running the server as a GM and "Test Player" connects to it.

Since b8, when making new elevations the suggested height does not reflect the height factor set in the map options. Although the ultimate number does seem to be affected by what the height factor is, it is usually in the 100s regardless of what the height factor is or what the height of the current elevation is
Stonegauntlet Landfill Site.rpmap.zip
.

Currently, an elevation-linked token's precise position is saved as part of its token appearance, even when 'Strict token appearance' is not enabled. The purpose is to ensure that macros or inadvertent drags do not break the token positions, since maps generally depend on precise token placement.

However, when the position is calculated from a static offset so off-canvas movements will be maintained when the linked token is reloaded, neat options emerge. For instance, with some macro wizardry scenarios like two sailing ships with exterior decks and interior hulls could be moved relative to each other while maintaining compatibility with Lib:Elevation.

This was asked for in Discord.