Разработка инструмента для театра и шоу

Сергей, как технодемка очень круто! Идея понятна, но если говорить о реальном применении… Чтобы знать, что именно применять, и как применять в театре, нужно в этой сфере поработать.
Собственно, здесь имеем частный случай применения одной операции ко множеству одинаковых однопримовых объектов, слинкованных в один.
Чаще мы имеем другую ситуацию, совершенно разные многопримовые объекты, к которым мы применяем разные операции в разное время. Допустим, один я двигаю, другой вращаю, у третьего изменяю размер, на четвертом текстуру, на пятом управляю прозрачностью, на шестом цветностью и т.д.
Это можно в принципе реализовать и в многопримовом объекте, но представь себе реальную ситуацию, когда тебе в декорации на 400 прим, объединенных в один объект, нужно найти скажем 50 прим, относящихся к визуально одному объекту, и к нему применить нужные операции? При этом, мы еще имеем множество граней, которые нужно указывать при таких операциях как смена текстур и многих других. Представь себе, как будет выглядеть твой командный файл для управления всем этим и каким увлекательным будет его процесс написания? Сомневаюсь что на этом фоне будет огромный выигрыш от замены нескольких скриптов на один.

Поэтому как частный случай для определенных конкретных условий, великолепно. Как универсальный скрипт для управления объектами на сцене — скорее всего нет, из-за большой сложности управления и написания командного файла.

Ну и как не печально, весь выигрыш от уменьшения количества скриптов в большим запасом перекроют пара лишних аватаров, прилетевших на постановку, на которых их надето по несколько сотен.

Кстати по стилю мне это что-то напомнило. Это ты не ты писал скрипт для управления монетками в одной из сцен «Буратино»? Собственно, это единственный более-менее сложный скрипт во всей постановке, чем он и запомнился.

Ну я то в принципе понял, что ты брал за основу.
wiki.secondlife.com/wiki/LlCreateLink
Первый пример кода это рез объекта из инвентаря root и его линкование, у тебя это в цикле матрицей 10 х 10.
Линковать объекты во всех случаях, это все равно подход неправильный, ибо не все манипуляции с объектами будут доступны в таком варианте, нарушится работа других скриптов из-за линкования объектов. Я сразу покажу тебе пример, который станет невозможен для реализации, если оставляем линкование как императив.
youtu.be/IwTlV19xT5k?t=1098
Если уж для театра, то скорее всего нужно писать полноценный резер со чтением заметки, а не просто llRezObject(ObjectName, llGetPos() + <0,0,0.5>, ZERO_VECTOR, llGetRot(), 0);
Соответственно нужен скрипт для объектов, скрипт который будет формировать эту заметку, опрашивая объекты и получая координаты и углы. Ибо объекты то будут разноплановые, и их сначала нужно разрезить, а потом уже крутить-вертеть.
Опять-таки, заметка в абсолютных координатах и углах создаст проблемы с переносом при смене сима-парселя, нужны координаты относительные, которые задаются положением какого-нибудь объекта или иным способом.
Хотя опять-таки, их валом на маркете по очень даже демократичным ценам, с возможностями, которых хватит всем, было бы желание. Покупные не все могут освоить, а ты им скрипт и команды на каналы)
Работы тут море, это мы касаемся только операций с объектами, пока даже не касаясь системы перемещения аватаров и их анимирования, если я расскажу что там нужно сделать, ты просто схватишься за голову.
Которую кстати нужно синхронизировать с операциями с объектами, причем с большой точностью. Аватар скажем поднимает руку, и из руки вырывается луч (это уж мой пример из постановки которая скоро будет показана), фактически луч — объект который мы достали перемещением, но это нужно сделать с большой точностью, даже разброс в 0,5 секунды будет заметен.
Нужен командный скрипт, который будет соединять воедино все, систему перемешений и анимировая, резов и любых манипуляций с объектами.
Команды в чат не уместны, и даже кнопки на хадах с повещенными командами годятся только для самых простых сцен с небольшим количеством действий.
Командный скрипт должен вычитывать заметку, которая есть сценарий, и соединят все воедино.
Это в двух словах, объем работы если все писать самому просто сумасшедший.
Если это проект сугубо некоммерческий, то я готов поаплодировать, учитывая объем и сложность работы, необходимости тщательной обкатки, а также поддержки.

Хочу привести в пример одну работу, о которой знают немногие. Для справки, этот театр существовал параллельно с театром «Пуазон», но о нем мало кто знал. И в то время, когда в Пуазоне еще резились примитивные декорации, и аватары вручную прыгали на таблетки, да и ходили вручную… делались вот такие вот вещи. Собственно, если разобраться, то ничего сложного, но есть момент примерно с 5-й минуты видео отработки скриптов на объектах аватаров. Этот момент меня заставил в свое время задуматься, сначала я думал что тут просто синхронное переодевание посредством RLVa скриптов, но слишком уж быстро. Как мне сказали, на реальном показе все было ровно также как и на видео, поэтому вывод очевиден. Такой вот прием в работе я пока не видел ни в одном другом театре. В любом случае, великолепная работа, которую стоит показать всем.

