Пока могу посоветовать в обще порядке (без привязки к Ревит/Динамо): удалить Динамо средствами спец.утилит типа Revo Uninstaller и ему подобным. Авось они лучше подчистят Windows от следов Динамо перед повторной установкой.
P.S. Сам пока не сталкивался с таким глюком.

Ну, его скрипт у меня тоже есть (имя Legantmar не знал). Буду смотреть/изучать. Для общего развития.

Alex Ward, я и здесь готов поблагодарить за твой труд! Твой совет из ответа на Ютубе применить пока не могу, т.к. ещё не дорос до “понимания” API. Это задача на будущее. Поэтому адаптация под 2015-й Ревит зашла в тупик. Что ж, не всё ревитчику м…[Читать далее]

Анатолий, про горячие клавиши написано в релизе Revit 2019. Про проблему знают, ждите решение в обновлениях.
Вопрос: про какого Антона речь? Если с именем не опечатались, то скиньте ссылку откуда качали его скрипт. У меня есть ещё несколько аналогичных скриптов с Инета, но готов и его глянуть.
По поводу задвоения листов: эту проблему наблюдаю…[Читать далее]

Сам спросил, сам отвечу.
Перед тем как попросить помощи, провел десятки тестов. Но, оказывается, не все возможные. Исходный скрипт брал у тов. Alex Babinoff на его канале.
Оказалось, что он работает только на Revit 2017, а я всё мучился с 2015-м.
И да, его скрипт из нода Print PDF модифицирован и отличается даже от последних версий пакета Arc…[Читать далее]

Серж, огромное спасибо. И за корректировку, и за показ “магии генератора списков”. Приму на заметку.

Серж, спасибо за правки. Но теперь наоборот, удаляются все Наборы, кроме одного.
В чем может быть причина? Текущий код – ссылка.

P.S. Минимум 1 ошибку нашел: IdList надо присваивать вне цикла for. Исправил.
Но проблема осталась. Список формируется всегда на 1 набор меньше существующих.

Выполнить надо только для выделенной области? Т.е. не смешивая с другими элементами 1-го уровня?
Также сделать группировку с List.GroupByKey – получатся группировки 3-го уровня. Там сделать суммирование для уровня L3 (настраивается на входе нода Sum.
P.S. Советы даю только по нодам. Уверен, что спецы по Python могут предложить код куда более оптимальный.

Вы пробовали применить связку List.SortByKey и List.GroupByKey вместо ist.GroupByFunction? Может поможет.

Эта задача решена универсальным методом для любых шрифтов и их модификаций Italic, Blod, а также для любого коэфициента ширины текста.

Даже так? Я переводил статью в ГуглПереводчике. И понял так, что автор сделал анализ только для одного шрифта, и то пришел в итоге к эмпиричности. Значит надо снова перечитать.
Если и с моими слабыми знаниями в…[Читать далее]

Пока только идеи:
– Tag Host Element (пакет Archi-lab.net, он же Archi-lab Grimshaw) – определит основу марки (маркируемый элемент)
– Считываете значение параметра из элемента.
– Определяете длину полки по длине текста (в соседней ветке давали ссылку на английскую статью). Мне же пришлось находит коэффициент эмпирически. Будет зависеть…[Читать далее]

Если в Динамо, попробуйте:
– у координат Z сортируете индексы – SortIndexByValue (нод с одним Входом)
– в нод List.GetItemAtIndex подаете список элементов, а индексы – от SortIndexByValue

Ну, пока можно определить требуемую длину полки и выбрать типоразмер с ближайшей Большей величиной (из списка типоразмеров с разными длинами полок). Костыль конечно, но хоть можно автоматизировать.
По крайней мере я собираюсь так сделать, как немного освобожусь…

ИваСерж, Alex Ward, большое вам спасибо. Похоже всё заработало.

Интересно, исправили ли этот косяк с TextNote в русской локали в Dynamo 2.0 (из-за которого пришлось придумывать такие костыли)? ))