Jumpgate Beta is Open to All Subscribers!

New issue with Jumpgate: Every time I open a jumpgate game, using the 2024 D&D sheet, I'm getting taken to the Settings tab to see this: I used to go to the Journal tab, now I'm taken here always. I also see on the map area: which is odd since I haven't selected any content yet... and the default for the game is the 2024 D&D sheet: Yes, some of the books I have in the Compendium sharing are 2014 books but I only want to be using the 2024 sheet for this game and have no intention of using both sheets. Any characters created, even one using 2014 species, classes/subclasses or backgrounds should use the 2024 sheet. It's possible that the reason I'm seeing this is because of the 2014 monster manuals, and monster blocks but the messages talk about the character sheets not the monster npc sheets so I'm puzzled why I'm seeing this. It's annoying and confusing.

The term "character sheet" is broad, and encompasses PC sheets, NPC statblocks, ship sheets, and more. These are essentially just different views of the same thing. A Monster Manual drag should come in using the sheet you've designated, though. I'm not sure what level of content would trigger such a message: spells, features, equipment, etc from anything but the 2024 PHB (time of writing), or module content? Without performing an "audit" of your game, it's pretty hard to tell.

Yeah, I know. This is why I posted it here, where the staff can see it and investigate, if they choose to do so. Oddly enough, I don't always see the errors. I haven't the last two times I entered the game. It's odd. Something is going on behind the scenes, for sure. keithcurtis said: The term "character sheet" is broad, and encompasses PC sheets, NPC statblocks, ship sheets, and more. These are essentially just different views of the same thing. A Monster Manual drag should come in using the sheet you've designated, though. I'm not sure what level of content would trigger such a message: spells, features, equipment, etc from anything but the 2024 PHB (time of writing), or module content? Without performing an "audit" of your game, it's pretty hard to tell.

Has jumpgate added the ability to enter a number on a token marker above 9 yet? It would be great to enter 150 on my flying token when a character is flying at 150 feet. And yes, I know that I can do various workarounds like using 2 token markers and dividing by 5 feet but that is all too complicated for players.

The popout windows are driving me nuts. Used to be that you would open a Roll20 popout window, and you could drag items and spells from the compendium directly onto the sheet.  Now? It creates a new window that can't interact with the rest of the Roll20 environment. This has totally sabotaged my game preparation.  Is there a workaround to this issue?

Hi Foebane93! To my pretty certain knowledge, you have never been able to drag an item to a popped out window. This is a limitation of browser technology, not Roll20. It's been in the documentation (at least the wiki) for years. Are you perhaps conflating a character sheet engaged window, with a popped out browser window? I.e. an engaged window that exists within the VTT window. That still exists and is the default. You can change the default behavior in the settings tab while you are in the game.

Keithcurtis, Not all heroes wear capes. Thank you.

The token aura's are much better now, however there is still an issue that they get mixed up if you have two tokens on the same square.  For example I had a spell token (lets say for entangle) behind a character token.  The token aura isn't visible as it's behind both tokens, rather than attached properly to the character token.. Jonathan

Hi Lavi, Yes, I see it periodically. Not every time though. And it has been more than once. Essentially: I created this campaign to test the character sheet and theorycraft characters. When I first created the game, I had no problem. Then, suddenly, a couple of days ago, I started seeing this message pop up.  Here it is popping up again today: The messages about choosing defaults, is not appearing. I'll send you the link privately if you want to look around. Lavi said: Hi Saul - the 2014 monster manual is the reason you're seeing this notification. That content is based off of the 2014 sheet, so while you intend to build new characters in 2024, you indirectly are including content based originally on the 2014 sheet. One bit i didn't quite understand from you is it seems like you're getting this notification continuously when entering the same game instead of just once? That's not the intended behavior and want to take a look at how to solve that. Can you let me know the title of your campaign so I can take a look?  Just in case you haven't discovered this yet - you can set your defaults for adding characters and dragging and dropping NPCs to bet 2024 sheet. This means that every time you take such action, you won't be asked to select between the 2014 and 2024 sheet, which should save a couple of clicks and popups. Saul J. said: Yeah, I know. This is why I posted it here, where the staff can see it and investigate, if they choose to do so. Oddly enough, I don't always see the errors. I haven't the last two times I entered the game. It's odd. Something is going on behind the scenes, for sure. keithcurtis said: The term "character sheet" is broad, and encompasses PC sheets, NPC statblocks, ship sheets, and more. These are essentially just different views of the same thing. A Monster Manual drag should come in using the sheet you've designated, though. I'm not sure what level of content would trigger such a message: spells, features, equipment, etc from anything but the 2024 PHB (time of writing), or module content? Without performing an "audit" of your game, it's pretty hard to tell.

