How would you get the working (active) layer from an embedded script?

[Rai López]

I haven't ever needed to get file attributes, but creating/removing directories can be done with os.execute, like I used in my Switch Icons tool.

But wasn't os.execute platform dependent or something so? I remember to have read about it but I'm totally not sure about it now...

To see if a file exists I've been using this:

Code: Select all

function FileExists(path) --win only??
	local f = io.open(path, "r")
	return f ~= nil and io.close(f)
end

Not sure where I got it, probably Stack Overflow, but as I said in my latest tests I couldn't make it work as expected even thought in the other cases it seemed to work well... In any canse any alternative is always welcomed, so I'll try your solution as well (which seems a little simpler) when I put at that part of the code in order to see which way can be more convenient. Thanks!

I guess I'm not quite following you. What I'm needing is to have a variable, set by a tool, accessible to a layerscript while rendering. So once the render starts, I'd have the same problem with any other layerscript I try to set and run, right? Unless the value of the variable was hard-coded in the layerscript, i.e. "var = value." Now, I can have a script write a layerscript on the fly, to do that, but that's starting to sound too involved for my purposes.

Hmm... Yeah, I can see how in your case it can not worth all the mess for only ensuring the availability of a simple variable... And what about storing your variable as "moho.document.MyVar = value"? Have you tried something like that? Because I've precisely making some test today and, even I would have bet it wasn't to be available for the other environment, I got mixed result (results I still have to confirm) that makes me think it could work. Normally I've used "moho.layer.MyVar = value" in some special cases and it has always worked flawlessly, but with all this Multienvironment of Madness ( ) I thought moho.document could be a better storage option for not being layer dependent. In my case I'd still need to get the string.dumb & load thing to work in order to can use this alternative method, but that's because what I intend to store there are entire functions, but for simple values, that I think is all you could need, maybe simply storing there could do the job. Anyway I'll know it soon, cause I wanted to continue exploring this possibility a little more...

[Rai López]

Argh... Nope, it doesn't seem to get passed to the other new environment, as I kinda suspected OTOH, but the way LC prints the results before and after rendering somehow made me think it could work... So, yeah, I'm not sure what would be the best in your case, cause I agree the script reloading workaround is like too convoluted only for solving that... I'll continue thinking about it, tough.

[Rai López]

Hmm... And using ScriptData instead? I'd be layer dependent, but taking into account there is always to be at least one layer in every project, maybe the tool function could write/update the value to be always available on e.g. layer 0 and then any other script in any other environment should be able to take it from there. It could still entail more work (for example to avoid residual values along the project should this first layer get moved along hierarchy) but, OTOH, working with ScriptData is quite straight forward and fast... Other than that I think I'm out of ideas, but I'll continue thinking on it.

[synthsin75]

I haven't ever needed to get file attributes, but creating/removing directories can be done with os.execute, like I used in my Switch Icons tool.

But wasn't os.execute platform dependent or something so? I remember to have read about it but I'm totally not sure about it now...

You just have to check which OS and use the appropriate commands.
Sometimes they're the same, sometimes not.

To see if a file exists I've been using this:

Code: Select all

function FileExists(path) --win only??
	local f = io.open(path, "r")
	return f ~= nil and io.close(f)
end

Not sure where I got it, probably Stack Overflow, but as I said in my latest tests I couldn't make it work as expected even thought in the other cases it seemed to work well... In any canse any alternative is always welcomed, so I'll try your solution as well (which seems a little simpler) when I put at that part of the code in order to see which way can be more convenient. Thanks!

That should do the same as mine, and should be platform independent. Maybe reading the file in binary mode, "rb," makes a difference.

I guess I'm not quite following you. What I'm needing is to have a variable, set by a tool, accessible to a layerscript while rendering. So once the render starts, I'd have the same problem with any other layerscript I try to set and run, right? Unless the value of the variable was hard-coded in the layerscript, i.e. "var = value." Now, I can have a script write a layerscript on the fly, to do that, but that's starting to sound too involved for my purposes.

Hmm... Yeah, I can see how in your case it can not worth all the mess for only ensuring the availability of a simple variable... And what about storing your variable as "moho.document.MyVar = value"? Have you tried something like that? Because I've precisely making some test today and, even I would have bet it wasn't to be available for the other environment, I got mixed result (results I still have to confirm) that makes me think it could work. Normally I've used "moho.layer.MyVar = value" in some special cases and it has always worked flawlessly, but with all this Multienvironment of Madness ( ) I thought moho.document could be a better storage option for not being layer dependent. In my case I'd still need to get the string.dumb & load thing to work in order to can use this alternative method, but that's because what I intend to store there are entire functions, but for simple values, that I think is all you could need, maybe simply storing there could do the job. Anyway I'll know it soon, cause I wanted to continue exploring this possibility a little more...

Great minds think alike. I was just about to try storing my variable using a moho table.

Argh... Nope, it doesn't seem to get passed to the other new environment, as I kinda suspected OTOH, but the way LC prints the results before and after rendering somehow made me think it could work... So, yeah, I'm not sure what would be the best in your case, cause I agree the script reloading workaround is like too convoluted only for solving that... I'll continue thinking about it, tough.

Drat.

Hmm... And using ScriptData instead? I'd be layer dependent, but taking into account there is always to be at least one layer in every project, maybe the tool function could write/update the value to be always available on e.g. layer 0 and then any other script in any other environment should be able to take it from there. It could still entail more work (for example to avoid residual values along the project should this first layer get moved along hierarchy) but, OTOH, working with ScriptData is quite straight forward and fast... Other than that I think I'm out of ideas, but I'll continue thinking on it.

That's a great idea. Thanks.

[Rai López]

Ahhh... Maybe when I start to deal again with all that file/directories matters I'll start to feel more confident with how it works and all... but, for the moment, thanks for the info/advices!

Haha, yeah, it would have turned to be too easy if it would have worked, but it had to be tried...

I'll be glad if it finally helps! It's kind of awkward to have to resort to permanent data for this kind of tasks we normally would solve with temporal variables that doesn't require any attention or "maintenance" once they do what they have to do, but given the situation I really don't see a better alternative for now... How I'd love right now Lua had something like SuperGlobals or something so, that only would ease all this situations so much that I can't believe such concept doesn't be more popular, specially for scripting languages. So, although surely there will be powerful technical reasons for not counting with that... all from my ignorance, it sounds to me like it could be a good Lua feature request

[synthsin75]

Thank you so much, Ramon. Layer scriptdata did the trick. Now rendering without any problems.

[Rai López]

I'm sure I only acted as a catalyst at most, but you're welcome and I'm glad something finally helped

BTW, another unexpected but good (very good, indeed, for me at least) side-effect derived from all this, is that there is now a way for a script to know if Moho is rendering or not. Well turns out I've always wanted to be able to do that, and I think I even requested it, for example to can use moho:CurrentTool() from embedded scripts (remember how I just mentioned it here a few days ago??) without crashing the renderer... Well, I had a lot of uses in mind for this method that I thought I couldn't be able to carry out due to that bug and, all of the sudden sudden, it's like if it would have been magically fixed (or the request granted), because now I can ensure CurrentTool() is only run should Moho is not rendering by simply checking if any of those variables normally available in the normal working environment exist in the renderer's one or not.

Well, just wanted to make a mention of it for the record, and why not... also to remind myself it's not all stones on the road when it comes to scripting, haha...