Deprecated Rhythm node?

rhythm

#1

I’ve got Rhythm 2018.6.7 installed & now I’m getting a “Node not found” for
GetParameterValueByNameAsString
Has that node been removed from that version of Rhythm?
(Please forgive me for not finding this info on github. Does anyone had a primer on github & how to understand version control there?)

I presume that node has been replaced by something else (OOTB?), but I tried the built-in Element.GetParameterValueByName
That node works, but sometime requires an additional “String from Object” node


#2

Yeah I dropped that node. Sorry about that. :grimacing:

In regards to “An Intro to GitHub”, I don’t know of anything that is really geared towards our industry. I actually proposed an AU class for this, so hopefully it gets the votes needed or whatever. :slight_smile:

The alternate method to use is the one you indicated, (that is actually all my node did),

Apologies for the few broken nodes lately as well. I am working on getting rid of all DYFs from my package as it is far easier for me to manage/update when all of the nodes are ZeroTouch(C#). This has also resulted in my package being managed primarily on BitBucket for the C# stuff and on GitHub for the other nodes.

Adding to this complexity are the changes in Dynamo 2.0.x versus 1.3.x. I am trying to get ready for an upgrade but want to make sure to have backwards compatibility. Getting rid of the DYFs helps ensure this.The reason being, I really do not want to have Rhythm for Dynamo 1.3.x and Rhythm for Dynamo 2.0.x.


#3

Yeah, there’s something going on with the package manager and the latest nodes. My dynamo 2.0 will barely even open and crashes every…single…time…I try to do something. Lunchbox is having similar problems, Nate just posted something. Not sure what happened but not too happy about it.
Thanks for your quick responsiveness John!


#4

I believe that Lunchbox errors are solved. Nathan uploaded a new version some days ago where he removed the “DynamoServices.dll” from the Lunchbox package.

Removing “DynamoServices.dll” solved the issues I reported at Dynamo DS Github, issues there was influencing my package. In general, nobody should include the “DynamoServices.dll” in a package or other dynamo assemblies.

@john_pierson, using Github for releasing your package will solve the issue to maintain a package for 1.3.0+ and 2.0.0+. You cant use .net 4.7 for 1.3.0 versions, so if you want to build a common version, then you have to use an older .net version for a long time.


#5

How is the user experience managing your package in this manner though? Most users will not go to Github to download a package from the releases page.

The package manager (as broken as it is), is a simple way for a user to just install a package without having to figure out a lot of other things.

-John


#6

I noticed that Dynashape did use Github and have never used the Package Manager. That goes apparently very well, I have never seen any complaints about that. The support for Dynashape is limited to a readme guide for installing.

However, I have had some complaints, whether this is due to I have more inexperienced users concerning dynamo or computer system management do I not know. Therefore did I create an executable installer, and that seems to do the job. For those that still might not able to figure out how to install do I not have any further help to offer.

I took this step since I was unsatisfied with the Package Manager and the Dynamo Team do not really listen when complaints are put up. You get a message that things are not prioritized. Giving me those messages means that I solve problems by my self if I can. Moving to Github was easy.

The Dynamo Team must find that as being acceptable since Long became a moderator with the speed of lightning, his record in the community is much shorter than mine and he has a much more limited participation than I. So you can apparently become accepted in the inner circle doing nothing and using nothing from the community. Therefore, I am now doing whatever I feel suits me if the Dynamo team think that is not supporting it is their problem. They need to think about their behavior because that is paving how they are acted upon.

So I took the stand that I had to move out and I don’t return to the package manager before the team wake up and make it doable again. Their behavior means that I will go my own ways until they fix the problems I put up.

Sadly as it can be said I think @Konrad_K_Sobon is right… Revit crashing when adding Package Path in Dynamo 2.0.1 and Revit crashing when adding Package Path in Dynamo 2.0.1

The shared and common understanding is dead. Dynamo has become Autodesk and that is not meant positive. Autodesk, in general, is one of the most tone-deaf companies I have meet… unless you are Disney.


#7

Long met the Dynamo team at a Hackathon in Munich (and knew them previously I am pretty sure). He developed Dynashape at that hackathon using quite a bit of guidance from the team and libraries supplied by the Open Source community. Saying he hasn’t contributed anything is pretty unfair to be honest. Also, I am pretty sure he became a moderator primarily to interact with his post regarding development announcements of Dynashape.

That being said, the package manager definitely needs work and I agree 100% on that. I do feel that it needs this work because the Dynamo team didn’t expect us all to use it in the manner we are. I spoke with the team once and they originally thought people would share “one-off” DYFs on it, and not whole suites of packages. :slight_smile: I think this is a good thing because we(the Dynamo community) are showing them how we want to use their software, and that can definitely lead to change.


#8

I agree with @john_pierson, there is no reason to take shots at Long here. He has done nothing wrong.

There is a reason he’s using GitHub Releases for this. His package as far as I know uses a View Extension to interact with the 3D Preview. These extensions have to be installed into a different folder than one that normal packages go into, hence Package Manager is not suitable for distribution.


#9

I don’t shoot at Long… But being a moderator is not about having an advanced package or not, it should only be about participation and contribution to the community with guidance and problem-solving. Knowing the Dynamo Team and been honored for that is problematic as I see it.

This is not Longs fault, it is a poor decision from the Dynamo Team. I have to admit that this decision has had an impact on how I act. I am always on guard for appointments made as an act of friendship.

Why is someone like Thomas Mahon, Mostafa El Ayoubi, Mostapha, Taco Pover, Cesare Caoduro, even Nathan Miller and Andreas Dieckmann… and myself (there is surely many more to mention), why are they/we not appointed Moderators if it is popular packages that need author guidance? No the Dynamo Team is on a wrong track here!

No matter why or what, Dynashape is released at Github, likewise is my package. Lets see what happens. I hope the best for all the users that the package manager will be “updated”.