Daz Studio BETA - version 4.23.1.20!

felis

If you have used mesh grabber, and then made your morph on top, then I think Daz will reference the scene file.

I think you should have saved the mesh grabber changes as a morph first.

barbult

felis said:

If you have used mesh grabber, and then made your morph on top, then I think Daz will reference the scene file.

I think you should have saved the mesh grabber changes as a morph first.

I was pretty sick with pneumonia at the time I did that, and I don't remember exactly what I did. I don't know if I used Mesh Grabber in addition to Blender or not. I think I somehow tried to save a G9 morph into an autofitted G3 garment. I had saved a G9 asset of the garment fit to the base G9, but I must not have reloaded that before creating the body morph for VYK Dystopian Daisy.Then today I forgot that I had even saved the G9 version, and I autofitted the G3 version again, getting the missing file error. I redid it all properly today and deleted the old morph file. It works properly now.

ina

I've done the update about 100 times now. It worked after the first update except for a few scripts (e.g. Mesh Grabber Rotations Add-On (Win) was missing and other scripts and all favorites were no longer listed). I was working on several files and then Daz Studio Pro Beta crashed without warning when saving a render. A restart showed a bug and it wouldn't start again. After several attempts, the data got stuck at 368 or 463 or 470 (37%) and so no products were displayed and an hour timer was shown. The program didn't allow any input and the interface froze completely with a transparent white interface. The program could only be closed via Microsoft. English is not my native language and the help service is poorly done - I couldn't send a zip file. But I saved it. I've been using DAZ Studio almost since the beginning, but this was the worst update so far (sorry). It would be nice if you could just install the previous version. If so, where can I find help for this - I don't want to waste any more time until the error(s) are fixed.

Richard Haseltine

ina said:

I've done the update about 100 times now. It worked after the first update except for a few scripts (e.g. Mesh Grabber Rotations Add-On (Win) was missing and other scripts and all favorites were no longer listed). I was working on several files and then Daz Studio Pro Beta crashed without warning when saving a render. A restart showed a bug and it wouldn't start again. After several attempts, the data got stuck at 368 or 463 or 470 (37%) and so no products were displayed and an hour timer was shown. The program didn't allow any input and the interface froze completely with a transparent white interface. The program could only be closed via Microsoft. English is not my native language and the help service is poorly done - I couldn't send a zip file. But I saved it. I've been using DAZ Studio almost since the beginning, but this was the worst update so far (sorry). It would be nice if you could just install the previous version. If so, where can I find help for this - I don't want to waste any more time until the error(s) are fixed.

This sounds like an unlucky crash, possibly leaving damaged files, nothing to do with the new vesiuon specifically. Unfortunately we would need more information to give any real suggestions. You might try posting in your native language, with any luck someone will be able to understand.

Richard Haseltine

Dolce Saito said:

Emmm;
1- Working anything within surface tab feels like trying to hold freshly-picked avocado seed with wet hands. I try to catch it, it just jumps somewhere else. Pure comedy show there.

johndoe_36eb90b0 said:

Ooof... also clicking on a surface in Surfaces -> Editor always resets the scroll position of the surface property list to the top. You wanted to flip back and forth between two surfaces to compare dForce settings? No can do anymore.

crosswind said:

Oh, yes, when change the surface selection in Surfaces tab, the property list is refreshed to go back to the top.. This is really annoying.

There was no such issue in previous DS PB version as well as DS 4.22.

Apparently, if I don't garble this, the issue was that previously the scroll area was not being refreshed properly to reflect its new contenmt when switching object/surface - if the number of sliders was the same that seemed OK, since it kept the length of and psotion in the scrollable area the same, which is what we are generally used to - but it could give odd results sometimes (I have occasionally seen a property slider cut off, and I think others have had them inaccessible). So the previous behaviour was a bug not a feature - but a relatively benign one. Presumably "fixing" the issue would mean implementing a way to deliberately find the visible property or relative position and, if possible, scroll to that - but that will be a decision for the devs and product management, all we have been given so far is the explanation for the chnaged behaviour.

johndoe_36eb90b0

Richard Haseltine said:

Dolce Saito said:

Emmm;
1- Working anything within surface tab feels like trying to hold freshly-picked avocado seed with wet hands. I try to catch it, it just jumps somewhere else. Pure comedy show there.

