Очень нравится ваш пост.

РЕДАКТИРОВАТЬ:
блин пропустил этот абзац

Имейте возможность фактически скопировать файлы в проект на случай, если желательна модификация на уровне исходного кода. Только потом файлы нужно занести в саму папку проекта. «Клонированные» ресурсы могут находиться в скрытой папке, например .custom.

Таким образом, вы в основном покрыли опасения, которые у меня были. (Прости)
Я просто углубляюсь в то, как я представляю себе рабочий процесс + поведение.

СООБЩЕНИЕ:
Однако один рабочий процесс упускается из виду, IMO.
Использование активов как просто ресурсов или первых строительных камней.
Текущий действительно прозрачный и простой подход также позволяет вам просто загрузить пару ресурсов. удалить некоторые файлы. Затем сохраните некоторые png и скрипт, который имеет некоторые функции, которые вам нужны. В настоящее время можно просто работать над ними и модифицировать.

Если бы активы были скрыты в папке .local/godot/assets , эта функциональность была бы потеряна.

Предложение

Активы по-прежнему должны быть видны и перечислены в браузере файлов редактора. Независимо от того, находятся ли они в папке .local/godot/assets или в самой папке проекта. Таким образом, вы можете просмотреть файлы и понять, как это работает, если нет надлежащей документации или если вы хотите извлечь из нее уроки.
Каждая папка, которая является «активом», также должна быть помечена каким-либо значком, чтобы у вас было общее представление о том, что является активом и где хранятся фактические файлы.
Также должно быть окно редактора, в котором перечислены все активы. (в таблице)

• Загружено — список всех загруженных ресурсов. Их можно добавить в ваш проект одним нажатием кнопки. Но в остальном они такие же, как активы в библиотеке активов. Этот список одинаков для любого проекта и не влияет на сам проект. (просто упрощает обзор. Также легко очистить этот список и повторно загрузить все активы при открытии проекта.)
• Всегда активен (в основном просто переключает «Используется в этом проекте (активный/неактивный)» для каждого проекта). Эти активы добавляются в КАЖДЫЙ ПРОЕКТ на вашем компьютере (даже вновь созданные). (Возможно, сам актив должен это учитывать.) Они действительно ориентированы на редактор. Как часы в углу, поддержка git, списки дел или дополнительные ресурсы по умолчанию: (настраиваемая среда, еще несколько тем и куча спрайтов для работы в начале каждого проекта)...
  Их можно деактивировать вручную для каждого проекта.
  Тем не менее, они по-прежнему перечислены в файловой системе проекта и ведут себя так же, как и любой другой ассет/плагин. так что вы можете просмотреть их файлы и посмотреть, как они работают / что они делают.
• При использовании в этом проекте (активный/неактивный) это фактически показывает связанную папку в файловой системе проекта. и "добавляет" (они все еще находятся в папке .local/godot/assets , но ведут себя как локальные файлы проекта.) файлы в проект.
  Здесь вы также можете выбрать, какую версию актива вы хотите активировать. И переключить версию.

Как только вы захотите отредактировать/сохранить/обновить файл из актива, вам будет предложено два варианта.

Сэкономьте в .local/godot/assets

либо обновите актив в .local/godot/assets , что поместит его в настраиваемую пользовательскую версию.
Если менеджер пакетов основан на git, пользовательская версия может быть одной дополнительной фиксацией. который получает commit --amend при каждом сохранении.
(например, 3.2.5/user ) и доступен во всех других ваших проектах. (при обновлении версии в этих других проектах до пользовательской версии)
почему это полезно?
Тема из магазина активов почти идеальна, но вы ненавидите тип шрифта...
измените тип шрифта, сохраните его как новую версию актива. Пересмотрите все свои другие проекты и измените версию ресурса на /user . Теперь вы счастливы.
Возможно, также может быть одна кнопка для публикации пользовательской версии актива.
Таким образом, в магазине активов у других пользователей есть возможность также выбрать пользовательскую версию с небольшими изменениями.
Просто в качестве промежуточного звена, чтобы сделать ссылку на репозиторий активов git. (или автор децидиса актива выбирает вишневые изменения из версии /user в новую версию на мастере.)

Сделать локальным для проекта

копирует файлы из папки .local/godot/assets в текущий проект... удаляет любое особое поведение активов (например, версию...), и теперь вы можете возиться с ним, как хотите. (также папка теряет свой внешний вид как актив.)

Это позволяет хранилищу активов также охватывать вариант использования шаблонов. И это идеальный выбор практически для любого актива, связанного с искусством. Так как вы можете работать над активами, чтобы сделать их такими, какими они вам нужны.
Вы всегда можете просто активировать кучу уже загруженных ресурсов (скажем, некоторые базовые прототипы спрайтов), сделать их локальными и импортировать.

случайная мысль

Это может быть даже хорошим решением для вашей собственной локальной библиотеки активов/ресурсов/коллекции. Папка в .local/godot/assets позволяет добавлять ее содержимое в любой проект Godot с помощью удобного пользовательского интерфейса редактора и без поиска в файловом менеджере вашей ОС.

Я согласен с тем, что как AssetLib, так и интеграция библиотеки ресурсов (как в редакторе, так и с GDScript) нуждаются в любви, если мы продолжим продвигать их как альтернативу включению вещей в основной движок.

Тем не менее, я лично не согласен с тем, насколько сильно должен продвигаться этот плагин .

Первый вопрос, который мы задаем себе в новом PR, не должен быть таким: может быть, это плагин? но, скорее , это будет использоваться достаточно, чтобы быть в ядре? .

Есть проблемы с наличием вещей в плагинах:

• Люди должны знать, что они ищут в первую очередь. Godot ориентирован на новичков . Программное обеспечение, удобное для начинающих, обычно пытается иметь все, что кому-то (разумно) нужно, потому что в противном случае им сначала нужно узнать, чего им не хватает, и как они собираются это получить.
  Есть причина, по которой новички используют Ubuntu, а не Gentoo. Независимо от того, насколько хорошо вы делаете эту систему зависимостей.
• Существует паралич принятия решений . Если в Godot есть функция, отлично, для ее использования требуется секунда. Если для него есть 5 плагинов, какой я буду использовать? Например, есть 5+ консольных плагинов. Какой выбрать новичку и почему, и сколько времени разумно потратить на это решение?
• Плагины забрасываются, имеют меньшее качество, отстают при обновлении. Еще меньше оснований полагать, что случайный плагин не сломается, чем доверять Godot, за которым стоит достаточное количество людей.
• См. Единство . Их активы в основном даже платные , и все еще отстойно, что для многих вещей вам сначала нужны плагины, которые в конечном итоге плохо интегрированы или ломаются при обновлениях - или прекращаются, даже если они платные и обычно могут позволить себе хотя бы некоторую поддержку.
• Документация : Нам этого все равно не хватает. Каждая функция не входит в ядро, я не могу использовать ее в официальных руководствах/документах. Случайные отдельные люди для плагинов, скорее всего, не предоставят документы или только короткие примеры, а не более ценную часть предоставления демонстраций или полноценных руководств о том, как легко интегрировать эту функцию с другими в проект.

Примеры:

• Узел пружинного рычага. (https://github.com/godotengine/godot/pull/18822) Достаточно небольшое дополнение, выделенное в отдельный класс, поэтому оно не должно ломать вещи, будет использоваться многими 3D-играми, если не каждой игрой от третьего лица . Ответ: должен быть плагин.
• Даже для ГСЧ обсуждалось использование его в виде плагина. Как бы не 90% игр где-то нужен ГСЧ.

Редактировать: Чтобы было ясно, я за то, чтобы избежать раздувания. Но это баланс, и я хочу озвучить поддержку того, что не все в плагинах. Очень специфичные для игры или не очень широко используемые вещи, проприетарные плагины, большие зависимости, да, пожалуйста , поместите их в Asset Lib!

@karroffel Это отличный пост, и я в основном согласен со всем, что вы сказали. Тем не менее, я хотел бы прокомментировать этот момент:

Ассеты сохраняются с привязкой к версии, все хранятся в .local/godot/assets или что-то в этом роде. Они больше не являются частью самого проекта, но доступны для всей системы.

Это похоже на то, как работает пипсовая система Python. Затем люди поняли, что последняя версия пакета испортила другие проекты в вашей системе. virtualenv решает эту проблему. В экосистеме Javascript npm модули устанавливаются локально в проект по умолчанию, а общесистемная является опциональной функцией ( npm install --global ). Затем вы регистрируете свой package-lock.json в системе управления версиями, чтобы убедиться, что все в команде используют одну и ту же версию каждого модуля npm, и избежать конфликтов.

Общесистемные пакеты хороши тем, что они уменьшают раздувание систем людей. Закрепление версий хорошо, потому что оно помогает команде поддерживать согласованный набор версий и может помочь вам определить полную коллекцию версий, которые хорошо работают вместе.

Если мы пойдем общесистемным путем, я бы предложил сохранить привязку версии. Например:

.local/godot/assets/fsm/1.0
.local/godot/assets/fsm/1.1

Проект A может использовать fsm-1.0, а проект B использует fsm-1.1. Появляется проект C, который можно использовать повторно. Пользователи должны иметь возможность указывать конкретные версии плагинов в своих файлах dependencies.json или минимальный патч, младшие или основные версии.

После загрузки зависимостей можно создать файл dependencies-lock.json и вернуть его в систему управления версиями.

@mhilbrunner Я определенно согласен, я думаю, что менталитет «это должен быть плагин» слишком сильно выражен, именно эти ситуации вызвали эти мысли. Я думаю, что более распространенные вещи, такие как SpringArm, достойны быть в движке, а также InterpolatedCamera , который Хуан хочет убрать, безумно полезны и круты! Даже если эти вещи представляют собой всего несколько строк кода, они требуют времени, чтобы сделать их правильно, поэтому «это слишком мало» также является плохим оправданием для продвижения в сторону AssetLibrary.

Мои мысли в основном были сосредоточены вокруг: «Ну, руководитель проекта сказал, что это так, так что же можно сделать, чтобы улучшить новую ситуацию?»

Я бы хотел, чтобы сильное продвижение функций в качестве плагинов было немного снижено, но в любом случае я думаю, что представленные изменения очень помогут!

@saltares Да, это была моя мысль. Я большой поклонник грузов для Rust. Он работает примерно так же. Библиотеки устанавливаются в общесистемную папку во всех версиях, которые когда-либо требовались локально. Описание в одном файле, а конкретная конфигурация в файле .lock , все работает отлично!

Я рад, что это уже вызвало некоторые обсуждения :blush:

Вот мой взгляд на вышеперечисленные пункты:

Выталкивание вещей из двигателя

Выталкивание вещей за пределы двигателя - это ИМО путь. Существует слишком много платформ, где размер развертывания имеет значение (мобильная версия, html5), а раздувание является серьезной проблемой для проекта размером с Godot, поэтому мы не можем просто включить все.

Философия для меня должна заключаться в том, что что-то должно быть частью двигателя, только если соблюдены ВСЕ критерии ниже:

1. Он используется относительно часто
2. сложно сделать самому
3. Есть только один способ сделать эту функцию

Это исключает пружинный рычаг, ландшафт, и я надеюсь, что в будущем это поможет удалить такие функции, как InterpolatedCamera, Vehicle и т. д., которые, по моему мнению, должны быть вне движка.

Основная проблема в том, что если что-то не является официальным, оно не будет поддерживаться. Здесь вы, ребята, ошибаетесь.

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

Расширения должны ощущаться как часть движка

Относительно этих моментов:

• упростить расширение пользовательских узлов, разрешить наследование сценариев между языками

Я очень сильно против этого. В этом нет никакой практической пользы, а стоимость реализации очень высока. Извините, ребята, я знаю, что это хорошая функция, но взвешивание затрат/выгод/рисков на очень отрицательной стороне.

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

Если новый узел добавляется из расширения и делается с помощью скрипта, это должно быть даже показано в диалоговом окне создания.

• Наследование скрипта не рекомендуется при присоединении скрипта — для таких случаев по умолчанию используется переопределение.

Это обязательно нужно сделать, и это было бы очень желанным дополнением.

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

Я думаю, что это может либо работать фантастически, либо привести к полному беспорядку и надстройкам, которые ломаются без очевидной причины. Глядя на то, как другие движки работают с этим, мне не кажется, что управление зависимостями так важно.

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

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

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

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

Этот комментарий разделен на свернутые разделы из-за его большой длины.

Хотите камеру? У Godot есть камера, которая может следить за игроком практически без вашего кода. Хотите сделать анимацию в Godot? Вы можете не только делать анимацию персонажей, та же самая система может (почти) заменить ту систему кат-сцен, над которой вы так усердно работали, для чего от вас потребуется всего пять или около того строк кода. Редактор даже использовался для создания других редакторов , таких как RPG in a Box. Просто фантастика, сколько всего можно создать в Godot.

Теперь, когда это не так, надеюсь, любой, кто читает это, может понять, о чем я думаю, когда я пытаюсь ответить на некоторые замечания Reduz относительно выталкивания вещей из двигателя. (Это не будет ответом на раздел «Расширения должны ощущаться как часть движка», поскольку в настоящее время у меня нет мыслей по этому поводу.)

Выталкивание вещей за пределы двигателя - это ИМО путь. Существует слишком много платформ, где размер развертывания имеет значение (мобильная версия, html5), а раздувание является серьезной проблемой для проекта размером с Godot, поэтому мы не можем просто включить все.

Я могу согласиться с тем, что раздувание вызывает беспокойство, но когда я вижу, что вы хотите удалить до сих пор, я спрашиваю себя, действительно ли вообще стоит удалять этот материал. Даже если вы удалите такие узлы, как Vehicle, InterpolatedCamera и т. д. Насколько сильно изменится размер файла? Может полмегабайта? Может пару мегабайт? Даже если это сэкономит несколько мегабайт, какая разница между загрузкой 35 МБ и загрузкой 45 МБ? В любом случае игровые активы быстро заполнят эти 10 МБ! Если вы не планируете снимать половину двигателя, я не вижу смысла.

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

Теперь, конечно, мы не можем просто включить каждое данное нам предложение...

1. Он используется относительно часто
2. сложно сделать самому
3. Есть только один способ сделать эту функцию

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

что-то должно быть частью двигателя, только если соблюдены ВСЕ критерии ниже

Но да ладно. Судьба функции или узла не должна сильно зависеть от того, является ли она основной функцией. Предлагаемые вами рекомендации великолепны, не поймите меня неправильно, но мы не должны использовать их в качестве контрольного списка. Это то, что делает YoYo Games, когда вы предлагаете функцию на их форумах, и это еще одна причина, по которой меня оттолкнули от их движка — можно ли это сделать с помощью расширения? Да? Тогда наш ответ сделать расширение. Угадайте, сколько запросов на добавление функций было отклонено из-за того, что вместо этого их можно было бы превратить в расширения, независимо от того, насколько разумным было бы их включение в движок, насколько легко по сравнению с этим было бы реализовать их или как сообщество относится к этому. эта функция.

Я хочу сказать, что вы определенно можете помнить об этих правилах. Вы можете рассматривать их каждый раз, когда предлагается функция. Но то, применимы ли все они, НЕ должно быть решающим фактором в том, будет ли функция реализована. Сравните идею с этими рекомендациями, подумайте, насколько важно каждое из этих рекомендаций, и придайте вес этим факторам... Просто потому, что идея не подходит. кажется, что он используется слишком часто, автоматически не делает его плохой идеей (имейте в виду, что вы можете не знать истинный масштаб того, как он используется, даже имея несколько лет опыта). Тот факт, что идею легко реализовать самим, не означает автоматически, что это плохая идея. И то, что мы можем реализовать идею несколькими способами, не означает, что это плохая идея! Не говоря уже о том, что, возможно, кто-то предлагает идею X, потому что думает, что от нее выиграют другие люди.

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

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

Основная проблема в том, что если что-то не является официальным, оно не будет поддерживаться. Здесь вы, ребята, ошибаетесь.

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

Лично я не согласен с этой идеей. Наряду с тем, что я сказал выше (что удаление его из ванильного движка не сэкономит вам много места), я должен спросить, собираемся ли мы конвертировать их все в GDscript, или мы собираемся потребовать их, чтобы перекомпилировать движок только для того, чтобы получить эти узлы.

• Если мы сохраним их как C++ и потребуем повторной компиляции... почему? Нет веских причин, по которым нам когда-либо потребуется перекомпилировать движок, если только мы не изменим его основную часть или не добавим собственную функциональность. Это просто дополнительное время, которое уходит на разработку, потому что мы ждем завершения процесса компиляции, а также требуем от обычного пользователя установки других инструментов, которые они, возможно, даже никогда больше не будут использовать, просто чтобы получить некоторые сторонние узлы. Теперь это звучит как вздутие живота!

• Если мы конвертируем их в GDscript, то это будет связано со всеми ограничениями GDscript. Такие ограничения, как потенциальные накладные расходы на дополнительные дочерние узлы (особенно если вы просите пользователя импортировать этот собственный узел в качестве сцены), необходимость использовать пути, а не имена классов для ссылки на их классы (хотя вы решили эту проблему, это кажется, но я чувствую, что мне нужно поднять его), более низкая производительность (независимо от того, насколько небольшой может быть разница, она все равно ниже) и т. д.. Это немного более идеально, чем C++, потому что вы перешли от перекомпиляции к перетаскивание, но...

Любой вариант также означает, что файлы для этих узлов должны быть импортированы в движок с каждым новым пользователем (для C++) или в папку проекта с каждым новым проектом (для GDscript), который хочет их использовать. Я не знаю, как для всех остальных, но для меня это звучит как хлопот, и звучит так, будто это сделает ваше первое правило («Оно используется относительно часто») очень спорным. Попробую объяснить, почему я так думаю.

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

Кроме того, вы говорите, что они будут поддерживаться. Замечательно! Но кто будет их содержать? Каковы наши рекомендации по добавлению новых вещей в этот репозиторий? И собираемся ли мы приложить усилия, чтобы этот репозиторий сторонних расширений всегда работал, будь то стабильная версия или мастер? В принципе, стоит ли это того, что фактически является отдельным проектом?

кстати, я предпочитаю реализовывать поддержку нескольких скриптов на каждом узле.
а не межъязыковое наследование. Первый - всего пара строк
кода..

В воскресенье, 10 июня 2018 г., в 13:51 [email protected] написал:

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

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

—
Вы получаете это, потому что вы прокомментировали.

Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/godotengine/godot/issues/19486#issuecomment-396063688 ,
или заглушить тему
https://github.com/notifications/unsubscribe-auth/AF-Z21jtcnUhRyhdyEEnaM_hfTACsxOiks5t7U6HgaJpZM4UhqDC
.

Несколько раз пытались запустить несколько скриптов на узел, и всегда они терпели неудачу.

то, что было предпринято, - это узел мультискрипта, но это было хлопотно

В воскресенье, 10 июня 2018 г., в 15:01 [email protected] написал:

Несколько раз пытались выполнить несколько сценариев на узел, и всегда
провал.

—
Вы получаете это, потому что вы прокомментировали.

Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/godotengine/godot/issues/19486#issuecomment-396068742 ,
или заглушить тему
https://github.com/notifications/unsubscribe-auth/AF-Z26u8Rqc1yL-BGX16CAx_iWsYEo1oks5t7V8CgaJpZM4UhqDC
.

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

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

Такие фреймворки, как Escoria, могут извлечь из этого большую пользу, и могут быть другие фреймворки для таких вещей, как ролевые игры, платформеры, визуальные романы и т. д.

Все, что я здесь говорю, довольно абстрактно, но четкое разделение того, что встроено, что является сторонним ресурсом, и что является пользовательским кодом (как бы это разделение ни представлялось), позволит «сохранить ядро ​​небольшим и предоставить расширения». "идти вперед намного легче.

Межъязыковое наследование кажется мне ужасной идеей.

В работе, которую я выполнял с TypeDB в EditorData, я сохранял имя типа в пространстве имен для пути к файлу HashMap, который после модификации преобразуется в Dictionary в ProjectSettings. В моей ветке синтаксический анализатор и компилятор GDScript используют эти данные для создания глобальных имен типов. В это время у меня появляются сценарии пользовательского типа. Сценарии могут обращаться к ним и наследовать их по имени. Более того, эти данные доступны всем, кто может видеть ProjectSettings. Таким образом, CSharpScript, видимый редактором, может генерировать сопоставление, которое вводится в словарь ProjectSettings, позволяя типам, объявленным в C#, быть доступными для GDScript. Вероятно, также существует способ обернуть данные словаря ProjectSettings в объект C#, который возвращает объекты Script при доступе, чтобы C# также мог обращаться к типам GDScript по имени.

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

Мне действительно нравится предложение @karroffel о возможности наследования сценариев между языками (даже не знаю, возможно ли это). Каким-то образом автоматически дублируются методы, делегирующие вызовы базовому скрипту, а также определяющие все те же свойства/сигналы/константы и т.д.

Я тоже хотел бы более упорядоченный доступ к контенту в AssetLibrary, с возможностью оставить некоторые плагины для редактора в целом, а другие плагины только для одного проекта.

Система TypeDB, которую я делаю, также будет поддерживать редактор для...

1. Отображение всех пользовательских сценариев в диалоговом окне CreateDialog
2. Расширение скрипта пользовательского типа автоматически заставит вас расширить этот скрипт при добавлении скрипта к узлу.
3. Удалив сценарий, который расширяет сценарий пользовательского типа, восстановите сценарий пользовательского типа после удаления (поэтому вы не можете удалить пользовательский сценарий — вместо этого вы должны использовать команду «Изменить тип» в редакторе).

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

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

Мое видение Годо

TLDR: я представляю Godot как инструмент, который можно значительно расширить с помощью ресурсов и плагинов очень простым, модульным и удобным для новичков способом.

Мотивы отказа от моей рекламы SpringArm более чем разумны, и поэтому @karroffel и я обсудили направление, в котором движок может оставаться легким и в то же время удобным для пользователя.

Я бы хотел, чтобы основной движок был чистым, небольшим и быстрым, а также хорошо интегрированной экосистемой дополнений и плагинов.
Поскольку ArchLinux имеет более одного репозитория пакетов, я думаю, было бы здорово, если бы у Godot был «официальный» (поддерживаемый Godot) репозиторий для основных функций (и узлов, которые теперь являются основными) и еще один репозиторий для сообщества. В основной «репозиторий расширений» Godot я бы поместил все узлы, которые сложно кодировать, но которых недостаточно для поставки с ванильной версией движка.
Заметим, что часто не принимается во внимание то, что некоторые функции могут быть легко закодированы, но также могут потребовать много исследований, прежде чем изложить эти несколько строк.

Я предполагаю, что пользователи смогут загружать плагины и активы, которые «расширяют» сам движок: в зависимости от того, что вы загружаете, у вас есть Godot-fps, Godot-platformer или Godot-racing.

Godot может стать первым движком, который действительно будет похож на Unix и станет модульным, превзойдя даже Unity с его расширениями редактора. Многие из вас знают, как хорошо, когда ваша система Linux не является «этим дистрибутивом», это ваша собственная и настроенная система с вашими очень личными функциями.

Преимущества

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

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

Разделение Godot на разные «кольца» дает возможность более тонкого управления PR и функциями и может дать @reduz и другим очень техническим разработчикам больше времени, чтобы сосредоточиться на хардкорных технических вещах , в то время как другая команда будет управлять кольцом расширения, больше учитывать отзывы пользователей и удобство использования , а не сталкиваться с раздуванием движка, поскольку «удлинительное кольцо» будет раздуваться по требованию.

О многоязычном наследовании

По мере того, как Godot растет, хранилище активов может легко превратиться в пылающий беспорядок. Строгое разделение между языками сценариев может буквально разрушить любую попытку людей продать активы и развить экосистему в магазине активов, лишив фрилансеров многих возможностей создавать и продавать инструменты для Godot.
Языковые мосты должны быть более полными, если мы хотим, чтобы любой шанс развивал живую экосистему.
На данный момент межъязыковое наследование кажется мне замечательным, но я недостаточно техничен, чтобы что-то сказать по этому вопросу. Я просто хочу указать на проблему, которая, скорее всего, скоро появится, тем более, что вокруг C# существует такое огромное сообщество.

Примечание об удобстве использования

Я использую Godot уже почти год, и в последнее время мне кажется, что люди, которые принимают решения о функциях, не используют движок для чего-то большего, чем небольшие демонстрации. @LikeLakers2 указал на проблему, которую, как мне кажется, разделяют некоторые пользователи, которые не очень хорошо разбираются в основной команде разработчиков.

Я думаю, что то, что считается раздуванием, является тривиальной темой в большей схеме вещей, это не похоже на решение, которое мы принимаем сейчас, это то, что нам нужно будет соблюдать на протяжении всей жизни Годо. Открытый исходный код позволяет нам вносить изменения, когда нам нравится, единственная проблема заключается в том, что чем больше мы ждем, тем более тяжелым будет решение об изменении.

Теперь это также обсуждение для другого дня. Прямо сейчас, в настоящем, факты таковы,

1. Godot — это компактный, быстрый и портативный игровой движок. И мне это очень нравится, но....
2. Исполняемый файл Godot занимает около 45-60 МБ в зависимости от различных факторов. Но размер шаблона экспорта может достигать 300 МБ. Теперь это большой удар по первому пункту.
3. Godot имеет множество замечательных функций, которые делают его интересным для новичков, таких как Camera Follow, Parallax BG и Vehicles, это большой плюс по сравнению с другими подобными игровыми движками. Поскольку это значительно упрощает создание игр в Godot. И делает Godot домом для многих разработчиков-новичков, у которых нет навыков написания собственных реализаций для таких инструментов.

Теперь, что произойдет, если мы удалим функции, которые некоторые люди считают раздутыми. Ну, двигатель, конечно, будет компактнее, но нужно ли это? Я не вижу проблемы в том, чтобы скачать 100-мегабайтный движок, если он лучше удовлетворяет мои потребности. Но как насчет экспорта, разве 100-мегабайтный движок не будет экспортировать большие игры?

Вероятно, да, но в мире, где настольные компьютеры, похоже, не используют что-то меньшее, чем 256 ГБ SSD + 1 ТБ HDD, и даже телефоны имеют пространство, начиная с минимум 16 ГБ, и все это, более чем вероятно, увеличится , будет ли это так? ПЛОХОЙ?
Я имею в виду, что нам пока не нужно ничего удалять, нам просто нужно начать лучше управлять некоторыми вещами, и на этом все.
Функции должны иметь своего рода список важности, чтобы решить, должны ли они быть в ядре или нет, но это не означает, что это становится законом, а скорее эмпирическим правилом.

А для придирок мы могли бы удалить некоторые крайне неиспользуемые инструменты, но это все. Функции не раздувают движок, если мы не будем небрежны. И даже раздувание Unity не помешало людям его использовать.
И я абсолютно не имею в виду, что мы не должны заботиться о вздутии живота, но быть осторожным и быть параноиком — это разные вещи вместе взятые.

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

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

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

Точка межъязыкового наследования нуждается в некотором объяснении. Я не только считаю это плохой идеей, но даже не представляю, как это возможно.

1. Исполняемый файл Godot занимает около 45-60 МБ в зависимости от различных факторов. Но размер шаблона экспорта может достигать 300 МБ. Теперь это большой удар по первому пункту.

300MB шаблонов экспорта? Вы имеете в виду с активами?

@neikeq дело в том, что если весь ваш проект написан на C#, но вы используете пользовательский узел, загруженный из AssetLibrary, то этот узел является просто обычным узлом, скорее всего, только с прикрепленным GDScript.

Если вы хотите «расширить» узел, вы не можете! Я думаю, вы можете добавить дочерний узел, чтобы добавить новые функции, но таким образом невозможно переопределить вещи.

Реализация

В настоящее время языки сценариев используют очень похожий шаблон для унаследованных вызовов, который можно обобщить.

https://github.com/godotengine/godot/blob/76875ba145c5745033d0a1c9fda2f4349e2509b3/modules/gdnative/nativescript/nativescript.cpp#L696 -L712

https://github.com/godotengine/godot/blob/76875ba145c5745033d0a1c9fda2f4349e2509b3/modules/gdscript/gdscript.cpp#L638 -L651

https://github.com/godotengine/godot/blob/76875ba145c5745033d0a1c9fda2f4349e2509b3/modules/mono/csharp_script.cpp#L1175 -L1191

Шаблон здесь

Class *c = bottom;
while (c) {
    if (c->has_method(m)) {
        c->call(m);
        break;
    }
    c = c->base;
}

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

Если бы каждый скрипт имел Ref<Script> parent_script вместо специфичной для языка структуры наследования, это можно было бы обобщить до

if (this_class->has_method(m)) {
    this_class->call(m);
} else {
    // method not declared here, go to base class
    parent_script->call(m);
}

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

@neikeq Смотри это,

@swarnimarun Это шаблоны экспорта для всех платформ, всех поддерживаемых арок, отладки и выпуска, их размер совершенно не имеет отношения к «раздуванию» движка. Мы можем решить поддерживать только 64-битную версию Linux X11, и этот файл будет весить 20 МБ...

@ akien-mga Я не собирался называть это раздуванием.
Но новый пользователь загрузит его в полном размере, у него не будет достаточно опыта, чтобы знать, что он может собрать его отдельно или загрузить для определенной платформы.

Как это не имеет значения, когда это то, что мы предоставляем начинающим пользователям?

@akien-mga: размер шаблонов экспорта имеет значение, поскольку ваш аргумент в пользу удаления узлов был

размер развертывания имеет значение (мобильный, HTML5)

@swarnimarun @Zireael07 Да, размер шаблонов экспорта имеет значение индивидуально , но я считаю, что измерение размера пакета шаблонов не дает нам никаких указаний. Размер одного шаблона (например, шаблон выпуска wasm, заархивированный 3,4 МБ, или APK выпуска Android, 23 МБ заархивированный с библиотеками armv7 и x86) гораздо важнее, чем «загрузка всего необходимого для разработки занимает 350 МБ» (+, может быть, 10 ГБ для Visual Studio, если вам нужно что-то построить...). Что имеет значение, какой размер минимальная игра будет иметь на платформах, где размер имеет значение (веб, мобильная версия).

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

Это то, что я действительно люблю в Годо. Вы можете сразу закодировать свою функцию, а затем кто-то придет и скажет вам: «Эй, ты знал, что у нас есть эта встроенная вещь, которую ты можешь использовать?»

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

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

Это то же самое, что потерять переносимость. Мои плагины являются частью моего проекта, мне это нужно на любом компьютере, на котором я работаю, и мне нужна конкретная модификация каждого плагина для каждого проекта... Я не вижу никаких преимуществ в том, чтобы мои плагины хранились в .local/независимо . Это своего рода запутывание моих проектов.

Актуальная система res://addons хороша... бесплатна для пользователя и переносима на компьютеры. Если на эту систему нет нареканий, нужно ли ее менять? Есть много других вещей, на которые пользователи действительно жалуются...

@Ranoller , вы сможете в любой момент скопировать плагин в папку с игрой.
В любом случае, в этом случае в вашем проекте project.godot ваш плагин будет указан как зависимость, и он будет загружен на ваш новый компьютер с правильной версией.

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

@Ranoller идея состоит в том, чтобы переместить те плагины за пределы проекта , которые вам не нужно изменять . Например, InterpolatedCamera будет просто узлом, который вы хотите использовать как есть, а не изменять его код.

То же самое может быть в случае с плагинами только для редактора, такими как списки TODO или интеграция с git и т. д. Это вещи, которые вы хотите использовать, но не менять.

Это очень похоже на менеджер пакетов, и библиотеки работают на всех языках, кроме C и C++. У вас есть файл, в котором указаны все зависимости, а затем менеджер пакетов извлечет эти зависимости. Это происходит даже при смене ПК — менеджер пакетов загрузит любые еще не существующие пакеты.

Когда вы хотите что-то изменить , вы вносите код в проект. Затем это в вашем git и проекте со всем его исходным кодом и т. д. Но это не всегда так.

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

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

@karroffel Но как межъязыковое наследование будет работать на каждом языке? Это может быть легко для GDScript, который тесно связан с движком, но это совсем другая история для языков общего назначения, таких как C# или других языков, добавленных поверх GDNative.
Я серьезно не понимаю, как этого можно было достичь, тем более, как это не могло принести больше вреда, чем пользы.

IMO, не рекомендуется изменять содержимое надстройки, от которой зависит ваш проект. Если необходимы какие-либо изменения, просто скопируйте содержимое за пределы папки аддона и внесите изменения там.

РЕДАКТИРОВАТЬ: или "форкнуть" аддон 😜

@neikeq То, что вы изменяете, находится внутри вашего проекта. Когда вы хотите изменить аддон, он копируется внутри вашего проекта и модифицируется только локально.

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

@QbieShay Что делать, если есть обновление, которое изменяет измененные вами файлы?

@neikeq Наследование сценариев не является РЕШЕНИЕМ этой проблемы, это будет только одно из них. В настоящее время нет хорошего способа переопределить функциональность узла с прикрепленным скриптом, когда вы хотите использовать другой язык программирования.

Если бы у нас была возможность переопределять методы в API Script , это тоже было бы хорошо! (в основном внешнее определение новых методов и переопределение существующих методов).

@PLyczkowski это предложение, которое тоже было бы полезно, но то, что я предлагаю, не ограничивается этим - и не без причины.

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

С другой стороны, интеграция с git может быть очень полезной для добавления пользовательского поведения, которое трудно выразить с помощью git-хуков, поэтому желательна настройка.

Нет черной/белой линии, когда что-то должно быть внутри проекта, а когда снаружи, редактор или нет.

@neikeq

Что делать, если есть обновление, которое изменяет файлы, которые вы изменили?

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

Идея в том,

• вне проекта: легче обновлять, легче иметь кросс-проект
• внутри проекта: настраиваемый, теряет статус актива, без автоматических обновлений

В основном они становятся обычными файлами, когда вы копируете их в свой проект.

Читая это, я могу сказать, что предотвращение раздувания и минимизация размера файлов игр — это правильно. Позвольте мне бросить несколько идей здесь все же.

• Godot может использовать систему, которая удаляет из игры код, используемый узлами, которые он не использует (т. е. большинство 2D-узлов со многими 3D-играми и большинство 3D-узлов со многими 2D-играми). Это уменьшит давление, чтобы не принимать новые типы узлов, чтобы уменьшить размер файла игры. Например, пользователи Unity уже используют что-то похожее на отличные результаты.
• Godot, возможно, может иметь встроенный браузер ресурсов, который подключается к странице плагина на сайте Godot. Вы выбираете, какие пользовательские узлы вам нужны, и они автоматически устанавливаются в нужное место. Плагины, которые не используются, удаляются при упаковке игры.
• Возможно, даже популярные пользовательские узлы могут быть связаны со сборками Godot (как это делает Blender с надстройками). Пользовательские узлы также должны быть помечены, поскольку они обычно могут быть более высокого уровня и могут, в некоторой степени, быть более черными ящиками, чем более общие узлы.

Мои 2 цента в любом случае.

@Ace-Dragon

1. Я думаю, что ваш первый пункт был бы действительно крутым, если бы он стал функцией всего движка. Если экспортированная игра не использует узел или если узел не используется ни одним из узлов, которые вы используете в своем проекте, было бы здорово, если бы можно было автоматически исключить их из окончательного двоичного файла. Помимо этого, в настоящее время вам просто нужно полагаться на переключатели и перекомпилировать движок. :-/

2. Это в основном то, чем уже является библиотека активов. Проблема в том, что он не имеет никакого понятия о зависимостях, напрямую помещает вещи в каталог вашего проекта и не имеет никаких средств для поддержки заданного набора плагинов в масштабах всей системы для каждого проекта, который вы делаете.

3. Пользовательские узлы всегда явно отмечены, так что не нужно об этом беспокоиться (у них есть значок скрипта рядом с ними, потому что вы создаете пользовательские узлы, используя скрипт для его расширения). Поскольку это скрипты, они никогда не поставляются с движком. Они будут частью какого-то плагина, так что, если что, у вас может быть что-то похожее на мой репозиторий godot-next, который представляет собой репозиторий «расширений узлов» для сбора материалов. Это будет просто более «официальная» емкость (это репо также может потребовать много работы, смеется).

Хорошо, медленно, но ловко... Если я буду поддерживать аддоны внутри проекта, я смогу работать в коде плагина, как и в других скриптах, без потери интеграции git с текущим проектом и без потери переносимости... Но если я хочу преобразовать какой-либо из плагины в инструменте для других разработчиков или в общем инструменте для всех моих проектов, я разделяю его в форме внешнего пакета, который можно актуализировать с помощью внешнего репозитория git инструмента и изменить для других людей с библиотекой активов... Если да, для меня это нормально... Если другой разработчик использует инструмент и ему нужна его личная версия, ему/ей нужно хранить внутри проекта, и в этом случае плагин не актуализируется (не потеряйте свою работу )... Это?

@Ranoller Да, я думаю, вы поняли суть его предложения.

Некоторые отзывы о том, что вы, ребята, обсуждаете

1) Если бы это была реальная проблема, требующая решения, я бы предпочел поддержку нескольких скриптов на узел (это всего лишь пара строк кода), а не межъязыковое наследование (что является безумием). Я все еще не думаю, что это проблема, требующая решения.

2) Мне не нравится идея менеджера пакетов и общесистемной установки надстроек. Я думаю, что это ужасная идея, и ничего значимого из этого не получается. Я видел, как травматично даже для разработчиков Unity обновлять версию ресурса в крупных проектах, видеть, как все ломается, и тратить дни на исправление.

3) Мне не нравится сама идея управления пакетами. Я видел, как пользователи Unity в подавляющем большинстве случаев без конца взламывали то, что они получают из хранилища ассетов. Слишком часто они просто используют его как основу, затем работают над ним и настраивают его для своих собственных целей, потому что актив, который вы получаете, только на 60/70% соответствует тому, каким вы хотите его видеть... или они просто хотели увидеть как это делается, а затем сделать свое дело позже.

Я думаю, что в реальной жизни обсуждаемые предложения ничего не дают, поэтому я не планирую добавлять что-либо к этому обсуждению.

Насколько мы можем уменьшить размер движка, если позволим людям экспортировать без каких-либо 3D-материалов простым способом? Многим играм (половина? больше половины?) не требуются функции 3D, но они все еще находятся в одном и том же бинарном файле. Я знаю, что теоретически его можно перекомпилировать самостоятельно с помощью макроса на любой платформе, но с небольшими вложениями...
Кроме того, следуя этой идее, если бы модули были просто «внутренними» динамическими библиотеками, которые являются частью официальных дистрибутивов движка, добавление дополнительных функций к движку было бы меньшей проблемой в том смысле, что их можно было бы очень легко отключить (просто так). ), однако использование подобных динамических библиотек может быть немного ограничивающим для некоторых платформ (в основном для мобильных устройств и HTML5). Так что для модулей я бы понял, что GDNative предпочтительнее (о, подождите... у него те же проблемы ^^).

@reduz как будут работать несколько скриптов? И как это повлияет на удлинение двигателя? Вы объяснили свою идею в существующем выпуске? (спрашиваю, потому что это, вероятно, слишком много, чтобы объяснить это в этой теме)

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

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

Что касается проблем с раздуванием, я был бы признателен за больший контроль над _modules_, и за это уже проголосовали в опросе Patreon в январе 2018 года:

Приоритет дорожной карты: больше возможностей отказаться от компиляции частей движка для создания двоичных файлов меньшего размера [ожидается в версии 3.1]

Трудно комментировать это предложение, поскольку оно касается самых разных вещей, и люди комментируют разные аспекты и поднимают разные вопросы.

В целом, я думаю, что предложение для «менеджера зависимостей» звучит хорошо на бумаге, но я думаю, что реализация не принесет никаких преимуществ, которые не принесет просто добавление дополнений в папку проекта. Потребуется включить сложный механизм управления зависимостями, чтобы решить 1 случай «более простой установки». В этом проекте уже открыто более 3000 вопросов с небольшой командой участников. По моему мнению, внедрение чего-то столь сложного, как управление зависимостями, является пушками.

Я согласен с @reduz , что ядро ​​должно быть минималистичным. На мой взгляд, все, что не может быть классифицировано как «основное», должно быть включено независимо. Как пользователь, я ожидаю, что Godot будет мультиплатформенной игрой на движке. Если мне нужен _игровой фреймворк_ godot (транспортные средства, интерполированные камеры, ландшафт, контроллеры игроков и т. д.), он должен быть доступен в виде первоклассного дополнения (или модуля?), независимого от ядра. Я думаю, что улучшение истории аддонов помогает в этом, но полноценный менеджер зависимостей и автоматизированный менеджер аддонов, похоже, подталкивают его к низкой чистой выгоде.

Мой последний комментарий будет заключаться в том, чтобы с осторожностью относиться к «новичкам» и отказываться от «опытных» пользователей. Godot привлекает внимание более продвинутых пользователей благодаря своим мощным функциям (модули, gdnative, gdscript, редактор и т. д.) и гибкости. Именно такие пользователи проверяют godot, раздвигают его границы, изучают его API и часто вносят свой вклад в проект. Это те же пользователи, которые могут создавать символические ссылки на каталог в своей файловой системе, чтобы повторно использовать свои дополнения в нескольких проектах.

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

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

Я предполагаю, что в конце концов управление пакетами будет довольно хлопотным большую часть времени. Даже в случае новой версии пользовательского узла, который вы добавили в свой проект, его обновление может вызвать множество других проблем (даже с semver, поскольку вы могли обойти ошибку, которая теперь исправлена).

OTOH для некоторых плагинов редактора может иметь смысл исключить их из проекта и часто обновлять. Примером может служить плагин My ​​Tiled importer. Скорее всего , вы не хотите, чтобы он поставлялся с игрой, и хотите иметь последнюю версию, которая поддерживает больше функций и содержит исправления.

Это даже больше относится к другим расширениям редактора, таким как менеджеры git и трекеры времени. Возможно, вас даже не волнует, есть ли у ваших товарищей по команде плагин для отслеживания времени или нет, это не связано с проектом. Тем не менее, вы должны поместить в свою папку addons и включить в настройках проекта, а затем будьте осторожны, чтобы не зафиксировать это с остальной частью игры. Это, вероятно, меньшинство плагинов, но все же наличие общесистемных плагинов, которые не привязаны к проекту, имеют реальный вариант использования.

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

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

Теперь наследование кросс-скриптов для меня - нет-нет (если это вообще возможно). Мультискрипт довольно странный, но он эффективно заменит наследование кросс-скриптов более чистым способом. Хотя это вызывает некоторые опасения, например: как вызвать функцию другого скрипта в том же объекте? Думаю, это другое обсуждение.

Ссылка на скрипты по имени OTOH звучит очень красиво. В идеале на все ресурсы можно было бы ссылаться по имени, поэтому пути не являются проблемой для решения, если вы решите перемещать вещи.

@vnen единственная проблема, которую я все еще вижу, это несовместимость между аддонами и проектами. Как бы вы решили эту проблему?
Потому что, если есть официальная библиотека расширений, поддерживаемая Godot, либо каждая нода поставляется на всех возможных языках, либо я вижу межъязыковое наследование единственным способом, которым мы можем сохранить удобство для пользователя.

@vnen , если вы ссылаетесь на все активы по имени, это будет конфликтный беспорядок. Это больше подходит для сценариев, поскольку только программисты должны придумывать уникальные имена для своих классов, чтобы вводить и использовать их (или, реже, ресурсы). Что касается других вещей, если мы избавимся от путей, нам понадобится этот https://github.com/godotengine/godot/issues/15673 , если только вы не хотите, чтобы художники, дизайнеры и т. д. имели уникальное имя для всех своих активов (что все еще идет с проблемой переименования).

@Zylann @vnen TypeDB, которую я пишу, теоретически должна позволять людям при желании регистрировать имя для любого актива. В настоящее время я использую его только для сценариев и планирую также использовать его для сцен пользовательского типа, но вы также можете изменить его для работы с ресурсами. В настоящее время логика имеет только HashMap для сценариев и сцен, но, возможно, я мог бы обобщить логику для обработки любого типа активов, все в категоризированных HashMap.

Я могу уважать озабоченность Reduz по поводу общесистемных вещей, и это, безусловно, проблемы с плагинами, которые изменят предложения движка, но когда дело доходит до функций конкретно для редактора, как описывает vnen, я определенно вижу, что это полезно в относительно безопасный способ. Если люди добавляют плагины, чтобы предоставить редактору больше возможностей, это не те вещи, которые они обычно взламывают и модифицируют сами. Они просто будут использовать его как есть, а если и внесут изменения, то, вероятно, для того, чтобы прорекламировать эти изменения, чтобы улучшить инструменты. В конце концов, вы не адаптируете их к игре. Таким образом, если это для такого плагина, я думаю, у нас должны быть средства легкого предоставления этих функций движку, когда вы начинаете новый проект (каким-то образом).

Одним из возможных методов, который мог бы упростить задачу без использования диспетчера зависимостей, было бы просто не делиться зависимостями между плагинами, а вместо этого дублировать их внутри проекта, таким образом, управление версиями не является проблемой. Потенциально это сделало бы отдельный проект больше, но если он предназначен для контента, который имеет отношение к игре, и люди все равно будут возиться со всем этим, как говорит Редуз, тогда они могут просто переместить зависимости. Что нам нужно в этом случае, так это способ для плагинов объявить, КАКИЕ внешние плагины-зависимости у них есть, и дать пользователям возможность настроить, где они ищут этот зависимый плагин. Таким образом, если они ДЕЙСТВИТЕЛЬНО решат переместить плагин и заставить другие плагины искать его в том же месте, они смогут это настроить. Но тогда по умолчанию все просто работало бы из коробки, управляя собственными зависимостями. В этом случае, вероятно, также будет легче справиться с полным предложением плагинов как подпроектов (# 19178).

Это убережет нас от глобальных зависимостей, которые вообще требуют менеджера зависимостей (проблема Reduz номер 3). И мы могли бы связать это с функцией, которая позволяет пользователям создавать список избранных ресурсов из библиотеки ресурсов, которые они могут выбрать для автоматической установки в свои проекты при создании нового проекта (так что все по-прежнему хранится локально, но это происходит автоматически). и им не нужно вручную выходить, находить все предпочитаемые плагины и вручную загружать и устанавливать их). Это устранит проблему удобства использования, которую @karroffel хочет решить в отношении простого расширения движка идентичными активами при создании нового проекта.

Для более специфичных для редактора плагинов, которые не нужно было бы дублировать, возможно, люди могли бы просто пометить эти «любимые» плагины, и они автоматически создали бы для них символические ссылки, сохраняя плагины в какой-то пользовательской папке. Итак, возможно, есть «Избранное редактора» и «Избранное проекта» для «Я хочу это в каждом проекте, сохранить его в общем месте и сделать символическую ссылку» и «Я хочу это в каждом проекте, дублировать его» соответственно.

Объедините это с материалом TypeDB для именования скриптов / настройки пользовательских типов, и я считаю, что это правильно решит все упомянутые проблемы, за исключением проблемы межъязыкового наследования скриптов / мультискриптов, которая является чем-то совершенно другим.

Итак, возможно, есть «Избранное редактора» и «Избранное проекта» для «Я хочу это в каждом проекте, сохранить его в общем месте и сделать символическую ссылку» и «Я хочу это в каждом проекте, дублировать его» соответственно.

Может тогда удобнее иметь "связки" плагинов - пользовательские официально утвержденные + пользовательские локальные. Таким образом, вместо «Избранное редактора» и «Избранное проекта» у нас есть «Стрелок от первого лица», «Игра с блоками вокселей» или просто «Мои материалы». Почти так же, как, например, стартовые активы Unity, но не нужно раздувать их текстурами и т. Д., Разных типов лиц талисмана Годо должно быть достаточно: D

Это также работает как менеджер пакетов, где менеджер пакетов теперь является набором плагинов, курирующим человека.

@starry-abyss Плагины, которые люди делают сейчас, уже потенциально могут быть «наборами» других плагинов (пользователь или разработчик плагинов может просто переместить их внутрь себя и объединить вместе). Цель здесь состоит в том, чтобы иметь функциональное различие между категориями, где редактор фактически выполняет операции по улучшению удобства использования от имени пользователя, чтобы пользователю не приходилось делать что-то вручную.

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

@Зиланн

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

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

@QbieShay

единственная проблема, которую я все еще вижу, это несовместимость между аддонами и проектами. Как бы вы решили эту проблему?

Если это действительно проблема, то мультискрипт, вероятно, самое простое решение. Он был удален в основном из-за обсуждения в #8546, но я думаю, что это можно решить без особых усилий.

Я считаю, что проблема нескольких плагинов, делающих одно и то же, носит виртуальный характер. У нас уже есть звездная система в ассетлибе, эта система как раз такая, показатель того, что обычно используют и предпочитают.

То, что упускается из виду, но, по моему мнению, является одной из причин, по которой люди просят дополнения к основному движку, заключается в следующем: кто собирается компилировать эту вещь для всех платформ?

Конечно, для плагина gdscript это не проблема, но для плагина Cpp это огромная проблема.

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

Поэтому, на мой взгляд, мы должны сначала решить эту проблему, и я понятия не имею, как. Можно ли, например, скомпилировать для всех платформ через линукс? Если да, то мы можем использовать что-то вроде Ubuntu Imager: https://www.maketecheasier.com/create-linux-distro/ , чтобы создать уже настроенную среду Linux для создателей плагинов и пользователей GDNative.

Можно ли, например, скомпилировать для всех платформ через линукс? Если да, то мы можем использовать что-то вроде Ubuntu Imager: https://www.maketecheasier.com/create-linux-distro/ , чтобы создать уже настроенную среду Linux для создателей плагинов и пользователей GDNative.

Нет (сборки macOS и iOS действительно могут быть скомпилированы только из macOS), и я не думаю, что заставлять людей загружать живую ОС Linux, чтобы иметь возможность загружать библиотеки GDNative в библиотеку ресурсов, — хорошая идея.

Однако можно скомпилировать для всех платформ с помощью Travis CI и AppVeyor, которые вы можете бесплатно установить в общедоступных репозиториях GitHub.

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

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

Встроенные узлы для основных вещей — одна из лучших вещей редактора, если важные узлы или ресурсы будут удалены, менеджеру проекта потребуются шаблоны для автоматической загрузки общих узлов.

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

И магазин должен предлагать официальные пакеты для офлайн-использования (с поддержкой офлайн-магазина в редакторе).

если это будет сделано, многие другие вещи должны будут получить официальную поддержку (исправление ошибок) и доступность (обновление версии).

TBH, обслуживание вещей в двигателе или в магазине почти одинаково. Например, узлы транспортных средств имеют мало отчетов об ошибках, потому что их почти никто не использует, и даже те ошибки, о которых сообщалось, так и не были исправлены. Я считаю, что аутсорсинг таких узлов намного лучше, потому что легче заставить людей пытаться что-то исправить, не возясь с исходным кодом движка, поэтому есть больше потенциальных участников.

Если в узле движка есть проблема, люди откроют отчет об ошибке. Но если это плагин с кодом GDScript, человеку довольно легко изменить код и протестировать его, вероятно, предоставив исправление сообществу. Я действительно вижу в этом выгоду. Но только в том случае, если эти внешние узлы могут быть легко интегрированы, что в настоящее время не так. Это включает в себя хорошую видимость и интегрированную документацию.

И магазин должен предлагать официальные пакеты для офлайн-использования (с поддержкой офлайн-магазина в редакторе).

Да, и автономные пакеты также должны быть легко установлены.

@редуз

Мне не нравится идея менеджера пакетов и общесистемной установки надстроек. Я думаю, что это ужасная идея, и ничего значимого из этого не получается. Я видел, как травматично даже для разработчиков Unity обновлять версию ресурса в крупных проектах, видеть, как все ломается, и тратить дни на исправление.

Хорошо, но почему ? Каковы фактические ограничения и проблемы, которые вы видите в этом? Если сказать «мне это не нравится», не объяснив, почему, это не убедит людей в том, что это плохая идея; вы должны дать хотя бы какое-то объяснение, кроме упомянутых расплывчатых причин.

Хорошо, но почему? Каковы фактические ограничения и проблемы, которые вы видите в этом? Если сказать «мне это не нравится», не объяснив, почему, это не убедит людей в том, что это плохая идея; вы должны дать хотя бы какое-то объяснение, кроме упомянутых расплывчатых причин.

Предполагая глобальный реестр «аддонов» в системе:

• Загрузите дополнение v1.3 из онлайн-системы дополнений. Аддон установлен в ~/.godot или что-то еще
• Версия связана с моим проектом в ~/my-project в каком-то локальном хранилище (файл, sqlite и т. д.)
• Я обновляюсь до v1.4. Теперь мой менеджер дополнений должен знать, что 1.3 не используется ни одним проектом, и очистить его. Таким образом, у менеджера есть дополнительные функции для отслеживания зависимостей и того, какие проекты имеют какие зависимости. В качестве альтернативы никто не добавляет эту функцию, поэтому моя локальная машина загрязняется несколькими версиями одного и того же дополнения.
• Я решаю, что хочу переместить свой проект в ~/big-project/game . Теперь мне нужен способ обновить ссылку на мой проект в реестре дополнений. Как я могу это сделать? Должен ли я запускать менеджер надстроек отдельно? Manager register new_proj_location ?
• Теперь принято решение хранить зависимости локально в стиле requirements.txt python. Отлично, проблема решена. За исключением того, что я снова не знаю, какие проекты зависят от каких глобальных пакетов, мне приходится сканировать систему на наличие проектов godot или регистрировать каждый проект, чтобы не накапливать версии.
• Хорошо, я просто работаю над проблемой. Время от времени вручную очищайте мертвые пакеты. Итак, я работаю над VehicleBodyAddon для своего проекта, используя v1.5. Тьфу, он делает F * M для расчета ускорения, но я хочу сделать F * M * 5. Позвольте мне быстро изменить код ... Упс, вот и все мои другие проекты, использующие этот аддон.
• Позвольте мне создать новый аддон, который зависит от другого аддона. Хм, теперь мне нужно зарегистрировать, что мой новый пользовательский аддон зависит от существующего. Теперь мне нужно расширить менеджер, чтобы он не только загружал дополнения из удаленного места, но и работал с локальными путями или репозиториями git или чем-то еще.

Предполагая, что "вендорные" аддоны:

• Скачать аддон в каталог аддонов
• Обновление переопределяет аддон в каталоге

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

Это именно то, что делает другая команда ruby gem , и никто не жалуется, поскольку у них есть команда для очистки старых версий драгоценных камней (термин ruby ​​для надстроек), от которых не зависят другие драгоценные камни. Кроме того, зачем нам сохранять старую версию, когда, если мы обновляем, новая версия, вероятно, в любом случае будет в основном совместима? Толчок к толчку, пользователь может снова получить старую версию, если его программа абсолютно зависит от старой версии, чего, скорее всего, не будет.

Я решаю, что хочу переместить свой проект в ~/big-project/game . Теперь мне нужен способ обновить ссылку на мой проект в реестре дополнений.

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

Теперь принято решение хранить зависимости локально в стиле requirements.txt python. Отлично, проблема решена. За исключением того, что я снова не знаю, какие проекты зависят от каких глобальных пакетов, мне приходится сканировать систему на наличие проектов godot или регистрировать каждый проект, чтобы не накапливать версии.

Требование в стиле Python.txt было бы отличным вариантом для такой системы надстроек. Таким образом, если проекту абсолютно действительно нужна какая-то старая версия (но опять же, вам все равно часто нужна последняя версия), мы можем указать это, и если менеджер дополнений в конечном итоге удалит эту старую версию, он может знать чтобы повторно загрузить его позже.

Итак, я работаю над VehicleBodyAddon для своего проекта, используя v1.5. Тьфу, он делает F * M для расчета ускорения, но я хочу сделать F * M * 5. Позвольте мне быстро изменить код ... Упс, вот и все мои другие проекты, использующие этот аддон.

Или использовать локальную копию надстройки для этого проекта? Если это действительно требует изменения, которое применяется только к одному проекту, и вы действительно не хотите делать локальную копию проекта, просто создайте файл .gd, который расширяет его и вносит изменения, а затем используйте этот новый файл GD вместо файла из аддона.

Позвольте мне создать новый аддон, который зависит от другого аддона. Хм, теперь мне нужно зарегистрировать, что мой новый пользовательский аддон зависит от существующего. Теперь мне нужно расширить менеджер, чтобы он не только загружал дополнения из удаленного места, но и работал с локальными путями или репозиториями git или чем-то еще.

Подмодули Git. Еще один файл requirements.txt (например, что делает python). Или просто скажите пользователю, что для этого требуется надстройка X. Это не так сложно, как вы думаете. Большинство пользователей Godot не тупые. Они знают, что означает «Для этого дополнения требуется: дополнение X Core, дополнение Y, дополнение Z».

@rminderhoud Если ваша рекомендация состоит в том, чтобы хранить копию надстроек проекта в каждом проекте по мере необходимости (чтобы у него была только та версия, которая ему нужна, и ее можно было свободно изменять, не вызывая проблем), то, возможно, мое предыдущее предложение может касаться ядра проблема, связанная с этой проблемой? А именно, создайте утилиту в EditorSettings, которая позволит пользователю указать, какие надстройки они хотят автоматически устанавливать при создании нового проекта.

Мы могли бы даже создать аналогичную утилиту, которая позволяет людям формировать жесткие ссылки на местоположение user:// для хранения определенных (особенно для дополнений, добавляющих функции редактора). Если пользователь решит сделать это безответственно и облажается со своим проектом, это будет его собственное решение. Метод по умолчанию простого копирования всех ресурсов во время создания проекта может быть очень полезным.

Добавление новой системы плагинов не должно быть несовместимо с res://addons , как сейчас... И это потому, что:

Настоящая система отличная...

Я повторяю:

Настоящая система отличная...

Никаких предыдущих жалоб на этот момент.

Я опоздал на это обсуждение, вот некоторые мысли по поводу предложения:

• Я лично еще не использую много «активов» и чувствую, что с папкой аддона как есть легко работать.
• Я понимаю, что будет делать межъязыковое наследование сценариев и какую проблему оно решит (разрешить разработчику C# расширяться от сценария GDScript для добавления пользовательских функций с помощью C#) (не то чтобы у меня было какое-либо желание его использовать), но я не уверен что будет делать несколько скриптов на узел. О, так вместо сценария C#, расширяющегося от сценария GDScript, он сможет его вызывать? Какой сценарий будет основным? Как код C# изменит то, что делает скрипт GDScript?
• Разрешение ссылаться на скрипты по имени класса/пространству имен (TypeDB) может быть полезным. Я в порядке с res://paths , но это правда, что наследование от чего-то в надстройках приводит к очень длинным именам путей. Не серьезная проблема, но приятная - вероятно, потребуется (или предпочтительнее), хотя для межъязыкового наследования.

Я бы предложил более простой дизайн для управления активами:

• Наличие зависимостей.json (или просто сохранение данных в настройках проекта) полезно, просто чтобы я знал, какую версию актива я скачал и есть ли обновленная версия. Думаю нужная информация.
• Нет, не позволяйте активам определять зависимости. Я не думаю, что активы Godot будут иметь такую ​​большую зависимость друг от друга, как модули npm. Пусть разработчик актива указывает в документации, действительно ли он зависит от другого актива, и пусть пользователь устанавливает его вручную. Это упростит ситуацию, и нам не придется создавать еще одну вещь для проверки зависимостей, которая представляет собой раздувание кода/больше кода для поддержки.
• Нет, не сохраняйте активы в «глобальном» местоположении. Хранить их в папке надстроек проекта уже хорошо. Это позволяет им фиксироваться системой контроля версий вместе с проектом и упрощает управление ими. Даже npm node_modules сохраняет модули проекта внутри проекта.
• Теперь улучшите браузер активов, чтобы он мог перечислять, какие из установленных активов были обновлены, и позволял вам обновлять их, если хотите.
• Теперь имеет смысл иметь «глобальные» надстройки для тех надстроек, которые являются просто улучшениями редактора. Таким образом, обычные надстройки по-прежнему помещаются в папку надстроек проекта, но для надстроек, связанных с редактором, у вас есть возможность установить их глобально. Это также перемещает этот код за пределы папки надстроек проекта, чтобы он не попадал в пакет выпуска. (Это похоже на npm install -g для инструментов разработки)

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

Предполагая, что мы не обрабатываем зависимости, я чувствую, что может возникнуть проблема доступности/простоты использования для пользователей. Допустим, новый пользователь хочет попробовать подключаемый модуль или «пакет ресурсов», имеющий зависимость. Пакет отображается в библиотеке активов, загружается, затем он не работает, вероятно, из-за какого-то «внутреннего скрипта не удалось загрузить» или что-то в этом роде. Это загадочно.

• Либо каждый разработчик, осмеливающийся иметь хотя бы одну зависимость, должен будет настроить шаблонный код, чтобы показать пользователю, что ему нужно установить зависимость (даже если пакет является просто демонстрацией для этого плагина!)
• Или по крайней мере указать это в assetslib?

Также +1 за легкое обновление ресурсов, не нужно снова просматривать их в библиотеке.

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

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

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

Добавьте сверху разрывные зависимости между активами из-за обновлений (что часто встречается в движках, зависящих от сторонних ресурсов), многие версии одного и того же плагина должны храниться в библиотеке.

@eon-s Итак, что-то вроде предложения @bojidar-bg?

Я думаю, что более важный вопрос, обсуждаемый здесь, касается темы включения вещей в основной движок по сравнению с их использованием в качестве расширений или официальных расширений.

Лично мне очень нравится идея возможности настраивать движок и удалять все, что я на самом деле не использую. [Может ли кто-нибудь указать мне, как, например, удалить все 3D-материалы? И можно ли просто отключить компиляцию модулей, которые я не использую? Как?]

Дело в том, что когда кто-то предлагает новый тип узла, например. упомянутый Spring Arm или новый класс, например. лучший класс RNG, или если некоторые существующие основные узлы должны быть удалены, например. Контроллер транспортного средства... это код C++. Если они не включены в ядро, то как они будут добавлены в качестве расширений? Активы GDNative? Это было бы много dll и общих библиотек для управления/сборки.

Как человек, который создает свою собственную сборку Godot, я бы предпочел иметь возможность установить их в папку сборки Godot. Например, если бы они были модулями, я бы просто клонировал их в папку с модулями, или, может быть, был бы инструмент, который каким-то образом автоматизирует это. Вы сможете выбрать все модули, которые хотите использовать, из списка официальных модулей, официальных модулей расширения, а также из представленных пользователями. Затем загрузите (git clone) их, а затем вы можете продолжить и создать свой собственный Godot. Также можно было бы увидеть, какие из них были обновлены, обновить их и установить новые позже. (Это относится к коду C++.)

Итак, я предполагаю, что сначала нам нужна лучшая и гибкая библиотека ресурсов (установка ресурсов, зависимости, управление версиями и т. д.) и более простая интеграция/расширение плагинов (инструменты редактора, скриптовые пользовательские узлы и т. д.), прежде чем пытаться удалить функции из движка. .

Отвечаю @chanon здесь.

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

Но почему? В таком случае, почему бы просто не позволить активам иметь этот файл зависимостей, поскольку он ничему не повредит? Причина, по которой многие модули npm имеют зависимости, заключается в том, что это избавляет всех от хлопот и повторно использует код из других модулей, которые пользователь, возможно, уже установил. То же самое касается драгоценных камней Ruby, Python через pip , даже менеджеры пакетов в дистрибутивах Linux позволяют это. Я не понимаю, почему мы не должны разрешать зависимости от активов только потому, что они могут использоваться не так часто.

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

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

Я даже не согласен с идеей удаления функций только потому, что их можно сделать в GDScript. Проще говоря, это противоречит цели Godot « узлы для всех ваших нужд », если вы собираетесь заставить большое количество пользователей загрузить или внедрить инструмент/функцию/и т. д., который им нужен.

На самом деле огромное количество узлов подпадает под второе требование @reduz для включения в движок просто потому, что фраза «это сложно сделать самому» совершенно произвольна. Что для одних может быть просто, для других сложно.

Я не думаю, что наличие официального репозитория расширений идет вразрез с «узлами для всех ваших нужд». То, что они не интегрированы в загружаемый исполняемый файл, не означает, что они не предоставляются. Кроме того, идея состоит в том, что базовые потребности покрываются, а возможности для их расширения доступны для конкретных игровых потребностей.

Приятно иметь готовый контроллер персонажа FPS, но он бесполезен для всех, кто не играет в FPS. И, добавляя такие вещи, вы делаете практически каждую игру, содержащую множество функций, которые им не нужны, увеличивая конечный двоичный файл (что очень важно для мобильных и веб-целей). Должен быть способ удалить неиспользуемые вещи из конечного экспорта, и предоставление их извне по мере необходимости — это один из способов (хотя бы частично).

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

Я все же считаю, что выгоднее предоставлять официальные ноды для скачивания и обрезать ядро. При этом мы можем:

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

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

Интересное обсуждение. Так же много хороших предложений.

Прежде всего, я должен сказать, что ценю компактность финального бинарного файла и благодарен за то, что существует движок, созданный с учетом этой цели. Я рад, что центральное видение здесь — активно бороться с раздуванием. По крайней мере, я предпочитаю иметь под рукой только те инструменты, которые мне нужны для работы.

Просто хотел передать намек на некоторые из этих интересных идей.

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

Исходя из этого, я представляю, что это похоже на ядро, а затем на библиотеку модулей, основные из которых установлены по умолчанию. Возможно, многие можно было бы отключить через настройки редактора. (Я полагаю, Зиланн упоминал об исключении 3D для 2D-игры.) Помимо стандартных модулей можно было легко найти и включить другие модули.

Хотя меня интересуют трудности реализации, потому что вам придется подумать о том, что происходит, когда кто-то может захотеть удалить модуль, который активно участвует в проекте. Возможно, ему придется предупредить пользователя, чтобы он удалил его из этих сцен/скриптов, прежде чем его можно будет деактивировать... или они останутся в проекте как надгробные элементы, которые могут возродиться, когда модуль будет добавлен обратно?

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

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

Кто-то сказал «да», а кто-то «нет» этой идее сделать аддоны более похожими на самого Годо, но он может представить, что это, возможно, ситуативно. Я также мог представить, что это можно сделать, немного разделив концепцию. Предоставление обоих.

Мне также было бы интересно посмотреть, что можно сделать, чтобы инструменты редактора не включались в окончательную сборку. Я много трудился, пытаясь разделить эти вещи, потому что ошибки и поведение, предназначенное для инструментов, могут проникнуть в саму игру. Иногда разрушительно, если вы делаете что-то с изменением данных, которые будут сохранены.

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

В любом случае, продолжайте в том же духе.

Еще одна сумасшедшая идея:

Может быть, можно было бы каким-то образом автоматически преобразовать GDNative C++ в модуль (в идеале удалив уровни косвенности, созданные GDNative)? Тогда это может понравиться как сторонникам подхода «все в одном статическом исполняемом файле», так и сторонникам подхода «удалить функции без установки компилятора».

Для тех, кто против удаления узлов, если удаляемые узлы будут реализованы в GDScript как официальные плагины, не будет ли это лучше, чем то, что у нас есть сейчас? Потому что тогда новички могли бы заглянуть внутрь скрипта, чтобы увидеть, как он работает.

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

В пятницу, 22 июня 2018 г., в 23:10, Алан Норт, [email protected]
написал:

Для тех, кто против удаления узлов, если удаляемые узлы
реализованы в GDScript как официальные плагины, не лучше ли это, чем
что мы имеем на данный момент? Потому что тогда новички могли бы на самом деле достичь пика внутри
скрипт, чтобы посмотреть, как он работает.

—
Вы получаете это, потому что вы прокомментировали.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/godotengine/godot/issues/19486#issuecomment-399628884 ,
или заглушить тему
https://github.com/notifications/unsubscribe-auth/AEJES-DWkzuyItQDPbOZgsuN_lA345z7ks5t_b_NgaJpZM4UhqDC
.

@AlansCodeLog Если их абсолютно необходимо удалить и превратить во внешние расширения, было бы неплохо иметь хотя бы версию GDScript, чтобы пользователям не нужно было перекомпилировать движок (если это исходные файлы C++) или устанавливать Mono ( если он преобразован в GDNative). Тем не менее, часть моего первоначального ответа (см. раздел об официальном репозитории расширений) касалась моей обеспокоенности тем, что добавление их в расширения просто создаст этот странный вид рынка (из-за отсутствия лучшего слова), если пользователи перестанут помнить, что существует репозиторий расширений. который содержит то, что им нужно, независимо от того, насколько официальной или насколько актуальной является официальная версия. В библиотеку ресурсов будут входить новые дополнения, которые будут иметь «Узел X с функцией X», «Узел X с функцией Y» и так далее («Узел X», представляющий узел, который был преобразован в расширение) — создавая беспорядок. аддонов, которые все утверждают, что помогают с транспортными средствами, но не имеют того уровня или проверки, которые могли бы получить более официальные узлы.

@LikeLakers2

Но почему? В таком случае, почему бы просто не позволить активам иметь этот файл зависимостей, поскольку он ничему не повредит?

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

Однако я против идеи установки надстроек проекта за пределами папки проекта, поскольку это усложняет управление. Только «глобальные» надстройки редактора должны находиться вне папки проекта.

Еще немного подумав, на самом деле, если основные функции будут удалены, и люди хотят иметь доступ к этим основным функциям [которые тогда будут расширениями] во всех своих проектах, тогда имеет смысл установить эти расширения на глобальное расположение с управлением версиями для них. Но возможность скачать и установить расширение прямо в папку проекта в этом случае также должна остаться. (Опять же, это похоже на опцию npm для локальной или глобальной установки с -g)

Как сказано выше в eon-s, имеет смысл иметь лучшую систему управления активами, если нужно удалить вещи из основного движка и превратить их в активы. В противном случае это будет равносильно потере функциональности движка, поскольку пользователи не смогут легко обнаружить удаленную функциональность.

Я думал, что идеальный сценарий для

• Новые пользователи и люди, которые не компилируют движок: на странице загрузки движка у них есть возможность загрузить основной движок, а также выбрать, какие официальные или рекомендуемые расширения они хотят включить в загрузку движка. ( Обратите внимание, что это было бы невозможно, если бы расширения не могли быть сохранены в глобальной папке. Вместо этого пользователям пришлось бы находить расширения после создания проекта, что вредит возможности обнаружения. ... Однако в идеальном [невозможном] мире веб-сайт создать пользовательскую сборку C++ из выбранных расширений/компонентов на месте.)
• Люди, которые компилируют движок: Инструмент, который управляет загрузками и версиями кода расширения C++ и помещает их в правильное место в папке сборки, чтобы они включались в сборки движка.

Как человек, который компилирует движок, я хотел бы, чтобы мои расширения были модулями, а не GDNative (или более медленным GDScript). Я представляю уровень модульности, при котором я могу выбирать определенные типы узлов, чтобы включать или не включать их в свою сборку, или даже отказаться от всего 3D-материала.

Если все расширения C++ будут GDNative, то это возлагает на создателя расширений бремя создания для всех платформ, что, я думаю, может отбить у людей охоту настраивать его для простых небольших расширений, которые могут быть полезными, поскольку они будут казаться излишними для делать все, что требуется для его публикации, а также не поощряет разделение функциональности на множество небольших модулей. Мне также не нравится тот факт, что в выходной проект будет добавлено так много файлов dll/общих библиотек.

С другой стороны, для тех, кто не компилирует движок, GDNative — единственное решение для добавления расширений C++.

Итак, как предложил starry-abyss, если бы GDNative можно было автоматически адаптировать в обычный модуль, это было бы здорово.

Хорошо, поэтому я изменил свою позицию. Мне нравится идея движка без раздувания с возможностями в той же лиге, что и у лидеров отрасли.

Разделение всех дополнительных узлов даст множество преимуществ, особенно возможность выбирать, что вам нужно, а что нет.

Вот некоторые из моих предложений о том, как подойти к этому,

1. Во-первых, мы можем добавить в библиотеку ассетов возможность иметь ассеты, которые можно устанавливать по частям, в git их можно разделить тегами или ветками.
   Так что теперь, если бы мне нужны были только узлы 2D-функций, я мог бы загрузить только их, но у меня все еще есть только одно место, где можно проверить наличие обновлений.
2. Во-вторых, мы можем добавить возможность добавлять метки к обновлениям активов, например, некоторые из них могут быть основными обновлениями некоторых функций, а некоторые — нарушением обратной совместимости.
   Затем это может быть использовано Asset Manager автоматически для обновления надстроек и запроса обновлений по этому вопросу. Например, он скажет вам, что вы ожидаете основных обновлений, или ваше следующее обновление будет нарушать обратную совместимость. Вы хотите обновить или нет.
3. В-третьих, чтобы разрешить наличие нескольких версий актива, а затем, когда версия становится слишком старой, разработчик аддона / актива может пометить ее как устаревшую, что будет отражено, когда вы откроете Godot, и он попросит вас удалить старую версию или нет. .
4. И, наконец, возможность для дополнений запрашивать другие дополнения, это будет похоже на зависимость, но оно просто скажет вам, что вам нужно это дополнение для запуска этого дополнения, и если у вас его нет, установите его.
   И если когда-нибудь сам аддон заметит, что аддон больше не может быть найден, попросите добавить его повторно или просто показать сообщение об ошибке.

Используя этот метод, нам не понадобится менеджер зависимостей, но разработчики будут нести ответственность за работу. Если аддон устарел и использует устаревший актив/аддон, тогда оба разработчика могут поговорить, а разработчик может решить, что делать.
Он может просто быстро портировать свой аддон. При необходимости или в некоторых случаях другой аддон может даже удалить устаревший тег.

И, как сказал @chanon , нам нужно будет загрузить ресурсы как глобальные, которые затем можно будет импортировать в проект, как это сделала Unity.
И должен быть разрешен лучший менеджер активов, чем наша текущая реализация, с большей гибкостью в процессе установки аддона.
Я рекомендую иметь возможность добавить аддон как в GDNative, так и в модуль, что создаст некоторую нагрузку на разработчиков аддонов, но я думаю, что это единственное приемлемое решение, если здесь что-то радикально не изменится.
Но мы все еще можем добавить некоторые функции в GDNative, чтобы упростить создание дополнений. Например, возможность сборки для всех платформ одновременно была бы намного лучше.

Что касается проблем с зависимостями и ассетами из-за обновления плагинов,
почему бы и нет (и извиняюсь, если я пропустил кого-то, кто уже предлагал это)

1. пусть сервер хранит каждую загруженную версию

2. разрешить плагинам указывать конкретную версию конкретного плагина

3. попробуйте использовать разумную систему управления версиями для плагинов (похоже, Годо использует
   Нумерация версий Major.Feature.BugFix, что мне нравится)

4. И самое главное, плагины не обновляются автоматически? (Или, по крайней мере, разрешить
   пользователь может выбрать тип обновлений, с которыми он согласен, например, исправления ошибок и
   обновления функций, но не основные обновления).

@Two-Tone Тогда зачем вообще делать все это свободным от раздувания.??

Мы ведем это обсуждение, чтобы сделать движок и всю систему как можно более свободными от раздувания, чтобы не было ненужных версий.

Вы правы, позволяя пользователям решать обновляться, но исправление ошибок должно быть автоматическим по умолчанию. Потому что, если у меня будет сотня аддонов, я не буду проверять их один за другим на наличие обновлений для исправления ошибок.
Остальное может быть до пользователя, у нас может быть настройка для отключения, если это необходимо.

И магазин должен предлагать официальные пакеты для офлайн-использования (с поддержкой офлайн-магазина в редакторе).

Я бы предложил один автономный пакет из нескольких десятков МБ, содержащий самые важные демонстрации и самые важные надстройки, которые должно быть очень легко обнаружить. Ссылка на меньший шрифт на официальной странице загрузки, например, для старых версий Godot, была бы отличной.

Вероятно, да, но в мире, где настольные компьютеры, кажется, не используют что-то меньшее, чем 256 ГБ SSD + 1 ТБ HDD, и даже телефоны имеют пространство, начиная с минимум 16 ГБ, и все это, более чем вероятно, увеличится, будет ли это так? ПЛОХОЙ?

В сегменте портативных и недорогих ноутбуков eMMC жив и здоров, а размер 32 ГБ (из них менее 10 ГБ) не такая уж редкость.

Кстати, на этом классе ноутбуков я думаю, что текущая система экспорта андроида пригодна для использования, а планируемая (https://github.com/godotengine/godot/issues/18865) - нет. Я понимаю достоинства новой системы, и в целом я бы, вероятно, проголосовал за нее (когда я увидел проблему, конкурса уже не было), но мы должны понимать, что мы теряем важный вариант использования из-за изменения.

@swarnimarun Может быть недоразумение. Когда я говорю «система» в этом комментарии, я имел в виду сервер, который обслуживает плагины, а не движок. Извините, если это то, что вас сбило с толку.

Если нет, то я не понимаю, почему попытки решить проблемы людей с помощью системы зависимостей для плагинов противоречат попыткам уменьшить раздувание движка. Плагин, хранящийся на сервере на случай, если он кому-то понадобится, не способствует раздуванию или накладным расходам на обслуживание, и большинство из них настолько малы, что стоимость их хранения не должна быть такой высокой.

@Two-Tone Да, я думал, ты имеешь в виду компьютер. Но на сервере все в порядке, и это уже можно сделать, поскольку Github позволяет сохранять хэши даже после внесения изменений, поэтому в текущей системе даже после обновления репо вы должны обновить хэш на странице ресурсов.

Не только github, даже gitlab и другие тоже это позволяют. Если есть другие. Git поддерживает сохранение хешей в качестве идентификатора коммита, поэтому все делается так, как делается.

Просто мои несколько центов, почти уверен, что большая часть этого уже была сказана ранее, поэтому я сомневаюсь, что вношу что-то новое.

Я не верю в то, что нужно делать что-то в виде плагинов ради того, чтобы делать что-то в виде плагинов. Я понимаю проблему размера, но мы больше не живем в 80-х. Мы говорим о движке размером 50 МБ или 55 МБ, а не между движком 50 МБ или 500 МБ, дополнительное увеличение размера функции, которая будет перемещена в плагин, незначительно по сравнению с размером ресурсов любой серьезной игры. Если цена, которую мы платим, представляет собой более хлопотную интеграцию, она того не стоит.

Есть много мест, где плагины имеют больше смысла, и с такой архитектурой, как GDNative, мы определенно должны задать вопрос «лучше ли быть плагином», и во многих случаях я бы сказал, что ответ положительный. Что мне нравится в плагинах, так это то, что они дают вам как разработчику больше свободы во многих отношениях. Но есть и пределы.

Мой опыт виртуальной реальности ускользает от некоторых из них. Есть причина, по которой это занимает больше времени, чем я хотел бы запустить это на мобильном телефоне. Из-за требований, особенно на мобильных устройствах, настройки дисплеев различными способами, вам нужно изменить способ работы ядра, и его сложно зафиксировать в плагине.
OpenVR и OpenHMD до сих пор были самыми простыми. Oculus Я использовал обходной путь, на который смотрят свысока, но я им доволен.
ARKit должен быть в ядре, его нельзя решить как модуль, по крайней мере, не в нашей текущей структуре (Apple даже не разрешает динамические библиотеки на iOS, так что это тоже есть).
GearVR и Daydream действительно должны быть в ядре, что невозможно для GearVR из-за использования проприетарных библиотек.
Hololens/Microsoft MR Я иду по пути, чтобы посмотреть, смогу ли я сделать это выбором платформы, Microsoft видит их таким образом, потому что приложения должны работать между ними и устанавливаются на Hololens как только голографическое приложение.

Теперь AR и VR — это нишевые функции, которые будут использовать очень немногие, поэтому они должны оставаться вне ядра, если это вообще возможно, и я полностью согласен с этой точкой зрения. Но я не могу сказать то же самое о других вещах.

Я где-то видел упоминание о кузове, серьезно? Килобайт кода, который вы экономите, вкладывая его в плагин? Физика — это то, что, как мне кажется, должно быть полностью реализовано в ядре ИМХО. Я скорее увижу полный набор полностью интегрированных физических объектов внутри ядра, чем буду искать их в плагинах. Хотя подход к интерфейсу, подобный ARVRInterface, который мы написали в GDNative, вероятно, создаст прочную интеграцию, я все еще чувствую, что мы просто излишне усложняем жизнь.

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

Короче говоря, там, где плагины имеют смысл, поддерживайте плагины, но не переусердствуйте.

Узлы, которые, возможно, стоит превратить в плагины, — это узлы управления, которые создаются узлами управления (составными), оставляя только простые узлы для создания других.

Узлы со сложной логикой, такие как Vehicle, или даже простые, но полезные, такие как Position, хороши в ядре.

ИМО, ни один из них не должен быть удален из двигателя. Узлы управления, физические узлы (например, транспортное средство) и даже не существующая в настоящее время поддержка Terrain:

Я использую Godot, потому что это довольно автономное интегрированное приложение.
Если в будущем мне нужно будет скачать Godot, а потом искать Vehicle, Control nodes, Terrain support, редактор Shader, достойный плагин Navmesh и так далее и тому подобное — используя текущий плагин и систему AssetLib — нет, спасибо.

Если мы пойдем по этому пути, и инфраструктура плагинов, и AssetLib нуждаются в капитальном ремонте с точки зрения удобства использования.

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

Я не уверен, сколько из этого уже было сказано, за такими большими потоками может быть трудно следить, но в любом случае:

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

Размер экспорта не должен ухудшать удобство использования движка, ИМО. Если нам нужно сократить размер экспорта, то сделайте какую-нибудь функцию, чтобы отключить разделы движка, такие как 3D, при экспорте. Тем более, что лично я не ценю такие платформы, как мобильные и особенно веб, и мне больно видеть, как они сдерживают движок в подобных дискуссиях. (Я вижу спрос на них, не поймите меня неправильно, хоть паутина к черту)

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

Я не читал полностью все обсуждение, но хотел бы его немного подкорректировать: нас не волнует размер. Конечно, сохранение небольшого размера экспорта на некоторых платформах важно, но это не решающий фактор при реализации функций в движке. Как уже упоминалось, если некоторые функции необходимо сделать условными, чтобы разрешить небольшие размеры экспорта, это тривиально. Размер загрузки для самого движка значения не имеет.

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

• Технический долг. Весь код необходимо поддерживать. Сломанный VehicleBody, такой как тот, что у нас есть с 2014 года, не особенно полезен, так как он недостаточно хорош для реальных игр. Недавно он был улучшен с помощью Bullet, поэтому он становится лучше, но за последние 4 года это был фактически мертвый код и ненужная нагрузка на обслуживание.
• Универсальность: Godot — это движок, позволяющий создавать любые игры, а предоставляемые им функции должны позволять вам создавать любые игры. Это не означает, что он должен быть эксклюзивным (вам не нужны одновременно и 2D, и 3D в большинстве игр), но функции должны удовлетворять общие потребности большинства пользователей. Это означает, что функции, которые мы предоставляем, должны быть низкого уровня, а функции высокого уровня для конкретных игр в большинстве случаев лучше всего предоставлять извне.
• Гибкость: наличие высокоуровневых функций, поддерживаемых вне ядра, позволяет гораздо быстрее итерировать процесс их улучшения, разветвления, если это необходимо, и т. д.

Если мы пойдем по этому пути, и инфраструктура плагинов, и AssetLib нуждаются в капитальном ремонте с точки зрения удобства использования.

Ну, это смысл существования этого выпуска, не так ли? :) Все дело в том, что нам нужно пересмотреть удобство использования, чтобы обеспечить лучший рабочий процесс вместо того, чтобы объединять все крайние случаи в основной движок.

Ну... если кому-то нужны идеи для запуска внешних функций в дополнение к так называемому VehicleBody, я хочу вспомнить некоторые ноды и классы, потерянные от godot 2 до 3: ParticlesAttractor2D (узел) и EventStreamChibi (этот класс идеально подходит для внешнего актива ), я знаю, что аттрактор частиц несовместим с реальной системой частиц, но... Как насчет восстановления утраченной функциональности godot в виде внешнего актива (Ej, старая система частиц, сосуществующая с новой....). Может быть, кто-то захочет сохранить этот код в отдельных репозиториях...

Новые системы @Ranoller всегда удаляют старые вещи, это неизбежно.
Предполагается, что частицы ЦП возвращаются с GLES2 (потому что не поддерживает частицы ЦП), но иметь аттракторы на ЦП, а не на ГП, будет нехорошо.
EventStreamChibi был модулем, я думаю, что новая аудиосистема может обеспечить лучшую поддержку файлов трекера, если станет более гибкой.

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

Если вы думаете, что проще заставить людей работать над отдельными файлами кода, то это неправильно, большинство просто не будет знать об этих файлах, поскольку они никогда не получат такой же информации, менеджер активов нуждается в работе, да, но наличие функций в виде плагинов не работает. .
Я видел, как несколько человек перешли с Unity на Godot, потому что он так хорошо интегрирован и не предлагает основных функций в виде плагинов.
И Unity поняла, что начала работать над тем, чтобы сделать вещи более интегрированными, и добавила разработчиков дополнений в команду разработчиков Unity.

Если нам нужно загрузить 30-мегабайтный движок, а затем тратить время на загрузку отдельных функций в виде плагинов, которые я мог забыть добавить в свой проект, то я мог бы вообще не использовать их. Что является проблемой для новичка.

Что касается технического долга, то это проблема, с которой рано или поздно сталкивается каждый проект (FOSS или коммерческий). Правда в том, что некоторые разработчики со временем уходят, и область перестает привлекать к себе внимание (поэтому ее приходится переводить в режим «обслуживания», пока кто-то не заинтересуется). Как я уже упоминал, это происходит даже с крупными коммерческими приложениями. так что с Годо это неизбежно произойдет, сколько бы дифферентов двигателю не досталось.

Лучшее решение в этой области — просто поддерживать сцену разработки, которая побуждает людей начать вносить свой вклад в исходный код (и сцена Годо отлично справлялась со всем развитием добровольцев, но ее нужно поддерживать через такие вещи, как убедиться, что участник исправления не ждет слишком долго, чтобы увидеть обзор). Однако следует по возможности избегать удаления функций из-за ухода разработчика (поскольку постоянно меняющийся список функций был бы отличным способом убедить людей _не использовать_ Godot вообще). Скорее, удаление функции должно происходить главным образом потому, что она заменяется чем-то лучшим.

Однако следует по возможности избегать удаления функций из-за ухода разработчика (потому что постоянно меняющийся список функций был бы отличным способом убедить людей вообще не использовать Godot). Скорее, удаление функции должно происходить главным образом потому, что она заменяется чем-то лучшим.

Опять же, обсуждение идет в неправильном направлении, поэтому я попытаюсь направить его в нужное русло. Тема не столько об удалении вещей, сколько о предотвращении добавления новых вещей, которые мы можем в конечном итоге захотеть удалить. Потому что добавлять вещи очень просто, но потом мы не можем удалить их, не нарушив совместимость.

По мере роста Godot все больше и больше новых участников приходят с дополнениями, которые могут не соответствовать архитектуре или дизайну, которым мы хотим, чтобы движок следовал. Просмотр всех этих изменений занимает много времени, и тем более решение, соответствуют ли они тому, что мы хотим. Объединение таких новых функций новыми участниками приведет к коду, который сопровождающие движка плохо знают или могут не полностью одобрить в конечном итоге, а первоначальные участники часто могут не задерживаться, чтобы реорганизовать его и убедиться, что он соответствует тому, что мы хотим (см. например, узел Tween, который является отличной функцией, но с некачественным дизайном, а оригинального автора больше нет, поэтому мы должны переосмыслить и переписать его, нарушив совместимость по пути).

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

Мы не пытаемся сократить кодовую базу Godot, мы думаем о том, как защитить себя от взрыва и выхода из-под контроля. (Потому что одноразовые участники с большим PR встречаются гораздо чаще, чем сопровождающие движка с глубоким пониманием всей кодовой базы и нашим видением будущего движка).

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

Я должен спросить, что сделает их превращение в активы в библиотеке активов, кроме как отодвинет проблему на шаг назад? Вы переходите от кода, связанного с Godot, который больше не поддерживается, к коду в активе Godot, который больше не поддерживается. В любом случае, первоначальный участник, вероятно, прекратит поддерживать его в какой-то момент, и в конечном итоге он снова сломается.

@ LikeLakers2 Ну, цель этого состоит в том, чтобы создать гладкий путь для добавления новых вкладов в движок (поскольку большинство из них, в большей степени связанных с активами, пока отклонены). Если какой-то аспект движка не поддерживается, то его не следует связывать с движком в первую очередь, поскольку в этот момент он просто раздулся. Вещи такого рода особенно подходят в качестве подключаемых/обновляемых плагинов извне.

Если в будущем мне нужно будет скачать Godot, а потом искать Vehicle, Control nodes, Terrain support, редактор Shader, достойный плагин Navmesh и так далее и тому подобное — используя текущий плагин и систему AssetLib — нет, спасибо.

Точно. AssetLib/надстройки в целом сейчас плохо работают для этого, поэтому разговор склоняется к ним. Я не думаю, что кто-то хочет убрать что-то прямо сейчас, но, как уже упоминалось, суть в том, чтобы не добавлять слишком много нового.

Я должен спросить, что сделает их превращение в активы в библиотеке активов, кроме как отодвинет проблему на шаг назад? Вы переходите от кода, связанного с Godot, который больше не поддерживается, к коду в активе Godot, который больше не поддерживается. В любом случае, первоначальный участник, вероятно, прекратит поддерживать его в какой-то момент, и в конечном итоге он снова сломается.

Ну, я предполагаю, что было бы проще, если бы ими можно было управлять отдельно от двигателя. Блендер делает что-то вроде этого. У них есть «официальные» (не совсем официальные, просто предварительно включенные) надстройки, но их код хранится в отдельном подмодуле git, и когда они перестают поддерживаться людьми, которые их отправили (я думаю, вам нужно повторно отправить с каждым большим выпуском), они удаляются. Хотя мне, честно говоря, не очень нравится такой подход, я бы хотел, чтобы у них был встроенный браузер активов для 90% вещей, а все остальное (например, экспортеры) просто интегрировалось.

Я думаю, что идея состоит в том, что в движок должны быть включены только основные строительные блоки, затем такие вещи, как узел транспортного средства, могут быть официальными надстройками, тогда все остальное, что является большим и может быть реализовано по-разному, должно быть просто обычными надстройками. , правильно?

Чего я не понимаю, так это того, как будут реализованы официальные надстройки. Я думал, что в настоящее время мы не можем писать пользовательские узлы, которые выглядят так, как будто они встроены, верно, у них должен быть скрипт? Или это возможно с модулем С++ или чем-то еще (здесь я новичок С++).

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

Поздно на вечеринку, но, учитывая масштаб моего текущего проекта, я обнаружил, что разрабатываю _множество_ плагинов для Godot 3 и вижу, что буду разрабатывать еще много, прежде чем проект будет завершен. С каждым плагином я стараюсь разработать как можно больше, независимо от игры, и открыть их исходный код под лицензией MIT для использования другими. Я не собираюсь лгать. Нынешняя система аддонов действительно не так уж плоха по большому счету... ОДНАКО есть пара недостающих частей, которые во многих случаях делают ее практически бесполезной. Однако прежде чем я перейду к ним, я хочу сказать пару слов об идеях @karroffel .

Во-первых, спасибо за решение этой проблемы вместе. Я думаю, что это обсуждение важно, особенно в ближайшем будущем. Тем не менее, я действительно думаю, что каждый из пунктов обсуждения, которые вы представили в OP, в основном ортогонален только с тангенциальным перекрытием. Я думаю, что мы можем очень много итерировать решение здесь, не решая все проблемы за один раз.

Это приводит меня к моим _личным_ сомнениям по поводу текущей системы дополнений и тому, что я думаю, было бы двумя очень хорошими отправными точками в лучший мир от кого-то, кто действительно разрабатывает плагины на регулярной основе:

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

Это уже активно обсуждалось, но большинство предложений довольно неуклюжи и не совсем совместимы с текущей системой. Я еще не ознакомился с кодовой базой модуля assetslib, но думаю, что в этом отделе _должна_ быть легкая победа. В настоящее время репозитории надстроек третьей части на Github имеют следующую структуру папок:

addons/
    addon_name/
        plugin.cfg
        ...other files

Я предлагаю расширить схему plugin.cfg и добавить возможность просто иметь список версий зависимостей с хэшем фиксации опции (или именем ветки/тега) для использования. Что-то вроде следующего будет работать:

[plugin]
name="foo"
description="foobar"
author="blah"
version="1.0.0"
script="plugin.gd"

[dependency]
name="dep1"
path="github.com/foo/dep1"
hash="7fc2367508c41cfab86eaf7d84e04cd122978fdb"

[dependency]
name="dep2"
path="github.com/foo/dep2"
tag="v3.1.2"

[dependency]
name="dep3"
path="github.com/foo/dep3"
branch="big-refactor"

Затем, когда библиотека активов переходит к установке актива, она сначала загружает проект в каталог дополнений, как это происходит в настоящее время, а затем загружает каждую зависимость (используя правильный хэш или заданную ветку) и также помещает его в каталог дополнений. . В качестве первого шага конфликты зависимостей можно либо игнорировать, либо позволить пользователю выбирать, какие из них использовать. Это не _идеальное_ решение, но я думаю, что оно сработает в большинстве случаев и, по крайней мере, задержит нас до тех пор, пока не будет выполнен более сложный пересмотр библиотеки активов. (если кто-то не может придумать простой способ справиться с конфликтами зависимостей).

В качестве примера из реального мира,
У меня есть актив для деревьев поведения godot. Частью этой системы является узел Blackboard, похожий на UE4, для хранения произвольных глобальных или локальных данных узла, которые должны совместно использоваться узлами. Это используется в системе BT для обмена состоянием между узлами поведения. Это все прекрасно и денди, но в настоящее время я разрабатываю диалоговую систему и сопутствующие инструменты, и часть этой системы требует какой-то базы данных переменных для использования в качестве условий. Я бы очень хотел повторно использовать компонент доски из системы BT для диалоговой системы. На самом деле, компонент Blackboard настолько универсален, насколько это возможно, а глобальные данные — довольно распространенная идиома в разработке игр, поэтому даже сам по себе это может быть довольно полезным дополнением, поскольку в любом случае он повторно реализуется практически в каждом проекте. .

С надлежащей системой зависимостей я мог бы разбить компонент Blackboard на отдельный аддон, а затем повторно использовать этот компонент во всех аддонах BT, аддонах диалоговой системы и любых других игровых приложениях, которые у меня есть. Кажется, что я имею в виду?

Необходимость в многоскриптовых узлах

Это уже другая горячая тема в этом выпуске, и, честно говоря, у меня нет хорошего способа подойти к этому без изменения фундаментальной идеологии того, как Годо предназначен для использования. Это может быть хорошо, а может и нет, но да... В любом случае, это не столько проблема для плагина _authors_, сколько для плагина _users_ (хотя часто это один и тот же человек ;).

В конце концов, если мы сможем решить эти две проблемы, я думаю, мы добьемся успеха на 90%. Остальные 10%, на мой взгляд, не так уж важны, и, вероятно, к ним следует подходить с точки зрения пересмотра фундаментальной архитектуры активов, которые, на мой взгляд, могут подождать после того, как поджарят гораздо более крупную рыбу.

Если нет возражений, возможно, я попытаюсь реализовать свое предложение по управлению зависимостями в коде assetslib в ближайшие дни.

управление зависимостями звучит круто для меня. :смайлик:

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

если кто-то не может придумать простой способ справиться с конфликтами зависимостей навскидку

Я думаю, что решение для этого будет зависеть от того, как плагин вызывает код из
другой плагин. Если мы настроим его так, чтобы скрипты плагина выполняли
extends "dep2/folder/script.gd" , при установке мы можем просто изменить dep2
до dep2-v3.1.2 . Для хэшей мы могли бы просто использовать первые 5 цифр (если только
нам нужны папки с именами длиной не менее 42 символов). В 5
цифр вероятность столкновения невероятно мала.

Я немного устал сейчас, поэтому, возможно, я что-то упускаю, но я не вижу
любые вопросы.

@jonbonazza , если вы это сделаете, постарайтесь не жестко кодировать использование Git в нем. Хотя здесь это звучит как само собой разумеющееся, некоторые люди могут предпочесть другие системы VCS (или вообще не использовать VCS), поэтому, возможно, это должна быть деталь, которую нужно обрабатывать на стороне библиотеки ресурсов.
Кроме того, мне интересно, рассматриваем ли мы возможность сделать что-то, чтобы упростить использование плагинов в качестве подрепозиториев VCS в проекте? В какой-то момент это упоминалось, но я не помню, было ли соглашение.

Да, я думаю, достаточно только id ассета и версии.

Указание репозитория/ветви/тега/хэша Git может быть необязательным способом указать зависимость, но основным способом должен быть идентификатор актива.

Я не уверен, есть ли в библиотеке активов уникальные удобочитаемые идентификаторы (слаги). Если не должен. Например, у модулей npm есть имя/идентификатор текстового модуля, которые вы используете при их установке.

Тогда спецификация зависимости может выглядеть так:

[dependency]
asset_id="some_asset"
version="1.0.0"

@Two-Tone Я пытался не слишком сходить с ума по этому поводу. Просто хотел что-то простое, чтобы задержать нас, пока не будет выбран лучший подход.

@Zylann Я бы, вероятно, использовал тот же подход, который в настоящее время используется в библиотеке активов, - загрузив и распаковав zip-файл из github.

@chanon , библиотека активов работает с github напрямую, поэтому единственная идентификация, которую мы имеем для версий, — это хэш коммита, ветка и тег.

Какая часть слишком сумасшедшая? Наличие обязательных версий зависимостей или мое решение
для конфликтов зависимостей? Один из них является стандартным в большинстве мест, где есть
управление зависимостями, а другое - простое редактирование текста и папки
названный. Я не думаю, что любая из этих вещей сумасшедшая.

Во вторник, 3 июля 2018 г., 11:23 Jon [email protected] написал:

@Two-Tone https://github.com/Two-Tone Я пытался не сойти с ума
с этим. Просто хотел что-то простое, чтобы задержать нас до лучших времен.
подход определяется.

@Zylann https://github.com/Zylann Я бы, наверное, использовал тот же подход
который в настоящее время используется в библиотеке активов — загрузка и распаковка zip
файл с гитхаба.

@chanon https://github.com/chanon библиотека активов работает с github
напрямую, поэтому единственной идентификацией, которая у нас есть для версий, является хэш коммита,
ветвь и тег.

—
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/godotengine/godot/issues/19486#issuecomment-402214905 ,
или заглушить тему
https://github.com/notifications/unsubscribe-auth/AEJES-_IJBjvj3ImvZnqdu-cIAunCp2gks5uC5qIgaJpZM4UhqDC
.

@ Two-Tone Извините, но «слишком сумасшедший» я имел в виду «слишком сложный», так как это должно было быть быстрым решением, чтобы задержать нас. Я согласен с тем, что в долгосрочной перспективе необходимо надлежащее разрешение конфликтов, но я надеялся, что мы сможем просто обойтись без него в промежутке времени.

Другой вариант — просто отказаться от assetslib и просто git клонировать deps непосредственно в проект, хотя, поскольку текущая де-факто структура проекта плагина находится в каталоге addons , на самом деле это не сработает. Нам нужно, чтобы корень проекта был на один уровень глубже (т. е. за исключением каталога дополнений и укоренялся в имени плагина). Я искренне думаю, что это было бы долгожданным изменением, так как тогда вы могли бы использовать подмодули git для зависимостей.

@jonbonazza Понятно . Ваше решение может быть реализовано и работать сразу же без необходимости изменения библиотеки ресурсов. Тогда я согласен, что это хороший первый шаг. (Не то чтобы я являлся основным сопровождающим, имеющим какие-либо полномочия... просто я думаю, что это хороший первый шаг.)

Я думаю, что если в базу данных библиотеки активов добавлен текстовый идентификатор (slug) плюс информация о версии, то это можно добавить, как в моем примере выше.

вы можете использовать подмодули git для зависимостей.

@jonbonazza , и вот здесь снова возникает мой последний вопрос, поскольку кажется невозможным использовать подмодули с репродукцией плагина, потому что это репо должно включать полную иерархию файлов, чтобы быть подходящим для загрузки, заставляя .git папки должны находиться в одном месте... но даже если бы это было так, помните, что это заставит людей предоставлять все свои данные через Git.

@chanon точно. Это просто потребует небольшого количества дополнительного кода в паре файлов. Честно говоря, вероятно, можно было бы разработать аддон, который мог бы сделать это для вас, вместо того, чтобы встраивать его в ассетлиб.

@Zylann , да, это то, о чем я говорил в своем комментарии о подмодулях. В настоящее время это невозможно из-за текущих ограничений на структуру проекта, но изменить библиотеку активов на более гибкую в этом отношении было бы тривиально.

РЕДАКТИРОВАТЬ: Это также можно сделать с обратной совместимостью.

На самом деле я сделал предложение относительно структуры проекта некоторое время назад. На самом деле это моя главная жалоба на то, как сейчас работают плагины. Нет хорошего способа их упаковать. См. № 18131. Это действительно нужно изменить в первую очередь, imo, прежде чем что-либо, и чем раньше, тем лучше, чтобы у нас было меньше людей, которым приходится переводить свои плагины.

Что в этом сложного? Одним из них является требование, которое может быть обеспечено с помощью
простая проверка, а другой - простое совпадение и замена или
добавить / добавить. Это проще, чем добавление поддержки зависимостей.

Во вторник, 3 июля 2018 г., 12:11 Джон Бонацца уведомления[email protected] написал:

@Two-Tone https://github.com/Two-Tone извините, но я имел в виду "слишком сумасшедший"
«слишком сложно», так как это просто должно быть быстрым решением, чтобы задержать нас.
Я согласен с тем, что в долгосрочной перспективе необходимо надлежащее разрешение конфликтов, но
Я надеялся, что мы сможем обойтись без него тем временем.

—
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/godotengine/godot/issues/19486#issuecomment-402229111 ,
или заглушить тему
https://github.com/notifications/unsubscribe-auth/AEJES7c8ziwhXZirsTsLY0zWfI-jrBzmks5uC6XUgaJpZM4UhqDC
.

@Two-Tone, вы не можете просто переименовывать папки, потому что скрипты в коде плагина часто напрямую используют путь к аддону. Например

extends "res://addons/foo/bar.gd"

@jonbonazza Я бы добавил, что это делают не только сценарии, но и любой ресурс, ссылающийся на другой.

Затем сделайте структуру папок надстроек такой, как я сказал, но обязательной, затем в
во время установки просто используйте функции поиска и замены, которые класс String
есть на каждом скрипте искать

'расширяет " res://имя_аддона/ '

И замените его на

'расширяет " res://addonname-номер_версии/ '

Это не сложные проблемы в коде. Они действительно просты благодаря С++.
В основном это просто проблемы пользователей, чтобы гарантировать их устранение.
мы должны обязать некоторые вещи. Если они загружают подключаемый модуль и пользователи обнаруживают, что
это полностью сломано, потому что разработчик не следовал этим невероятно
простые правила, то что есть на плагине разработчика.

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

В среду, 4 июля 2018 г., 12:48 Марк уведомления[email protected] написал:

@jonbonazza https://github.com/jonbonazza Я бы добавил, это не просто
скрипты, которые делают это, но любой ресурс, ссылающийся на другой.

—
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/godotengine/godot/issues/19486#issuecomment-402533781 ,
или заглушить тему
https://github.com/notifications/unsubscribe-auth/AEJESwoMKvVVXclllrQ4YQQO852oZ1v7rks5uDP_SgaJpZM4UhqDC
.

Я предполагаю, что если плагин нарушает совместимость после обновления, они должны либо предоставить запасные варианты устаревания, либо сделать, как говорит @Two-Tone, намеренно разбив путь, либо переименовав плагин, либо его подпапку (хотя это был бы наихудший сценарий, потому что не приятная ситуация). Так делает сам двигатель, так делают и другие. Написание плагина связано с совершенно другим мышлением, которое зависит от других людей/плагинов, которых вы не знаете.

Это решает не проблему зависимости, а решение конфликтов зависимости. Один плагин может зависеть от версии 1 другого дополнения, а другой может зависеть от версии 2, без этого или чего-то подобного у нас либо были бы конфликты, либо нам пришлось бы запретить пользователю использовать плагины, которые имеют противоречивые зависимости.

И решение, позволяющее предотвратить нарушение совместимости обновлений, заключается в обеспечении того, чтобы каждое обновление имело уникальный номер версии. Это, однако, может начать попадать в категорию «слишком сложно», так как вам придется анализировать plugin.cfg , а затем запрашивать сервер ресурсов, существует ли уже плагин с таким именем и номером версии. Если есть, скиньте ошибку. Если нет, то все должно быть хорошо.

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

Единственное решение, о котором я могу думать, это расширение gdscript, чтобы пользователь мог указать в сценарии, какую версию плагина они используют, а затем с этого момента они просто делают extends "res://addonname/etc и обрабатывают сам движок, используя правильный путь. Однако это определенно относится к «слишком сложной» проблеме, о которой упоминал @jonbonazza . Но на короткий срок его можно пропустить.

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

Я абсолютно понимаю, почему @reduz считает, что управление зависимостями не важно. Есть так много переменных, которые _ нужно _ рассмотреть и решить, чтобы это стоило включения в Godot, иначе мы получим систему, которая не лучше, чем та, которую используют другие движки.

Честно говоря, я думаю, что лучший способ действий для краткосрочного решения — это изменить библиотеку активов для поддержки (хотя и не _require_ из-за обратной совместимости) возможности обслуживать проекты, которые находятся на одном уровне под директорией addons . Например

godot-tools.level-streamer/
    project.cfg

Вместо

addons/
    godot-tools.level-streamer/
        project.cfg

Таким образом, мы можем просто указать в описании аддона, что он требует какого-то другого аддона.

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

Как насчет того, чтобы сделать это для депов (например, dep/ ), а затем вручную установить плагины в корневом каталоге или в папке, определенной пользователем? Таким образом, зависимости не загромождают корень, и аддоны могут быть в любом или?

$UserSetLocation/
    godot-tools.level-streamer/
        project.cfg

deps/
    thing-level-streamer-uses/
        project.cfg

@ Two-Tone Но что тогда, если у вашей зависимости есть зависимость? Разве папка deps не должна быть подпапкой самого плагина, чтобы вы могли углубляться по мере необходимости?

Я чувствую, что вся эта проблема зависимости слишком много обдумывается. Может, стоит придумать несколько простых систем и обсудить каждую или проголосовать? Я не предвижу, что этот разговор закончится так, как он движется сейчас.

Что, как говорится...

@willnationsdev Это может сработать, но если многие плагины полагаются на одну и ту же зависимость, то у вас будет несколько копий этой зависимости, где может потребоваться только ... две.

Да, управление зависимостями — непростая вещь. В противном случае npm не должен был бы быть таким сложным, как он есть, и yarn не нужно было бы создавать.

Я не думаю, что размещение зависимостей в качестве подпапки активов — хорошая идея, поскольку это ведет к очень сложному пути. Будет случай, когда 2 или более активов имеют одинаковую зависимость, и потребуется какая-то дедупликация. Кроме того, я думаю, что разработчику игры лучше точно видеть, какие зависимости есть в проекте, а не просматривать подпапки подпапок, чтобы выяснить, какие зависимости используются и/или дублируются n раз, поскольку это общая зависимость.

Например, в веб-разработке node.js можно игнорировать то, что находится внутри node_modules, пока оно работает, поскольку оно будет развернуто только на сервере. Для игры вы будете упаковывать весь этот код/активы в окончательный пакет приложения, и дублирование одной и той же зависимости n раз — это довольно плохо.

Именно из-за этих проблем в моих первоначальных предложениях говорилось, что пока ресурсы не определяют зависимости, а просто есть способ перечислить зависимости проекта и позволить пользователю вручную устанавливать любые зависимости активов:
https://github.com/godotengine/godot/issues/19486#issuecomment -399559419

Если у нас есть активы, определяющие зависимости, то я думаю, что все они должны быть установлены на одном уровне (в папке res://addons ). Для конфликтов версий зависимостей (два ресурса зависят от одного и того же ресурса, но разных его версий) я думаю, что лучше всего будет простое решение, например, всегда использовать более новую версию.

С другой стороны, если мы действительно хотим реализовать управление зависимостями с дедупликацией и разрешением конфликтов версий, разрешив установку нескольких версий одного и того же актива, то это тоже нормально! Если он действительно надежно сделан, то сможет поддерживать расширение экосистемы активов в долгосрочной перспективе. Почему-то мне не нравится идея иметь несколько версий одного и того же актива в моем игровом проекте. И потребовалось npm так много версий, пока они не сделали это правильно (хотя я все еще предпочитаю yarn ), поэтому я не думаю, что эту задачу следует недооценивать.

Я не думаю, что размещение зависимостей в качестве подпапки активов — хорошая идея, поскольку это ведет к очень сложному пути.
Если у нас есть активы, определяющие зависимости, то я думаю, что все они должны быть установлены на одном уровне (в папке res://addons ).

Я согласен с этим. Я также предпочел бы, чтобы надстройки существовали в проекте один раз в стандартном месте, а не столько раз, сколько версий требуется для различных других источников и в разных папках. Зависимости - это вещь, но мы также можем найти золотую середину вместо того, чтобы максимально детализировать, чтобы все было относительно просто.

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

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

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

@LikeLakers2 Надлежащее управление зависимостями и предотвращение конфликтов — важный и сложный вопрос. Это так много обсуждается из-за этого

Я не предвижу, что этот разговор закончится так, как он движется сейчас.

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

Для конфликтов версий зависимостей (два актива зависят от одного и того же актива, но разных его версий) я думаю, что лучше всего будет простое решение.

@chanon Мои идеи просты . Что сложного в том, чтобы назвать папку и изменить соответствующие пути к файлам в текстовых документах? Это единовременная плата для пользователя, она дает понять, какая версия того, что вы установили, и ее довольно легко написать.

например, всегда иду на более новую версию

Это приведет к тому, что подключаемые модули будут ломаться без предупреждения, поскольку их зависимости обновляются и изменяют их работу. EG Plugin 1 и 2 зависят от Dep 1, но разных версий. Плагин 2 зависит от текущей, последней версии, но плагин 1 зависит от более старой версии, которая ведет себя иначе, чем последняя версия. Плагин 1 больше не работает должным образом или содержит ошибки, с которыми он не поставлялся.

Нам, вероятно, также не нужно разрешать конфликты зависимостей, по крайней мере, инструмент установки может информировать пользователя, если он может их обнаружить.

@Zylann Тогда у нас возникает проблема, когда пользователь не может установить плагин x, потому что y использует другую версию той же зависимости. Это не будет восприниматься пользователями как нечто хорошее.

Я согласен с @willnationsdev и @LikeLakers2

Я чувствую, что вся эта проблема зависимости слишком много обдумывается. Может, стоит придумать несколько простых систем и обсудить каждую или проголосовать? Я не предвижу, что этот разговор закончится так, как он движется сейчас.

Слишком много сбрасывания велосипедов. Это игровой движок, а не игровой движок-доставка-платформа. Просто укажите зависимости от поставщика в каждом из каталогов дополнений и на этом закончите. Никакого стресса по поводу конфликта версий или управления или w/e за счет некоторой неэффективности. Если пользователя аддона беспокоит производительность, он должен быть в состоянии рассмотреть НАСТОЯЩИЕ оптимизации производительности, такие как GDNative или модули. Я также не могу себе представить, почему любой аддон должен иметь глубокий граф зависимостей. Единственная причина, по которой я вижу, что аддон имеет зависимость от другого, заключается в том, что он каким-то образом расширяет его: SweetFpsController -> SweetFpsController w/ flying . В этом случае я бы сказал, что два проекта или их пользователи должны согласовать свою связь, а не возлагать ответственность на движок.

@Two-Tone, если плагину A нужна версия 1 X, а плагину B нужна версия 2 X, я бы сказал, что Godot не должен пытаться исправить это волшебным образом. Вот простые решения для этого:

• Обычно версия 2 X должна быть обратно совместима с версией 1, и так должно быть, чтобы все было просто (помните, когда я упоминал образ мышления при разработке плагинов).
• Если вы не можете использовать последнюю версию X, подождите, пока плагин A поддержит ее, и загрузите предыдущую версию (нам нужен API-интерфейс assetslib для обработки получения разных версий, а не только самой последней, это не должно быть сложно сделать). Это как моды, они не должны быть идеальными.
• Создатель плагина X загружает его как другой плагин (поскольку API нарушает совместимость), точно так же, как мы должны были это сделать, когда вышел Godot 3. Таким образом, у вас будет дважды один и тот же плагин, но это нормально, потому что в любом случае они слишком разные, чтобы быть действительно одними и теми же, и вещи, зависящие от него, тоже будут работать. Это может быть даже просто переименование папки разработчиком плагина, даже не обязательно иметь две записи в библиотеке ресурсов.

В худшем случае вам придется заставить это работать вручную (и в конечном итоге PR-совместимость с производителем плагинов).

Если бы не они, это потребовало бы установки двух версий с разными путями каждый раз (свернуть все ссылки при каждом обновлении) или внесения основных изменений в движок, чтобы изменить работу путей (сложно).
Я думаю, что если бы мы могли просто получить простое управление зависимостями, это уже было бы неплохо, поскольку оно в основном использовало бы функциональность и структуру, которые уже есть у Godot (так что это было бы также довольно просто реализовать), и автоматически делало бы то, что пользователь в настоящее время имеет. все равно делать вручную.

Я не рассматриваю управление зависимостями как вещь, которая всегда должна работать и полностью ложиться на движок (например, npm), потому что это потребует много работы. Я рассматриваю это в первую очередь как удобство для вещей, которые вы в настоящее время должны делать вручную с существующей функциональностью, и производители плагинов могут выпускать свою работу на основе этой простой системы.
Если кому-то удастся красиво реализовать систему, идущую намного дальше этого, то это можно будет сделать позже, потому что то, что я описал выше, работало раньше и в основном представляет собой простые улучшения только для библиотеки ресурсов и редактора.

@Zylann Чем любой из этих вариантов лучше того, что я предложил? И нет ничего волшебного в поиске и добавлении текста к определенной строке.

Вариант 1 заставляет разработчиков стараться следить за тем, чтобы обновления их версий не нарушали работу других зависящих от него плагинов, что добавляет им много дополнительной работы. Кто хочет разрабатывать плагины для чего-то подобного?

Вариант 2 заставляет пользователей не использовать плагин, который они хотят, потому что они должны либо ждать обновления плагина, если он еще активно разрабатывается, либо просто не использовать его вообще.

Вариант 3 еще раз усложняет задачу разработчикам плагинов.

Две версии с разными путями не являются сложной проблемой. Если они когда-либо будут обновляться, проверьте, какие установочные пакеты имеют их в качестве зависимости, повторно запустите поиск и замену (с учетом старого номера версии) для всех сценариев для этих пакетов, а затем, наконец, распакуйте новую версию.

Я чувствую, что люди пытаются сделать это более сложным, чем это должно быть.

Надлежащее управление зависимостями и предотвращение конфликтов — важный и сложный вопрос. Это так много обсуждается из-за этого

@ Two-Tone Я имел в виду, что ты слишком много думаешь об этом вопросе, даже несмотря на то, что это сложный вопрос. Многие разговоры (в том числе мои ответы, по общему признанию, поэтому, пожалуйста, извините меня, так как это прозвучит лицемерно) были о том, что не так с представленными идеями, а не о том, что можно сделать, чтобы изменить их и сделать лучше. строить планы. Предлагаемые идеи могут иметь не только недостатки, не так ли? Кажется, что каждый хочет по-своему и только по-своему, что не помогает делу.

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

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

Меня немного раздражает то, как долго этот разговор продолжается без какого-либо прогресса. Серьезно.

Две версии с разными путями не являются сложной проблемой

Одного этого, наверное, нет. Но наличие двух версий одного и того же плагина в данный момент времени в Godot подразумевает другие вещи, решение которых становится запутанным.

• Ваши пути больше не являются тем, чем вы их считаете / необходимо внести изменения в ядро, что в основном беспокоит разработчиков ядра.
• Если плагин предоставляет пользовательский тип, какой из них отображает редактор?
• Если плагин написан на C#, как его скомпилировать, не конфликтуя с другими копиями?
• Если плагин регистрирует автозагрузки, как их отличить?
• Если пользователь создает данные, которые используют плагин, какой из них он будет использовать?
• Какой из них будет отображать пользовательский интерфейс в редакторе?

Я думаю, что еще до того, как мы сможем найти простые решения для тех, которые подходят для движка (а может быть и больше, о чем я не подумал), мы уже можем улучшить существующие вещи в редакторе и ассет-библиотеке, не нарушая совместимости и не внося основных изменений.

+1 за все в этой теме - расширение модуля плагина и расширение использования библиотеки активов - это путь

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

Во-первых, в Unity теперь есть «Диспетчер пакетов», с помощью которого пользователи могут выбирать, какие компоненты движка они хотели бы установить/удалить. Похоже, они также могут использовать это для Asset Store в будущем.

Нечто подобное действительно помогло бы Godot «уменьшить раздувание» при наличии «официальных дополнений». Unity по-прежнему сильно раздута даже с их менеджером пакетов, а если бы он был у Godot, он мог бы стать еще меньше. Однако, возможно, придется отказаться от метода распространения «один exe».

Кроме того, обычные «модули», возможно, должны быть созданы как общие библиотеки (файлы dll/.so), чтобы их можно было выбрать для установки/удаления в диспетчере пакетов.

Проекты и пакеты должны иметь файлы манифеста, в которых перечислены пакеты, от которых они зависят, и Godot/менеджер пакетов должен убедиться, что необходимые пакеты установлены.

Потребуется общедоступный реестр пакетов.

Это позволило бы сообществу легко расширять возможности Godot и легко опираться на работы друг друга. Я думаю, что это очень поспособствовало бы развитию сообщества.

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

С менеджером пакетов область тестирования увеличивается в геометрической прогрессии для каждого плагина и версии. Это не так уж плохо, если плагины в основном представляют собой небольшие дополнения (как в настоящее время в AssetLib), не слишком глубоко зацепляющие ядро ​​движка, но это быстро становится таковым, если вы разделяете основные части движка.

Unity уже сталкивается с проблемами, сбоями и проблемами совместимости с различными версиями их пакетов, их редакторами или с установленными (или не установленными) некоторыми определенными комбинациями пакетов или даже с порядком, в котором они были установлены.

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

Что касается ада зависимостей, почему бы не взять страницу из чего-то вроде AppImage и попытаться избежать проблем с зависимостями, возложив на распространителей плагинов ответственность за управление зависимостями активов/файлов? Вот как я вижу эту проблему...

Плагины должны (в идеале) быть автономными элементами либо логики (пользовательские редакторы, пользовательские узлы, динамически подключаемые библиотеки), либо ресурсов (моделей, материалов, шрифтов, текстур и т. д.), которые должны иметь свои собственные наборы зависимостей. Попытка выяснить общие зависимости — это головоломка, которая, хотя людям может нравиться, требует гораздо больше усилий для ее поддержки. Если бы вы действительно разрешили общие зависимости, вам пришлось бы подходить к этой проблеме так же, как к среде выполнения Steam, и поддерживать множество различных библиотек, плагинов и ресурсов как свои собственные уникальные пакеты. Вам также потребуется хранить несколько одинаковых пакетов на сервере для нескольких версий — это было бы кошмаром для обслуживания, и неудивительно, что современные дистрибутивы Linux более или менее уходят от менеджеров пакетов.

По сути, плагин может быть единым архивом tar со всеми элементами, необходимыми для того, чтобы этот плагин функционировал изолированно. Они должны работать сами по себе со всеми зависимостями, заархивированными внутри. Когда godot видит этот файл, он проверяет наличие файла манифеста в корне архивной папки. Этот манифест может содержать основную информацию (имя, описание, версию godot, значок, авторов), но также должен содержать такие вещи, как: информация об обновлении (ссылка для загрузки последней версии, поддерживаемая разработчиками плагинов), которую godot может использовать для автоматического обновления plugin (с разрешения пользователей), project_website (ссылка на репозиторий или веб-сайт, чтобы пользователи могли быстро найти источник пакета) и class_names (список классов в этом дополнении, который можно расширить, использовать для сценариев). Он также может указывать на аддоны, которые он использует как зависимости, используя относительный путь к внутреннему файлу плагина.

Если мы разрешим плагины внутри плагинов, то проблемы с зависимостями будут (более или менее) решены. Различные версии одной и той же библиотеки будут находиться в разных путях каталогов и могут рассматриваться как разные «пути» в данной вилке. Проблемы с этой системой, конечно же, в том, что вы получаете много дублирующейся информации на данном диске. Однако при упаковке игры godot в идеале мог бы пройтись по всем каталогам плагинов и объединить ссылки на файлы, соответствующие контрольной сумме (это может включать файловые структуры, представленные в tar?). Таким образом, если два файла идентичны, godot оптимизирует конечный выходной двоичный файл, объединив ссылку на один файл.

Я уверен, что это слишком наивное решение для такой сложной проблемы, но я недавно думал о системе плагинов из-за моего собственного исправления шрифта. Я думаю, что лучший пользовательский опыт — это тот, где им не нужно беспокоиться о зависимостях, а разработчики — это те, кто должен заботиться об управлении своими собственными зависимостями. Это облегчает пользователю управление: надстройки проекта могут быть представлены в виде одного файла в доке файловой системы, вы можете щелкнуть правой кнопкой мыши и получить дополнительные параметры ( extract files (для разработки), update plugin (для простых обновлений), перейдите на веб-сайт ( for easy community organization )) и также ссылайтесь на классы в данном «контейнере» ( extends "[path-to-addon-tar]://ClassName" )

Просто мои 2 цента по этому поводу, я уверен, что есть некоторые недостатки в том, как я думаю об этом, но это может быть интересным решением, а также достойным способом сократить потребность в обслуживании для Команда Годо.

Всего 2 цента на основе предыдущих 2 центов (это делает 4 милли?):
Я предполагаю, что архивы .tar будут немного незнакомы большинству пользователей (кхм, пользователям Windows), поэтому может быть лучше использовать архивы .zip , так как они имеют несколько более широкую поддержку.

При этом как насчет распространения плагинов в собственном формате Godot .pck ? У меня есть некоторые недостатки (например, нераспознаваемость большинством приложений), но это может быть шанс сделать его более стандартным и используемым.

Я предполагаю, что архивы .tar будут немного незнакомы большинству пользователей (кхм, пользователям Windows), поэтому может быть лучше использовать архивы .zip, поскольку они имеют несколько более широкую поддержку.

При этом как насчет распространения плагинов в собственном формате Godot .pck? У меня есть некоторые недостатки (например, нераспознаваемость большинством приложений), но это может быть шанс сделать его более стандартным и используемым.

Конечно, я в основном имел в виду .tar как пример общего типа упакованного архива. Он может и, вероятно, должен использовать формат godot .pck.

Почему бы не использовать ZIP, поскольку он предлагает сжатие и является стандартным форматом?

@ Калину, я согласен. Если мы пропишем, что файлы .pck должны использоваться, тогда людям придется использовать Godot Engine для упаковки вещей, а не просто использовать любой предпочитаемый ими инструмент упаковки, чтобы упаковать свой плагин для использования. GitHub также загружает репозитории в виде файлов .zip и на данный момент содержит самую большую коллекцию плагинов Godot.

Я согласен здесь. Я не думаю, что нужно создавать другой тип файла. Zip-файлы, кажется, работают очень хорошо, и у людей есть возможность установить с помощью интерфейса Godot через библиотеку ресурсов или загрузить вручную. файл .pck не позволяет сделать такой выбор.

В моем идеальном мире я хотел бы иметь две кнопки загрузки на https://godotengine.org/download :

• Одна гладкая минимальная загрузка, которая соответствует трем требованиям, и
• Одна раздутая загрузка со всеми одобренными и регулярно поддерживаемыми плагинами, которые превзошли некоторый контроль качества, поэтому я знаю, что их API работает с ядром не хуже, чем API из минимальной версии.

Еще более идеально:
Выберите и смешайте. После загрузки минимальной версии я могу выбрать минимальную версию + плагин «Темы». Это наборы общих плагинов, необходимых для обычных случаев использования. (например: 2DPixelart, 3D FirstPersonShooter, 3D ThirdPerson, RTS, RPG, 2.5D игры, 2DCutout, Rougelike, ManagementSim, Sidescroller, Eventpackage, Shaderpackage, Scriptpackage, Assetpackace и т. д.). Поэтому, когда я запускаю движки, основные плагины уже установлены и готовы к работе, и я знаю, что они работают, потому что они были одобрены.
Более продвинутые пользователи могут снять отметку с отдельных плагинов в этих коллекциях тем, если они знают, что они им не нужны, или объединить две или более тем плагинов, или добавить дополнительные отдельные плагины к темам из пула утвержденных плагинов, чтобы создать собственный пакет.

В идеале результатом будет то, что https://godotengine.org/download создаст из этих вариантов _одну ссылку для скачивания на лету_.

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

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

Более простым решением было бы попросить установить дополнительные [только официальные?] плагины при первом запуске редактора. В настоящее время у нас есть возможность открыть AssetLib, если список проектов пуст; почему бы не иметь диалоговое окно для установки официальных плагинов при первом запуске Godot?

Закрытие в пользу https://github.com/godotengine/godot-proposals/issues/142 , https://github.com/godotengine/godot-proposals/issues/577 и https://github.com/godotengine/ godot-proposals/issues/607 , так как предложения функций теперь отслеживаются в репозитории предложений Godot.

Изменить от aaronfranke: также см. https://github.com/godotengine/godot-proposals/issues/554 .