Marionette - Versioning System

[Kevin McAllister]

Versioning is going to become important with Marionette nodes. See here - https://techboard.vectorworks.net/ubbthreads.php?ubb=showflat&Number=220305#Post220305

I wish for the following -

1) There should be a line of code you can add at the beginning of a marionette node's script that is recognized by VW as the nodes version (version # + date).

2) The version text should show automatically for any given node as read only text in the OIP (see Landru plugins).

3) When the debug tool is activated it should provide a tooltip showing a node's version when hovering over the node name.

and

4) The VW Developer Wiki should also have a maintained list of official Marionette nodes and their current versions.

Kevin

[PVA - Admin]

This is actively being discussed for a number of reasons both internal and external. At the moment I think its more a matter of HOW the versioning system is implemented rather than if it will be. Forwarding this thread to the engineers working on it.

[Kevin McAllister]

Thanks Jim.

KM

[Dieter @ DWorks]

This is actively being discussed for a number of reasons both internal and external. At the moment I think its more a matter of HOW the versioning system is implemented rather than if it will be. Forwarding this thread to the engineers working on it.

I really wonder why this wasn't seen as one of the basic feature that really needs to be there? We all know that Marionette has been developed untill the end, even changed a lot at the end too.... I guess it had to be rushed in the end?

Ow, and this may be personal, but the gradient of the nodes really is looking bad, and sometimes makes the texts not very readable....

Edited December 9, 2015 by Dieter @ DWorks

[PVA - Admin]

Mainly because its STILL being developed.

As opposed to many previous years where critics pointed out that we released new features and then they sat by the sidelines next version, a LOT of focus is being placed on 2.0, 3.0 etc versions of new tools and systems that we include, where we take all the initial and inevitable feedback when features hit the public and then add those in addition to anything that was originally planned but didn't make the cut.

The simple answer is "time" but fortunately things are being handled far superior to how they were in the past in regards to placing focus on existing tech upgrades.

[Dieter @ DWorks]

Mainly because its STILL being developed.

As opposed to many previous years where critics pointed out that we released new features and then they sat by the sidelines next version, a LOT of focus is being placed on 2.0, 3.0 etc versions of new tools and systems that we include, where we take all the initial and inevitable feedback when features hit the public and then add those in addition to anything that was originally planned but didn't make the cut.

The simple answer is "time" but fortunately things are being handled far superior to how they were in the past in regards to placing focus on existing tech upgrades.

I don't mind that tools aren't finished yet, but the basics need to be there, which means it needs to be fully usable, with just a few options, nothing more. Then you can enhance it. From my experience as a software engineer, I know that adding a versioning system now will be very hard....

Imho, working agile works, but it needs to be done right.

Edited December 9, 2015 by Dieter @ DWorks

[PVA - Admin]

I don't mind that tools aren't finished yet, but the basics need to be there, which means it needs to be fully usable, with just a few options, nothing more. Then you can enhance it. From my experience as a software engineer, I know that adding a versioning system now will be very hard....

Imho, working agile works, but it needs to be done right.

I feel thats partly an unfair criticism. Marionette is certainly usable as it is currently without a versioning system. From my talks with engineering, adding a versioning system after the fact is more difficult, but not as bad as making Marionette sit on the bench for another yearly release cycle.

I do see your point, honestly, but its really just a matter of differing opinions on when something can go out the door. I'm not part of the teams that make those choices, but I have seen enough releases to know that if it hadn't been node versioning, it would have been slider bar ability, on-node input boxes or some other feature that was seen as "This seems like it should have been here from the beginning."

Subdivision also got that treatment, converting solids/meshes INTO Subdivision objects was almost included in 2016, but it just wasn't ready for the public. But as-released, Subdivision is still a very useful tool that I've already seen many users start to benefit from even without that ability.

On a more personal note, I almost disagree with the text I've just written above....

I am a HUGE proponent of "Take longer but knock it out of the park" as well as the concept of taking an entire release cycle to just improve existing technology. Regardless of that personal viewpoint, it's someone else's job to pick which features go public and when, and by and large they make the right calls the majority of the time. A lot of the reasons behind feature decisions are back-end and not something that can be posted about publicly here. While I am a strong proponent of more openness from us as a company, I understand that some things are internal business and need to be kept that way.

I try to walk the line between defending our actions with legitimate reasons and publicly accepting any failings, its not been easy but all told, its been an improvement. Sorry for the random tangent, my last cup of coffee must be wearing off, I just wanted to make it clear that these decisions aren't made lightly. A lot of different factors come into play and even if it doesn't seem like it, the largest concern is always you folks. There are passionate people here that stand up for user experience and ease of use on a regular basis and expound the virtues of good design, I really wish that was something I could show you directly.