johndoe_36eb90b0 said:

Ooof... also clicking on a surface in Surfaces -> Editor always resets the scroll position of the surface property list to the top. You wanted to flip back and forth between two surfaces to compare dForce settings? No can do anymore.

crosswind said:

Oh, yes, when change the surface selection in Surfaces tab, the property list is refreshed to go back to the top.. This is really annoying.

There was no such issue in previous DS PB version as well as DS 4.22.

Apparently, if I don't garble this, the issue was that previously the scroll area was not being refreshed properly to reflect its new contenmt when switching object/surface - if the number of sliders was the same that seemed OK, since it kept the length of and psotion in the scrollable area the same, which is what we are generally used to - but it could give odd results sometimes (I have occasionally seen a property slider cut off, and I think others have had them inaccessible). So the previous behaviour was a bug not a feature - but a relatively benign one. Presumably "fixing" the issue would mean implementing a way to deliberately find the visible property or relative position and, if possible, scroll to that - but that will be a decision for the devs and product management, all we have been given so far is the explanation for the chnaged behaviour.

Richard, the previous behavior you describe as a bug was the one any reasonable software user would expect -- most surfaces have same or similar enough shaders and properties that flipping back and forth between them was really useful when you want to compare or adjust something. For example if you wanted to check quickly which polygons belong to which surface on a clothing item you could have scrolled to cutout opacity and then set it to 0 to see what part of clothing will disappear. Or another example, flipping back and forth between surfaces and adjusting dForce parameters.

I agree that it was inconsistent when surfaces had different properties but the worst case was it didn't show the right property and you had to scroll a bit for that one surface and now you have to scroll always for every surface.

Furthermore, the "fix" just bad.

Not only it resets scroll position when you click on different surface but also when you adjust any of the sliders.

So sorry but no -- previous behavior was not a bug but this definitely is.

1. Moving sliders shouldn't reset scroll position for current surface (for me it does)
2. Switching surfaces shouldn't scroll to top if the last interacted property exists on the next surface as well.

Richard Haseltine

johndoe_36eb90b0 said:

Richard Haseltine said:

Dolce Saito said:

Emmm;
1- Working anything within surface tab feels like trying to hold freshly-picked avocado seed with wet hands. I try to catch it, it just jumps somewhere else. Pure comedy show there.

johndoe_36eb90b0 said:

Ooof... also clicking on a surface in Surfaces -> Editor always resets the scroll position of the surface property list to the top. You wanted to flip back and forth between two surfaces to compare dForce settings? No can do anymore.

crosswind said:

Oh, yes, when change the surface selection in Surfaces tab, the property list is refreshed to go back to the top.. This is really annoying.

There was no such issue in previous DS PB version as well as DS 4.22.

Apparently, if I don't garble this, the issue was that previously the scroll area was not being refreshed properly to reflect its new contenmt when switching object/surface - if the number of sliders was the same that seemed OK, since it kept the length of and psotion in the scrollable area the same, which is what we are generally used to - but it could give odd results sometimes (I have occasionally seen a property slider cut off, and I think others have had them inaccessible). So the previous behaviour was a bug not a feature - but a relatively benign one. Presumably "fixing" the issue would mean implementing a way to deliberately find the visible property or relative position and, if possible, scroll to that - but that will be a decision for the devs and product management, all we have been given so far is the explanation for the chnaged behaviour.

Richard, the previous behavior you describe as a bug was the one any reasonable software user would expect -- most surfaces have same or similar enough shaders and properties that flipping back and forth between them was really useful when you want to compare or adjust something. For example if you wanted to check quickly which polygons belong to which surface on a clothing item you could have scrolled to cutout opacity and then set it to 0 to see what part of clothing will disappear. Or another example, flipping back and forth between surfaces and adjusting dForce parameters.

I agree that it was inconsistent when surfaces had different properties but the worst case was it didn't show the right property and you had to scroll a bit for that one surface and now you have to scroll always for every surface.

Furthermore, the "fix" just bad.

Not only it resets scroll position when you click on different surface but also when you adjust any of the sliders.

So sorry but no -- previous behavior was not a bug but this definitely is.

1. Moving sliders shouldn't reset scroll position for current surface (for me it does)
2. Switching surfaces shouldn't scroll to top if the last interacted property exists on the next surface as well.