I converted to Jumpgate to see how it helped in lag, etc. So far, not so bad, however, I am getting "Ghost" tokens - where, when I drop a token on the Token layer, then move it, it leaves a ghost image of the original. I can move either now, but if I delete one, sometimes they both disappear, sometimes one does. PLUS, on my GM screen, I couldn't see the actual token image, but saw the name/hp stat where it would be IF the token was there. The reverse happened for my players.  Is this something known and being worked on, or is it via my system/config??

Aura's are definitely better again, but there is still the weird effect where they disappear depending on where the token is on the map..

Known! Have it too, sometimes! Token appears twice, once when moved, a "ghost" token where the token was before... Syber Duke said: I converted to Jumpgate to see how it helped in lag, etc. So far, not so bad, however, I am getting "Ghost" tokens - where, when I drop a token on the Token layer, then move it, it leaves a ghost image of the original. I can move either now, but if I delete one, sometimes they both disappear, sometimes one does. PLUS, on my GM screen, I couldn't see the actual token image, but saw the name/hp stat where it would be IF the token was there. The reverse happened for my players.  Is this something known and being worked on, or is it via my system/config??

Running Tomb of Annihilation decided to try jumpgate so copied my game. Loaded up and tried to open the players chult map it took a long time for the map to load. Went back to my original game and checked same map and it was almost instant, I thought jumpgate was meant to run smoother and faster?

Hi David! You might also be dealing with cached data on the old game. Try opening the new one again.

Keith as always you are very helpful that worked a treat cleared my cache and loads perfectly thank you :)

I'm not sure I'm the only one to have this issue and I don't have time right now to wade through ten pages of postings; Creating hyperlink in a handout to a different handout in Jumpgate game doesn't work. But I can get it to work in a non-jumpgate game. This is not listed in the known issues link in the OP.

Hi Doug! Does the link not form, or does it fail to take you to the handout? If the former, look for duplicate handout names. If the latter, make sure you are not set to pop handouts out into their own window by default. 

FINALLY! Lavi said: A little preview into what's coming up after the November holidays! We are excited to share a much anticipated and upcoming enhancement to our Fog of War and Dynamic lighting tools, set to debut in December! Please check out the latest Blog with more info on what we learned from your feedback and input, and what updates you can expect. In the meantime, we all hope you enjoy the holiday weekend, and we'll reconnect with you next week!

One thing I noticed and I am not sure if this is JUMPGATE exclusive. I am on the Map Layer, uploaded this image directly to it. And while on the Map Layer and interacting with the image uploaded (moving / adjusting etc.) it shows Token Menus and also those 3 Bubbles as if the image was a token. And I thought this was fixed recently!

keithcurtis said: Hi Doug! Does the link not form, or does it fail to take you to the handout? If the former, look for duplicate handout names. If the latter, make sure you are not set to pop handouts out into their own window by default.  Hi Keith, The link wasn't forming. However, as I was creating a test handout for the purpose of reproductive steps, it started working. Even with the same target handout that wouldn't link! So I think it has something to do with the 'link to' handout being corrupted or something.

Today was the first time in a few weeks that JG was working a little rough for me. There was a 2-3 second delay when trying to select tokens and I couldn't get any tokens to resize by selecting the token and dragging the corners of it to enlarge. Also players still seeing tokens after I delete them until they refresh the page.

Love the sepia color on explorer mode. And fog effects look really cool!

I can see one thing already that I don't like. You've collapsed several of the tools into a sub-menu. I don't like that. I like the way it was before. I don't like this: I liked this (from a non-jumpgate game): Lavi said: We are really excited to share that the update to the Fog-of-War and Dynamic Lighting features have launched today! Our goal here was to  make interacting with these capabilities smoother and more intuitive, letting GMs focus on gameplay and vibes, not troubleshooting. Please let us know what you think via the feedback form linked right in the Dynamic Lighting tool (also  here for easy access). Please check out our Blog for more information, and here's a summary of the updates: 1) Introduced a New Dynamic Lighting tool in Left Toolbar Subscribers now have access to a fully revamped Dynamic Lighting tool accessible in Left Toolbar, which consolidates all relevant settings in one place. You’ll see real-time updates to your map as you adjust things, with updated tooltips providing additional clarity. This eliminates the need to navigate to and switch between tabs in page settings. Dynamic Lighting will also include Explorer Mode (formerly “Explorable Darkness”), enabling a map area to become and stay revealed to a player – in a neat sepia color – once their token has seen it. Explorer mode is still editable, but in a new context, so that users don’t get confused between explorer mode and hide/reveal!  To help troubleshoot lighting issues quickly, we’ve added a diagnostics section to the footer of the Dynamic Lighting tool (helping callout tokens with vision, and light sources on the map) Added animated darkness effects, such as Dark Fog or Pale Mist to create a more immersive experience 2) Updated Hide / Reveal Mask tool All users can enjoy a simpler and clearer interface for hiding and revealing areas of the map during game play with Hide / Reveal Mask tool. Previously called “Permanent Darkness” within Fog of War, this tool allows for quick hide-and-reveal actions to manage map visibility on the fly. We simplified the language and instructions to make things clear and more accessible, removing ambiguity around terms like “add” and “subtract.” We’re also retiring references to Fog of War, Permanent Darkness and Explorable Darkness to remove perceived overlap with Dynamic Lighting – just hide or reveal some stuff! 

