ETA for script usability in DAZ alpha 6.25?
windli3356
Posts: 290
in The Commons
Alpha 6.25 has being lovely so far, the performance & loading speed is vastly improved over the old Daz, but the inability to use all the scripts and plugins really prevent me from going full time on it. Can we have an ETA on when can purchased script & plugins can be used on this build at least? or never at all due to technical issue? perfer honestly over sugarcoated baloney
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
I don't think a global answer can be provided, because it'll depend on each PA.
And I think, but may be mistaken, that @Totte said that many of them are waiting because some important changes on how scripts and plugins have to be written can still be made by Daz.
Scripts needs in many cases to be updated due to changes (good changes that brings more stability to DS scripting) in how things works between ECMA 5 and ECMA 7+. As DS 6/2025 is still in alpha (meaning not feature complete) things might change, so to avoid doing changes more than one time, we all patientally awaits the final verdict on how things will work. Some scripts do work, but basically the rule is the more complicated a script solution is, and the older it is, the bigger risk is that it wont work out of the box in 2025.The amount of work to fix spans from in best of cases less than an hour, to several days and even weeks of work to get things working correctly in DS 6/2025, which means it's not only getting it to not give errors or crash, it also needs full testing in all edge cases whch is in itself a very time consuming thing.
To complete Totte's answer on scripts, regarding plugins:
The DS4 version of plugins will never work in DS2025, they all require a new version based on the DS6 SDK.
As with scripts, the amount of work required to create a DS2025 version will depend on the plugin and which features of DS and the SDK it uses: some will only need recompiling, some will need minor updates, some will need major changes, and some might even need a complete rewrite. And some will never be updated, eg because the PA is not available anymore to update them (Dimension3D plugins for example), or the plugin is not available for sale anymore so the creator might not see the point of updating it, or it would be too complex to update.
Nice thread. I planned to update everything, and if possible in a bi-compatiblity mode (4/2025). I already started to update my own scripted products, and so far it is not too complicated - but long, even if some of the disappeared native functions lead me to huge "rebuild" of equivalent functions which was not easy at all. All the updates I made so far are both compatible with DS4 and DS 2025. The same as Totte, I won't submit the updates "too early" and for two reasons : 1/ I am still waiting for beta testers to be willing to have a look, and 2/ I read that there still could be modifications in Daz Studio 2025 which could make my updates to be "updated again"... So not in a hurry, but if you need an update, simply apply as a beta tester, and you'll have it as soon as ready ;) It could even trigger my next update. And I have a thread for that in the commercial forum for that : https://www.daz3d.com/forums/discussion/728061/v3digitimes-2025-compatibility-updates#latest
Good idea @V3Digitimes with a DS2025 Comptibility thread, I think I do that too. Some scripts will be "dropped" as they have no real purpose in DS 2025.
Yes, I think a Compatibilty thread is important if you want to avoir 10 people asking on 20 products if/where/when the update is... And even for you when you update, it looks like a filling progress bar, good for the mood (or bad at start lol)...
If the scripting system is being updated for Studio 2025 then I assume that updated scripts won't work in Studio 4.2x. This would mean updated scripts and plugins couldn't be released through DIM until 2025 became the current release version, It will also cause problems for anyone wanting to keep running 4.2x when 2025 is released. I want to keep using 3Delight so I intend to keep 4.2x installed as well as 2025.
I don't see why that would be the case. Many products on the store include separate versions for DS and Poser, and DIM can handle a single SKU having multiple downloads... and, indeed, a SKU being updated to have more packages than originally (such as when the Anime models were added to G9, they had a new ZIP package).
If a new version of an existing script is required for it to work in DS25 (and assuming it's not being sold as a new product - I recognise that while I'd *like* them to be free updates, the work will often be significant enough that doesn't make sense for the PAs), then it should be possible for DIM to provide separate packages for each version.
That actually depends. I've updated a few (and also done some new) that are designed so they work on both. There are different ways of doing that.
(1) Grab DS version you run you and check against the version whenever you are about to do something that breaks in either world, and do the right thing. This method do require that you do not use any new language features of ECMA 7+ as those will break in DS 4.
(2) Write a small use facing script that checks which DS version is used and then load and execute the proper script from a non user facing world. More work and requires that the user doesn't go bananas when installing, breaking tghe logical relationships between lauched and actual scripts.
Both methods do add a lot of development time, so I guess newer scripts when DS 6/2025 is out and released, that needs the powers of ECMA 7+, will be using the ECMA 7+ specific lanuage model and then render the script useless in DS 4 branch
That's great news! you can potentially roll out a script compatiablity product targeting this if Daz offical doesn't come up with one fast enough(track record suggest they probably won't)
(Edited by mod to fix quote)
Old scripts using APIs deprecated in DS 4 will have issues as those API are no longer available, and should have been replaced 10 years ago.
There are a lot of those scripts laying around, specially .ds scripts for material settings.
The most common is things like this:
if (this.fDS6 == true) {
connect(this.wSetList, 'selectionChanged', this, 'selectionChanged_wSetList');
}
else {
connect(this.wSetList, 'selectionChanged()', this, 'selectionChanged_wSetList');
}
something like this, except that on my side I embbed all in function I call 'safeconnect" of that, to keep the script text lighter (and the update of all the corresponding widgets easier), and to copy paste the function in the other scripts to update.
edit : the most annoying thing for me so far is the "doDuplicateElement" which I did not manage to have working at all in my context, and required a lot of lines to process things in an alternate way to get the result I wanted..
My two main issues are with DzListView:
(1) Pixmaps are always displayed as tiny small 22x22 pixel thumbs no matter how I try to se height of Listitems.
(2) When you have s signal slot for 'mouseButtonPressed(int,DzListViewItem*,const QPoint&,int)' for DzListView with DzCheckListItems
and do this in the slignal handler:
var aChecked = this.wTheList.getItems(DzListView.Checked);
in DS 4, aChecked contains the current state of all DzCheckListItems, in DS 6 it contains the state before the click/change that triggered the signal, i.e. the change of state happens after the callback on DS 6 but before the callback in DS 4.
Oh gosh, you’re in a complicated one! I quickly checked one of my scripts - and since the function is triggered by a separate button that uses wListView.getItems(DzListView.Checked), I didn’t encounter the issue.
If I remember correctly, Filatoon Converter uses closures around stateChanged(int) on the listView, but only for multi-selection purposes. Sadly I haven’t started updating that one yet (I think), but launching it from the scriptIDE still allows me this multiselection... I'll let you know if I have some inputs on this if/when I meet this issue.
Lol - many of my scripts are "complicated". They are designed with the German engineering designpattern in mind "Why make it simple, when you can make it so beautifully complicated" ;-)
Haha, I love that — you're building German-engineered symphonies, while I'm over here patching things together with duct tape and version checks.
My scripts are more like wartime survival kits: not elegant, but a bit less difficult to patch. When DS2025 breaks something, I just grab my roll of tape and cast 'Fix Compatibility – Level 1'.
No abstraction layers, no design patterns — just brute force scripting with a mug of tea and a battle axe under the table.
We’d probably make a great party: your elven precision, my dwarven pragmatism.
It's more like "I want it to work this way, so I bend DS to my will with complicated solutions because I ran out of simple ones."
http://docs.daz3d.com/doku.php/public/software/dazstudio/6/change_log#6_25_2025_11417
You do realise that daz has already done a lot of work to maintain what degree of compatibility they can? Products released will "target" the general release, not a beta, unless specifically stated otherwise (and that is very rare - I'm not sure it has happened since the original DS 4 beta, with Genesis content).
So the big question is what would happen to all recent scripts in the final build? Some later released scripts and utitlies got to be auto compatible like it's in 4.25. For example all my purchased scripts and unilities are from 2020 - 2025. such as pose converter, mesh smoother, mesh grabber etc. if they can't be auto converted in final build, I'd imaging it's gonna cost users alot.
The issue with scripts is geenrally changesin the scripting engine or possibly changes in DS - either way if they are incompatible now they will likely still be incompatible in a final release unless/until the PA addresses the issues, though that is not absolutely set in stone.
Moving a script to work under DS 6 can take everything from "no time" (it works), to several weeks for complicated scripts. It will be a tough and hard descision to make for all scripters, what to spend time on and what not, and what new things to add to make it worth issue a new version. Still, even though you get the script to work, there are a lot of styling / gui issues that you need to either solve, redesign, or hope that it will be addressed in upcoming builds.
As a side note, my latest set of scripts, LowPi Toolbox Volume I, works in both DS 4 and DS 6, but it doesn't use any of the things I've seen works differently or not at all.
" if they are incompatible now they will likely still be incompatible in a final release " I hope that process will be mandatory for all PAs, if the benchmark is Alpha 6.25, then unfortunately nearly no scripts works at moment, from the most basic pose/cloth converter (big deals for users who own tons of resource on G3/8/9) to a slightly complex ones like mesh grabber to fiso physics engine. Personally I hope the most basic ones can be addressed by DAZ, I image if PA don't come up with any updates upon release, it's gonna upset a lot of people here.
Contracts and commerce don't exactly work that way. For example, if you bought a dvd just as digital media came in, you can't sue to require the media company to give you a digital version to work on your smart tv or computer; you bought a dvd to use in your dvd player and you got a dvd. In this case you bought scripts that work in a certain version of software and operating system enviroment and you got that. The creators can not be forced to provide infinite support as that is not in the contract (we could afford to pay for infinite support), many of them are eithert dead or no longer in the business, and Daz can't do anything with someone else's intellectual property. It is no different than when your favorite candy bar is no longer made; the grocery can't force the confectioner to keep making the candy bar. Many vendors plan to update their scripts as they want to cover every version, some will not, some will charge and some won't, and the best we all can do is try. Yes, people will be upset but it doesn't shift reality.
As I said before, the work is between an hour to several weeks, per product. The changes required wont be addressed by Daz as the changes are deep inside Qt and Qt-Script engine and cannot be "fixed" without breaking something else.
Script that are popular and has sold well will probably be updated, scripts that didn't, or that for example do something no longer needed will probably not. Scripts with GUI will require much more work as for example font sizes has changed, styles has changed, and a lot of GUI callbacks has changed to work with Qt 6+.
As a user without programmer knowledge, but with both 4.24.0.3 Beta and 6.25.17807 Alpha currently installed on my MacMini M4 and my Windows 11 computers I am assured that my scripts on the Beta are not messed with by the Alpha. I am the one who decides which product/script/plugin to attempt to use on the Alpha, not the programs. So far I have only tested three of Code66's scripts just to see if the Alpha will keep them in my Favorites from one update to another. If I need my scripts/plugins, I use my Beta then open the file in the Alpha if necessary. For the Mac it is the ability to use Filament that is the big plus. By contributing to the Alpha thread what you observe will only help improve it. I would help the PAs in testing but I am probably the last person they would want because I stumble around many scripts. But I will support their work fully no matter what form it arrives in. They provide a service I can not do myself.