красивая идея танца. Но Несс ставит тоже потрясающие танцы.

Я мало видел Несс, но если брать то что я видел, какого-то виртуозного применения скриптов я не обнаружил. Собственно, их технических приемов обычно рез сцены из 2-3 объектов, и вывод танцоров на таблетках хореографа в варианте точка-точка (из-за сцены, за сцену), ну и понятное дело анимирование, партикли, надеваемые на аватары. Хотя, повторюсь, не могу похвастаться тем, что видел все. Художественную часть я сейчас во внимание не беру, с учетом обсуждаемой темы, а по технической все очень просто, и сравнивать с видео выше немного некорректно.

Скорее это управление цветностью, прозрачностью и свечением на определенных гранях. Может и смена текстур присутствует, но прогрузка текстур занимает некоторое время, на видео она не видна, там все мгновенно. Если смена текстур и присутствует, то скорее всего надето по второму костюму и зонтику с нужной текстурой, первый вариант оправляется в невидимость, когда появляется второй. Относительно каких-то ручных манипуляций с альфой, то абсолютно исключено, с учетом скорости и синхронности происходящего. Тут либо костюм и зонтик заранее подготовленные со скриптами, либо по два варианта того и другого, аналогично со скриптами. Дальше прописываем нужные команды на нужный канал в нужный момент в сценарии, синхронизируем это с аналогичной операцией над декорацией, чтобы выглядело особенно эффектно и получаем результат. К таком выводу я пришел из разбора этой сцены. Саму идею я хочу использовать, думаю в реализации никаких подводных камней не будет.

Сереж, а мне понравился этот скрипт! жду конечного результата

Тут нужна обкатка, чтобы понять, есть ли хоть какой-то смысл в объединении объектов. Думаю, при наличии 60 аватаров на участке, выигрыш из-за такого подхода может не составить и 1% от общей нагрузки на сервер. Ну и количество возможных операций над отдельными примами слинкованного объекта все-таки уже.
Язык написания заметки-сценария при сохранении нужной гибкости уже мало будет отличаться от собственно написания непосредственно скрипта. Для передвижения объекта из точки А в точку Б мы должны указать номер (ID) объекта, команду на передвижение, начальные и конечные координаты, время за которое объект должен совершить передвижение, начальные и конечные углы поворота, скорость поворота объекта. В команде на вращение опять-таки, скорость, оси. Интерпретатор заметки и в целом управляющий скрипт могут приобрести монструозный вид, и исполняться медленно, создавая ту самую нагрузку на сервер.
В моем варианте я просто вложу пропишу координаты и скорость в простенький скрипт передвижения, а командный скрипт оправит простую команду в нужный момент на нужный канал. Команда просто триггер на исполнение последовательности в скрипте целевого объекта, момент интерпретации команды, а значит и значительный блок дополнительного кода в принципе отсутствуют. Таких последовательностей в скрипте может быть столько, сколько мне нужно для управления объектом. Разумеется, я не пишу каждый раз все заново, большинство операций типовые, и просто берется подходящий блок из уже написанного, и переделывается нужным образом.
Приведу маленькое сравнение. У меня есть пара навороченных покупных резеров. Один работает с заметками, другой, неприлично дорогой, вообще не требует заметок, я просто редактирую сцену как надо и все изменения в положении объектов тут же фиксируется. Но у меня есть и третий резер, который я написал сам. Зачем он при наличии таких инструментов? Как раз его применение состоит в его простоте, потому что скрипт работает практически мгновенно именно за счет того, что он крайне прост. При этом в жертву принесено удобство, нужно вручную прописать в этот скрипт названия объектов, координаты и углы. Зато скорость реза сравнима со скоростью перемещения объектов в пределах парселя. Навороченные резеры не в пример удобнее, но и резят намного медленнее именно за счет сложности их скриптов. Есть некоторые ситуации когда это критично, а примов может не хватить для размещения объектов за пределами сцены и перемещения в нужный момент.
Вот небольшой намек для правильного выбора подхода к разработке.

Ну это то понятно, я знаю как можно отдавать команды внутри линкованного объекта.
wiki.secondlife.com/wiki/LlMessageLinked
Количество прослушиваний сократили. Даст это выигрыш в уменьшении нагрузки на сервер, либо она наоборот увеличиться, за счет резкого увеличения сложности управляющих скриптов, тут очевидно может дать ответ только практика.