LuciferVisuals wrote: ↑April 21st, 2023, 11:36 am
It's brilliant, but has so many things I have not used, and never even see before. It's another level, of coding and I'm nowhere near it yet.
No, it's not. It's quite simple. BUT, in general, for someone just starting with something, there are a few guidelines that should be followed, IMHO:
1) the key in doing something is to first understand how it works
2) because of the above, it's preferable to:
a) start simple, with just the element(s) you need to understand
b) start from scratch with them, i.e. from a blank file to writing those element(s) yourself
c) use the documentation available, aka the manual, when needed
d) if you're going to use other bits of code, do not proceed further until everything from them is clear
e) if you're going to use other bits of code, adjust their parameters (in this case, the variables) to see what they do
3) the key in completing something is to know exactly what you want to get to
In this case, the only element in the code that's slightly more "complex" is the ActionTimer measure, and that's only because it's a bit outside the box in the way it uses the plugin to repeat things ad infinitum, i.e. Action3 and the Rerun options. The rest is just standard stuff, really, but you can't expect to know how to do it if you don't examine the code, play with the parameters, or try to replicate an even simpler version of it yourself from scratch.
In the code, [Frame] is iterating from 0 to the number of frames, [Container] is masking out the outside of a disk about the size of the stargate by drawing a opaque ellipse to show the interior and letting the rest transparent to hide the exterior, [Woosh] is displaying the .jpg based on the active frame number from the corresponding measure and masking it based on the container, and [Slider] is updating the relevant sections and redrawing the skin once every #FastUpdate# milliseconds.
If the woosh wasn't "overflowing" the stargate at its edges, keeping only the former would have been easily achievable by increasing the Edge variable to something like 60 (pixels). What such an increase does is simply lower the radius of the ellipse from the container via the (#Size#/2-#Edge#) formula, in effect making the shown part (i.e. disk area) of the .jpg smaller. The Glow variable is a remnant of one of my codes to more or less "blur" the edges of the shown disk area to make them fuzzier. The rest of it is just plain English, really.
Regarding the two IfCondition lines I recommended to be added to the code, that is not required if you're using an ActionTimer measure in a standard way - adding them is simply an effect of my initial "thinking outside the box" design of that measure for endless animations and not specifying there when it should stop with the repeating of the update+redraw system used in the animation (thus, having to test whether that moment came outside the [Slider] measure, in the IfCondition from the [Frame] one). So no, if you don't use the same approach I did with the ActionTimer measure, you don't need to add similar lines to processes involving them. That part is usually, in a standard implementation, handled by the Repeat Count Number values mentioned in the explanation from the
manual. Since I don't use such an approach here, I need to check it out someplace else, like already described above.