Может, уже предлагали. Хотелось бы, чтобы информация о том, в каком профиле последний раз была открыта карта и в какой конфигурации компилилась, сохранялась для автоматической подстановки при следующем её открытии и при следующей сборке.
У меня несколько профилей для разных игр и выбирать каждый раз из большого списка неудобно (да и иногда я забываю, в каком профиле редактирую карту ). А экспертных конфигураций по сборке так и вовсе довольно много даже при стандартной установке.
FreeSlave
Не буду делать вид, мол, "да, конечно, как-нибудь сделаю" и скажу честно. Эти предложения мне не нравятся.
Цитата:
FreeSlave писал: информация о том, в каком профиле последний раз была открыта карта
Эта идея не нравится тем, что перед "нормальным" чтением карты нужно будет делать некое предварительное чтение. То есть читать файл карты дважды. К тому же, это сработает только для формата JMF, а значит, дважды нужно будет и определять тип файла, т.е. дублировать логику в коде. Если бы такое двойное чтение было изначально заложено в архитектуру, но мне такое даже не могло прийти в голову на этапе проектирования. Зато я сделал возможность временно выключать любые конфигурации. У самого их 10 штук, однако окошко выбора даже не выводится, потому что у 9 их 10 снял флажок "Enable".
Цитата:
FreeSlave писал: в какой конфигурации компилилась
А эта идея не нравится тем, что непонятно, что именно сохранять. Индекс экспертного конфига? Но ведь любой экспертный конфиг переписывается в два счёта и без каких-либо предупреждений. Сами команды? Тогда как сверять, какому конфигу они соответствуют, сверять покомандно? А если что-то не совпадёт по причине, описанной выше? Ну, по крайней мере, это принципиально реализуемо в текущей архитектуре.
XaeroX писал: Зато я сделал возможность временно выключать любые конфигурации.
Это хорошо, но не решение, если работаешь одновременно в нескольких профилях.
Цитата:
XaeroX писал: Эти предложения мне не нравятся.
Судя по твоим словам не нравятся чисто с точки зрения сложности реализации. Так-то для пользователя фичи нужные.
Я ни формата jmf, ни архитектуры джека не знаю, поэтому спорить не стану. Может, и правда всё это сложно, тебе виднее. Но создание юзабельного приложения и есть штука сложная, никуда не деться.
FreeSlave писал: Судя по твоим словам не нравятся чисто с точки зрения сложности реализации.
Ну разумеется. Мало ли что мне не нравится с точки зрения идеологии? Да, я бы эти вещи юзать не стал, ну так я много чего сделал в джеке для других, что сам не юзаю. Но лишь то, что сильно не влияло на архитектуру.
Цитата:
FreeSlave писал: Но создание юзабельного приложения и есть штука сложная, никуда не деться.
Я бы сказал - это невозможно. То, что русскому юзабельно - немцу смерть, например. Поэтому недовольные джеком будут всегда и во все времена. Даже когда на свете останется всего один пользователь джека, он обязательно чем-то да будет недоволен.
А так же когда юзер нажимает на "крестик" (закрывает диалог), то экспорт карты по идеи вообще не должен происходить.
Добавлено 11-12-2015 в 19:54:
One more:
Есть предложение с "разделенной" отправкой объектов в ентити. Т.е. сейчас мы выделяем три браша и обращаем их в func_wall, мы получим один func_wall из них. А если отправлять с зажатым SHIFT'ом (к примеру), то каждый из объектов будет отдельной ентитью (3-и func_wall'а с одинаковыми настройками).
В момент открытия окна Entity Report, проверяется, выделены ли какие-нибудь объекты-ентити, и если выделены, то они выделяются в списке ентитей. Для чистоты, если при этом выделены не ентити (World браши, etc.), то ничего не выделяется.
CTRL+A внутри Vertex Manipulation, выделяет вертексы всей карты, не логичнее ли выделять только все вертексы объект(ов)а, с которым работает инструмент?
02-12-2015 04:44
). А экспертных конфигураций по сборке так и вовсе довольно много даже при стандартной установке.
