Профессионально пользуюсь Годо больше года.

Я согласен со всем, что вы сказали, кроме:

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

Если у нас будет такая прекрасная возможность, давайте просто все переименуем. Сюда входят Sprite2D и MeshInstance3D.

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

Кстати о переименовании: https://github.com/godotengine/godot/issues/16863

@ jahd2602 Лично я не возражаю в любом случае, мы можем опросить это в худшем случае.

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

@Zylann Я знаю, если мы что-то решим здесь, мы переместим это туда.

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

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

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

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

@CodeDarigan Я понимаю, что у этого есть преимущества, и я не отрицаю их, но я искренне верю, что затраты перевешивают их.

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

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

Навигация -> Nagivagion3D
Это опечатка?

@nitodico действительно

@reduz Я согласен с @ jahd2602. Даже если некоторые вещи могут быть очевидны, для единообразия мы должны добавить либо 2D, либо 3D.

Я все еще начинаю работать с Godot, и предлагаемые изменения кажутся мне разумными - использование слегка разных имен для 2D или 3D варианта узла - это то, что вызвало у меня небольшую путаницу, когда я узнал, какой конец работает, и перехожу на Thing2D. / Thing3D или Thing / Thing3D кажется значительным улучшением ясности и понятности.

Пожалуйста, сделайте это.

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

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

Я также за то, чтобы явно переименовывать вещи в 3D или 2D.

Разве нельзя было бы, чтобы оригинальные имена все еще существовали как псевдонимы для новых? Они будут скрыты от редактора, поэтому старые имена нельзя будет использовать (или они будут помещены под заголовок «не рекомендуемый»). Таким образом, старый код будет работать без изменений и без дополнительной логики для преобразования чего-либо.

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

Если есть две версии узла, я всегда добавляю суффикс 2D / 3D.

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

@ Janders1800 вот как это работает сейчас: чем меньше функций вы используете в SpatialMaterial, тем меньше шейдер он создает.

Я человек 2d, поэтому для узлов, в основном использующих 2d приложение, мне кажется, что имена узлов без суффикса, если они еще не имеют, подходят. Это кажется более болезненным рефакторингом для пользователей 3D, но это имеет большой смысл, когда определенные узлы имеют только 2d или 3D приложение, по большей части, они сохраняют более короткое имя для своего предполагаемого домена и имеют суффикс в другом месте. Было бы неплохо объединить все остальное, что можно объединить, в частности Spatial .

Я также за безоговорочное использование суффиксов 2D / 3D .

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

Что мне не очень нравится, так это то, что StandardMaterial3D является ORM. Я хочу сказать, что ORM более сильно поддерживается стандартом (по крайней мере, RM, который у вас есть в glTF).

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

Возможно, это также возможность что-то сделать с «холстом». Иногда эта концепция меня немного сбивала с толку.

Я знаю, что это сложно, потому что у него нет 3D-аналога: 3D-сцены живут в узлах Spatial , но холсты могут содержать смесь Node2D s и Control s.

Однако было бы замечательно, если бы мы могли определить какое-то именование, которое позволяло бы переименовать CanvasItemMaterial в Material2D , сохраняя его значимость для «чистых» областей 2D и GUI.

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

для будущей совместимости в gdscript

файл gdscript ...

расширяет пространственный
имя_класса Node3D

И так далее.

Вы думали о переименовании translation для пространственных узлов в position ?

@BeayemX Я думаю, что перевод - это общий термин для трехмерного пространства, а положение - обычное дело для разработчиков 2D: мышление:

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

Я поддерживаю переименование 3D-узлов, как предлагается здесь. Я не знаю, насколько это будет проблемой для создателей учебников. По крайней мере, рефакторинг существующих кодовых баз должен быть тривиальным. В C # мы могли бы даже использовать ObsoleteAttribute в режиме отладки, чтобы упростить задачу (хотя не уверен, что это хорошая идея):
[Obsolete("Use Node3D", error: true)] class Spatial { /* Nothing here */ }

Я надеюсь, что мы добавим пространства имен / категории, как описано в # 18711. Я хочу разделить C # API на пространства имен и, возможно, сборки, чтобы пользователи могли выбирать только то, что им нужно.
Мой план для 4.0 заключался в том, чтобы самому жестко закодировать таблицу пространств имен, если бы не было другого выбора, но я бы предпочел, чтобы вместо этого я мог получить эту информацию из ClassDB.

@ eon-s Я не думаю, что это так ... хотя translation технически допустимо для представления координат, Godot - первый движок, в котором я вижу, что здесь используется другой термин, иначе я всегда видел position независимо от 2D или 3D. Также для меня translation ассоциируется с движением и конфликтует с другим термином, связанным с языком / преобразованием, что делает его странным. Об этом также упоминалось в https://github.com/godotengine/godot/issues/16863 .

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

@neikeq не может дождаться 5.0? поскольку не планируется никаких новых или крупных функций, в противном случае люди перестанут создавать вещи и покупать курсы для движка, который меняет важные детали каждые 1 или 2 года (для создателей видеоуроков это означает переделывать всю свою работу) и с несколькими месяцами предупреждения ...

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

@ eon-s Безусловно, ожидание версии 5.0 означает, что будет еще больше работы, которую необходимо обновить?

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

Я ценю разницу в именах между Node и Spatial, потому что узлы Node не знают пространства, наличие Node, Node2D и Node3D было бы запутанным. Если вы не планируете избавляться от Node, это будет иметь смысл.

Я за то, что только одна область 2D или 3D должна иметь суффикс. Сейчас это 2D, и на этом путаница между 2D и 3D заканчивается.

Пожалуйста, не добавляйте суффикс 3D. Неужели стоит головная боль из-за того, что он добавляет? Стоит ли это затрат? обновления всего или устаревших руководств? Неизменяемые и устаревшие руководства по YouTube? Это принесет еще больше путаницы.

@dpalacio Я использую Godot всего несколько месяцев, но я думаю, что более ясно и кратко использовать Node3D, Node2D и Node, потому что Spatial действует как Node3D, а у Node нет информации о пространстве. Я думаю, что добавление суффикса для 3D будет намного проще для понимания, поскольку оно будет называться «наоборот». Я знаю, что это не совсем противоположности, но я не знаю, как это лучше выразить, потому что английский не мой родной язык. Мне кажется, что ставить 3d вместо 2d явно здорово. Я думаю, это будет намного проще для новичков, а тем более для людей, впервые столкнувшихся с игровым движком. Пространства имен тоже хороши, в основном для больших проектов и плагинов. Противоречивые имена - головная боль. Как новичок, я думаю, что нарушение совместимости должно быть минимальным и автоматическим, потому что сложно постоянно менять проекты между версиями. Если у нас много изменений, нам также понадобится инструмент автоматического преобразования и документация для него.

@neikeq да, категорию нужно заменить пространством имен, и мы должны сделать правильные.

В точности то, о чем я думал, когда пробовал Godot. Мой ОКР говорит мне, что так и должно быть.

Вы думали о переименовании translation для пространственных узлов в position ?

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

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

Я полностью поддерживаю изменение имен узлов, чтобы они оставались последовательными, и я согласен с другими, что последовательность важна, даже если она делает вещи, возможно, более многословными. Я бы предпочел добавить 3D или 2D в конец / начало узлов, если это сделает вещи более последовательными в базе кода и документации.

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

• MeshInstance -> MeshInstance3D (чтобы не противоречить MeshInstance2D )
• GridMap -> TileMap3D или GridMap3D
• TileMap -> TileMap2D или GridMap2D
• YSort -> YSort2D или 2DSort (или что-то другое, чтобы показать, что это для 2D)
• ProximityGroup -> ProximityGroup3D
• GIProbe -> GIProbe3D (или что-нибудь, чтобы показать, что это для 3D)
• ReflectionProbe -> ReflectionProbe3D (или что-нибудь, чтобы показать, что это для 3D)
• SpatialMaterial -> PBRMaterial или Godot3DMaterial или StandardMaterial3D (только идеи)
• Label -> TextLabel (я согласен с @MuffinManKen)

Вот мои мысли об этом предложении, начиная с положительных моментов:

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

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

Еще одно преимущество, которое я вижу в этом изменении, заключается в том, что оно устанавливает стандарт именования узлов, что может быть полезно для создателей плагинов и будущих вкладов Godot Engine. Например, если я создаю узел декали (например), то с этим изменением я знаю, что должен назвать его как-то вроде Decal3D а не просто Decal .
Это также может помочь с именованием классов, определенных в GDScript / C #.

Это также упростит написание учебников в будущем, поскольку вам больше не нужно объяснять, что Spatial - это, по сути, Node2D в 3D.

Теперь о минусах:

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

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

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

Я согласен с @ eon-s: не могут ли эти изменения немного подождать? С Godot 4.0 ситуация уже меняется довольно кардинально, по крайней мере, в кодовой базе. Я думаю, что добавление еще одного масштабного изменения только усложнит разработку и сбросит значительный прогресс, достигнутый людьми с трехмерной стороной Godot.

Когда выйдет Godot 4.0, я думаю, что работа над переименованием узлов в версии 4.1 или 5.0 будет отличной, но, на мой взгляд, добавление еще одного большого изменения, подобного этому, принесет больше вреда, чем помощи.

Одна вещь, которая может сделать этот переход лучше, - это иметь псевдоним / переходный период, например, с Godot 4.0 на Godot 4.1. Это не сделает учебные пособия и ресурсы (особенно 3D) мгновенно устаревшими и даст каждому возможность адаптироваться к предстоящим изменениям, при этом сохраняя возможность извлекать выгоду из изменений в Godot 4.0.

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

TL; DR: я полностью за изменения, я думаю, что следует просто подождать, пока Godot 4.1 или система / период перехода не будут созданы, чтобы дать всем время для адаптации к изменениям.

Независимо от того, чем закончится это предложение: я думаю, что Godot 4.0 будет отличным вариантом, и я с нетерпением жду его 🙂

@reduz, я говорю,

Я не большой поклонник того, чтобы все 3D-узлы заканчивались на «3D», но уверен, если все этого захотят. Я действительно думаю, что лучше использовать разные имена, чем всегда иметь суффикс (например, TileMap и GridMap)

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

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

(Кстати, почему существует Sprite3D, если это может быть просто четырехугольная сетка?)

@TwistedTwigleg Прочтите мой пост, проекты 3.0 откроются нормально в 4.0, если будет добавлена ​​внутренняя система совместимости ..

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

Вы можете подробнее объяснить, что означают текстуры в стиле ORM?

@reduz - единственное различие между стандартным пространственным материалом и ORM в том, что у вас есть только один канал текстуры (а не 3, как сейчас) с ORM? Будете ли вы по-прежнему иметь доступ к тем же параметрам (по металлу и шероховатости), таким как зеркальное отражение и множители? Используется не часто, но иногда используется для настройки.

Мне нравится эта идея, но мне интересно, не будет ли лишним иметь 2 типа материала для такого небольшого изменения. Может ли вместо этого быть переключатель для переключения между 1 каналом текстуры для режима ORM или 3 для существующего стиля с использованием одного материала?

Я также недавно поместил канал глубины (высоты) в альфа-канал моих карт ORM, чтобы получить больше информации о текстурах. Затем вы можете создавать большинство текстур, используя всего 3 текстуры ... альбедо / нормальный / ORM (H). Это может быть полезно добавить по умолчанию (если мы не получим 16-битную опцию для карт высот, где вы захотите использовать отдельную). Если 4.0 в конечном итоге получит тесселяцию / смещение, канал высоты будет намного важнее, чем сейчас.

И, говоря об этом, это также будет хорошей возможностью изменить название канала DEPTH на HEIGHT в 4.0 и заставить его использовать обратное тому, что он сейчас использует (т. Е. Белый - это выступающая поверхность, а черный - утопленный). Это позволит согласовать его с другими рендерерами и игровыми движками и, что более важно, с такими инструментами, как Substance, Quixel и Marmoset.

Я бы предпочел явные суффиксы для 2D и 3D узлов и без суффиксов, если это неприменимо. Я также хотел бы, чтобы узлы «Control» были полностью отделены для узлов «Node2D» (в настоящее время они оба сгруппированы в «CanvasItem»).

Что касается translation сравнению с position , я бы выбрал первое как в 2D, так и в 3D.

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

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

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

@TwistedTwigleg по поводу выпуска 3D игр, потому что мы ждем 4.0 и Vulcan 😎

Я бы также просмотрел имена узлов Control ... и встроенную документацию.

Иногда мне интересно, в чем разница между AcceptDialog и ConfirmationDialog , и то же самое с PopupPanel , PopupDialog , PopupMenu ... надеюсь, это помогает!

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

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

• Прокомментируйте, пожалуйста, только предложение о переименовании узлов и его технические последствия для сохранения совместимости, влияние на существующие проекты, учебные пособия, создателей контента и т. Д.
• Это не место для обсуждения конкретных моментов в API, которые следует учитывать при переименовании. Если мы все же решим пойти на это массовое переименование, мы рассмотрим весь API в электронной таблице, чтобы убедиться, что у нас есть согласованные имена. Для конкретных вещей, таких как методы, свойства или классы, которые должны быть переименованы сверх того, что здесь обсуждается, см. # 16863.
• @RandomShaper @fracteed @fire @reduz Переместите обсуждение стандартных материалов в отдельный выпуск.

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

Использование декоратора также может дать два других преимущества:

1. IDE может легко выбрать этот тег и отобразить его в окне выбора узла, например, вместо того, чтобы просто сказать «Пространственный», он мог бы читать «Пространственный (устаревшее использование Node3D)».

2. Затем декоратор может стать встроенным предупреждением, отображаемым в редакторе кода.

К тому же это никому не мешает создавать инструмент для переименования ...

Некоторые мысли:

Я согласен с переименованием узлов, а также с некоторыми методами и свойствами (см. Текущий список в # 16863) для улучшения согласованности и упрощения изучения и использования API. Четкое разделение 2D / 3D кажется хорошей идеей, и если это сделано, то это следует делать последовательно (например, MeshInstance3D, как уже упоминалось). Я предлагаю использовать электронную таблицу для перечисления всех текущих узлов и их новых имен в 4.0 - и мы можем рассказать там о конкретных узлах, таких как TileMap / GridMap. Я создам эту таблицу в ближайшие дни, если мы подтвердим, что именно так мы и хотим идти.

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

Как упоминалось @RandomShaper и @chucklepie , мы должны добавить устаревшие псевдонимы для всех узлов, методов, свойств, констант, сигналов и т. Д., Которые мы переименовываем, с помощью декоратора / метаданных свойств, который будет сигнализировать об их устаревании и побуждать пользователей менять их код. Использование этой информации в среде IDE должно позволить пользователям без проблем следовать руководствам по 3.x в 4.0, при этом легко узнавая новые имена по мере их появления.

Для этого нам нужны вспомогательные методы, которые позволят нам определять устаревшие псевдонимы при регистрации привязок. # 23023 - это первая попытка добавить такой интерфейс, но его все еще нужно пересмотреть, объединить и, возможно, расширить, если этого недостаточно для того, что нам понадобится в 4.0. Эти устаревшие псевдонимы можно сохранить в течение всего цикла выпуска 4.x и удалить в версии 5.0.
Я бы выступил против любого переименования, нарушающего совместимость, до тех пор, пока этот интерфейс не будет хорошо спроектирован и объединен, поэтому любой, кто заинтересован в этом, может попробовать этот PR и предложить изменения, если это необходимо.

Что касается « когда» , то я настаиваю на том, что если мы снова захотим нарушить совместимость, это произойдет сейчас. Ожидание 5.0 не имеет смысла, так как это сделает еще больше контента устаревшим, когда мы достигнем 5.0, и это не поможет изобразить Godot как стабильный инструмент разработки, если мы нарушим совместимость (надеюсь) со многими отличными играми, разрабатываемыми с помощью Godot 4. .Икс.

База пользователей Godot более или менее удваивается каждый год, поэтому каждый прошедший год делает рефакторинг менее реалистичным, поскольку в конечном итоге инерция большой базы пользователей перевешивает выгоды от нарушения совместимости. Если другие движки, такие как Unity или Unreal, кажутся относительно стабильными с точки зрения API по сравнению с Godot, это не потому, что у них нет вещей, которые они хотели бы реорганизовать или переименовывать, а потому, что они не могут себе этого позволить. Пока мы все еще можем, поэтому мы должны использовать эту возможность. То же самое было и с Godot 3.0, и сообщество вышло из этого относительно невредимым, хотя у нас есть небольшая часть пользователей, придерживающихся 2.1, поскольку они не могут позволить себе переход на 3.0. Мы надеемся, что для 4.0 объем этих изменений должен быть намного меньше, и любая работа по переносу должна быть простой, но за это время сообщество выросло в разы, поэтому влияние любого нарушения совместимости будет таким же большим или большим, чем для 3.0 дюйма с точки зрения имиджа / совокупного раздражения пользователей :)

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

Что касается переименований, это помогает сократить кривую обучения, если в материале есть шаблоны, которые нужно изучить. Например, Node2D vs Node3D и т. Д. Для всех остальных узлов. Если это похоже на утку, вы знаете, как это происходит, скорее всего, это утка или узел в данном случае.
Человеческий мозг работает как оптимизирующий квантовый компьютер, который учится, соединяя самые низкие энергетические состояния систем друг с другом, чтобы создавать логические пути между идеями. Если изучаемые идеи похожи, их самые низкие энергетические состояния ближе друг к другу, что упрощает их соединение (и запоминание), что объясняет, почему ученику легче понять 3D, если его заранее обучили 2D . Если имена узлов отражают сходство между ними, также легче изучить и понять, как следует использовать новый тип, если сведения о подобном типе присутствуют.

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

В связи с этим возьмем, к примеру, Blender 2.80. Сравните, как он выглядит и ведет себя сейчас, с тем, что было раньше. Это серьезное изменение, которое заставляет многих разработчиков заново изучать, как работает программное обеспечение. А теперь подумайте, сколько пользователей у Blender. По сравнению с Godot они гигантские, но все равно кардинально изменили свое программное обеспечение. Почему? Потому что в долгосрочной перспективе всегда выгоднее сократить кривую обучения и повысить удобство использования, даже если это означает потерю некоторых пользователей, у которых нет терпения перейти на новый рабочий процесс.

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

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

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

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

@fracteed На самом деле наличие глубины в канале другой текстуры, вероятно, не

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

@chucklepie Проблема в том, что не все языки поддерживают псевдонимы классов, такие как typedef. C # - один из них.

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

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

@neikeq Проблема в том, что не все языки поддерживают псевдонимы классов, такие как typedef. C # - один из них.

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

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

Я большой поклонник

Навигация -> Nagivagion3D

переименовать. Я поддерживаю эту просьбу!

@reduz сказал:
@TwistedTwigleg Прочтите мой пост, проекты 3.0 откроются нормально в 4.0, если будет добавлена ​​внутренняя система совместимости ..

Плохо, я пропустил эту часть сообщения.

Система внутренней совместимости помогла бы с миграцией и определенно заставит меня больше ориентироваться на «внесение изменений», особенно в сочетании с чем-то вроде # 23023. Приятно знать, что что-то запланировано для проектов до этого изменения, и это снимает многие мои опасения по поводу этого предложения.

@Norrox сказал:
@TwistedTwigleg по поводу выпуска 3D игр, потому что мы ждем 4.0 и Vulcan 😎

Это честно.
Особенно с учетом улучшений в 3D-части Godot, которые появятся в Godot 4.0, ожидание может быть неплохим делом для тяжелых 3D-проектов.

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

Что касается предлагаемых изменений в OP: узлы 2d уже имеют суффикс «2D», что _ по сути означает, что их аналоги - 3d_.

однако я поддерживаю такие изменения, как Label на TextLabel . ( @MuffinManKen отлично замечает )

Я полностью поддерживаю здесь практически все, но что касается вопроса «Sprite2D / Sprite3D», я бы предложил оставить Sprite как Sprite, если только по той или иной причине, кроме как суффикс 2D, добавляет дополнительное количество беспорядка, ИМО.

Как @girng словам, 2D / 3D дифференциация уже довольно ясно , из - за цвета-кодирования, так что мы не должны идти на большие длины , чтобы избежать путаницы. С точки зрения разработчика Godot, мне лично не понравилось бы, что -2D привязаны к каждому непереименованному узлу в моем проекте. : D

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

@reduz спасибо за ответ. Я понимаю, что это для основной версии и, таким образом, в каком-то смысле вполне нормально. Лично я бы не стал вносить подобные изменения даже в основную версию, но я знаю, что вы гораздо лучше понимаете, будет ли это проблемой или нет. Я просто смотрю историю больших изменений в основных версиях (например, с python2 на python3), и обычно я предпочитаю жить с несогласованностью (или новыми именами узлов плюс старыми, устаревшими узлами). В любом случае, я люблю Godot и буду продолжать его использовать, какие бы критические изменения ни произошли.

Но опять же, не стесняйтесь предлагать что-то более явное и всегда делать все 2D / 3D.

явное лучше, чем неявное.

@girng @AlexHoratio Узлы, имеющие другой цвет в редакторе, бесполезны при написании кода. Думаю, здесь возникает путаница.

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

@gimg , @AlexHoratio Не забывайте, что 4,5% населения также страдают дальтонизмом: stuck_out_tongue:

Думаю, переименование - хорошая идея.
Переход от 2D к 3D станет намного проще. По крайней мере, для людей, которые начинают с 2D (и, вероятно, наоборот)

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

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

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

Я действительно думаю, что это отталкивает, что CanvasLayer и CanvasItem не сгруппированы, и что Node2D находится внутри CanvasItem с Control, как указывали другие.

Я знаю, что @ akien-mga сказал, что это только для переименования узлов, но я думаю, что, по крайней мере, здесь вступают в игру дебаты о position против translation . Я думаю, что цель переименования узлов становится несколько плоской, если их API-интерфейсы значительно отличаются (за исключением различий между системами координат и т.п.), поэтому они определенно должны быть одинаковыми, какими бы они ни были. Я бы проголосовал за «позицию», как за путь здесь, был комментарий о том, что это вводит в заблуждение по сравнению с «переводом». Я бы сказал, что «перевод» вводит в заблуждение, потому что он подразумевает преобразование или движение, а не просто координаты. Положение интуитивно относительное, imo (вы не распрямляете стулья относительно направления компаса, вы делаете это относительно стен комнаты).

Я думаю, что переменные должны быть названы position для обоих, но функции translate должны остаться, изменив move_local functions в Node2D на translate_local , даже документацию называет это переводом. Я бы сохранил использование move для узлов, связанных с физикой, чтобы различать физическое движение и геометрический перенос.

Большая часть второй половины этого также относится к # 16863.

Также @reduz , я думаю, что по мере того, как C # приобретает функциональность в движке, все больше и больше людей будут нуждаться в пространствах имен для C #, и как только они будут на C #, я могу представить, что многие пользователи gdscript хотят их использовать и не переключать языки за функциональность. Я думаю, что пространства имен совершенно необходимы для возможной поддержки C #, хотя для gdscript преимущества гораздо менее драматичны, но он сделает пакеты plug and play возможными без беспокойства пользователя.

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

Это позволило бы избежать беспорядка при просмотре имен "2D" или "3D" по умолчанию в Иерархии, если пользователь решит включить его, но все же сделало бы код более последовательным и явным. Без узлов 3D, содержащих «3D», это могло бы сбивать с толку, но было бы разумно с «3D» в конце по умолчанию.

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

@aaronfranke Я бы не хотел быть тем, кто портит разумную идею, но разные имена узлов в разных системах сделают невозможным совместное использование файлов сценариев gd. Поскольку все плагины экспортируются как необработанные файлы и сцены gscript, они перестали бы работать, если бы были разработаны в системе с другими сопоставлениями узлов. Чтобы этого избежать, все файлы gdscript и файлы сцен должны включать сопоставления имен узлов для перевода файла для новой системы. Я почти уверен, что такие накладные расходы - большой отказ для @reduz.

@aspenforest Я не думаю, что добавление сопоставления было бы большими накладными расходами, но, возможно, я наивен, поскольку не знаю архитектуры движка

Из идеи MeshInstance автоматически будет называться mesh_instance вместо MeshInstance ), для суффиксов узлов можно добавить еще один параметр, который удалит суффикс «2D» или «3D» из имен узлов (так что новый узел Sprite2D получает имя только Sprite ).

Никто никогда не жаловался на KinematicBody2D или Particles2D и тому подобное с ненужным суффиксом «2D», поэтому я не понимаю, почему мы должны добавлять функции для обхода добавления суффикса «3D». на своих аналогах ... Если пользователи действительно не хотят, чтобы эти суффиксы присутствовали в первую очередь, то это предложение, возможно, следует отбросить, а не работать над способом переименования узлов в IDE по какой-то косметической причине ...

@ akien-mga это не столько «работа над» новыми именами узлов, для меня это скорее соус на вершине, что-то, что не является хакерским только с последовательной схемой именования. Мне ДЕЙСТВИТЕЛЬНО нужны суффиксы, когда я кодирую, добавляю узлы или ищу документацию. Но как только они попадают в сцену, я знаю, что они из себя представляют, и многие вещи в любом случае получат собственные имена.

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

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

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

+1 за явные 2D / 3D имена.

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

@SaracenOne Это

Есть еще одна проблема для более общего обсуждения изменений имени https://github.com/godotengine/godot/issues/16863

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

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

Теоретически такая система могла:

1. Убедитесь, что мы создаем согласованные API-интерфейсы между 2D / 3D аналогами. На мой взгляд, это одновременно и преимущество, и недостаток, поскольку, несмотря на эту последовательность, могут быть вещи, которые необязательно включать в один, но есть в другом.
2. Упростите взаимодействие двух разных типов или создание пользовательских сценариев, которые вы хотели бы прикрепить как к 2D, так и к 3D-версиям узла.

Было бы хорошо избежать ситуации, когда «SomeClass2D имеет реализованные x, y и z, но для SomeClass3D ничего подобного нет», и это решает проблему именования другим способом. Это, вероятно, монументально глупо по некоторым причинам, о которых я не думаю прямо сейчас, но я подумал, что выкину это там.

@vortexofdoom Это уже то, что происходит. Node2D наследуется всеми 2D-узлами, а Spatial наследуется всеми 3D-узлами. Вопрос в том, как все называть.

И, что более важно, Spatial и Node2D наследуются от Node .

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

Просто интересно: как вы думаете, было бы полезно добавить суффикс - Res ко всем классам, производным от Resource ?

@aaronfranke Я имею в виду идею наличия ОДНОГО узла каждого типа (просто KinematicBody или Sprite), а верхний из них представляет собой своего рода Node2D3D который диктует их поведение. Извините, если это не было хорошо объяснено. Таким образом, вместо двухмерной иерархии и трехмерной иерархии у нас будет двухмерная / трехмерная иерархия. Вот почему я сказал, что это будет более масштабный рефакторинг, чем это возможно.

Он _ может_ работать, если базовые типы не могут использоваться сами по себе, но должны быть реализованы как 2D / 3D, чтобы они были реальным узлом, и в этом случае мы вернемся к квадрату в именах узлов, но наследование больше автоматически направлять и связывать 2D и 3D, и взаимодействие между системами все равно было бы лучше (я думаю).

@vortexofdoom Но на самом деле между 2D и 3D нет ничего общего. У них могут быть одни и те же типы узлов и одинаковые имена методов, но почти все реализации полностью различаются. Наибольшее распространение, которое я мог ожидать, было бы интерфейсом, поскольку ваша идея будет включать if (is2d) { do 2d stuff } else { do 3d stuff } и сделает файлы кода вдвое длиннее и нечитабельными без всякой пользы.

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

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

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

@RandomShaper Я определенно мог бы увидеть в этом выгоду, особенно если у нас есть такая опция простых имен.

Оставляю свои комментарии для потомков, но я отказываюсь от своего предложения в пользу строгой схемы именования 2D / 3D, оставляя иерархию в основном как есть.

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

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

Я очень рад, что это обсуждается. Я надеюсь, что это будет сделано.

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

Пример:

Geometry.get_closest_point_to_segment()    # <-- this is the 3D version
Geometry.get_closest_point_to_segment_2d()

А что насчет структур данных, помимо узлов и методов? Я предполагаю, что Transform будет переименован в Transform3D чтобы соответствовать Transform2D , но Basis вероятно, не обязательно должно быть Basis3D потому что нет Basis2D поскольку все это включено в Transform2D .

@RandomShaper

Просто интересно: как вы думаете, было бы полезно добавить суффикс - Res ко всем классам, производным от Resource ?

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

Насчет отдельных проектов в 2D и 3D.

(В предложении изображения заменить 2d на UI и 3d на Scene).

Когда вы запускаете проект, вы выбираете, над каким вы будете работать.
Больше никаких суффиксов (2D, 3D) в именах классов не требуется.

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

используя Godot2D;
с использованием Godot3D;

Когда вы находитесь в трехмерном или двумерном проекте - нажмите на пользовательский интерфейс, у вас есть окно пользовательского интерфейса (2D) для редактирования графического интерфейса, при нажатии на сцену - вы находитесь в сцене (2d или 3d зависят от типа проекта).

Таким образом, мы сохраняем 2-мерный режим для пользовательского интерфейса в любом проекте, но Сцена открывает 2-мерное или 3-мерное окно.

В этом окне будут доступны только сущности, относящиеся к типу проекта (2d или 3d) или общие, если они используются в обоих

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

@dmitryuck Для размещенного вами изображения кнопка 2D всегда необходима, поскольку даже в 3D-играх потребуется использовать 2D-режим Godot для пользовательского интерфейса и прочего. И все равно желательно уметь смешивать 2D и 3D. Технически 2D-игры не нуждаются в использовании кнопки 3D, но вряд ли нужно ее скрывать.

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

@aaronfranke Я добавил немного

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

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

@dmitryuck В некоторых проектах может потребоваться смешивание 2D и 3D, а в некоторых играх пользовательский интерфейс в 3D.

@Skaruts, переключение на 2d вид в 3d сцене возможно, реализовав компонент как в этом редакторе

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

@reduz Переименование - это хорошо, но должен быть длительный переходный период, например, с 4.0 на 5.0, потому что это устаревшее множество руководств и ответов с https://godotengine.org/qa

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

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

Node type 'Spatial' is deprecated and replaced by 'Node3D'. 

а также

Method 'clip_polygon()' is deprecated and replaced by 'clip_polygon_3d()'. 

Вчера я обнаружил, что не все константы следуют одному и тому же регистру. Например, есть Color.black и Vector3.UP . Разве это не должно быть согласовано с 4.0?

@BenjaminNavarro Изменение цветовых констант на верхний регистр также обсуждалось внизу https://github.com/godotengine/godot/pull/14704.

Кроме того, переименование метода / сигнала / константы должно обсуждаться в # 16863, поскольку этот вопрос касается конкретно имен узлов.

@Calinou Спасибо, я был уверен, что были другие проблемы, но не смог их найти.

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

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

SemVer: учитывая номер версии MAJOR.MINOR.PATCH, увеличьте:
ОСНОВНАЯ версия при внесении несовместимых изменений API,
МИНИМАЛЬНАЯ версия, когда вы добавляете функциональность обратно совместимым образом, и
Версия PATCH при исправлении ошибок с обратной совместимостью.

Как далеко вы зайдете с этим?

Станет ли GridMap, например, TileMap3D, а Tilemap Tilemap2D?

Кроме того, node2D и node3D кажутся немного общими, почему бы тогда не использовать Spatial2D и Spatial3D?

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

Что касается методов, я думаю, нет необходимости добавлять к ним постфикс 2D или 3D, так как вы знаете, как вы их называете?

Я все еще надеюсь сделать некоторые полезные обновления, такие как решение проблемы медленного импорта ресурсов и оптимизация производительности сценариев GD. В настоящее время импорт ресурсов 1G занимает около часа. Если вы импортируете ресурсы 10G, вам придется сидеть перед компьютером и спать два дня. Однако браузер файловой системы редактора ресурсов для импорта 700M-1G теперь не работает, и ничего не будет отображаться. Список файлов, это может быть недостаток самого редактора, поэтому я думаю, что оптимизация и решение существующих проблем - лучший способ для Godot. Если я могу импортировать только 100-500 миллионов ресурсов, то предназначено, что Godot не сможет разрабатывать большие игры. Но мой путь теперь заблокирован, и я не могу двигаться дальше. Надеюсь, что следующая версия решит такие проблемы, желаю Годо все лучше и лучше!

@ qq715152910 Пожалуйста, не комментируйте длинные

Выскажу свое мнение по поводу некоторых переименований, которые были бы полезны для нас (в основном мы используем C #)

Переименование, которое мы настоятельно рекомендуем:

1. Transform.origin -> transform.origin

(Делаем доступ к свойству преобразования в нижнем регистре)

Почему?
Например, в пространственном есть Transform, к которому мы можем получить доступ, но много раз мы пишем this.Transform.origin для лучшей читаемости, если мы изменим «Transform» на «transform», нам не нужно будет использовать все «this». время. Это наше личное мнение.

1. Мы также поддерживаем замену Label на что-то вроде TextLabel. Или, по крайней мере, когда мы ищем по «тексту» при добавлении нового узла, должна появиться «метка», поскольку она полностью связана.

2. Константы для некоторых предварительно определенных цветов должны быть доступны с помощью Color в отличие от Colors .

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

Атлас Текстура -> Текстура Атлас

Он назван AtlasTexture, потому что следует обычному соглашению <Type>Texture где <Type> может быть Image , Viewport , Stream ,…

Атлас Текстура -> Текстура Атлас

Он назван AtlasTexture, потому что следует обычному соглашению <Type>Texture где <Type> может быть Image , Viewport , Stream ,…

Это то, что появляется, когда я набираю «Атлас».

Вот что происходит, когда мы набираем текстуру:

Изменить: мы понимаем, почему это соглашение. На 2-м скриншоте AtlasTexture очень сильно обозначено рядом с другими вещами, которые следуют соглашению <Type>Texture . После этого этот пункт был удален из нашего предыдущего поста. Для этого конкретного случая все еще не очень дружелюбен к автозаполнению. Но мы это принимаем. .

@bigmonte Transform структура будет может быть переименована в Transform3D в Годо 4.0 в соответствии с этим вопросом, так что вам больше не нужно this. , чтобы понять , что это свойство.

РЕДАКТИРОВАТЬ: https://github.com/godotengine/godot/pull/38430

Константы для некоторых предварительно определенных цветов должны быть доступны с помощью Color в отличие от Colors .

Я был тем, кто предложил это в первую очередь, и я категорически не согласен. Лучше держать их отдельно, так как это увеличивает обнаруживаемость статических членов Color (в настоящее время Color8 , ColorN и FromHsv ) при использовании автозаполнения в различные IDE. Я также рассматриваю возможность переименования Color.red etc -> Colors.RED в GDScript для единообразия.

Кстати, я думаю, вы искали №16863.