being preferable to the current behaviour doesn't mean that the old behaviour wasn't the result of a bug. Nor does the current state being a fixed version with respect to that bug mean they will not reimplement the way it used to behave, but without the bug and without the oddities.

johndoe_36eb90b0

Richard Haseltine said:

being preferable to the current behaviour doesn't mean that the old behaviour wasn't the result of a bug. Nor does the current state being a fixed version with respect to that bug mean they will not reimplement the way it used to behave, but without the bug and without the oddities.

I don't know about Daz developers, but being a software engineer myself I'd like to point out the following:

1. To consider something a bug, you first have to define what is expected behavior. Clearly, the behavior expected by the users (judging from the number of complaints in the thread) is that the list keeps its position when surface selection changes. The developers' idea that correct behavior should be scroll to the top is therefore divorced from reality and suggests they rarely use the application themselves.

2. Once you identify expected behavior you proceed to identify incorrect behavior. In this case, the incorrect behavior wasn't the property list not scrolling to the top on surface switch -- it was only incorrect when switching to a surface whose shader was different and had different number and/or order of properties.

So, what you call a fix I call a regression because part of previous behavior was correct and now all of it is incorrect.

Richard Haseltine

johndoe_36eb90b0 said:

Richard Haseltine said:

being preferable to the current behaviour doesn't mean that the old behaviour wasn't the result of a bug. Nor does the current state being a fixed version with respect to that bug mean they will not reimplement the way it used to behave, but without the bug and without the oddities.

I don't know about Daz developers, but being a software engineer myself I'd like to point out the following:

1. To consider something a bug, you first have to define what is expected behavior. Clearly, the behavior expected by the users (judging from the number of complaints in the thread) is that the list keeps its position when surface selection changes. The developers' idea that correct behavior should be scroll to the top is therefore divorced from reality and suggests they rarely use the application themselves.

The expected/intended behaviour was that the content of the pane reflect the state of the proerpties. It doesn't, so that is a bug. A side-effect of the bug is that it was keeping the list positioned in a helpful manner. The desirability of the side effect doesn't mean that the failure to function correctly ceases to be a bug - it merely shows that the previous behaviour was, in that repect, desirable and, we may hope, gets reinstating that behaviour added to the development plan.

2. Once you identify expected behavior you proceed to identify incorrect behavior. In this case, the incorrect behavior wasn't the property list not scrolling to the top on surface switch -- it was only incorrect when switching to a surface whose shader was different and had different number and/or order of properties.

So, what you call a fix I call a regression because part of previous behavior was correct and now all of it is incorrect.

This does not seem a wise approach to development - even if it causes issues in only specific places it is an issue, and it may well come back to haunt the project at a later date (when people may have to figure out what is going on from scratch). The problem behaviour has been resolved and that now gives a stable position from which further work can be done (but  how soon, or even if, obviously depends on risk and ressource requirements)..

johndoe_36eb90b0

Richard Haseltine said:

The expected/intended behaviour was that the content of the pane reflect the state of the proerpties. It doesn't, so that is a bug.

It doesn't how? It was showing properties of the second / third / nth surface as you clicked on them AND it kept the position. If one surface shader was different then it wasn't showing properties of that surface at the same position but scrolling that one list into view was less of an issue than this "fix" which forces you to scroll every single time for every surface.

Richard Haseltine said:

This does not seem a wise approach to development - even if it causes issues in only specific places it is an issue, and it may well come back to haunt the project at a later date (when people may have to figure out what is going on from scratch). The problem behaviour has been resolved and that now gives a stable position from which further work can be done (but  how soon, or even if, obviously depends on risk and ressource requirements)..

I am not advocating for not fixing the issue -- I am disputing what the issue was to begin with and I am arguing that the fix shouldn't have been partial and done in two steps while exposing users to extreme inconvenience. Hence the regression label.

Richard Haseltine

johndoe_36eb90b0 said:

Richard Haseltine said:

The expected/intended behaviour was that the content of the pane reflect the state of the proerpties. It doesn't, so that is a bug.

It doesn't how? It was showing properties of the second / third / nth surface as you clicked on them AND it kept the position. If one surface shader was different then it wasn't showing properties of that surface at the same position but scrolling that one list into view was less of an issue than this "fix" which forces you to scroll every single time for every surface.