Hi Saul! What is the resolution of your screen? Or is that from a mobile device? Here is what I see on a 1080 monitor: The only way I can see what you are seeing is to use browser zoom at 150%.

I don't think the resolution matters.  Prior to rhe last update, it was fine. It's fine in non-jumpgate games. This is something that Roll20 changed and I think it's a bad change. FWIW, I'm on a 16" Macbook Pro with Liquid Retina XDR display at the default resolution, which I believe is  3456-by-2234 native resolution at 254 pixels per inch. There's no browser zoom involved:   keithcurtis said: Hi Saul! What is the resolution of your screen? Or is that from a mobile device? Here is what I see on a 1080 monitor: The only way I can see what you are seeing is to use browser zoom at 150%.

My screen also looks like what  keithcurtis  posted . My monitor resolution is  1920 x 1080;  I'm using  Windows 10 and the Chrome browser.  I'm wondering if this is a device or browser specific issue? Just to cover all bases: do the screen shots that you posted show the total vertical display or did you crop them to show only the upper icons on the left side menu? Also, are you showing a full-screen or windowed view? Edit: I went back to my game and tried the windowed view, but that still  won't show what you've posted.  I've also tried this using Firefox, with the same results.  The only way I can get it to show a collapsed menu is by going to 125% browser zoom, which you've already said isn't your case.  Saul J. said: I can see one thing already that I don't like. You've collapsed several of the tools into a sub-menu. I don't like that. I like the way it was before. I don't like this: I liked this (from a non-jumpgate game):

The rollout happened to me during a game and really messed me up as I couldn't find things quickly where I'm used to them being - like the turn tracker. Initially, I had the three vertical dots but that went away when I maximized my browser. The dots come back (and hides the submenu items) when the browser is not maximized.

Saul J. said: I don't think the resolution matters.  Prior to rhe last update, it was fine. It's fine in non-jumpgate games. This is something that Roll20 changed and I think it's a bad change. FWIW, I'm on a 16" Macbook Pro with Liquid Retina XDR display at the default resolution, which I believe is  3456-by-2234 native resolution at 254 pixels per inch. There's no browser zoom involved: Perhaps it has something to do with the Retina display? I can't test for that, but it's data that Roll20 might be able to investigate.

FWIW, I'd rather you scaled the size of the icons (which is how browsers are supposed to handle things)  rather than collapsing them . Or maybe make it so that the icons scale but provide an optional collapse that would then collapse the icons and increase the scale/size of the remaining icons and giving the choice to the user as to whether to have smaller icons or collapsed icons. Lavi said: Saul And Doug - thank you for bringing this up. Wanted to provide a bit more context and a small update we'll be making to help reduce the collapse instances for tools over the next couple of days. Firstly, since we did introduce a new tool & tool sections to the Left Bar with Dynamic Lighting that didn't exist before, it overall increases the number of tools, and naturally the number of instances in which the collapse would be triggered on smaller screens/higher zoom levels. However, the old behavior collapsed layers before it collapsed tools - so we are going to bring that back which should help you more immediately. Additionally, different browsers have different zoom defaults, so adjusting zoom is another additional option here. Longer term, we are exploring solutions to the crowding & tool accessibility solutions on the Left menu because we recognize as we introduce more new tools in the future, the usability challenges your are describing will be more persistant.

Anyone else having a issue copy/pasting tokens onto another page and the tokens wont resize at all?

Hi All, I haven't been through all the pages of this, but I have just copied a game and converted it to Jumpgate. It's all looking good with two minor caveats: - Graphics dropped on the map layer have the three token 'bubbles' and token marker and settings icons etc. like a token... Is this intended? I know it can be set to 'is drawing' but I still need map items to snap to grid...  - Graphics dropped to map area aren't always seen by players, sometimes a reload is required Everything else is good and all my scripts work, and animations are now nice to have! Regards, ~ Coryphon ~