[Marissa Farrell]

I just wanted to make it clear that these decisions aren't made lightly, a LOT of different factors come into play and even if it doesn't seem like it, the largest concern, is always you folks. There are passionate people here that stand up for user experience and ease of use on a regular basis and expound the virtues of good design, I really wish that was something I could show you directly.

I want to second this statement. I work with the Quality Assurance team, as my primary position, and there are a few of us who are obnoxiously passionate about improving user experience. Unfortunately, things take time and we need to get our opinions further up the food chain in order for anything to really make it into the software.

My personal on-the-side project is improving Marionette as a whole, my current contribution is making sure that the default content that we ship with is up to par, and unfortunately a lot of iffy stuff slipped through the cracks, but we are definitely working to clean it up.

Version control has been near the top of our list as to improvements for Marionette, and although it won't have been implemented at the beginning as it should have been, we can take the current status of the nodes and consider that our 'first version', once we all decide that's the way to go. Sure, it may not entirely reflect how many times we've edited it up to now, but it at least helps us moving forward.

I also want to make it very clear that Marionette is VERY MUCH in working condition. There is absolutely nothing preventing a user to create a network and have it do as he/she wishes. I will honestly say that there are currently nodes that aren't up to par, but that in no way prevents usability of Marionette on its own.

[Dieter @ DWorks]

Sorry if I sounded harsh, it wasn't meant that way. I never said that Marionette couldn't be used in it's current version. I just stated what I felt about it, only knowing what I read on these forums.

[Kevin McAllister]

I'm going to wade in since I'm the first person who asked about this back in September soon after it was released - https://techboard.vectorworks.net/ubbthreads.php?ubb=showflat&Number=216140#Post216140

I am not at all a programmer. The reason why I originally posted my question was based on personal experience with drawing sets where versioning is immensely important. In the first few days of using Marionette I had new versions of NV nodes posted in the forums to fix problems plus multiple versions of my own nodes or scripts. Marionette is targeted at non-programmers. I can imagine as time goes on there will be a deluge of questions from newbies like me when a Marionette node or network doesn't work. I worry about how much troubleshooting resource (end user, developer, tech support) will be spent on finding problems caused by deprecated or outdated nodes with no way to identify them. Time that is already in short supply (see my wish to clone Jim).

I makes me want to make another wish - an update nodes to current version command - much like update plugin objects.

Kevin

[Dieter @ DWorks]

... but not as bad as making Marionette sit on the bench for another yearly release cycle.

Umm, I thought that from now on VW would be updated regularly? Or is this still something you guys wish to go to in the future? It defenetely has been talked about.

[PVA - Admin]

Umm, I thought that from now on VW would be updated regularly? Or is this still something you guys wish to go to in the future? It defenetely has been talked about.

We're sort of between states at the moment. Before now, there were few "new features" added between major releases since 2007, other than some instances of adding new DWG export versions or improving IFC export in service packs. But we rarely added new capabilities to existing tools, like Door Operation types or Site Model 3D graphics modes.

Marionette is a special case, and is the first time where new capability is being semi-regularly added to a tool without waiting for the release of a full version. This is mainly because content (Normally referring to things like Plants, Lighting Instruments or Entourage figures) for Marionette is the same thing as adding new abilities to it.

A feature such as a versioning system or an auto-update ability for nodes is still something that would likely come in a yearly release, whereas adding more node types like Numbered List is something that can happen in between versions in service packs or just casually handed out here on the forums.

I can imagine as time goes on there will be a deluge of questions from newbies like me when a Marionette node or network doesn't work. I worry about how much troubleshooting resource (end user, developer, tech support) will be spent on finding problems caused by deprecated or outdated nodes with no way to identify them. Time that is already in short supply (see my wish to clone Jim).

I makes me want to make another wish - an update nodes to current version command - much like update plugin objects.

This was a major concern of Technical Support as well. In prior years, anything related to scripting was not covered by support directly and not part of regular support staff training. Now that its become abundantly clear that Marionette is going to play a major role in the software from here on, that will probably have to change.

To start with, I want a large array of reference materials for non-coders and newcomers, most likely starting with a Primer as mentioned in another thread, eventually moving to more specific tutorials. As these materials are developed, the info will be pushed out to Tech Support and other departments and the average level of competency using Marionette both here at the company as well as in our user base will rise and it will become easier to quickly get answers to common questions in more than one place.