Richard Haseltine said:

This does not seem a wise approach to development - even if it causes issues in only specific places it is an issue, and it may well come back to haunt the project at a later date (when people may have to figure out what is going on from scratch). The problem behaviour has been resolved and that now gives a stable position from which further work can be done (but  how soon, or even if, obviously depends on risk and ressource requirements)..

I am not advocating for not fixing the issue -- I am disputing what the issue was to begin with and I am arguing that the fix shouldn't have been partial and done in two steps while exposing users to extreme inconvenience. Hence the regression label.

It isn't a "two part fix" - they fixed an issue, apparently without realising the consequence or at least its impact (I am not certain of this) and are now at least considering how to deal with the consequences (but I don't have any promises or timelines). A regession implies a bug, the consequences may be undesirable - and if product development agrees that they are we may hope they will be fixed - but they are no a bug per se.

johndoe_36eb90b0

Perhaps an analogy will help.

Imagine if a mouse vendor said "our mouse firmware sometimes didn't register right click properly so we have released a fix which temporarily swaps your mouse buttons so that your right click is now always properly registered."

Never mind that you used left button way more often than the right, but now your right one is "fixed".

Don't worry though, next update might fix the "fix". You just need to put up with broken left button for a couple of weeks longer.

Richard Haseltine

johndoe_36eb90b0 said:

Perhaps an analogy will help.

Imagine if a mouse vendor said "our mouse firmware sometimes didn't register right click properly so we have released a fix which temporarily swaps your mouse buttons so that your right click is now always properly registered."

Never mind that you used left button way more often than the right, but now your right one is "fixed".

Don't worry though, next update might fix the "fix". You just need to put up with broken left button for a couple of weeks longer.

That is clearly not the same thing. In any event it is out of our hands, so arguing the toss is not going to achieve anything.

ina

Richard Haseltine said:

ina said:

I've done the update about 100 times now. It worked after the first update except for a few scripts (e.g. Mesh Grabber Rotations Add-On (Win) was missing and other scripts and all favorites were no longer listed). I was working on several files and then Daz Studio Pro Beta crashed without warning when saving a render. A restart showed a bug and it wouldn't start again. After several attempts, the data got stuck at 368 or 463 or 470 (37%) and so no products were displayed and an hour timer was shown. The program didn't allow any input and the interface froze completely with a transparent white interface. The program could only be closed via Microsoft. English is not my native language and the help service is poorly done - I couldn't send a zip file. But I saved it. I've been using DAZ Studio almost since the beginning, but this was the worst update so far (sorry). It would be nice if you could just install the previous version. If so, where can I find help for this - I don't want to waste any more time until the error(s) are fixed.

This sounds like an unlucky crash, possibly leaving damaged files, nothing to do with the new vesiuon specifically. Unfortunately we would need more information to give any real suggestions. You might try posting in your native language, with any luck someone will be able to understand.

Nach Absturz des Programms zeigte Window 10 Daz Studio nicht mehr an, Neustart und Neuinstallation erst über DAZ Install Manager (64-bit) versucht, die Windowoberfläche bleibt in der Taskleiste hängen und auf der Oberfläche werden nur vereinzelt Popup-Fenster gezeigt und irgendwann friert die Oberfläche ein. 
Das Programm lässt sich nicht sauber deinstallieren und wird nicht in Win 10 unter Programme aufgelistet, aber im Startmenü angezeigt.  DAZ Installmanager funktioniert, PostgrrrreSQL CMS - letzte Version. Manueller Versucht der Installation funktionierte auch nicht. Die Benutzeroberfläche bleibt in der Taskleiste hängen und wird nur als Miniaturbild angezeigt - davon kann man aber kein Screenshot machen - wenn man den Quickstart durchführt wird eine Lektion angezeigt (im Miniatiurbild).
Ich hatte mit der vorhergehenden Beta-Version Null Probleme, das Update funktionierte bis ich das erste Mal einen Render erstellte der genau 2 Stunden renderte, komplett und sauber angezeigt wurde und beim Speichern abstürzte. Ich sehe hier einen Zusammenhang mit dem Update, irgendetwas war da nicht in Ordnung. Siehe Bilder im Anhang. 

 

 

 