Had problems this weekend making page setting changes and having them immediately reflected in the graphics window.  I am used to the behavior of being able to update page size, or grid size, or grid type (square to hex) and having the graphic window update automatically and instantaneously.  Instead, this weekend, I had to go to a different page and come back to have the page changes reflected in the  graphics window.  Is this intended behavior, as it is different than previous behavior.  Other than that, so far liking jumpgate.   Also mirroring Coryphon’s comments.  The new jumpgate seems to treat all items dropped to the map layer as tokens.  Can’t find the setting where graphics dropped to the map layer are treated as drawings.  Wasn’t that a thing?  Regardless, behavior is different than what I’m used to.  Is this intended.  Did not have the player reload issue

Graphics dropped to the map layer are not "drawings" as defined by the interface. It's just that the token interface does not display on an image on the map layer. It still snaps to grid, for instance. That being said, it does seem from multiple reports that the token interface is displaying on the map layer on Jumpgate. That sounds like a bit of parity to address.

I just did a test. I loaded a non-jumpgate game, created a new page, moved to the map layer, and dropped a map graphic onto the layer. The game dropped the image onto the VTT, asked me if I wanted to adjust the size, and then loaded the graphic. The token interface did not come up. I then went into a jumpgate game I've been working on. Created a new page, moved to the map layer, and dropped the SAME map graphic onto the screen. Two things: 1. The token interface came up when I clicked on the image and 2. I was not asked if I wanted to adjust the size. It dropped the image onto the VTT as a 4x4 token. I repeated the test again with a different graphic just to be sure. The first one was a jpg graphic, the second was a webp graphic. The same thing happened. I have been working on this jumpgate game for about 6 months preparing a game to run next year some time. I don't believe it was working this way when I started but I could be wrong. I know it has been working this way since July - right around the time that the 2024 PHB came out and the new 2024 5E sheet was made public. I don't know if it's related or not. Probably not, but you can never tell. keithcurtis said: Graphics dropped to the map layer are not "drawings" as defined by the interface. It's just that the token interface does not display on an image on the map layer. It still snaps to grid, for instance. That being said, it does seem from multiple reports that the token interface is displaying on the map layer on Jumpgate. That sounds like a bit of parity to address.

Hi Saul! I can only verify part of this. Graphics dropped onto a Jumpgate map layer do indeed show the token interface, unlike Classic. I'm not sure how much of a bug this is, other than just being needless interface cruft. They both behave as tokens, regarding snap to grid. I agree that the Classic behavior is better. However if I drop a graphic onto a page that has a smaller height or width than the graphic dimensions, it will offer to (correctly) resize. If the page is already larger than the graphic in both dimensions, the resize option will not come up, but it will drop as a 3x3 unit graphic. This is normal behavior. It will only come in at native pixel dimensions if it is currently being uploaded, or if the dimensions have been manually pre-set in the library. This behavior is identical across Classic and Jumpgate for me. I have also tested with png and jpg. I have made a report of this thread for hopeful dev investigation, though.

keithcurtis said: Hi Saul! I can only verify part of this. Graphics dropped onto a Jumpgate map layer do indeed show the token interface, unlike Classic. I'm not sure how much of a bug this is, other than just being needless interface cruft. They both behave as tokens, regarding snap to grid. I agree that the Classic behavior is better. However if I drop a graphic onto a page that has a smaller height or width than the graphic dimensions, it will offer to (correctly) resize. If the page is already larger than the graphic in both dimensions, the resize option will not come up, but it will drop as a 3x3 unit graphic. This is normal behavior. It will only come in at native pixel dimensions if it is currently being uploaded, or if the dimensions have been manually pre-set in the library. This behavior is identical across Classic and Jumpgate for me. I have also tested with png and jpg. I have made a report of this thread for hopeful dev investigation, though. Keith, Don't know what to say except that your experience and mine differs. I've found that loading a graphic from the file system (i.e. as it is loaded) works only about 90% of the time. I have had graphics that were larger than the page that would not resize when being loaded.  And, like I said, the *same* graphics worked correctly and were resized in Classic but not in jumpgate. Neither graphic had its dimensions pre-set in the library. Neither were currently being loaded. They were graphics I had previous loaded, and btw, at least one of them had its dimensions at 1x1. This is annoying. The graphics should behave the same in jumpgate as they do in Classic.  I hope this is something the devs will look at and fix.

MAYBE the "new" Feature with Jumpgate is interfering here... the feature that there are visible parts to the players although the map might be larger... The correct behaviour would be IMO that if the image uploaded is larger than the map it should ASK first, if the map height and width should be adjusted, THEN (if NO was selected) it should ask to fit the image on the map with its current dimensions. IF the answer here is still NO, it should just upload the image in its original dimensions with only parts beeing visible to the players! Saul J. said: keithcurtis said: Hi Saul! I can only verify part of this. Graphics dropped onto a Jumpgate map layer do indeed show the token interface, unlike Classic. I'm not sure how much of a bug this is, other than just being needless interface cruft. They both behave as tokens, regarding snap to grid. I agree that the Classic behavior is better. However if I drop a graphic onto a page that has a smaller height or width than the graphic dimensions, it will offer to (correctly) resize. If the page is already larger than the graphic in both dimensions, the resize option will not come up, but it will drop as a 3x3 unit graphic. This is normal behavior. It will only come in at native pixel dimensions if it is currently being uploaded, or if the dimensions have been manually pre-set in the library. This behavior is identical across Classic and Jumpgate for me. I have also tested with png and jpg. I have made a report of this thread for hopeful dev investigation, though. Keith, Don't know what to say except that your experience and mine differs. I've found that loading a graphic from the file system (i.e. as it is loaded) works only about 90% of the time. I have had graphics that were larger than the page that would not resize when being loaded.  And, like I said, the *same* graphics worked correctly and were resized in Classic but not in jumpgate. Neither graphic had its dimensions pre-set in the library. Neither were currently being loaded. They were graphics I had previous loaded, and btw, at least one of them had its dimensions at 1x1. This is annoying. The graphics should behave the same in jumpgate as they do in Classic.  I hope this is something the devs will look at and fix.

Saul, if you want to PM me a link to the test image(s) you are using, along with repro steps of the page size before placement, I'll try and duplicate your steps more closely. I tested with graphics as small as 280 x 280 px going on a 210x210 px page, and ones that were actual full size maps and got the results I reported, both on Classic and Jumpgate. BTW, I have been told that a fix for the token interface displaying on the map layer is underway.

Keith, I don't really have links to give you since I do not recall where I got these maps from. I've had to hunt a lot to find the images I wanted for this game and they came from all over the Internet. :-) I have them on disk and I could put them on dropbox if it were really necessary. I've learned to live with it - if the image doesn't resize automatically, I just do it myself. It's not a big deal. I have rarely created maps from the library images and the system working 90% of the time is good enough, IMO.  Fixing the token interface displaying on the map layer is good enough for me.  keithcurtis said: Saul, if you want to PM me a link to the test image(s) you are using, along with repro steps of the page size before placement, I'll try and duplicate your steps more closely. I tested with graphics as small as 280 x 280 px going on a 210x210 px page, and ones that were actual full size maps and got the results I reported, both on Classic and Jumpgate. BTW, I have been told that a fix for the token interface displaying on the map layer is underway.

If your good, then cool. For future reference, if you do need to share such an image, place it on the VTT, select it and preview it with the Z key. You can then copy the URL to share with someone, or download it to your computer.

If you do want to play with one image, here's a case where things didn't work as expected: <a href="https://files.d20.io/images/420674298/WYfuTy-xLSWUMUkKBVwJYw/original.jpg?1733866009" rel="nofollow">https://files.d20.io/images/420674298/WYfuTy-xLSWUMUkKBVwJYw/original.jpg?1733866009</a> I loaded this from my file system direct to the map layer. The system asked me if I wanted to adjust the size, and I chose "adjust the size of the page". The page size wasn't adjusted. The image size wasn't adjusted. The original image is 2048x2048, FWIW. keithcurtis said: If your good, then cool. For future reference, if you do need to share such an image, place it on the VTT, select it and preview it with the Z key. You can then copy the URL to share with someone, or download it to your computer.

I'm also experiencing the phenomena that changes to the map settings (such as changing the color of the gridlines) does not &nbsp;get reflected on the screen until I do a reload. This was not &nbsp;the case when I first started working on this game.&nbsp;

Here is what I get when I upload that graphic directly to the map layer and choose to resize. The page fits correctly, but of course the grids don't match (2048 does not divide by 70 evenly, and the system has to assume a pixels per cell value.) But I don't show that bleed you are seeing. I have tested on Mac and Chromebook, both on relatively recent versions of Chrome. I am also not experiencing a reload when changing a value like grid color. I don't know if your Retina display has anything to do with the experiences you've been having, but can't test for that. Does anyone using Roll20 on a Retina display have the ability to run a test?