Moho Forum

Hi, I'm several days after something that sounded simple at first but here I'm kind of stagnant and I wanted to be sure I'm not missing something that finally could make it that simple... I wanted to implement a reliable counter of how many times a layer script is run or, in other words, how many times the function "LayerScript(moho)" is called each time Moho detects a change that triggers layer scripts to run.

The tricky part is that I'm trying to do it no-matter-what, I mean, I can reset the counter in base of some changeable parameter that let me do it, for example, using the typical current frame change for simplicity (although it could be layer's stacking order, or anything like that) I'd do it as follows:

And as a result...



...I'll have I think a reliable way of knowing if I'm in the first, second, three... call of the LayerScript function because I can ensure runCount gets reset to 1 in the very first run of the cycle. But as I said, what if I wanted to know this all the time and not in base of a changeable state like, in this case, the current frame? Do you think there could be a way of knowing for sure in which run/call of the embedded script cycle for each Moho change you are?

Oh, or do you think I could make use of any of this Lua's debug functions for returning an info like this? It calls my attention specially those "debug.sethook()" and "debug.gethook()", but being all this debug library an unknown part of Lua for me it's being hard to figure out how to really use them, for now at least...

Well, that's all and I hope it makes sense (or not sound too trivial/silly ) this way exposed... Thanks in advance for any insight you could come up with, if you think it's somehow possible and you don't mind!

Not a complete solution, but closer at catching anything that invokes the layerscript:
The problem is that the processor time of events may not always be consistent or reliable.

this might help https://mohoscripting.com/script_structure -- scroll down to layerscript and the example there about run once per frame ... should be able to change that to focus just on moho.frame and count how many times HS_lastF == F

If you need to run the same layerscript in many layers, you can generate a variable Global name (e.g. local key = " HS_LastF" .. layer:UUID) and instead of testing HS_LastF test _G[key]

First off, thank you both for replying!

synthsin75 wrote: ↑Sun Sep 18, 2022 6:10 am The problem is that the processor time of events may not always be consistent or reliable.

I admit I didn't do too much testing in base of "os.clock()" because of that, and due to I'm not sure how time differences could reliably differentiate between LayerScript() calls in the same cycle or calls of the previous or following cycle if they happen quickly enough, that is what I consider the more important point here. BTW, when I say cycles maybe I'm not using the correct terminology, but for a cycle I refer to the "chain" of repeating calls of LayerScript() functions that Moho makes after any change in UI, current frame or Play, mouse movements with tools with "NonDragMouseMove()", etc., which may be two calls per cycle, three or four (and maybe even five? But I'd say four is the top). For example, if you change the current frame not too fast, your code seems consistent and prints each cycle of 4 calls separately as desired, but if you start changing the current frame more quickly, it starts printing cycles of 5 or 6 calls, or even cycles of endless calls if you press Play or move the mouse over viewport with the Transform Layer tool... So that's the tricky part I was referring, to can get a way for telling a counter to be reset when starting a new cycle no matter time or anything, if that is even possible in some way, cause I'm starting to afraid that unless Lua count with some kind of "hidden" way of doing it by some of those debug functions or whatever, there may be no real solution for this problem. But I think I deny to totally believe it yet...

hayasidist wrote: ↑Sun Sep 18, 2022 10:28 am the example there about run once per frame ... should be able to change that to focus just on moho.frame and count how many times HS_lastF == F

But Paul, wouldn't that code be limited to work only in base of frame changing too? Or there is something on it I'm not grasping? I mean the key here is try to get a way of know which is the very first call of "function LayerScript(moho)" at any script run cycle no matter if it has been caused by a frame change, any user/tool interaction or even after Moho being idle for some time and for no apparent reason (although I always suspected Autosave could have something to do with this), so as far as I can think, any frame based solution would prevent the code in it to be run under any of those circumstances if there is no frame change at all... But sorry if I'm misunderstanding something or I didn't get to explain it better before!

Yeah, that's why I said it wasn't a complete solution. It works in more cases than just changing frames, but not very accurately.

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.


Is this still about keeping layers from being moved? As you were trying to do in this thread: viewtopic.php?t=35331
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.


EDIT: You could even have it check for the layerscript, and only do it for those layers.

this is a direct mod of your script.

it swaps frame for layer's x position -- I kept "oldframe" as the "old value" - just plain lazy on my part!
and it seems to do what you want -- it will run up to 4 times with the same x then stop even if you then change frames / tools etc although, obviously, if you move to a frame with a different x, the script will fire.

BUT, if that's not what you wanted, then apologies for misunderstanding!

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). You can avoid that by creating a unique name at run time.

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

Ramón López wrote: ↑Tue Sep 20, 2022 2:41 am

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).