Richard Haseltine

That sounds as if the crash damaged one of the files in a way that means it cannot be removed, and so the reinstallation cannot complete nor can the application launch. Without the text to translate it is hard to be sure, but the message might implicate libpq.dll

Richard Haseltine

Richard Haseltine said:

johndoe_36eb90b0 said:

Richard Haseltine said:

The expected/intended behaviour was that the content of the pane reflect the state of the proerpties. It doesn't, so that is a bug.

It doesn't how? It was showing properties of the second / third / nth surface as you clicked on them AND it kept the position. If one surface shader was different then it wasn't showing properties of that surface at the same position but scrolling that one list into view was less of an issue than this "fix" which forces you to scroll every single time for every surface.

Richard Haseltine said:

This does not seem a wise approach to development - even if it causes issues in only specific places it is an issue, and it may well come back to haunt the project at a later date (when people may have to figure out what is going on from scratch). The problem behaviour has been resolved and that now gives a stable position from which further work can be done (but  how soon, or even if, obviously depends on risk and ressource requirements)..

I am not advocating for not fixing the issue -- I am disputing what the issue was to begin with and I am arguing that the fix shouldn't have been partial and done in two steps while exposing users to extreme inconvenience. Hence the regression label.

It isn't a "two part fix" - they fixed an issue, apparently without realising the consequence or at least its impact (I am not certain of this) and are now at least considering how to deal with the consequences (but I don't have any promises or timelines). A regession implies a bug, the consequences may be undesirable - and if product development agrees that they are we may hope they will be fixed - but they are no a bug per se.

