Calsa

Maybe I missed it in the documentation, but was this ever added to the official GS codebase with a different function name, or do we still need to include this function to use it? I know there is a killTweensOf, but it does not seem to propagate down to children. My goal being to call this on the master node of an SVG group and kill all children when reloading page sections. I rather not include extra code, if a native function is already hiding somewhere in GS.

So, I am trying my first timeline and wanted to make sure I am not starting out with bad habits. Can I just get some critique, pointers on coding style and techniques to optimize? This compiles fine in TS and visually works - and actually fixes the opacity bug I was asking about here, but the style looks strange to me. It is lot more code than just discretely setting delay for each element and using fromTo's as I was doing before transitioning to a timeline based method.

Firing GreenSock fromTo for: #nk_title_1 . Opacity Changing to: 0 nurkle.ts:516 Firing GreenSock fromTo for: #nk_title_4 . Opacity Changing to: 0 nurkle.ts:516 Firing GreenSock fromTo for: #nk_title_5 . Opacity Changing to: 0 nurkle.ts:516 Firing GreenSock fromTo for: #nk_title_89 . Opacity Changing to: 0 nurkle.ts:516 Firing GreenSock fromTo for: #nk_title_28 . Opacity Changing to: 0.9933 nurkle //Next Tick Firing GreenSock fromTo for: #nk_title_1 . Opacity Changing to: 0 nurkle.ts:516 Firing GreenSock fromTo for: #nk_title_4 . Opacity Changing to: 0 nurkle.ts:516 Firing GreenSock fromTo for: #nk_title_5 . Opacity Changing to: 0 nurkle.ts:516 Firing GreenSock fromTo for: #nk_title_89 . Opacity Changing to: 0 nurkle.ts:516 Firing GreenSock fromTo for: #nk_title_28 . Opacity Changing to: 0.9966 Console reports they are completing their tween, firing every frame as they should. They just don't update their opacity value. I left in the debug so the live console reports on the dev domain show this happening. One element is indeed transitioning, the others are found, initial value is set by GS to 0 opacity, but they then just don't transition. It's odd, as if I remove elements from the list of callouts, its always only the last that successfully transitions, all others stay frozen at 0 opacity even though they are set in the from part of the fromTo. Question: Is there a way to see, or even manually step through a global timeline to see what is being executed across all timelines tick by tick? This is more of a general question for future debugging. I don't set opacity in CSS or through GS opacity on anything else up the DOM tree. Clearly I am doing something dumb here as there is not much way to bork up the fromTo. So just looking for ways to better debug on my own under the hood of GS. Yeah I get that, I am grasping at this point too. As this should be a very simple thing. And yes, I actually started out with opacity before discovering GS had an autoAlpha which is your equivalent to fadeIn() fadeOut() in jquery - which btw does work. I was trying to migrate all animations to GS as the DrawSVG was a component I needed but did not want to build myself and I did not want a mix of frameworks controlling animations, though at this point somewhat regretting that decision Ah, I left that in by accident when I went to bed, I was checking on something and wanted to see what would come out with a bad ID was given to GS, Sorry for the confusion, this is a dev domain not production so I regularly break things when playing. This whole project was driven by me not touching Web Development in about a decade since I headed off overseas to do humanitarian engineering work. I never really did professionally web dev before that, but always liked to dabble. Now that I am back in the western world, and locked down like everyone else, I decided to explore what the state of modern web has become by building something fun. Now I remember why I never wanted to do it professionally OK so other things I tried I removed all other GS animations to make sure they did not conflict... no change I can verify without GS visibility is full on (so we do fire the initial from part of a fromTo autoAlpha which sets all elements to Opacity:0) I can make any one object transition by making sure its the last element through the for loop that triggers these animations - so they *can* all work. I can verify the tween fires its update for every frame, but new values are never set. You can now see this yourself in the live console logs. I can verify if I feed a class to the elements, that class transitions as expected - but can't go this route as some elements will eventually be hidden when not in use, but not there yet I can do an utter hack to verify it can be updated within a GS tick by doing gsap.fromTo("nk_title_" + nurkleID, {autoAlpha:0}, {autoAlpha:1, duration:0.5, delay:1.85, onUpdate:() => { console.log("Firing GreenSock fromTo for: #nk_title_" + nurkleID + " . Opacity Changing to: " + document.getElementById( "nk_title_" + nurkleID)!.style.opacity) let ele = document.getElementById("nk_title_" + nurkleID); let opac = ele.style.opacity ele.setAttribute('style', 'opacity:' + (opac + 0.1)); } How is that for a hack to test things ? IDK, it is a weird issue. But I admit hard to troubleshoot as there are only so many fail points in GS and we hit the basics. Though it still feels like is is GS as Jquery .fadeIn() works in the same loop and I can manually force value in plain JavaScript, using the hack above. Anyway, I spent too much time on this seemingly little issue, so I'm going to give it a rest for now unless anyone has any bright ideas. Thanks for trying folks.

