
Gauss and Keith helped highlight this to us a little bit ago. The teams is working on a fix that should be out tomorrow or the day after at the latest, and return your token bars to the original state. Apologies for the temporary clutter here while we're getting this resolved.
keithcurtis said:
David Q. said:
This has happened since the update all bars show even if not temp hp I have bar2 ac and bar3 challenge it has added alot of clutter to my game
Confirmed. This is not parity behavior and is nonsensical for items that have a discrete value (AC, Speed) as opposed to a trackable range (HP)
Tuo said:
So the intended behavior is that if the denominator is 0, the bar is shown, but a null denominator defaults to 0, so it shows even when not desired. This creates a situation where you can not have a token bar value that's not shown as a bar, as even invalid values as denominator create a bar.
Gauss said:
The correct behavior should be:
X/Y = bar with X/Y values
X/0 = bar with X value (and a + sign at the end but that was always...ok whatever behavior)
X/blank = no bar
X/0 was dropped in Jumpgate compared to Legacy and needed to be brought back, but clearly that hasn't worked correctly. :)
keithcurtis said:
This has been reported. Devs are investigating.
Hi all - the fix for this has been released, so should function as expected going forward for people newly loading into games! For those in-game, you'll just need to refresh to see the updates reflected!
Lavi said:
Gauss and Keith helped highlight this to us a little bit ago. The teams is working on a fix that should be out tomorrow or the day after at the latest, and return your token bars to the original state. Apologies for the temporary clutter here while we're getting this resolved.
keithcurtis said:
David Q. said:
This has happened since the update all bars show even if not temp hp I have bar2 ac and bar3 challenge it has added alot of clutter to my game
Confirmed. This is not parity behavior and is nonsensical for items that have a discrete value (AC, Speed) as opposed to a trackable range (HP)
Tuo said:
So the intended behavior is that if the denominator is 0, the bar is shown, but a null denominator defaults to 0, so it shows even when not desired. This creates a situation where you can not have a token bar value that's not shown as a bar, as even invalid values as denominator create a bar.
Gauss said:
The correct behavior should be:
X/Y = bar with X/Y values
X/0 = bar with X value (and a + sign at the end but that was always...ok whatever behavior)
X/blank = no bar
X/0 was dropped in Jumpgate compared to Legacy and needed to be brought back, but clearly that hasn't worked correctly. :)
keithcurtis said:
This has been reported. Devs are investigating.
Oginme said:
When you drag the character to the VTT, it is trying to pull the image from the proper side of the multisided token. With the rollable table not available, it appears to put an invisible marker for that token. When you brought over the rollable table which was connected to the character sheet, it populated the markers on the VTT.
This happens in legacy also. When I am moving a character sheet over, I make sure that any associated rollable it moved first.
Jim W. said:
Today had a character I am trying to drop on a map, and it would just not appear.
I had transmogrified it from another game, but not the multi-sided token. When I transmogrified the multi-sided token I suddenly got a number of tokens on map - so the drag and drop had worked, just invisible?
Now this is odd, because the Token had been updated into the sheet, so I'd have thought the sheet would have included it when moved. Also the settings were all lost - unlike other standard tokens in sheets that had been moved. I've not tested this in Legacy, as game time is soon!
and yet apparantly you can copy it to another player as per https://app.roll20.net/forum/post/12275796/transferring-a-rollable-token
Seems backwards to me...
One misapprehension I've seen above: once you create a rollable table token, the images are stored as a string of image links in a field on the token. It no longer has any connection to the table that created it. There is no need to transmogrify a table along with the token, unless you wish to regenerate a new token from the table.
Copying/pasting, setting default, or transmogrifying a rollable token creates a token with all the faces resident on the token.
If you can give step-by-step repro on the issue you are experiencing, I will try to duplicate the behavior.
keithcurtis said:
One misapprehension I've seen above: once you create a rollable table token, the images are stored as a string of image links in a field on the token. It no longer has any connection to the table that created it. There is no need to transmogrify a table along with the token, unless you wish to regenerate a new token from the table.
Copying/pasting, setting default, or transmogrifying a rollable token creates a token with all the faces resident on the token.
If you can give step-by-step repro on the issue you are experiencing, I will try to duplicate the behavior.
Me?
I created a multi-sided token, put on map. Linked to character and set all the settings as I wanted, then updated the default. The token could then be dropped from the 2014 player sheet on any map in that game.
Tranmogrified the character to another game, and tried to drag and drop the character to sheet and nothing seemed to happen. Went into the character and saw it had no token, though does have an image above that. (This image used to be used if there was no token, but no longer? Would have clued me in on tyhe issue sooner if it had).
Transmogrified the table and the token appeared on map. Still had to reset all the settings and save as default though.
Just tried to transmogrify to another game, and everything worked (except the transmogrify and character token view windows are awful, the former hiding the lists out of the focus area (and having a huge whitespace area if drag the bottom of window down, an issue I first noted a few days ago) and the latter having only a small visible focus area... in a game which I created a few days ago and only used for transmogrify testing).
EDIT: odd sizing and visibility in windows is not specific to Jumpgate, also applies in Legacy
What Jim W. describes is exactly the issue that I have run into with rollable tokens attached to character sheets. I have done it dozens of time with the same issue if I do not transmogrify the rollable table over to the game.
OG.
Jim W. said:
keithcurtis said:
One misapprehension I've seen above: once you create a rollable table token, the images are stored as a string of image links in a field on the token. It no longer has any connection to the table that created it. There is no need to transmogrify a table along with the token, unless you wish to regenerate a new token from the table.
Copying/pasting, setting default, or transmogrifying a rollable token creates a token with all the faces resident on the token.
If you can give step-by-step repro on the issue you are experiencing, I will try to duplicate the behavior.
Me?I created a multi-sided token, put on map. Linked to character and set all the settings as I wanted, then updated the default. The token could then be dropped from the 2014 player sheet on any map in that game.
Tranmogrified the character to another game, and tried to drag and drop the character to sheet and nothing seemed to happen. Went into the character and saw it had no token, though does have an image above that. (This image used to be used if there was no token, but no longer? Would have clued me in on tyhe issue sooner if it had).
Transmogrified the table and the token appeared on map. Still had to reset all the settings and save as default though.
Just tried to transmogrify to another game, and everything worked (except the transmogrify and character token view windows are awful, the former hiding the lists out of the focus area (and having a huge whitespace area if drag the bottom of window down, an issue I first noted a few days ago) and the latter having only a small visible focus area... in a game which I created a few days ago and only used for transmogrify testing).EDIT: odd sizing and visibility in windows is not specific to Jumpgate, also applies in Legacy
I am unable to reproduce this with the information so far provided. I opened my regular Jumpgate (two sheet) game and selected two characters, one built with the 2014 sheet and one with the 2024 sheet, each with a rollable token as the default token. I transmogrified them into another Jumpgate game, mostly empty (I use it to hold pre-lit maps for transmogrifying).
Each came through with all sides intact. All graphics were uploaded by me, not marketplace imagery. What am I doing different from what you (Jim or Oginme) are doing?
I also have to reiterate that even if they are coming through with no faces intact, I cannot see a mechanism that would fix this by transmogrifying the table that produced the token. There is no backwards link to the table. It's just a static list put into a property called "sides" token upon creation:
The forum is still ^^^ doing that behavior where,
The pictures you posted are not Clickable to see in larger size.
It used to be -- on this very forum -- any nonsmall image you uploaded would be able to click to pop-up and see in larger size.
For the last few months this feature of the forum seems broken and often isn't happening anymore
Hi,
Yesterday, I ran a session on Jumpgate, after converting an existing campaign (5E - 2014). All in all it went quite well, had no issues with dynamic lighting, ghost tokens, etc.
The problems I had were the following:
- After my players had a go at trying out all the SFX, one player had some of them stuck on their page, going on forever. A reload obviously fixed this.
- Some players could not cast spells from their spell character sheet. The spells that had an attack associated to them could be "cast" from the attack page. I think I 've fixed it in the meantime, by toggling every spell in the sheet from spellcard to attack, and back again. Is this a known issue?
- One player had a lot of latency issues. It took a while before a click on a roll came through in chat. Not sure if this is a recurring issue with Jumpgate or not, but it was noticeable.
- Casting spells that request a choice of level to cast it on, the pop up window did not sit on the front, but always hidden behind the open character sheet. It would be handy if this pop up window would be forced to the foreground.
Just giving a report on the state as I encountered it. Carry on
Eric,
The one bullet-point I saw that you could troubleshoot and possibly fix or improve the performance for your player:
Eric G. said:
- One player had a lot of latency issues. It took a while before a click on a roll came through in chat. Not sure if this is a recurring issue with Jumpgate or not, but it was noticeable.
Tell this player to try changing some of the graphics performance options in Roll20, under the Settings cog at the top-right above your Roll20 table's chat room. Those settings might improve that player's rolling output latency.
keithcurtis said:
I am unable to reproduce this with the information so far provided. I opened my regular Jumpgate (two sheet) game and selected two characters, one built with the 2014 sheet and one with the 2024 sheet, each with a rollable token as the default token. I transmogrified them into another Jumpgate game, mostly empty (I use it to hold pre-lit maps for transmogrifying).
Each came through with all sides intact. All graphics were uploaded by me, not marketplace imagery. What am I doing different from what you (Jim or Oginme) are doing?
One sheet - 2014 -
When I brought the table over the images appeared on map.
Though... this issue does not always happen (I think)
Last night my players completed one of the major plot encounters in my campaign, in which they revisited a lair that they'd previously explored but where not powerful enough at that time to defeat the BBEG. The first time that I used this particular map my game was pre-Jumpgate. At that time had set up some custom visual effects to simulate the D&D 5e spell "Guards & Wards" and I had 70 NPCs of 8 different types (none of which had vision enabled) on a map that is 90 x 60 grid squares with dynamic lighting enabled; the game ran smoothly for all players and for me as GM.
Since that time I have converted my game to Jumpgate. Last night we were using the same map, but without the special visual effects (the G&W had been dispelled), half as many NPCs and those were of only three types.
-The one animated graphic element (a token) wasn't working, although it was working the day before when I was reviewing the page.
-Character sheets for spellcasters were taking up to a minute to load for me and even longer for one of the players.
-Links within handouts that were working fine last week did not work.
-Two players had to repeatedly leave and re-enter the game because they were having difficulty moving their tokens.
-Rolling from the player character sheets was very slow for all players. One player had to restart the game several times to get their sheet to work at all.
-I had to restart the Experimental API sandbox several times over the course of the 4 1/2 hour game session.
Solutions attempted by me and by the players:
-Clearing the browser cache
-Leaving and re-entering the game.
-Refreshing the game.
-Moving the player ribbon away from the map then back again.
The map size is 90 x 60 grid squares, 5 ft. squares, with dynamic lighting in use. Token vision was not enabled for any NPCs. Only the Chrome and Firefox browsers in use. There were 7 player character sheets in use by 6 players. We are using the D&D 5e for Roll20 (2014) character sheet.
I've just finished DMing a game. I had to leave and re-join the game as though the map had loaded, once I opened a character sheet I had a blank brown screen. Leaving and then re-joining did fix this. I then experienced, for the first time a ghost token, I moved it and it was still visible in its pre moved position and its new position, but only I could see this. It didn't happen to any of the other tokens.
Ok, new problem: I was setting up a page in my game. There are several characters/tokens I wanted to set the tooltip for to be "Servant" to identify them as random servants in a mansion:
1. After entering the tooltip text, I have to click "Show" twice. The first time I click "Show", the screen adjusts to show the upper portion of the token edit screen. The second time actually sets it to show.
2. After clicking "Show" the first time, the token disappears from the screen. It's still there... I can still click on it if I know where it is. But, it's not displayed. It's truly invisible. The tooltip text displays if I hover over where the token should be.
3. If I refresh/reload using "Ctrl-R" the tokens reappear... but they are set to their original state - no Tooltip text and "Show" is not set.
I wish I could post video here because it'd be easier to show with a short video but that's not allowed in the forums.
I'm hoping this is a temporary problem. It wasn't happening yesterday when I was working on another page. That page is fine - the tokens all still have the tooltips that were set yesterday. But, today, I can't set tooltips on any token. I didn't try other settings. I did try another page and it is happening there too - so it's not just the one page.
Hi Saul J.,
The Devs are currently working on issue #2.
Regarding issue #1, I'd like to see what happens after the fix is out for issue #2 to see what remains of that issue.
Interesting. It wasn't that way a couple of days ago when I was working on another map.
Thanks for posting the information!
Gauss said:
Hi Saul J.,
The Devs are currently working on issue #2.
Regarding issue #1, I'd like to see what happens after the fix is out for issue #2 to see what remains of that issue.
Hi Saul - the team released a fix as of about 2-3 hours ago that i believe would fix all the issues you listed (but may require you to delete cached data). In case they are continuing to occur, could you let us know?
Saul J. said:
Interesting. It wasn't that way a couple of days ago when I was working on another map.
Thanks for posting the information!
Gauss said:
Hi Saul J.,
The Devs are currently working on issue #2.
Regarding issue #1, I'd like to see what happens after the fix is out for issue #2 to see what remains of that issue.
Hi Lavi,
It fixed the disappearing token problem, but not the having to click "Show" twice problem. I think the problem where the tokens were being reset were an artifact of the disappearing token problem. So, almost there. :-) But, if I have to click "Show" twice it's not a big deal. An annoyance, sure. But, not a big one.
Thanks, Lavi!
Lavi said:
Hi Saul - the team released a fix as of about 2-3 hours ago that i believe would fix all the issues you listed (but may require you to delete cached data). In case they are continuing to occur, could you let us know?Saul J. said:
Interesting. It wasn't that way a couple of days ago when I was working on another map.
Thanks for posting the information!
Gauss said:
Hi Saul J.,
The Devs are currently working on issue #2.
Regarding issue #1, I'd like to see what happens after the fix is out for issue #2 to see what remains of that issue.
Any reason why, in the update, the positions of the "Map" and "Light" layers on the left bar were switched? It used to be (top to bottom): Tokens, GM, Light, Map. Now, it's Tokens, GM, Map, Light. I preferred it the old/first way.
I thought I noticed something weird.
Also I'm going to need to give up on using maps that exceed or even approach 100 (70px) grid squares in any dimension. At that size, using DL, the lag and slow refresh makes them unusable. Maps of that size were still workable before I converted to Jumpgate.
Saul J. said:
Any reason why, in the update, the positions of the "Map" and "Light" layers on the left bar were switched? It used to be (top to bottom): Tokens, GM, Light, Map. Now, it's Tokens, GM, Map, Light. I preferred it the old/first way.
Saul J. said:
Any reason why, in the update, the positions of the "Map" and "Light" layers on the left bar were switched? It used to be (top to bottom): Tokens, GM, Light, Map. Now, it's Tokens, GM, Map, Light. I preferred it the old/first way.
Hi Saul, this is in preparation for a new button for the foreground layer, coming soon.
Ok, and another new problem: lights on the Dynamic Lighting layer are sort of persistent. For example, if I place a light on the lighting layer, and set it "on" so that it's emitting light it's fine. But, if I then turn that light "off", the behavior doesn't change - it's as if the light were still "on". If I refresh the screen (Ctrl-R) the light goes away. This worked as expected before the recent update - the lights went "on" and "off" without needing a screen refresh.
Well, that's nice but... I keep clicking the wrong button. And I use the button for the light layer more than I use the button for the map layer so look for it first... where it always was before. There's no reason why the new button couldn't have been put between the Light and Map buttons in the order they were in originally.
Gauss said:
Saul J. said:
Any reason why, in the update, the positions of the "Map" and "Light" layers on the left bar were switched? It used to be (top to bottom): Tokens, GM, Light, Map. Now, it's Tokens, GM, Map, Light. I preferred it the old/first way.
Hi Saul, this is in preparation for a new button for the foreground layer, coming soon.
I think the new order will make more sense when the new layer is added. I was lucky enough to have had some feedback on that feature, and was also reticent about a change. I think that it will be a matter of a week or so, before the fingers forget it used to be another way.
I remain skeptical. Muscle memory is a powerful thing. I haven't touched a piano in about 25 years but my fingers still remember where all the keys are and how to play them. :-)
keithcurtis said:
I think the new order will make more sense when the new layer is added. I was lucky enough to have had some feedback on that feature, and was also reticent about a change. I think that it will be a matter of a week or so, before the fingers forget it used to be another way.
Ah - I can replicate the issue having to click "show" twice. I added it to our list of bugs as it's definitely one. In case you do know - did this change for you recently?
Saul J. said:
Hi Lavi,
It fixed the disappearing token problem, but not the having to click "Show" twice problem. I think the problem where the tokens were being reset were an artifact of the disappearing token problem. So, almost there. :-) But, if I have to click "Show" twice it's not a big deal. An annoyance, sure. But, not a big one.
Thanks, Lavi!
Lavi said:
Hi Saul - the team released a fix as of about 2-3 hours ago that i believe would fix all the issues you listed (but may require you to delete cached data). In case they are continuing to occur, could you let us know?Saul J. said:
Interesting. It wasn't that way a couple of days ago when I was working on another map.
Thanks for posting the information!
Gauss said:
Hi Saul J.,
The Devs are currently working on issue #2.
Regarding issue #1, I'd like to see what happens after the fix is out for issue #2 to see what remains of that issue.
Ulti said:
On Jumpgate, the result of @{target|token_id} is always the same id whatever the token I point to. From my experiments, it seems to always be the id of the token in front. Please fix, this makes the mod I need unusable and prevents me from using Jumpgate.
Is @{target|token_id} supposed to work on Jumpgate, or is it abandoned and replaced by something else?
There is the same issue with @{target|token_name} by the way. I opened a ticket about all that 8 days ago, but only received the automated answer.
I just started putting tooltips onto tokens recently, as I'm putting tokens on maps. I don't know if this behavior existed before about a week or two ago. It hasn't changed in the last update.
One thing I noticed is that if you click show, then add the toolip text, there's no issue. I *think* what's happening is that the first click of "show" takes you out of the "edit tooltip text" mode and then you have to click "show" again. But, IMO, the first click should be sufficient. So, yes, to me it's a bug. It's a minor one, for sure, especially given there's an easy workaround. But, still...
Lavi said:
Ah - I can replicate the issue having to click "show" twice. I added it to our list of bugs as it's definitely one. In case you do know - did this change for you recently?
Saul J. said:
Hi Lavi,
It fixed the disappearing token problem, but not the having to click "Show" twice problem. I think the problem where the tokens were being reset were an artifact of the disappearing token problem. So, almost there. :-) But, if I have to click "Show" twice it's not a big deal. An annoyance, sure. But, not a big one.
Thanks, Lavi!
Lavi said:
Hi Saul - the team released a fix as of about 2-3 hours ago that i believe would fix all the issues you listed (but may require you to delete cached data). In case they are continuing to occur, could you let us know?Saul J. said:
Interesting. It wasn't that way a couple of days ago when I was working on another map.
Thanks for posting the information!
Gauss said:
Hi Saul J.,
The Devs are currently working on issue #2.
Regarding issue #1, I'd like to see what happens after the fix is out for issue #2 to see what remains of that issue.
Ulti said:
There is the same issue with @{target|token_name} by the way. I opened a ticket about all that 8 days ago, but only received the automated answer.
I can't replicate this issue, both @{target|token_name} and @{target|token_id} resolved fine in a jumpgate test game, both for tokens dragged from different character sheets, and for tokens dragged from the same character sheet. Each one returned their unique ID or name as supposed to.
Tuo said:
Ulti said:
There is the same issue with @{target|token_name} by the way. I opened a ticket about all that 8 days ago, but only received the automated answer.
I can't replicate this issue, both @{target|token_name} and @{target|token_id} resolved fine in a jumpgate test game, both for tokens dragged from different character sheets, and for tokens dragged from the same character sheet. Each one returned their unique ID or name as supposed to.
Did you run both calls in the same macro?
keithcurtis said:
Tuo said:
Ulti said:
There is the same issue with @{target|token_name} by the way. I opened a ticket about all that 8 days ago, but only received the automated answer.
I can't replicate this issue, both @{target|token_name} and @{target|token_id} resolved fine in a jumpgate test game, both for tokens dragged from different character sheets, and for tokens dragged from the same character sheet. Each one returned their unique ID or name as supposed to.
Did you run both calls in the same macro?
I did now, as @{target|target1|token_name} and @{target|target2|token_name}, and @{target|target1|token_id} and @{target|target2|token_id}, and then all together for good measure. Still all unique returns.
Hmm. I believe it was a reversion that gave the bad target. Maybe the reversions has been... reverted.
The tooltip show click twice issue was not there when I was doing a prep for a game a few months ago..
edit: Just tested and does happen now in same game... 2014 and Jumpgate
Some good news regarding dynamic lighting using Explorer Mode (Using Update Vision On Token Drop), the lighting barriers seem to be working :)
We are still investigating this as a high priority to figure out/resolve which set of circumstances cause it to sometimes returns wrong values. We identified and released a fix in the last 2 months that was specific to Beacon sheets, but appears that there are additional scenarios for non-Beacon sheets as well. Will keep this thread updated when we're nearing a resolution.
Tuo said:
keithcurtis said:
Tuo said:
Ulti said:
There is the same issue with @{target|token_name} by the way. I opened a ticket about all that 8 days ago, but only received the automated answer.
I can't replicate this issue, both @{target|token_name} and @{target|token_id} resolved fine in a jumpgate test game, both for tokens dragged from different character sheets, and for tokens dragged from the same character sheet. Each one returned their unique ID or name as supposed to.
Did you run both calls in the same macro?
I did now, as @{target|target1|token_name} and @{target|target2|token_name}, and @{target|target1|token_id} and @{target|target2|token_id}, and then all together for good measure. Still all unique returns.
keithcurtis said:
Hmm. I believe it was a reversion that gave the bad target. Maybe the reversions has been... reverted.
Gez - i'm super happy to hear it's working for you, but truthfully we haven't made an update and are still in weeds or narrowing down the root cause. In other words, I still expect DL to reveal areas unexpectedly in certain circumstances.
Given the intermittent nature this has been a challenging one to track down, but we're in the process of doing it now as high priority. This is another issue that i'll ensure to callout when we're nearing a fix.
Gez C. said:
Some good news regarding dynamic lighting using Explorer Mode (Using Update Vision On Token Drop), the lighting barriers seem to be working :)
Ahhhh. That's a shame. They are the WORST kinds of bugs. But the advice given regarding using Update Vision On Token Drop, does seem to be working.
Lavi said:
Gez - i'm super happy to hear it's working for you, but truthfully we haven't made an update and are still in weeds or narrowing down the root cause. In other words, I still expect DL to reveal areas unexpectedly in certain circumstances.
Given the intermittent nature this has been a challenging one to track down, but we're in the process of doing it now as high priority. This is another issue that i'll ensure to callout when we're nearing a fix.Gez C. said:
Some good news regarding dynamic lighting using Explorer Mode (Using Update Vision On Token Drop), the lighting barriers seem to be working :)
Tuo said:
Ulti said:
There is the same issue with @{target|token_name} by the way. I opened a ticket about all that 8 days ago, but only received the automated answer.
I can't replicate this issue, both @{target|token_name} and @{target|token_id} resolved fine in a jumpgate test game, both for tokens dragged from different character sheets, and for tokens dragged from the same character sheet. Each one returned their unique ID or name as supposed to.
Yes, it seems I cannot replicate that anymore with new games. I can still reliably replicate on old games, but not when I create a new one.
What issues are people still having? I want to try the foreground update but I haven't played any of my games in Jumpgate yet because it had a bunch of issues at the start. Would anyone recommend updating or should I wait until it's more stable? (note: I have a few API, use macros, and made rollable tables)
I would say the only remaining issue in Jumpgate are "Ghost" token. In where I put tokens on the map and I need to refresh it or else I have a ghost version of it that stays where I put it and never disappears until I refresh the page/browser
Andez said:
What issues are people still having? I want to try the foreground update but I haven't played any of my games in Jumpgate yet because it had a bunch of issues at the start. Would anyone recommend updating or should I wait until it's more stable? (note: I have a few API, use macros, and made rollable tables)
I would suggest making a copy of your game then converting the copy to jumpgate and giving it a try but keeping the original just in case.
I wish I had done that.
The principle issues I have have been
Breaches through dynamic lighting barriers when in explorer mode (though update Vision on token Drop seems to have stopped this at the moment)
I had an issue with duplicated tokens, moving one but a ghost token remained in place (this only happened to me once)
Elements on the map level disappearing. That's happened a few times.
Slow map loads