Roll20 uses cookies to improve your experience on our site. Cookies enable you to enjoy certain features, social sharing functionality, and tailor message and display ads to your interests on our site and others. They also help us understand how our site is being used. By continuing to use our site, you consent to our use of cookies. Update your cookie preferences .
×
Advertisement Create a free account

API: sendPing doesn't scroll for non-gms

1535040875

Edited 1535994772
Detailed description of the problem (Previously reported Here , and Here ) Alright since I can't add to the previous bug report threads I'll go into excruciating detail here. The API function sendPing doesn't center all players views on the ping regardless of whether or not the moveAll argument is true. It works as intended if the player viewing the ping is a GM but not for normal players. The underlying issue is twofold, 1. The API doesn't send a 'currentLayer' property in the shout event that triggers the receiveMapping update. A real ping on the table sends the current layer in the event, the API does not. Screenshot of the two different event objects (little e) here: 2: These event objects get processed by d20.engine.receiveMapping and are checked with the following ("objects" === e.currentLayer || "map" === e.currentLayer || window.is_gm) which is (presumably) designed so that pings to layers will only only move players who have access to that layer. Everyone can see objects and map, otherwise you have to be a gm. Since the API Ping doesn't send a "currentLayer" the logic follows that the current layer is not "objects" or "map" so you'll only be moved if your view is using a GM player. Minimum number of steps to reproduce the problem -Use a sendPing() function with the API -Be a non-GM -Don't get moved to ping Description of setup Chrome 68 Broken with/ without plugins Windows 10 Proposed Solution(s) [Any should work] -API for sendPing could include a layer the ping will be emulated as -API for sendPing could default to 'objects' -d20.engine.receiveMapping logic could be changed to ("objects" === e.currentLayer || "map" === e.currentLayer || !e.currentLayer || window.is_gm) To take advantage of short circuiting and the likelihood that the most common types of pings are objects > map > API > other. Proposed workarounds - Wiki should be updated in meantime to warn GMs who may accidentally spend an entire Tuesday programming a feature for it to only work on 1/6 players -javascript could theoretically be injected clientside with a bookmarklet. It could theoretically look like this. If such a solution were to be used, every client not a GM would have to run the bookmarklet. javascript:(function()%7BJSON.parse2%20%3D%20JSON.parse%3BJSON.parse%20%3D%20function(e)%20%7Bvar%20intercept%20%3D%20JSON.parse2(e)%3Bif%20(intercept.type%20%3D%3D%20'mapping')%20%7Bintercept.currentLayer%20%3D%20'objects'%3Bif%20(intercept.pageid%20!%3D%20Campaign.activePage().id)intercept.scrollto%20%3D%20false%3B%7Dreturn%20intercept%3B%7D%7D)() (I wanted a more elegant solution but I've run out of dev time for the day).
1535046697
Stephanie B.
Forum Champion
Sheet Author
Hi, thanks for your report. This is a known issue, and I'll be sure to add your thorough troubleshooting to the ticket. This should help speed the process of fixing it.
1535994518

Edited 1537032869
I would like to add additional notes I've noticed now that I have the feature working locally. The moveall/ scrollto tag doesn't respect pageid. If players are on separate pages they will get pulled to the same coordinates on their respective pages. I imagine this is not usually a problem people would notice and haven't seen any previous bug reports about it. Should I make a separate post with more details or are these similar enough issues for them to be merged together? Regardless, I added this fix to a compilation of tweaks to the client that can be found here.