Yeah, I get its a massive pain to debug given no codepen. I almost did not post as its a near impossible task to help, and I did not want to come off as too much of a noob. Still, its strange that the initial values set -so divs are found and opacity is set to zero by GS - then the tween just does not fire. I figured maybe someone saw this before.

I am having trouble reproducing this in a codepen, so this will be for general advice to help narrow possibility. I have two fromTo that set opacity of divs gsap.fromTo("#nk_title_" + nurkleID, { autoAlpha:0 }, {autoAlpha:1, duration:0.5, delay:1.85}); // title gsap.fromTo("#nurkle_desc_" + nurkleID, { autoAlpha:0 }, {autoAlpha:1, duration:0.5, delay:1.85}); // description NurkleID is being fed by a for loop. The first nurkleID will fire fine and its fromTo normally. But any additional nurkleID's will only set their from value, but then not transition toward the "to". Oddly, there is no console error and there are many other animations and animations along with these two within that loop structure that have no issue doing fromTo. So the loop does complete each cycle. What sort of things should I be looking for that may cause this, the rest of this animation set behaves exactly like it should. Sorry, I know its frustrating not being able to reproduce it in a codepen so I will keep trying.... You can see it here https://dern.tech/?n=30. Just wait a few seconds for everything to load, I have not got around to a loading screen yet. The one white text label over GeneXpert fully transitions, but all other labels fail to ever appear. Chromes inspector does show them setting opacity to 0, so they fire the "from" part of a fromTo. They just don't then start the transition.

Thanks for the example, comments, and product. Though, I was using jquery for positioning as if you set your X and Y inside GS (this was actually done way up top) the issue does not manifest. It is only if position data is set outside of GS does the issue become noticeable. Jquery was the quickest, and most easy way to simulate what my site is doing, so you could see the issue. At any rate, were all good here. Thanks for the awesome product.

My solution was to stop trying to reinvent the wheel by animating everything in jquery / jscript, and buy GS ? From a noob starting out, its not. Maybe to an admin it is . Maybe add something to SVG tips to help others? I did RTFM first thing but could not find any sort of clue in there this needed to happen. The story of my life.... I do tend to find new and creative ways of breaking software. It is a gift. I think....

You answers what was going on under the hood, but not necessarly how to fix it from a user perspective in that initial post. Technically, I am still cheating a solution by wrapping it in a group, which would not be very intuitive if you only had one element like this example. https://codepen.io/Calsa128/pen/gOLWqmE Any time you apply rotate to a cx,cy coordinate set manipulated outside of GS it seems this behavior will happen (though I am a noob so maybe not?) I may just be an oddball case as most people are likely keep all animation in GS. But IMO it seemed more unexpected that a position cx, cy would be thrown off so much when a simple rotation is applied, given how "smart and easy" the positioning of GS is suppose to be. I still don't understand why positioning was thrown off so much or what exactly it was even using for its position to move like it was. Regardless, if wrapping things in groups gets the job done, good enough for me I suppose. Two days lost on this is enough. Thanks for the help.

https://codepen.io/Calsa128/pen/JjbNBeP That seems to do it. I forgot about groups. Thanks. Just as a followup Q before I mark solution, so this does not get buried and I don't learn from this. Why was that not moving correctly before? Clearly it was a translation issue, but I don't understand why rotate was causing that to happen.

In this Codepen, notice how green/ blue elements center_2 and outer_2 stay in formation, with outer_2 orbiting close to center_2 as their cx and cy are changed? This is what I expect to happen as they both share the same cx, cy points. The red/black is the problem in this example. center_1 and outer_1 also both share a cx and cy point, but the outer_1 is not moving to the same position visually as center_1. The only difference between green/blue, and red/black is that red/black is using a rotate on the outer_1 element: gsap.to("#outer_1", {rotation: 360, transformOrigin:"center", ease: Power0.easeNone, repeat:-1, duration: 1, delay:0.5}); // base https://codepen.io/Calsa128/pen/LYbyyeB How do I still use the rotate, but not have the black outer_1 chunk move randomly about the screen, instead of doing what it should, which is spin around the black center_1 circle as blue/green is doing?