I get that you're delving into layerscript possibilities, but that may be a dead end.
I wasn't suggesting counting layerscript runs by a tool IsEnabled function. I meant you could keep a layer from being moved in the layers window (putting it back every time).

Just saying, that task would be easier in a tool (where PlaceLayerBehindAnother would be reliable), but could still work in conjunction with a layerscript.

But I'm all for anyone learning new, reliable hacks for scripting. That's how I came up with using IsEnabled for that sort of thing.

I'm still struggling to understand what your desired condition for re-setting the runcounter is.

I can see Wes has suggested some elapsed time; and I think I've (finally!) grasped what you were saying about it NOT being related to something "obvious" in the layer's environment itself that changes...

but there must be many sorts of event "deep inside Moho" that makes it set off layerscripts... such as UI stuff (click a tool, etc) and maybe some "heartbeat" function (e.g. writing a backup.) Looking back at testing my own tool set, I've also found that Update Widgets seems to run "more often than I was expecting" -- so I'm also wondering if the number of "trigger pulls" might have something to do with exactly which tool is active (e.g. how often that tool does an UpdateUI).

I'll find a dark room with a cold towel round my head and ponder some more ...

====
[later>>>>>>]


I put this together... I made a simple 3 layer test environment:

vector
group
> vector

All vector layers were empty; and each of the 3 layers had the above layerscript.

I poked at moho randomly for a few minutes ... not a rigorous test, but enough to show up a few "facts":

Most tools fired the active layer's layerscript TWICE but once for the others.
Transform Layer kept firing all layerscripts whenever the mouse moved (non-drag mouse???)
Using Pan Workspace, the layerscript fired on mouse down and mouse up
Changing a tool seems to cause layerscripts to run in two bursts: one burst when "leaving" the tool and one burst on starting the new one.
A layer in a group and its group layer seem to get their layerscript invoked "more often" than a "lone" layer
Minimising, then restoring the Moho window produced a cascade of layerscript invocations.

exiting Moho produced a cascade of layerscript invocations as did loading the saved file with the layerscript "active"


=====

My take on this: There are so many conditions under which moho will invoke the layerscripts in layers (selected and unselected) that I seriously doubt that any code in a layerscript could begin to work out "if this was the time to re-set its invocation counter"

===

so -- on the assumption that I have actually understood what you wanted, I think it's, well, going to be tricky or worse to achieve!
Dare I ask what underlying problem you're trying to solve? Making sure that layers update in "the right order" perhaps?????

synthsin75 wrote: ↑Tue Sep 20, 2022 3:18 am I get that you're delving into layerscript possibilities, but that may be a dead end.

And that's maybe what I was looking for (well, a possible solution to the problem would have been better, or course ), thanks! I mean, my main fear was I may be missing something obvious after so much struggling because at some point I even started to can't think with clarity about it... And I kind of suspected it, but now it's clear I was in a "trap" if your more experienced minds neither can see a way to get it work the way I wanted, within the posibilites Moho and Lua can bring right now at least.

synthsin75 wrote: ↑Tue Sep 20, 2022 3:18 am I wasn't suggesting counting layerscript runs by a tool IsEnabled function. I meant you could keep a layer from being moved in the layers window (putting it back every time).

Just saying, that task would be easier in a tool (where PlaceLayerBehindAnother would be reliable), but could still work in conjunction with a layerscript.

Yes, yes, I understood you were not suggesting to move the run counter to there but the placing layers part, and it may be a possibility in the future when/if an accompanying tool script start to make more sense along other possibilities.

synthsin75 wrote: ↑Tue Sep 20, 2022 3:18 am But I'm all for anyone learning new, reliable hacks for scripting. That's how I came up with using IsEnabled for that sort of thing.

As exciting as it is frustrating! But, well... we got ourselves all on our own into all this

Paul, I've to get a little more time to really can get into your reply right now, but I'll check it and comment impressions as soon as possible, thanks too!

I got curious if an IsEnabled function could count layerscript runs better. If you want to test it yourself, you just need "self.ran = true" in any tool's IsEnabled function (and change the variable below to match). It will reset the runCount every time it's invoked, but still need the oldFrame logic, since IsEnabled only gets invoked when entering/leaving frame zero.
Seems very consistent, but click & dragging in the workspace (or a tool selected with NonDragMouseMove) just keeps counting. But clicking on and sorting layers seems consistent.

I don't know if that helps anything. I was just curious.

hayasidist wrote: ↑Tue Sep 20, 2022 7:48 am My take on this: There are so many conditions under which moho will invoke the layerscripts in layers (selected and unselected) that I seriously doubt that any code in a layerscript could begin to work out "if this was the time to re-set its invocation counter"

