Daz Studio 2025, "Global" variables, Scoping, and Lifetime
RiverSoft Art
Posts: 6,777
I am slowly going insane trying to figure out the scripting in Daz Studio 2025. I understand it is an alpha, it may change, etc, but I am getting questions on my scripts in DS 2025, and I cannot do anything until I can figure out what is the proper "hoped for" behavior in DS 2025. I am baffled by the scoping and lifetime rules in Daz Studio 2025, so much so I am wondering which are bugs and which are intended changes? I hope someone can explain so I can convert scripts to DS 2025.
- Global variables are global, until they are not.
- Global variables defined in an included script are persistent and global to every script for the lifetime of Daz Studio
Global variables are global, until they are not.
Write the following code and execute it. It works properly, myvar, a global variable, is printed out.
var myvar = "Hello";
function PrintMyVar()
{
print('My var is', myvar);
}
PrintMyVar();
Now move the PrintMyVar function into a file and include ("PATH HERE/MyFile.dsa") and execute it. Myvar is no longer a valid global variable. This makes no sense. I assume this strange behavior is because (from the evergreen thread): "An includee (inner) script no longer has visibility of variables in the scope of the includer (outer) script", which kinda defeats the purpose of global variables.
var myvar = "Hello";
include ("PATH HERE/MyFunction.dsa"); // has PrintMyVar in it
PrintMyVar();
Now move the "var myvar" statement into ANOTHER file and include("./MyConsts.dsa") and execute it. Myvar IS a valid global variable again.
include ("PATH HERE/MyConsts.dsa"); // var myvar = "Hello";
include ("PATH HERE/MyFunction.dsa"); // has PrintMyVar in it
PrintMyVar();
Global variables defined in an included script are persistent and global to every script for the lifetime of Daz Studio
Now what is worse is those global variables and functions are now global for the lifetime of Daz Studio. Bring up the IDE window, type PrintMyVar() and execute it. The function is there, the variable is defined! Talk about side effects! One of the reasons I have been struggling to figure out what is happening is that the IDE window exhibits this behavior so I would start a new script but the variable was still defined when I didn't expect it to be anymore. While I can see uses for this behavior, I feel like this is incredibly dangerous. If we want global persistent variables, they should be defined some other way, perhaps with the export and import module rules (which I haven't explored yet as they would break too many of my scripts and are not backward compatible to DS 4.24)
What would I like to see? Like DS 4.24 and everything ever:
- Variables and functions have scope and can be seen at their current level and all below it. They are trashed when that block goes out of scope
- Include works like a standard include in every other language, as if the code was typed right into the script at the include line. Get rid of that strange behavior defined in the evergreen thread
Daz 3D is part of 
Connect
DAZ Productions, Inc.
7533 S Center View Ct #4664
West Jordan, UT 84084
Licensing Agreement | Terms of Service | Privacy Policy | EULA
© 2025 Daz Productions Inc. All Rights Reserved.
Comments
These are chnages in the underlaying script standard, ECMAScript 5.1 in DS 4 and ECMAScript 7th Edition in DS 2025 that affect many things and sciope is one of them. Have you seen https://www.daz3d.com/forums/discussion/727631/daz-studio-2025-6-25-2025-x-evergreen#latest which has discussion of these topics?
Yes, I have. In fact, my post references what Rob wrote for the "include" statement in that thread. This one change he made breaks in some way most scripts I have written as I relied on it heavily to write maintainable code. As far as global, he just mentions it but as I posted, it doesn't seem to be working consistently. I am trying to figure out what I can do. Unfortunately, experimenting using the Script IDE runs into these odd behaviors (bugs?) and I am struggling to come up with solutions.
The changes in scripting listed in the evergreen thread are not bugs or things Rob has chosen to do, they are changes in the underlying Qt Script engine. That means that daz, and we, are stuck with them (though Rob has ameliorated some of their effects where possible). On variables from included scripts,s ee under the Modular Code section:
I don't know how useful it is, but this page comes fairly high in the search results when looking up the terms mentioned under that same heading https://www.freecodecamp.org/news/modules-in-javascript/
Thanks for the reference Richard. It is talking about modules, which are different.
I am not knocking all the work Rob is doing. He is doing an incredible job. DS is so big and there is so much work. However, with global variables and include files, I have been scouring the web and finding nothing about the behavior changed between ECMA 5 and 7. As someone who has exposed an application through a scripting interface before, I know it is a lot of work and you make choices. I think he made a choice, perhaps thinking that it is too much work or it won't break compatibility with lots of scripts. I am saying it does for myself, as a major vendor of scripts. I am hoping he will revisit that choice.
There are also things I would consider bugs, like global variables and functions defined for the lifetime of DS. I find that behavior dangerous at worse and leading to a lot of unintended bugs in scripts at best. IMO, scripts should be scoped and not allowed to play outside their sandbox, unless there is a specific mechanism scripters would have to do, such as having a globalThis exposed, where only variables added to it deliberately would live after the script is done. The "Lifetime of imported ES modules coincide with the lifetime of the script engine (application)" statement, which is similar to how the global variables/functions are acting, is less dangerous as you have to explicitly import things from these modules.
DS 4 was built on Qt 4, not Qt 5 - though the underlying chnages are actually back one level from that, in the respective ECMA standards.
I am not worrying about which version of Qt right now.
My point was that comparing the two you quoted wasn't actually comparing DS 4 and DS 2025/6.
To summarise, I hope acurately, the infromation we have been given:
In 4.x.x.x (and earlier, I believe) a script runs in a script context - varables created within that context live as long as the context and then die, unless they are in some way made permanent (e.g. attached to a scene object). A variable that is not explictly created is global - that is, it outlives the script context and may therefore cause issues with other scripts, which is why it is advised against.
In DS 2025/6 scripts are wrapped in an anonymous function (the way the sample scripts have been written for some time, but not visible in the code) and that was true even before the CommonJS Module support was added. Variables declared with var then live with the function, while variable declared with let or cosnt live with the block that contains them. This is covered by https://www.daz3d.com/forums/discussion/comment/9137806/#Comment_9137806 and http://docs.daz3d.com/doku.php/public/software/dazstudio/6/change_log#6_25_2025_17207 .
I feel like we are talking past each other somehow, but all this fighting with DS2025 is just costing me time and money. I feel like I am being punished for writing maintainable code before. I will have to hack whatever works, at the cost of maintainable code, because I need to support BOTH DS 4 and 2025. That means either using "include" or explicitly throwing all the shared code into the main unit so I have a bazillion copies of functions. As "include" is so broken in DS 2025 the script debugger cannot even find out which line of code actually caused an error (try including a file that throws a runtime error, the script stack trace reports a line number beyond the end of the parent unit... useful? NOT), I probably have to go to a bazillion copies. Sigh.
[Edit: But I appreciate you trying to help Richard]
I think the biggest issue is using implicit global variables, where they are not declared, but as the iintermediary with neither code access nor a truly deep understanding of the application it is hard to be sure.
You might want to have a look at the latest change log, but pay close attention to the caveats and warnings.
I never used implicit global variables (unless it was an accident) so that is not my issue.
Is there something specific in the change log you wanted me to see or did you just mean, check it regularly?
It was added to the changelog around the time Richard posted. http://docs.daz3d.com/doku.php/public/software/dazstudio/6/change_log#6_25_2025_19207
Search for "include"
Interesting. I will update and see what happens.
I think this is not yet in a publicly available build, t was just a heads up about something to come.
Ok, thanks.
BTW, where should we report scripting bugs? For example, DzBasicCamera.cursorToScene always returns the Zero Vector:
var vm=MainWindow.getViewportMgr();
var vp=vm.getActiveViewport().get3DViewport();
var camera = vp.getCamera();
print(camera.cursorToScene(vp.currentDimensions().x/2, vp.currentDimensions().y/2, 0));
Ideally post them to the alpha discussion threads (you may have access to a PA-specific one) to see if others can reproduce, but an actual report goes through a Techncal Support ticket.
Ok, thanks.