Hmm, I gave it a shot and it still exhibited the same strange behavior. It almost looks like the transform origin remains at the initial point where rotate is called, but the X and Y of the shape expands as the cx and cy property move further away from that fixed origin point. I tried a few things to move the origin itself, but with a similar lack of success. How does GS generate its timelines? Is it all precomputed when you first call a to or fromTo? That would then make sense that the origin remains the same as its not even looking for the X and Y update; or does GS dynamically generate the tween each frame as they are played?

I am using NPM and Typescript. I have a strange issue, and I have stumped myself trying to figure out how to fix it. Somehow using GS to rotate an SVG element is not causing rotation to occur as anticipated when I am moving the cx and cy points of the same SVG circle element. This issue only is noticeable when you are moving the X and Y points of an SVG while also having the rotate: animation applied. If I am applying this animation to a stationary SVG, rotation works fine. Likewise the tracking code to move the cx and cy on my svg elements works fine without rotation applied. It is a combination of the two that seems to cause the problem. Also oddly, it only seems to happen when the cx and cy are modified outside of GS, if using a GS animation to move the x and y, this behavior does not happen. Unfortunately, I am using GS as part of a new GUI that is applying labels to 3d objects moving about in 3d space driven by BabylonJS, so a simple GS X and Y animation wont work. Expected Behavior: The SVG rotates around its center forever even if X any Y coordinates of the SVG were moved Actual Behavior: The object does rotate, but it also seems to have added an unwanted behavior of orbiting the X and Y point where the gsap rotation animation was first called (not the X and Y I am sending it). The radius of the orbit increases as I move the SVG's X and Y further from the 2d spot where the gsap.to was first called, and orbit decays if it is moved closer, eventually lining back up perfect if the 3d animation returns to the exact spot where the gsap was first initialized. (Example Above: A is close to where the rotation was first started, so its outer spinning shape is orbiting the center circle close, B is really far from where the animation was initially started so the piece being rotated has a massive super fast orbit, to the point where you rarely see it as a fragment wizzing by screen. C elements, never changed X or Y position so their callout shapes are positioned correctly around their inner circles) This is my rotation command, its basic, and works until you start trying to move the cx and cy coordinates, then it exhibits the behavior above... gsap.to("#outer_" + i, {rotation: 360, transformOrigin:"center", ease: Power0.easeNone, repeat:-1, duration: 1, delay:0.5}); // base This is my actual X and Y movement code. Its tracking a 3d object in a canvas and converting the X and Y to screen space to move SVG. This works fine until you start that animation above, then the behavior instantly starts manifesting as described in paragraph 1. // 2D Position the Nurkle Anchor Container targetNurkle.computeWorldMatrix(true); //calculate 2d X and Y from a Vector 3 (x,y,z) let targetPos= targetNurkle.getAbsolutePosition(); // get the 3d worldspace (x,y,z) of the object let p = pwtHelp.calc2dPointFrom3d(targetPos); // converts a 3d point into a 2d X,Y screen space let x2 = p.x; let y2 = p.y; let targetAnchorName = "nurkle_anchor_" + pwtNurkle.activeNurkles[i][0]; // build the target name let targetAnchorID = document.getElementById(targetAnchorName); // find the SVG in the HTML targetAnchorID!.setAttribute('cx', x2.toString()); // set anchor X coordinate - HERE IS X BEING SET targetAnchorID!.setAttribute('cy', y2.toString()); // set anchor Y Coordinate - HERE IS Y BEING SET In looking at the transform spec you need to feed in rotation and a rotation, x, and y. transform="rotate(deg, cx, cy)" I am assuming somehow I am messing with how GS is building that three part transform when you just feed it a rotation with GS and the X and Y is driven by the above. But I don't understand what exactly is happening / how this is manifesting what it is / what work arounds exist. I put everything up on a development domain and you can view this issue live here https://dern.tech/?n=30 . Watch the callout shapes and you will see part of them split off from the main shape tracking the 3d models. Unfortunately this bug is best seen on the site, it is a bit too complex to paste into a pastebin or codepin. I am actually having trouble describing it, as it seems so odd as nothing apparent is telling that rotation to orbit like it is, which is why I decided to link to the actual issue. If you sit there and watch it for a moment you will see what I am talking about. Note, the GS integration over the weekend broke a bunch of functionality in the site, so you can't really navigate or do much of anything but see the bug in action right now. that is not GS's fault I was re-writing some things moving from pure jquery animations for the 2D UI to gain more flexibility in doing things like animating SVG line. So far, I am loving the GS library. Once the page loads, you should just see the error. Watching the drones move toward and away from their home positions makes the bug very apparent. This whole project is only a month into development with absolutely tons to do. So, sort or embarrassed to link to the dev domain given its state being so far from feature complete and not pretty yet. But, this bugs got me stumped. Web development is not something I do often, in fact its been years. Likely, this is all a noob error. Thanks for any help you can offer.