First off, thanks again to take the time to make all those inquiries, Paul. Yes, I'm conscious that treat to solve the problem in base of Moho's LayerScript invocations would be a madness because there would be simply too much factors to take into account... plus. they may even be uncertain, change in a near future, etc. My best bet always has been there could be something in a scripting interface's function/global that returned me: Hey! This is the very first run of this LayerScript(Moho) chain of runs, enjoy " or... something like that . Jokes aside, it maybe some function that for whatever reason returned nil, false, true or whatever at the first (ideally) or last run of de chain/cycle, but I quickly realized that was not going to happen (or even if so, it probably would be a bug).

The other (more realistic ) possibility was I could take any info like that from the Lua's Debug library y mentioned, but after playing a little with "debug.getinfo" and "debug.getupvalue" and printing everything they can get (I think) I neither see how they could help on this... I kinda hoped they could say something about the number of function runs or anything happening in-between that could be useful to differentiate the run cycles from each other, but no luck, for now at least. I've not played yet with "debug.sethook/debug.gethook" ones, so not totally sure if there is still a possibility there... The other debug functions don't really sound like they could hide the key inside, but I may investigate them as well at some point out of curiosity...

hayasidist wrote: ↑Tue Sep 20, 2022 7:48 am so -- on the assumption that I have actually understood what you wanted, I think it's, well, going to be tricky or worse to achieve!

Yeah, it seams we all agree with that at this point, haha ( )

hayasidist wrote: ↑Tue Sep 20, 2022 7:48 am Dare I ask what underlying problem you're trying to solve? Making sure that layers update in "the right order" perhaps?????

Well, yes, update, move, whatever, but not only that... I more or less explained to Wes right above:

Ramón López wrote: ↑Tue Sep 20, 2022 2:41 am

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

In sort, I wanted to have an instrument for taking control over LayerScript() calls and can choose in which one of those several calls per cycle run certain parts of my code at will, starting with the moving layers issue (although luckily that could be finally solved, although in a little more convoluted way than desired), but with any other similar problem that could arise in the future in mind and other performance related applications.

So... well, unless something new arises, I believe I have to start thinking on turning page about this specific point and try to continue working with what I have now and see. Thank you very much to both for being there one more time!

synthsin75 wrote: ↑Tue Sep 20, 2022 11:53 pm Seems very consistent, but click & dragging in the workspace (or a tool selected with NonDragMouseMove) just keeps counting. But clicking on and sorting layers seems consistent.

I don't know if that helps anything. I was just curious.

Then thank you one more time, Wes. I also tested it here out of curiosity and I don't get too consistent cycle prints when simply clicking for example over a layer's icon in palette, plus the other exceptions you name... but it's what we agreed above, a hack is always going to be a hack... Maybe with more work and merging all the conclusions and ideas exposed along the thread it may work more reliably and under more situations (although surely never perfectly, unless some finding arise), but maybe that's something I'll have to deal with in the future if the need for it becomes more crucial.

I could try to make a feature request for a scripting interface addition with which can get the per cycle LayerScript() number of calls or something like that and, sincerely, something tells me probably it could be like an easy addition, but not sure if I'd get enough attention for it being a so specific/particular request... I'll think about it a little more for a time and then decide. Greetings and thanks again for your time.

I missed the original thread ... which I've now read.

If I've grasped that problem correctly, would one solution to "preventing a layer being in the wrong place" be to have it (or maybe its desired group layer) scream (Lua console message) if a layer was in the wrong place, rather than trying to automate moving it back?

hayasidist wrote: ↑Wed Sep 21, 2022 9:35 am would one solution to "preventing a layer being in the wrong place" be to have it (or maybe its desired group layer) scream (Lua console message) if a layer was in the wrong place, rather than trying to automate moving it back?

Yeah, I considered that option, but I wanted to reduce to minimum Lua console jumps or any kind of warning messages, so the "auto-moving-back when the layer is moved from a correct placement to an incorrect one" solution was the cleanest I can think. But I always have in mind the warning solution should finally I can't totally avoid the crashes under all circumstances (the only thing pending to solve now is a crash after dropping several layers into a Group Layer). I have considered other options as well, like turning layer red, add a warning mark to the name, etc., but I wanted to reserve those more visual and undefined solutions for catching attention over other kind of possible issues when needed, or for when the layer has been already placed in wrong place before hand.

BTW, I don't think I got to coment it there, but another thing I also tryied at some point (with a lot of hope on it I must admit) is just perform a "moho.document:Undo()" after the script detects a layer placement change, but no matter what I tried it always ended in a Moho crash... although now that I name it, I'm not totally sure if I tryied that after or before I got to apply the final run counter working solution, so I may try to test again and see if performing the Undo operation in another cycle call could make a difference. Surelly I already tried it indeed, but I think it will worth it a quick test to be totally sure just in case...

EDIT: Nah, it seems "moho.document:Undo()" always ends up making Moho crash no matter in which cycle call it's run...