synthsin75 wrote: ↑Mon Sep 19, 2022 2:43 am
It works in more cases than just changing frames, but not very accurately.
And it would be a good approaching (and of course I appreciate it anyway) if it weren't for, at least in this case, I need it to be totally bombproof, otherwise it would cause more problems (crashes) than what it's meant to solve.
synthsin75 wrote: ↑Mon Sep 19, 2022 2:43 am
I think the thing to remember is that layerscripts are primarily meant to make changes as the animation is played/rendered. In that case, running once per frame would be the solution.
But once you add in UI inputs that cause a layerscript to run, it doesn't really seemed designed to handle that. So any solution is going to be a hack.
Yeah, it's a good point and I know this kind of problems is what you get when you try to go a little beyond of what a feature was maybe primarily intended for, but OTOH it's interesting can know where the limits are. And that's true, a hack is always going to be a hack so 100% reliability is surely too much to ask...
synthsin75 wrote: ↑Mon Sep 19, 2022 2:43 am
Is this still about keeping layers from being moved? As you were trying to do in this thread: viewtopic.php?t=35331
Yes, in principle... I mean, that's the first use I had in mind, but I wanted to have a simple way of get LayerScript() calls count at any point of the script for any future uses I could come across, or if it's only for improving real-time performance in certain parts of the script that could be run once or two after any user interaction instead four, in which case I've found that doing it in the right call number can be crucial, hence it's also so important the calls counter reliability in this cases related to performance. Another reason is if I could get a unique and always working counter per script, I could do it all with only one global variable per script instead several of them for each part of the code which runs I want to limit... Well, it simply sounded all too good to resist to try
synthsin75 wrote: ↑Mon Sep 19, 2022 2:43 am
If so, I would suggest doing it in a tool script's IsEnabled function instead, as this responds to clicking or dragging layers, but much more predictably than a layerscript.
But that would imply have to count with a tool script accompanying the embedded script only for this and I don't think it would worth all the mess for now, sincerely this is something I've consider to study at some point to try to extend layer scripts possibilities (like get the desired access to "moho.view", for example), but I'm far to can plunge into that right now and I think I prefer to keep it as simply as possible by working over only one script (for now).
hayasidist wrote: ↑Mon Sep 19, 2022 3:39 pm
this is a direct mod of your script. it swaps frame for layer's x position [...] BUT, if that's not what you wanted, then apologies for misunderstanding!
Thanks, Paul, for taking the time and no need of apologies, of course! But unfortunately, yes... It suffers the same problem of the original one, that is, once the condition for running the code is not met (in this case the translation doesn't change), the counter stops being updated and I need it updated on every call and no matter what, so that I can know for sure in which Moho
sub-call (to name it somehow

) of the LayerScript() I am at any time and, therefore, can make conditions on base of that at will.
Anyway, if there were unclear/overcomplicated parts, I think all can be reduced to this: since Moho calls the embedded script's LayerScript() function several times after detecting a change, all I'd want is a way to can know, at any time and for sure, which one of those (normally between 2 and 4) calls is the very first call Moho does. That's why the conditions based on current frame, layer translation of whatever are not ideal, cause if the condition doesn't met you have nothing at all to work with.
hayasidist wrote: ↑Mon Sep 19, 2022 3:39 pm
Then, like I said, if this script is to be run in many layers, EACH will need their own unique variable (a global is just that - global -- so if two layers both access the same "old value" they'll continually compete with each other).
Yes, I'm aware about that and I don't think it will be a problem, anyway my plan is store those globals (or may I call them
semiglobals) as apart of a
per script table I'm declaring out of the "LayerScript(moho)" function. It seems to work, but even if I finally didn't do that I'll somehow try to ensure different global variable names.
Well, thanks for the inputs and sorry for the
too much text... BTW, I'm still investigating the
Lua's Debug library I named and, although I'm simply scratching the surface and I doubt I can finally get what I want from it, I'm already impressed to know all the info you can grab about Lua processes function calls and all

...