1) Can someone provide correct usage of kill() when feeding in multiple ID nodes? Though I doubt this is correct form, I was trying something like this to stop and clean up animations of a specific target after use.. I am just trying to remove all animations from GS applied to all of those ID nodes. 2) Related, Also on Kill() - what does GS auto cleanup? I would imagine the only tweens that need manually cleaned are things that loop forever using repeat like in #nurkle_anchorOuter_ below? I would think play once animations would play then auto clean up, but I just want to verify I don't leave a memory mess of unremoved tweens sitting around. // remove all active animations for this callout var tweenKiller = "#nurkle_anchor_" + nurkleID + " #nurkle_anchorOuter_" + nurkleID + " #nurkle_line_" + nurkleID + " #urkle_baseLine_" + nurkleID + " #nurkle_topLine_" + nurkleID + " #nurkle_bottomLine_" + nurkleID + " #urkle_titleInnerLineRight_" + nurkleID + " #nurkle_titleInnerLineLeft_" + nurkleID + " #nurkle_titleBackground_" + nurkleID; gsap.kill(tweenKiller); // Below here is just for reference on how these were created. It's not really super important to the question. Yes, I know I need to switch to timelines, I just picked up the lib today, got hung up on nesting timelines for something like this (what to do when most targets don't start at zero, and some loop forever and others dont). As I am just exploring the library, it was not yet a super high priority to revisit yet. // title animation in // todo Timelines! // @ 0sec gsap.fromTo("#nurkle_anchor_" + nurkleID,{r: "0"}, {r: "7", duration:0.5, ease:Bounce.easeOut}); gsap.fromTo("#nurkle_anchorOuter_" + nurkleID,{r: "0"}, {r: "10", duration:0.5, ease:Bounce.easeOut}); // @ 5sec shrink origin, draw anchor and baseline gsap.fromTo("#nurkle_line_" + nurkleID, {drawSVG: "0%"}, {drawSVG: "100%", duration:0.5, delay:0.5}); gsap.fromTo("#nurkle_baseLine_" + nurkleID, {drawSVG: "0%"}, {drawSVG: "100%", duration:0.5, delay:0.5}); gsap.fromTo("#nurkle_anchorOuter_" + nurkleID,{drawSVG: "100%"},{drawSVG: "0%", duration:2, delay:0.5, repeat:-1, yoyo:true}) gsap.to("#nurkle_anchorOuter_" + nurkleID,{rotation: 360, transformOrigin:"center", ease: Power0.easeNone, repeat:-1, duration: 1, delay:0.5}); // @1 seconds start drawing topline gsap.fromTo("#nurkle_topLine_" + nurkleID, {drawSVG: "0%"}, {drawSVG: "100%", duration:0.5, delay:1}); // @1.35 seconds start drawing inner shape gsap.fromTo("#nurkle_titleInnerLineRight_" + nurkleID, {drawSVG: "0%"}, {drawSVG: "100%", duration:0.5, delay:1.35}); gsap.fromTo("#nurkle_titleInnerLineLeft_" + nurkleID, {drawSVG: "0%"}, {drawSVG: "100%", duration:0.5, delay:1.35}); gsap.fromTo("#nurkle_titleBackground_" + nurkleID, {fillOpacity: "0%"}, {fillOpacity: "100%", duration:0.5, delay:1.85}); setTimeout(()=>{ document.getElementById("nurkle_titleBackground_" + nurkleID).setAttribute("fill", "var(--pwt-blue)"); }, 1850);