Check the change log (currently the last entry, which doesn't have a version number yet but folows 4.23.1.18) http://docs.daz3d.com/doku.php/public/software/dazstudio/4/change_log

• Side Nav Property Views now attempt to maintain visible properties in the Property View when selection in the Side Nav View changes

  • A list of the visible properties is captured immediately before the Property View is rebuilt

  • Immediately after rebuilding, the first match (if any) in the captured list is scrolled to

  • The scrolled amount/position of the scrollbar is not guaranteed to match the previous amount/position due to changes in list length and/or order

  • If no match is found, or the list is shorter than the visible area, no scrolling occurs

barbult

What is the AutoSave that is mentioned throughout the recent changelog notes?

crosswind

barbult said:

What is the AutoSave that is mentioned throughout the recent changelog notes?

It's a new plugin binded with Premier tier. In general, it can incrementally save the current scene, Layout and Script IDE to a designated folder with intervals that you defined. As per below screenshot, for your ref.

I think this plugin better be included in next General Release ~~

Besides, this Auto Save has no background job (at least by now...), the moment the countdown time reaches the pre-defined interval, saving progress dialogue jumps out... It's a bit annoying. Why not make it as a background job ?

barbult

Thank you for the explanation.

Richard Haseltine

crosswind said:

barbult said:

What is the AutoSave that is mentioned throughout the recent changelog notes?

It's a new plugin binded with Premier tier. In general, it can incrementally save the current scene, Layout and Script IDE to a designated folder with intervals that you defined. As per below screenshot, for your ref.

I think this plugin better be included in next General Release ~~

Besides, this Auto Save has no background job (at least by now...), the moment the countdown time reaches the pre-defined interval, saving progress dialogue jumps out... It's a bit annoying. Why not make it as a background job ?

Because that would entail a major rework of the architecture, with all the consequent risks and development time.

crosswind

barbult said:

Thank you for the explanation.

NP !

crosswind

Richard Haseltine said:

crosswind said:

barbult said:

What is the AutoSave that is mentioned throughout the recent changelog notes?

It's a new plugin binded with Premier tier. In general, it can incrementally save the current scene, Layout and Script IDE to a designated folder with intervals that you defined. As per below screenshot, for your ref.

I think this plugin better be included in next General Release ~~

Besides, this Auto Save has no background job (at least by now...), the moment the countdown time reaches the pre-defined interval, saving progress dialogue jumps out... It's a bit annoying. Why not make it as a background job ?

Because that would entail a major rework of the architecture, with all the consequent risks and development time.

Okay, I understand ~~ though some QT developer friends of mine thought the auto-saving process could be easily coded to silent ~~

crosswind

The property positioning issue in Surfaces pane has been fixed in the latest DS PB - 4.23.1.20. Thank you very much, Dev. TEAM !!

Richard Haseltine

crosswind said:

The property positioning issue in Surfaces pane has been fixed in the latest DS PB - 4.23.1.20. Thank you very much, Dev. TEAM !!

Rather, a completely new feature has been added to replace an accidental side-effect of a bug - it was not a matter of simply restoring what was there before.

crosswind

Richard Haseltine said:

crosswind said:

The property positioning issue in Surfaces pane has been fixed in the latest DS PB - 4.23.1.20. Thank you very much, Dev. TEAM !!

Rather, a completely new feature has been added to replace an accidental side-effect of a bug - it was not a matter of simply restoring what was there before.

I didn't check the change log but I've just checked it. Right, I'm glad to see it was improved with the enhancement and it works well ! It's great !!

crosswind

Then I wonder... when the low performance issue of adding / deleting Lights and Cameras in PB can be resolved / improved ~~~~~~~~~~~~ AHAHAHAHAH, I wish that day comes soon !!

barbult

Since I installed 4.23.1.18 and now 4.23.1.20, I get into a situation where Iray Render Settings Presets won't apply. No error is displayed, but the Environment Settings don't change. I have tied to apply both HDRI presets and Sun-Sky Only presets. I'll try to get more specific information next time it happens. I have to restart Daz Studio to get it to work again.

Has anyone else experienced this?

crosswind

barbult said:

Since I installed 4.23.1.18 and now 4.23.1.20, I get into a situation where Iray Render Settings Presets won't apply. No error is displayed, but the Environment Settings don't change. I have tied to apply both HDRI presets and Sun-Sky Only presets. I'll try to get more specific information next time it happens. I have to restart Daz Studio to get it to work again.

Has anyone else experienced this?

Unfortunately, same issue happened on my side as well... 

barbult

How can I track down the source of these [WARNING] messages in the log when I start DS 4.23.1.20?

2025-01-17 00:15:32.174 [INFO] :: Loading Actions: C:/Users/Barb/AppData/Roaming/DAZ 3D/Studio4 Public Build/actions.dsx
2025-01-17 00:15:32.218 [INFO] :: Loading Custom Actions: C:/Users/Barb/AppData/Roaming/DAZ 3D/Studio4 Public Build/customactions.dsx
2025-01-17 00:15:32.237 [WARNING] :: \src\sdksource\interface\actions\dzactionmgr.cpp(2742): No file or script specified for custom action '97a02b64-c41a-4add-b3f0-672a552f4776' in interface file.
2025-01-17 00:15:32.237 [WARNING] :: \src\sdksource\interface\actions\dzactionmgr.cpp(2742): No file or script specified for custom action 'ea99a9d8-3a25-4e92-8f0e-bc1d36567bbe' in interface file.
2025-01-17 00:15:32.238 [WARNING] :: \src\sdksource\interface\actions\dzactionmgr.cpp(2742): No file or script specified for custom action 'f95a7549-0906-4bea-b23d-05ce9c40c6fb' in interface file.
2025-01-17 00:15:32.239 [INFO] :: Loading Menus: C:/Users/Barb/AppData/Roaming/DAZ 3D/Studio4 Public Build/menus.dsx
2025-01-17 00:15:32.269 [INFO] :: Loading ToolBars: C:/Users/Barb/AppData/Roaming/DAZ 3D/Studio4 Public Build/toolbars.dsx

Edit: Oh, maybe I can figure it out by looking in the C:/Users/Barb/AppData/Roaming/DAZ 3D/Studio4 Public Build/customactions.dsx file.

Edit 2: No, I couldn't find any info about what they should have been, so I just deleted those entries and resaved the file (while DS was closed).

 

barbult

crosswind said:

barbult said:

Since I installed 4.23.1.18 and now 4.23.1.20, I get into a situation where Iray Render Settings Presets won't apply. No error is displayed, but the Environment Settings don't change. I have tied to apply both HDRI presets and Sun-Sky Only presets. I'll try to get more specific information next time it happens. I have to restart Daz Studio to get it to work again.

Has anyone else experienced this?

Unfortunately, same issue happened on my side as well... 

Uh oh. Thanks for the confirmation of the problem. I'll file a bug report tomorrow.