Marionette object style malfunctions in Vectorworks 2024

[Anthony Esau]

Hello!

 

After updating to Vectorworks 2024 from the 2023 version, I am having an issue with a Marionette object style that I have used extensively previously. The purpose of it is to "clone" or duplicate the geometry of a symbol and then swap the textures. So it is essentially a symbol that has textures that can be changed per instance. 

 

Now in VW 2024, the styled Marionette object no longer changes the textures. If I convert it to an unstyled Marionette object it works though!

 

However, if I convert each instance to unstyled, the settings of which textures to replace in the Object Info Palette also change. So I would have to manually change them back to the correct textures that are specified. If the OIP settings persisted, I would simply convert all the objects to unstyled for my current project and move on. While looking for solutions, I created a custom plug-in object that performs the same task as the Marionette object and functions properly in Vectorworks 2024, so I would transition to using that instead of Marionette objects. 

 

A simplified demonstration file is attached. Is there a way to convert all the objects to unstyled and keep the OIP settings? Or can a Marionette object be replaced with a custom plug-in object (and transfer the OIP settings)? I'm not afraid of a little scripting if that might provide a solution but would have to weigh that complexity against brute force manually changing all objects. 

 

 

Clone symbol Marionette object bug demo file.vwx

[Anthony Esau]

I ask about workarounds in the last paragraph above, but ultimately a bug fix for Vectorworks would be a better solution. Can anyone else confirm if this is a bug? Or is there something that needs to be updated with the Marionette object to be compatible with the VW 2024?

[Anthony Esau]

Since my demo file is for a very specific use case and contains custom Marionette nodes, I put together a simpler example with all standard nodes to check if the problem was unique to that Marionette network or not. The attached file demonstrates that string input is broken when a style is created from a Marionette object. It uses only standard nodes.

Marionette string input issue demo.vwx

[Anthony Esau]

Continuing my monologue 😅

 

It looks like the issue arises from naming the String nodes with a prefix of a number and a space. In that last demo file, I named them "1 String," "2 String," "3 String," and "4 String." In the OIP, they all show up as "String" but are in sequential order. 

 

If they are named "String1," "String2," "String3," and "String4" then the Marionette object style functions properly. 

 

Unfortunately, in my attempts so far, the string inputs in the OIP for existing objects using the old style stick to the old String node names even when the Marionette object style is edited or even replaced. So there is a workaround for the broader bug, but not an efficient solution for my existing project.

[Anthony Esau]

Quick update: I submitted this to tech support and received the response that "This issue has been escalated as a bug and is currently being investigated by our engineering team."

[John Meunier]

I am having issues with a custom marionette object as well, works perfectly in V2023, but in V2024 breaks down.

Some aspects work and some don't 'spooky' behavior.

 

Thanks for submitting a bug.

[John Meunier]

Posting the objects that breaks in v2024.

Seems to work if the marionette object is not styled.

 

Downspout v2023.vwx