What's Best Practices for Toggling Objects On & Off?

Whenever I need to toggle sandbox objects on or off temporarily, I do it by switching them to the "walls" layer and back again, turning my "walls" layer into a sort of storage area for assets I'm not currently using. I've been doing this for years now and it never occurred to me to ask if there's a better way (ideally one that won't interfere with people using the walls layer for lighting, since I'm branching into developing a few scripts for community release so I want to make sure my toggling method works for everyone)!  How do you toggle your sandbox objects?

I use the Bump script for tokens, and token-mod to move map things to the back of the map layer. Though the DL layer sounds like a better idea.

Your method sounds fine, just keep in mind that if the token emits light, it'll still emit light from the DL layer.

i'm not sure if i understood right, but i just move tokens between layers via hot keys (e.g. lo to move to object layer).  for hiding tokens from players, i just move them to GM layer.  that's what it's there for.

aisforanagrams said: i'm not sure if i understood right, but i just move tokens between layers via hot keys (e.g. lo to move to object layer).  for hiding tokens from players, i just move them to GM layer.  that's what it's there for. The GM Layer is there for more than just storage:  It's where I put various notes and text object alerts that only I should see, with the gm layer opacity set to something above zero. Currently, my plan is to allow users to configure which layer is used for temporary storage:  "walls" by default, with a note that if they change it to "gmlayer" they'll want to reduce the opacity to zero to avoid cluttering up their screen!

Eunomiac said: aisforanagrams said: i'm not sure if i understood right, but i just move tokens between layers via hot keys (e.g. lo to move to object layer).  for hiding tokens from players, i just move them to GM layer.  that's what it's there for. The GM Layer is there for more than just storage:  It's where I put various notes and text object alerts that only I should see, with the gm layer opacity set to something above zero. sure, but the point is you can use it to "store" tokens not currently being used.  i do this generally since with DL layer, it can affect the lighting AND you can't see the tokens unless you're in DL layer (which is a pain if you want to quickly locate it).  i even use the GM layer to move pieces of DL walls that i want to reveal.  GM layer is versatile and is completely invisible to the players (with DL layer this isn't true since tokens CAN affect lighting).

You can also move the object outside of the map, on the same layer. Then they won't be displayed, but still be there. It requires API scripting to do that and get them back, of course.

aisforanagrams said: Eunomiac said: The GM Layer is there for more than just storage:  It's where I put various notes and text object alerts that only I should see, with the gm layer opacity set to something above zero. sure, but the point is you can use it to "store" tokens not currently being used.  i do this generally since with DL layer, it can affect the lighting AND you can't see the tokens unless you're in DL layer (which is a pain if you want to quickly locate it).  i even use the GM layer to move pieces of DL walls that i want to reveal.  GM layer is versatile and is completely invisible to the players (with DL layer this isn't true since tokens CAN affect lighting). Yep, but in my case (where none of my tokens use light and I don't use path objects), the walls/lighting layer really is ideal storage.  I too use the GM layer to store assets I want to reveal or access manually; the walls/lighting layer is strictly used for objects I control via API scripts:  I simply have toggle() functions that switch the layer to "walls" (if toggling off) or back to its active layer (set in the object's registry entry in my state variable). However, because I'm now considering polishing some of my scripts up for community release, I wanted to see if there were better options that would work for players who do make use of the lighting layer. Currently, if my understanding is correct, it is safe to store absolutely anything on the "walls" layer except: graphic token (i.e. non-drawing) objects that emit light path objects For the former, I'll disable any light emission when toggling tokens off, and store their "active lighting" settings in their registry entry so I can restore them when toggling the object back on. For paths, I'll just record all of the data defining the path (color, points, etc) and destroy it on toggle off/recreate it on toggle on.   If I combine that with a "temporarily move all toggled-off objects from the walls layer to the gmlayer so you can work on your dynamic lighting stuff in peace" function, I think I've covered all my bases. Laurent said: You can also move the object outside of the map, on the same layer. Then they won't be displayed, but still be there. It requires API scripting to do that and get them back, of course. I'm up to 40,000 lines of custom code over 21 API scripts, so scripting is no problem --- quite the opposite, lol.   I considered your method, but the problem is I'm unsure how/when Roll20 and various browsers load images.  I'm fairly certain that images stored on the walls layer will not be loaded by the browser (which is a good thing, as there are a lot of graphic and text objects stored there, including several webm animations), but I'm not so sure that shifting the images so they exist outside the pixel bounds of the sandbox will stop browsers from loading them.  Do you happen to know?

I am pretty sure that all images on a map are loaded at page load regardless of layer. You could check this pretty easily by seeing if there's a delay between first switching to the DL layer and the images showing up.

Scott C. said: I am pretty sure that all images on a map are loaded at page load regardless of layer. You could check this pretty easily by seeing if there's a delay between first switching to the DL layer and the images showing up. Really?  I'll have to double-check, but I'm pretty sure my computer grinds to a halt when I actually switch to the walls layer --- maybe webm animations, or the whole painting aspect of drawing the web page, is what takes the extra time as opposed to the images being loaded. Is there anyone I can ask, or anywhere I can turn to, for definitive answers on these sorts of questions? Someone had to code Roll20, after all!  Do they make any appearances in any of the forums?

WebM files slow down your browser when they are playing, particularly if there are a bunch of them.  To a lesser extent, images being displayed take up some processing power.  Images that are downloaded to the local cache won't have a direct impact on performance if they aren't currently displayed, only on page load time, and only if they haven't already been cached.

The Aaron said: WebM files slow down your browser when they are playing, particularly if there are a bunch of them.  To a lesser extent, images being displayed take up some processing power.  Images that are downloaded to the local cache won't have a direct impact on performance if they aren't currently displayed, only on page load time, and only if they haven't already been cached. Could you please clarify what you mean by "currently displayed"?  Which, if any, of the following would qualify, such that the asset in question would be loaded and consume system resources? A webm or image file on the walls layer A webm or image file on the gmlayer (for players' clients; obviously this would be loaded for the GM) A webm or image file on the objects or map layer, but repositioned outside the sandbox boundaries (i.e. obj.set({left: -1000, top: -1000}) ) A webm or image file on the objects or map layer, but positioned behind and fully obscured by an opaque jpeg image via z-index I feel like this is something I could test, but I recently watched a "debugging performance with Chrome Dev Console" tutorial and my head started spinning when they went into painting cycles and even further into the weeds, so I fear any attempt on my part would result in an imperfect answer at best, likely because I failed to account for some aspect of asset/page loading!

I don't know if we know for sure about the player ones, but for the gm all of them definitely apply. And I'd guess that they all apply for players as well. The whole page is loaded when you go to the page. Full stop.