Unity3D 3.x Получение текущего активного окна

[sha1dy]

Поздравляю, вы только что повесили себе ружье на стену.

[DedalX]

Unity позволяет писать на JS, C# и Boo на выбор и прочитав эту статью хотелось бы задать вопрос — существует ли существенная разница в плане возможностей на чем писать? Может ли оказаться что есть вещи какие в Unity можно сделать только на одном из этих языков (к примеру C#) и в принципе невозможно сделать на другом (JS к примеру)? Или любую проблему можно решить на любом из языков, просто немного по разному? Ведь API Unity как я понимаю для всех языков одинаков (в плане возможностей)?

[agasper]

К сожалению я не знаю всех возможностей JavaScript, т.к. ничего серьезного на нем не писал.

[Andy_Ion]

На JS можно задать значение для координат трансформа (transform.position.x ,y, z) напрямую (transform.position.x = 50.0f), в C# же придется задавать через Vector3.

Это из известной мне разницы :)

[DedalX]

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

[Andy_Ion]

Функциональных ограничений? Не знаю насчет JS/Boo, но C# позволяет «использовать себя полностью», выходя за рамки встроенных возможностей Unity3D.

[Sergion]

Лучше использовать C#. JavaScript тут — это JScript от Microsoft, урезанный и стремный.

[kimag]

Для начала ссылка на официальную вики об особенностях местного JS.
Из того с чем я сталкивался:
— геттеры и сеттеры в UnityScript (будем его так называть) есть, но их использование иногда не удобно;
— невозможно передавать в UnityScript объекты в параметрах (в отличии от классического JS).

[HomoLuden]

Если это синглтон, то почему бы вам не сохранить куда-нибудь при старте ссылку на инстанс? Тогда и не нужно будет каждый раз рефлекшн дергать.

Еще вариант… отслеживать интеракции с окнами и хранить стэк окон.

П.С.: Ей Богу! Зря вы с рефлекшном завязываетесь! Лучше зайдите с другого бока к проблеме — наверняка есть решение много безопаснее.

[agasper]

почему бы вам не сохранить куда-нибудь при старте ссылку на инстанс? Тогда и не нужно будет каждый раз рефлекшн дергать.

Я об этом написал в примечании, сама функция это пример.

Еще вариант… отслеживать интеракции с окнами и хранить стэк окон.

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

Лучше зайдите с другого бока к проблеме — наверняка есть решение много безопаснее.

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

[WGH]

Небезопасность тут потоньше. Реализация может измениться и код вдруг начнет падать или работать не так.

[agasper]

Юнити не обновляется сама, так что с этим проблем не будет. В любом случае альтернатив этому решению нет.

[HomoLuden]

Тоже хотел написать об этом… но вспомнил, что при билде либы рантайма встраиваются в дистриб приложения.

[HomoLuden]

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

П.С.: еще вариант — докинг без перекрытия. Уж выстроить то окна рядом друг с другом можно?
См. тайловые менеджеры окон

[agasper]

Да, запретить перекрывать окна можно. Но для нашего интерфейса это не подходящий вариант.

[DisaDisa]

А сделать классы обертки для окон с уникальным ID нельзя?

[agasper]

все равно мы не будем знать на каком слое оно сейчас находится

[DisaDisa]

А если контролировать это изначально? То есть сделать свой z-buffer для них, свою переключалку по клику курсора?

[agasper]

Дело в том что после вывода окна на экран неизвестно на каком оно слое, еще до действий пользователя.

[DisaDisa]

Понял :/ Вечно с этим встроенным ГУИ траблы. С 4ой версией надеюсь будет получше

[agasper]

Да, текущий Unity GUI доставил нам немало неприятностей.

[Leopotam]

Есть еще одна проблема — рефлекшн выпилен в мобильных платформах и, потенциально, в вебплеере (надо проверять). Т.е. получается непереносимость проекта, что ломает одну из основных «фич» юнити — сборка одного проекта под несколько платформ.

[agasper]

Ну этот метод точно работает для Standalone, а для остальных случаев приходится менять концепцию интерфейса.

[kimag]

Не придираюсь к конкретному проекту, просто хотел бы обсудить конепцию данного интерфейса.
Придерживаюсь мнения, что перетаскиваемые окна не так удобны, как может показаться. Из примеров игр, в которых были реализованы «плавучий» оконный интерфейс вспоминаются Морровинд, ЕВЕ онлайн, Рагнарок онлайн. Из моих наблюдений во всех случаях игрок приходил к тому, что однажды распологал окна, а потом не менял эту схему на протяжении всей игровой «карьеры». Схема обычно придераживалась некоторых правил: окна не наслаивались друг на друга; схожие по функциональности окна (например, сундук и рюкзак) ставились рядом и подгонялись под одну высоту или ширину; чем больше информации в окне, тем больше окно. Словом, я считаю, что если бы за игрока все это сделал (конечно, с крайней вдумчивостью и отсветсвенностью) разработчик или дизайнер интерфейсов, то и игрок бы оказался в плюсе, и от многой лишней функциональности (перетаскивание окон) можно было бы отказаться.