Autodesk Licence

Getting “you’re not signed in” errors during syncing, except that I am still signed in so something is going on with licencing.
Have all Revit addins disabled, and this problem seems to happen only after I’ve used Dynamo.
Several of us often work over VPN however I seem to be the only one experiencing this. I’m also likely the only VPN users who actually uses Dynamo.

Just so I can rule it out or investigate further, is it at all possible that Dynamo could be causing issues with my Revit licencing? Google says Dynamo uses the same licence as the active session.

Revit 2025.4.5 & Dynamo 3.3.0.6523 and it happens with several projects.

TIA for any help.

Try disabling your Dynamo customizations to see if one of them is breaking things. If that doesn’t work submit a ticket to support via the accounts portal at manage.autodesk.com as the teams there are the ones who can troubleshoot that component.

Thanks Jacob, it does seems to be a dynamo add on issue as removing them all seems to stop the issue from happening. I guess I’ll have to go through each one when I can to figure out which it is.

These are the packages I had installed-

Using a Binary Search you can likely identify the culprit in at most 4 tests.

Test 1: 1-6, omitting 7-11. If the issue repeats you have narrowed it down to the first half of the packages. If not you have narrowed it down to the second half.
Test 2: First half of the failing half (first or second half), omitting the passing half (the second or first half). Effectively testing 1/4 of the dataset now.
Test 3: First half of the failing quarter from the second test (first or second quarter), omitting the passing quarter (second or first quarter). Effectively testing an eighth of the dataset now. At this point you have a dataset of 2 that you are testing, and if that doesn’t reproduce the issue you know the failure is in the half you didn’t test.
Test 4: First half of the failing eighth from the 3rd test (first or second eighth), omitting the passing eighth (second or first eighth). Effectively testing 1/16th of the dataset now, which is enough to know the single failure.

I highly recommend learning this technique for error handling.

nice strategy i saw someone during covid tweeted binary search for covid patients

Yeah - when things get as complex as virus transmission the process gets more complicated (how does one identify a ‘pass’ retroactively given you can only test once? what about false positive tests, exposure but not transmission, multiple exposures, etc.?), but it’s useful to keep in mind with large datasets that can return a ‘pass fail’ for the collection, as well as a bunch of ‘core’ computational aspects of collections (i.e. find the item in a sorted list). Given a dataset of 1024 items where only one value ‘fails’ you can identify the failure in only 10 tests (512 in the first test; 256 in the second; 128 in the 3rd, 64 in the 4th, 32 in the 5th, 16 in the 7th, 8 in the 8th, 4 in the 9th, 2 in the 10th resulting in finding the issue or confirming the opposite - add an 11th if you want to assure confirmation).

big o notation :wink:

For those unaware - Video #1 in this MIT OpenCourseWare series has a good summarization of what @sovitek has mentioned above: Introduction to Algorithms | Electrical Engineering and Computer Science | MIT OpenCourseWare

Whole series is worth a watch for those who are getting deeper into computational design.

For those who don’t want to get the full education, algorithms are typically sorted into 5 sets of time -

  1. Constant Time - referred to as O(1) where time to execute a tasks grows linearly against the size of the dataset. Things don’t get much faster than this, but generally these problems are VERY simple. Getting an item from a list given the index of the item - the List.GetItemAtIndex node. You can’t really get faster than this.

  2. Logarithmic Time - referred to as O(logn) where time to execute a task grows slowly, often cutting the problem size down at each step. Binary search is an example of this for computational terms, and in Dynamo the graphs which sequentially reduce the data size by List.FilterByBoolMask are a sort of example of this, but I don’t have a single clear case offhand.

  3. Linear time - referred to as O(n) where time execute is directly proportional to the size of the dataset - searching an unsorted list is a good example of this, such as the Dynamo node List.IndexOf.

  4. Quadratic Time - referred to as O(n^2) where time to execute is the square of the input. Graphs which pull geometry from two lists of elements and then attempt to find the intersections via cross product of each are a good example of this.

  5. Exponential Time - referred to as O(2^n) where time doubles with each element. Code which approach this time set are usually impractical for large datasets in any language, doubly so with Dynamo. Once you reach this level I usually find that moving to other means of problem solving makes sense (i.e. using Generative Design to solve layouts where each item placed doubles the number of items to account for).

The goal of most algorithms is to reduce the complexity to get results faster.

For Dynamo users keeping to lower levels of complexity will help keep things running faster. Most ‘validation’ and ‘data’ tasks can be completed in the first 3 levels of complexity. Geometry processing can be linear if you’re creative about it, or quadratic if not (Geometry.Intersect(n,Solid.ByUnion(m)) is linear time while Geometry.Intersect(n<1>,m<2>) is quadratic). And most design tasks are Exponential Time (or greater - the wicked problems where in a series of decisions each decision results in infinite possible subsequent decisions).

thx…nice :wink: