Jump to content

Search In
  • More options...
Find results that contain...
Find results in...

Search the Community

Showing results for 'overwrite'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


  • GreenSock Forums
    • GSAP
    • Banner Animation
    • Jobs & Freelance
  • Flash / ActionScript Archive
    • GSAP (Flash)
    • Loading (Flash)
    • TransformManager (Flash)

Product Groups

  • Club GreenSock
  • TransformManager
  • Supercharge


There are no results to display.

Find results in...

Find results that contain...

Date Created

  • Start


Last Updated

  • Start


Filter by number of...


  • Start



Personal Website



Company Website



  1. When a tween renders for the first time, it records the starting and ending values internally so that it can interpolate between them SUPER fast (we obsess about performance around here). If, for example, your element's "x" is 0 when you created that tween and itemWidthRef.current is 500, then of course it would record that internally and start animating from 0 to 500. If the window resizes halfway through that tween, nothing changes for GSAP. There's no way it could possibly know that itemWidthRef.current changed since you fed it in as a string anyway. Plus it would significantly degrade performance if it had to check that end value on every tick and re-configure the interpolation. So it'll just keep going with the original values, ending at 500 as requested. So if you want to alter where that element is animating to when the window resizes, you can do any of the following: Create a new tween accordingly with the new end value. Simple and clean. It's best to set overwrite: "auto" or overwrite: true so that the old one doesn't keep running and conflict. invalidate() the original tween to force it to flush its start/end values and re-record them on the very next render. You'd also need to use a function-based value to make it dynamic, like x: () => "+=" + itemWidthRef.current. Also beware that if you want to keep the starting values, you'd of course need to rewind that tween before you invalidate() it so that it reverts to the starting values and thus when it re-records, those remain. Otherwise it'll use the current value as the starting value (like any normal tween does). You can also record the progress value if you want, and then re-apply it after you invalidate() so that things appear more seamless mid-tween. Does that help? If you still need some assistance, a minimal demo is the best next step. Happy tweening!
  2. In JSFiddle, what I have built works like a charm(timeline with boxes that fade in from left/right). This was copied from a previous website I Have created and it worked perfect there as well. However, for some reason on another website it simply won't work. The error thrown is the overwrite error and I simply can't understand why it won't work considering it's literally the same. Done with ScrollMagic, GSAP, jQuery. https://goo.gl/JeUiEE
  3. I have one page scroll functionality. On scroll page jumps to top from random position. Sorry I'm without codepen right now. Maybe have you quick answer and you met this problem before? The link https://emelya.studio/storage/frame/ I'm scrolling with this code: function goToSection(panel, anim) { gsap.to(window, { scrollTo: {y: panel, autoKill: false}, duration: 2, overwrite: "auto", onComplete: () => { enableScroll(); } }); } gsap.utils.toArray(".map-slide-trigger").forEach((panel, i) => { ScrollTrigger.create({ trigger: panel, onEnter: () => goToSection(panel) }); ScrollTrigger.create({ trigger: panel, start: "bottom bottom", onEnterBack: () => goToSection(panel) }); });
  4. It's just a logic issue in your code - you're creating conflicting tweens that are fighting to control the same properties of the same object simultaneously. Your "out" tweens are only 0.3 seconds long, but your "in" tweens are 1 second long, thus think about what would happen if someone scrolls quickly. The "in" tween starts fading the element in, and then perhaps 0.1 seconds later you create ANOTHER tween that's fading the element out. So both tweens are running at the same time, fighting each other but the last one "wins". Then, when the fade-out finishes in this case, the fade-in still has 0.6 seconds left!! Thus it continues and you see the element finish fading in. GSAP is doing what it's supposed to do. All you'd need to do to fix this is set overwrite: true on your tweens (or you could do overwrite: "auto" but I think in this case it's cleaner/faster to just do true). https://codepen.io/GreenSock/pen/c51e08b1b31942b6a075181751836b6f?editors=0010 Side note: there's no reason to set scrub: true on your ScrollTrigger because that only applies if you actually have the ScrollTrigger controlling an animation. In your case, you don't. It's not hurting anything, but it's just unnecessary to have there. Happy tweening!
  5. Hey samlinck. This is because your tweens are in conflict with each other. Usually it's good to create animations beforehand but in this case it probably makes more sense to create a new animation each time an item is entered or left. If you do this you should make sure to overwrite the older animations: https://codepen.io/GreenSock/pen/NWRaxRW?editors=0010
  6. As the author of GSAP I'm sometimes asked if the Web Animations API (WAAPI) will be used under the hood eventually. My responses have gotten pretty long so I thought I'd share my findings with everyone here. Hopefully this sheds light on the challenges we face and perhaps it can lead to some changes to WAAPI in the future. WAAPI is a native browser technology that's similar to CSS animations, but for JavaScript. It's much more flexible than CSS animations and it taps into the same mechanisms under the hood so that the browser can maximize performance. Overall support is has gotten pretty good but there are multiple levels to the spec, so some browsers may support only "level 1", for example. The hope is that eventually all major browsers will support WAAPI fully. Progress in that direction has been very, very slow. You could think of WAAPI almost like a browser-level GSAP with a bunch of features stripped out. This has led some to suggest that perhaps GSAP should be built on TOP of WAAPI to reduce file size and maximize performance. Ideally, people could tap into the rich GSAP API with all of its extra features while benefiting from the browser's native underpinnings wherever possible. Sounds great, right? Unfortunately, WAAPI has some critical weak spots that make it virtually impossible for GSAP to leverage it under the hood (at least in any practical manner). I don't mean that as a criticism of WAAPI. In fact, I really wanted to find a way to leverage it inside GSAP, but I'll list a few of the top reasons why it doesn't seem feasible below. To be clear, this is NOT a feature comparison or a bunch of reasons why GSAP is "better" - these are things that make it architecturally impossible (or very cumbersome) to build GSAP on WAAPI. Custom easing WAAPI only supports cubic-bezier() for custom easing, meaning it's limited to one segment with two control points. It can't support eases like Bounce, Elastic, Rough, SlowMo, wiggle, ExpoScaleEase, etc. GSAP must support all of those eases plus any ease imaginable (unlimited segments and control points - see the CustomEase page). This alone is a deal-breaker. Expressive animation hinges on rich easing options. Independent transform components The most commonly animated values are translation (x/y position), rotation, and scale (all transform-related) but you cannot control them independently with CSS or WAAPI. For example, try moving (translate) something and then halfway through start rotating it and stagger a scale toward the end: |-------- translateX() ------------| |------ rotate() ------| |---------- translateY() -----------| |-------------- scale(x,y) --------------| Animators NEED to be able to independently control these values in their animations. Additive animations (composite:"add") probably aren't an adequate solution either. It's unrealistic to expect developers to track all the values manually or assume that stacking them on top of each other will deliver expected results - they should be able to just affect the rotation (or whatever) at any time, even if there was a translate() or scale() applied previously. GSAP could track everything for them, of course, but continuously stacking transforms on top of each other seems very inefficient and I imagine it'd hurt performance (every transform is another matrix concatenation under the hood). There is a new spec being proposed for translate, scale, and rotate CSS properties which would certainly help, but it's not a full solution because you still can't control the x/y components independently, or all of the 3D values like rotationX, rotationY, z, etc. This is an essential feature of GSAP that helped it become so popular. Example See the Pen Independent Transforms Demo by GreenSock (@GreenSock) on CodePen. Custom logic on each tick Certain types of animations require custom logic on each tick (like physics or custom rounding/snapping or morphing). Most GSAP plugins rely on this sort of thing (ModifiersPlugin, for example). I'm pretty sure that's impossible with WAAPI, especially with transforms being spun off to a different thread (any dependencies on JS-based logic would bind it to the main thread). Non-DOM targets As far as I know, WAAPI doesn't let you animate arbitrary properties of generic objects, like {myProperty:0}. This is another fundamental feature of GSAP - people can use it to animate any sort of objects including canvas library objects, generic objects, WebGL values, whatever. Global timing controls I don't think WAAPI lets you set a custom frame rate. Also, GSAP's lag smoothing feature requires the ability to tweak the global time (not timeScale - I mean literally the current time so that all the animations are pushed forward or backward). As far as I know, it's impossible with WAAPI. Synchronization (transforms and non-transforms) As demonstrated in this video, one of the hidden pitfalls of spinning transforms off to another thread is that they can lose synchronization with other main-thread-based animations. As far as I know, that hasn't been solved in all browsers. We can't afford to have things getting out-of-sync. Some have proposed that GSAP could just fall back to using a regular requestAnimationFrame loop to handle things that aren't adequately supported by WAAPI but that puts things at risk of falling out of sync. For example, if transforms are running on a separate thread they might keep moving while other parts of the animation (custom properties that get applied somehow in an onUpdate) slow down or jank. Compatibility GSAP has earned a reputation for "just working" across every browser. In order to deliver on that, we'd have to put extra conditional logic throughout GSAP, providing fallbacks when WAAPI isn't available or doesn't support a feature. That would balloon the file size substantially and slow things down. That's a tough pill to swallow. WAAPI still isn't implemented in several major browsers today. And then there are the browser inconsistencies (like the infamous SVG origin quirks) that will likely pop up over time and then we'd have to unplug those parts from WAAPI and maintain the legacy raw-JS mechanisms internally. Historically, there are plenty of cross-browser bugs in natively-implemented technologies, making it feel risky to build on top of. Performance WAAPI has a performance advantage because it can leverage a separate thread whereas JavaScript always runs on the main thread, right? Well, sort of. The only time a separate thread can be used is if transforms and/or opacity are the only things animating on a particular element (or else you run into synchronization issues). Plus there's overhead involved in managing that thread which can also get bogged down. There are tradeoffs either way. Having access to a different thread is fantastic even if it only applies in certain situations. That's probably the biggest reason I wanted to leverage WAAPI originally, but the limitations and tradeoffs are pretty significant, at least as it pertains to our goals with GSAP. Surprisingly, according to my tests GSAP was often faster than WAAPI. For example, in this speed test WAAPI didn't perform as well as GSAP on most devices I tried. Maybe performance will improve over time, but for now be sure to test to ensure that WAAPI is performing well for your animations. File Size To ensure compatibility, GSAP would need all of its current (non-WAAPI) code in place for fallbacks (most browsers won't fully support WAAPI for years) and then we'd need to layer in all the WAAPI-specific code on top of that like conditional logic checking for compatible eases, sensing when the user is attempting something WAAPI can't support, tracking/stacking additive animations, etc. That means file size would actually be far worse if GSAP were built on WAAPI. Some have suggested creating a different adapter/renderer for each tech, like a WebAnimationsAdapter. That way, we could segregate the logic and folks could just load it if they needed it which is clever but it doesn't really solve the problem. For example, some plugins may affect particular CSS properties or attributes, and at some point conditional logic would have to run to say "oh, if they're using the WebAnimationsAdapter, this part won't work so handle it differently". That conditional logic generally makes the most sense to have in the plugin itself (otherwise the adapter file would fill up with extra logic for every possible plugin, bloating file size unnecessarily and separating plugin logic from the plugin itself). So then if anyone uses that plugin, they'd pay a price for that extra logic that's along for the ride. Weighing the Pros & Cons At the end of the day, the list of "pros" must outweigh the "cons" for this to work, and currently that list is quite lopsided. I'd love to find a way to leverage any of the strengths of WAAPI inside GSAP for sure, but it just doesn't seem feasible or beneficial overall. The main benefit I see in using WAAPI inside GSAP is to get the off-the-main-thread-transforms juice but even that only seems useful in relatively uncommon scenarios, and it comes at a very high price. I'm struggling to find another compelling reason to build on WAAPI; GSAP already does everything WAAPI does plus a lot more. I'm hopeful that some of the WAAPI benefits will someday be possible directly in JS so that GSAP wouldn't have to create a dependency on WAAPI to get those. For example, browsers could expose an API that'd let developers tap into that off-the-main-thread transform performance. Ideally, browsers would also fix that hacky matrix()/matrix3d() string-based API and provide a way to set the numeric matrix values directly - that'd probably deliver a nice speed boost. Please chime in if I'm missing something, though. (Contact us or post in the forums) Why use GSAP even if/when WAAPI gets full browser support? Browser bugs/inconsistencies Lots of extra features like morphing, physics, Bezier tweening, text tweening, etc. Infinite easing options (Bounce, Elastic, Rough, SlowMo, ExpoScaleEase, Wiggle, Custom) Independent transform components (position, scale, rotation, etc.) Animate literally any property of any object (not just DOM) Timeline nesting (workflow) GSDevTools Relative values and overwrite management from() tweens are much easier - you don't need to get the current values yourself Familiar API Why WAAPI might be worth a try If you don’t need broad browser support today or any of GSAP’s unique features, you could save some kb by using WAAPI Solid performance, especially for transforms and opacity Always free Again, the goal of this article is NOT to criticize WAAPI at all. I think it's a great step forward for browsers. I just wanted to explain some of the challenges that prevent us from using it under the hood in GSAP, at least as it stands today. EDIT: Brian Birtles, one of the primary authors of the WAAPI spec, reached out and offered to work through the issues and try to find solutions (some of which may involve editing the spec itself) which is great. Rachel Nabors has also worked to connect people and find solutions. Although it may take years before it's realistic to consider building on WAAPI, it's reassuring to have so much support from leaders in the industry who are working hard to move animation forward on the web. 2020 EDIT: Now Brian Birtles is the only one working on WAAPI and he does so on a volunteer basis, so further development of WAAPI has understandably slowed down in recent times.
  7. Welcome to the forums and the wonderful world of GSAP, @miketwalker. You just need to base your timing off the number of elements you're staggering. Here's a corrected fork of your codepen: https://codepen.io/GreenSock/pen/2cebe760d96fd703c4a19002bf415d86?editors=0010 And there's an alternate approach that uses keyframes and a loop in there in case that seems more intuitive for you. Either one is fine. It's just that in some cases, it can get a little mind-bending to work out lots of timing stuff in multiple staggered animations on the same elements so it can make more sense to just do one sequence at a time, and lay those out individually on a timeline chunk by chunk. There are actually lots of ways you could approach this. Here's one more that uses a modular function so you can just focus on one at a time: function test() { var div = gsap.utils.toArray(".textdiv"), stagger = 2, tl = gsap.timeline(); // loop through and for each element, feed it to slideDown and insert the resulting animation into the timeline in a staggered way div.forEach((el, i) => tl.add(slideDown(el), i * stagger)); } function slideDown(element) { var tl = gsap.timeline(); gsap.set(element, {xPercent:-50, left:"50%", opacity: 0, yPercent:100, top:"0%", position: "absolute", overwrite: true}); tl.to(element, {opacity: 1, duration: 2}) .to(element, {yPercent: -100, top: "100%", duration: 12, ease: "none"}, 0) .to(element, {opacity: 0, duration: 2}, "-=2"); return tl; } Happy tweening!
  8. Yes - sure does. I figured this was probably an edge case given GSAP's user base and the fact I couldn't see anything on it. Now I know what to look for I wont have the same issue in future. Understand and agree it probably doesn't warrant addition in the doc's. Hopefully if (in the unlikely event) someone manages to repeat my mistake googling: Keywords: added properties delay duration ease overwrite repeat will lead them to this explanation anyway. Thanks for the reponses everyone.
  9. Hi, I wouldn't consider it a bug. Keep in mind that a zero duration tween is not a distinctive GSAP instance on it's own, just a regular GSAP instance with duration zero. The .set() method is just a shortand/convenience in order to make it easier on developers to write, read and maintain code, because once you get used to the API it's simpler to understand this: gsap.set(element, {config}) than this: gsap.to(element, {duration: 0, config}), if another developer in a team looks at the second example the first thing is: Why this animation has a duration of 0 seconds? If the set() method is confusing the dev can come to the API docs, check it and realize that it creates a zero seconds tween. With that in mind and not knowing all the ins and outs of the codebase, perhaps that this happens in one of this places in the code: https://github.com/greensock/GSAP/blob/master/src/gsap-core.js#L307-L352 https://github.com/greensock/GSAP/blob/master/src/gsap-core.js#L1115-L1130 Or somewhere else ... Now I have used several times the approach you're using of creating a re-usable config object, but I never took the time to inspect it after GSAP used it, because it never led to any unexpected behaviour. Keep in mind that most commonly objects are passed by reference so given the parts of the code I linked above is quite expected that the original object would be modified. Is this modification leading to some issue in your code? I'd expect that if you overwrite any of the properties added by GSAP the one that you add would take precedence over the ones added by GSAP since those are there just as defaults. Finally I believe that either @GreenSock or @ZachSaucier are in a better position to give you a more "official" answer. Happy Tweening!!!
  10. Hello GSAP forum! This is my first thread, hope I post it within the rules around here. I've been using GSAP for quite a while now, but there are still a lot of aspects that I couldn't comfortably say I've figured them all out. Such as overwrite, invalidate, restart, stop, seek and so on... I've been reading docs, search on Google, forum post etc, I still can't figure out the most simple things. Question: In the codepen sample, what should I do so whenever I click on buttons the line goes to left or right from wherever it is when the button is clicked. Multiple times. I seriously couldn't figure it out. Any help would be appreciated. Thank you
  11. You can just animate the progress. And you don't need to use a timeline - just use a simple fromTo() tween for each direction: https://codepen.io/GreenSock/pen/5bab7669c11ef8400b5b56f5939d2d59?editors=0010 Is that what you mean? Just don't forget the overwrite: true on at least one of the tweens, otherwise you'll create a bunch of overlapping/competing tweens on each mouse movement. Happy tweening!
  12. Hi everybody! I've been reading all the threads in the search results and reviewing documentation but I'm just really new to this, green you might say. I'd like to disable the left/right animation on mobile or if it's easier, disable all of them if I can't isolate them. It might look really stupid reading what I've done below but I'd love some help please if possible. I just don't know what I'm doing. Thanks in advance! ScrollTrigger.saveStyles(".gs_reveal_fromLeft, .gs_reveal_fromRight, .gs_reveal"); ScrollTrigger.matchMedia({ // desktop "(min-width: 800px)": function() { //Reveal Animations Scrolltrigger function animateFrom(elem, direction) { direction = direction | 1; var x = 0, y = direction * 100; if(elem.classList.contains("gs_reveal_fromLeft")) { x = -100; y = 0; } else if(elem.classList.contains("gs_reveal_fromRight")) { x = 100; y = 0; } gsap.fromTo(elem, {x: x, y: y, autoAlpha: 0}, { duration: 1.25, x: 0, y: 0, autoAlpha: 1, ease: "expo", overwrite: "auto" }); } }, // mobile "(max-width: 799px)": function() { return function() { gsap.kill(); // other cleanup code can go here. }; } }, // all "all": function() { function hide(elem) { gsap.set(elem, {autoAlpha: 0}); } document.addEventListener("DOMContentLoaded", function() { gsap.registerPlugin(ScrollTrigger); gsap.utils.toArray(".gs_reveal").forEach(function(elem) { hide(elem); // assure that the element is hidden when scrolled into view ScrollTrigger.create({ trigger: elem, onEnter: function() { animateFrom(elem) }, onEnterBack: function() { animateFrom(elem, -1) }, onLeave: function() { hide(elem) } // assure that the element is hidden when scrolled into view }); }); }); } );
  13. thank you for your feedback @ZachSaucier Something like that i was waiting for yep i really have to learn the full power of gsap to not fall back to jquery without any need of it - actually while reading your feedback i have no clue, what i could address to gsap instead of jquery but i will check that this is a good point, will also check that - btw. i meantioned to not have an idea, how to react on window resize. Is the only way to overwrite the whole timelime to change vh and vw used in the timeline? how to get timeline direction without asking timeline._ts? ok - i saw both on my readings and string form felt wrong in any way what do you mean? again jquery? or what is this related to? is there any special you would to address to ES6? as i have to support IE11 i cant use ES6 - does i?
  14. Hey guys! I have been lurking the forum since last few days. I have found a lot of useful information thanks for the great support. I am looking to smoothen the animation in my codepen by doing following: - fasten the timescale of tweens when 'onmouseover' so the div stop quickly but gracefully - Also smothen the tweening overwrite happening while moving the cursor fast I think the best way would be to use a timeline to update timescale but I am having trouble to figuring that out. Thanks in advance
  15. Thanks! Feared so. What is `overwrite: 'auto'` doing in your scrollTween? Also thanks for the idea of killing the tween when `wheel` event is triggered.
  16. So I'm implementing a smooth scroll like this: useEffect(() => { const container = document.querySelector(".scroll-container"); document.body.style.height = container.scrollHeight + "px"; const onScroll = () => { gsap.timeline() .to(".scroll-container", { y: -pageYOffset, overwrite: "auto" }, 0) } document.addEventListener("scroll", onScroll) }, []) The smooth scroll is working fine, but its height is not being calculated properly. In other words, the scrollHeight I get from the container, won't be enough to scroll the whole container using smooth scroll. How do I calculate the height I need for smooth scroll?
  17. Hey Pata. Tweens aren't meant to be changed too much after they have been created. Instead of creating a ScrollTrigger with an animation attached to it, I'd create a ScrollTrigger with no animation and then create a new tween inside of the onEnter. Something like this (untested): ScrollTrigger.create({ trigger: '#footer', start: 'top bottom', toggleActions: 'play pause resume reset', onEnter: self => { const velocity = self.getVelocity(); const variation = velocity / 10000; const footerBounce = gsap.to('#down', { duration: 2, morphSVG: '#up', ease: `elastic.out(${1 + variation}, ${1 - variation})`, overwrite: 'auto' // make sure old tweens are killed }) } })
  18. Another alternative is to use a completely different approach: Position the cursor element in the center of the pink element. Set its scale to 0. In the mouseenter of the pink section, animate the cursor element's scale to its normal scale. In the mousemove of the pink section, animate the position of the cursor to the mouse position. Make sure to overwrite any animations affecting the position of the cursor element. In the mouseleave of the pink section, animate the cursor element's scale back to 0 and its position back to 0, 0.
  19. Hey Coopski and welcome to the GreenSock forums. You're making one of the most common ScrollTrigger mistakes: nesting ScrollTrigger in tweens within a timeline. Doing so doesn't make much sense because the timeline and the ScrollTrigger try to control the animation. Once you fix that, you still have a logical error though: since your ScrollTrigger start point is before the initial scroll position, both your start animation and your ScrollTrigger are trying to set the value at the same time so one will overwrite the other. You probably want to wait to create the ScrollTrigger until after the load animation has finished. To prevent the jump in state caused by the initial scroll position affecting the ScrollTrigger, you could use a numerical scrub. Something like this: https://codepen.io/GreenSock/pen/mdEKYgE?editors=0010
  20. Hey @imChris, It could be a questions of positioning (more here) e.g. try timeline.to(boxInner, { x: sectionMovement.getAttribute('data-x'), ease: animationEase, //overwrite: 'auto' },0) Happy precise timing ... Mikel
  21. Hey Zach, Superb! That's exactly the effect I was looking for -- and has also given me a couple of new pointers for the future too. It makes total sense - I wasn't aware you could a) attach a tween to the onEnter/onLeaveBack calls in that way and b) hadn't properly grasped the impact/usage of the "overwrite:true" prop to kill the tween either. I'll make sure I do some reading around that one Many thanks (again!). Cheers!
  22. Okay, thanks again for your help. Looking at this a bit more, I agree with you on the necessity of the overwrite because I'm not really seeing a way around that. I may end up going that direction.
  23. Unfortunately we don't have the capacity to make every edge case meet your needs. I would say the overwrite is pretty necessary to prevent the conflicts. Best of luck getting it working the way you need it to be working!
  24. Thanks for your reply and suggestions, Zach! Much appreciated. Those changes have brought me very close to a solution. On touch devices, I am still having a few issues, however. Basically, if the Draggable section is part way in the viewport, and the user tries to grab it and scroll back up, Draggable events are firing and the user can't really scroll up normally. I messed around with a few options using the deltas and Draggable.enable()/disable(), but can't quite get it - basically I would need a way to disable Draggable if the user is scrolling vertically. As a side note, I did have to remove the overwrite: 'auto' on the updateProxy function or else that will kill the inertia movements. And related to that, when inertia movements are still going and a touch user tries to grab the screen to stop, a bunch of flickering starts happening as the native scroll position and the inertia movements are fighting. I suppose this is where the overwrite would come in handy, but I would really like to have the inertia preserved if possible - do you happen to have any additional ideas on that? Thank you again for your help!
  25. Hi Zach, Thanks for the reply. I stripped out everything and was finally able to pinpoint the issue to a gsap default setting of `overwrite: true`. The docs say: If true, all tweens of the same targets will be killed immediately regardless of what properties they affect. If "auto", when the tween renders for the first time it hunt down any conflicts in active animations (animating the same properties of the same targets) and kill only those parts of the other tweens. Non-conflicting parts remain intact. If false, no overwriting strategies will be employed. Default: false. Not really sure I understand how this applies to my case, but anyway, I'm glad I finally figured this out. Thank you for the suggestion.