Добро пожаловать в тред любви, взаимопомощи и типизированных луа-террейнов одним мешем!
Шапка: https://hipolink.me/godothread
Предыдущий: >>981386 (OP)
Архивный: >>977039 (OP)
Шапка: https://hipolink.me/godothread
Предыдущий: >>981386 (OP)
Архивный: >>977039 (OP)
>>5261 (OP)
Когда в годотю новый ги завезут? Надоело ждать, раз сделали хули не завозят?
Когда в годотю новый ги завезут? Надоело ждать, раз сделали хули не завозят?
274 Кб, 3840x2006>>985233 →
Он может быть полезен для обучения новичков, но фактически это тот же GDScript, только вместо ручной печати команд ты таскаешь их мышкой.
В идеале визуальный язык должен качественно отличаться от текстового тем, что может наглядно демонстрировать взаимосвязи между объектами.
>>5266
1. Над этим работает сам Хуан, в соло.
2. Там вроде ещё есть какие-то проблемы.
Можешь пробовать собрать движок сам:
https://github.com/godotengine/godot/pull/86267
Значит, можно ожидать в одной из следующих тестовых сборок 4.4, либо придётся ждать 4.5.
>блокскрипт. Он визуальнее визуального.
Он может быть полезен для обучения новичков, но фактически это тот же GDScript, только вместо ручной печати команд ты таскаешь их мышкой.
В идеале визуальный язык должен качественно отличаться от текстового тем, что может наглядно демонстрировать взаимосвязи между объектами.
>>5266
>Когда новый ги
1. Над этим работает сам Хуан, в соло.
2. Там вроде ещё есть какие-то проблемы.
Можешь пробовать собрать движок сам:
https://github.com/godotengine/godot/pull/86267
>Milestone 4.4
Значит, можно ожидать в одной из следующих тестовых сборок 4.4, либо придётся ждать 4.5.
>>5292
Да.
Мы это подробно обсудили в прошлом году в треде блочных языков (интересно, утонул ли он?)
> В идеале визуальный язык должен качественно отличаться от текстового тем, что может наглядно демонстрировать взаимосвязи между объектами.
Да.
Мы это подробно обсудили в прошлом году в треде блочных языков (интересно, утонул ли он?)
>>5292
Да, но он реально выполняет свою роль, он проще скриптинга, не нужно учить api, кликаешь на объект, вылезает окошечко с его свойствами, в констракте грамотно сделано, условия слева, события справа. А ноды нисколько не упрощают, только усложняют. Конечно, по идее это не нужно, но по идее и гдскрипт не нужен, пили на сишарпе или плюсах и в хуй не дуй
>Он может быть полезен для обучения новичков, но фактически это тот же GDScript, только вместо ручной печати команд ты таскаешь их мышкой.
Да, но он реально выполняет свою роль, он проще скриптинга, не нужно учить api, кликаешь на объект, вылезает окошечко с его свойствами, в констракте грамотно сделано, условия слева, события справа. А ноды нисколько не упрощают, только усложняют. Конечно, по идее это не нужно, но по идее и гдскрипт не нужен, пили на сишарпе или плюсах и в хуй не дуй
>>5300
Вот видите, мы постоянно из крайности в крайность кидаемся. То ничего не нужно, то всё нужно.
Я вам вот что скажу: нужен грамотный транспилинг, чтобы любой мог писать логику так ,как ему нравится и в любой момент мог спуститься на уровень ниже, чтобы оптимизировать. Самый высокий уровень: блоки/ивентщиты, уровнем пониже ноды/лапша, еще ниже высокоуровневые скрипты типа гдскрипта/питона/жс, еще ниже низкоуровневые скрипты типа шарпа/жавы, ну и в самом низу си/си++/паскаль/раст. И между этими уровнями уже сегодня можно спускаться сверху вниз. Тулчейны имеются. Но вверх, очевидно, задача нетривиальная, да и не нужно это.
> Конечно, по идее это не нужно, но по идее и гдскрипт не нужен, пили на сишарпе или плюсах и в хуй не дуй
Вот видите, мы постоянно из крайности в крайность кидаемся. То ничего не нужно, то всё нужно.
Я вам вот что скажу: нужен грамотный транспилинг, чтобы любой мог писать логику так ,как ему нравится и в любой момент мог спуститься на уровень ниже, чтобы оптимизировать. Самый высокий уровень: блоки/ивентщиты, уровнем пониже ноды/лапша, еще ниже высокоуровневые скрипты типа гдскрипта/питона/жс, еще ниже низкоуровневые скрипты типа шарпа/жавы, ну и в самом низу си/си++/паскаль/раст. И между этими уровнями уже сегодня можно спускаться сверху вниз. Тулчейны имеются. Но вверх, очевидно, задача нетривиальная, да и не нужно это.
>>5333
Чел, ну допустим у тебя будет что-то в выпадающем списке. Как ты узнаешь что из этого что не изучая?
А так в текстовых ЯП есть автодополнение.
Чел, ну допустим у тебя будет что-то в выпадающем списке. Как ты узнаешь что из этого что не изучая?
А так в текстовых ЯП есть автодополнение.
>>5334
Ты не пынямаешь. Я вот начинал с констракта, а сейчас на сишарпе, и констракт это единственный упрощенный "скриптинг", есть фишки для новичков, которые позволяют кодить простое просто
Ты не пынямаешь. Я вот начинал с констракта, а сейчас на сишарпе, и констракт это единственный упрощенный "скриптинг", есть фишки для новичков, которые позволяют кодить простое просто
>>5336
Мне кажется что Абу уже давно прикрутил нейронку и она копирует людей и потом пишет от их лица. Как будто я после трёх литров пива. Еще года три назад можно было определить Анонов по стилю написания, сейчас вообще не возможно.
Мне кажется что Абу уже давно прикрутил нейронку и она копирует людей и потом пишет от их лица. Как будто я после трёх литров пива. Еще года три назад можно было определить Анонов по стилю написания, сейчас вообще не возможно.
>>5349
Ты о чем, бот?
Ты о чем, бот?
>>5349
Какие нахуй боты нейронки? Вы что ёбнулись, друзья? Или ньюфаги? Любитель констракта здесь уже лет 5 сидит. Душнила с ним спорящий тоже не меньше. Вы их двоих не узнали штоле?
>>5319
Есть настолько интуитивные приложения, что никакие справочники не нужны. Например Paint никто не учил тебя как в нём рисовать. Там настолько всё очевидно, что ты просто берёшь мышку и рисуешь.
Полагаю, в констракте что-то подобное.
Какие нахуй боты нейронки? Вы что ёбнулись, друзья? Или ньюфаги? Любитель констракта здесь уже лет 5 сидит. Душнила с ним спорящий тоже не меньше. Вы их двоих не узнали штоле?
>>5319
> волшебным образом знания сами в голову подгрузятся
Есть настолько интуитивные приложения, что никакие справочники не нужны. Например Paint никто не учил тебя как в нём рисовать. Там настолько всё очевидно, что ты просто берёшь мышку и рисуешь.
Полагаю, в констракте что-то подобное.
>>5375
Я недавно вкатился, и только потому что у движка якобы есть поддержка сишарпа. Меня десять раз обосрали в прошлом треде за мой выбор яп. Да мы ебанулись. Нейронки даже ошибки те же самые делают в предложениях.
Я как-то своим бывшим друзьям, лет десять назад, говорил что на даваче боты треды пишут в б. А они мне Ты что ебанутый, быть такого не может, это же так сложно написать.
Я недавно вкатился, и только потому что у движка якобы есть поддержка сишарпа. Меня десять раз обосрали в прошлом треде за мой выбор яп. Да мы ебанулись. Нейронки даже ошибки те же самые делают в предложениях.
Я как-то своим бывшим друзьям, лет десять назад, говорил что на даваче боты треды пишут в б. А они мне Ты что ебанутый, быть такого не может, это же так сложно написать.
188 Кб, 1440x1287>>5378
Любишь шарп - пиши на шарпе. Официально.
Любишь шарп - пиши на шарпе. Официально.
880 Кб, 1887x748>>5375
А зачем сравнивать с ним? Тут сравнивать впору с фотошопом. А там таки надо учить. Вон какой код в констракте приходится писать прямо внутри поля.
>Paint никто не учил
А зачем сравнивать с ним? Тут сравнивать впору с фотошопом. А там таки надо учить. Вон какой код в констракте приходится писать прямо внутри поля.
А как можно поменять шрифт через код во всём проекте? Попробовал ProjectSettings.set_setting("gui/theme/custom_font", переменная с шрифтом), и другие способы, но чет не получалось
>>5388
Попробуй через настройки кастомной темы UI.
Попробуй через настройки кастомной темы UI.
>>5375
Спасибо за комплимент, ты тоже молодец.
>>5300
Твоя ошибка в том, что ты пытаешься нас убедить, что мышкой скроллить километровые менюшки и таскать из них блоки - это проще, чем простой текст.
API никуда не девается. Пример - вывести текст:
1. Открыть меню - "список доступных функций".
2. Пролистать колёсиком до функции "print text".
3. Перетащить мышкой функцию в окно кода.
4. Набрать желаемый текст на клавиатуре.
Классическим кодом будет примерно так:
1. Нажимаешь "p", "r", "i" или что-то вроде того.
2. Видишь - подсказка "print()" - жмёшь enter.
3. Набираешь желаемый текст на клавиатуре.
Как можешь заменить, во втором случае не нужно трогать мышь, листать километровые меню, что-то куда-то таскать. Но в обоих случаях ты добавляешь функцию с одинаковым названием и одинаково вынужден набирать текст на клавиатуре. Т.е. твой "блочный код" не даёт никаких преимуществ даже пользователям, не знакомым с клавиатурой.
Удобный визуальный язык должен абстрагировать пользователя от таких действий полностью. Как? Например, у тебя есть два объекта: "динамик" и "генератор звуков" - просто соединяешь динамик с генератором звуков и можешь слышать звуки. Без необходимости каким-либо способом вызывать API команды уровня "play sound: path to sound".
С таким языком ты можешь глянуть на монитор и мгновенно осознать: "ага, динамик соединяется с генератором звуков, значит, должно что-то звучать". Вместо необходимости искать глазами и читать текстовую строку "play sound", независимо от её внешности - цветная рамка её суть не меняет.
Но подобные языки - это DSL, а не что-то общее.
https://en.wikipedia.org/wiki/Domain-specific_language
Поэтому движок может предоставить только общие средства создания таких языков (GraphEdit в Godot).
>Душнила с ним спорящий тоже не меньше.
Спасибо за комплимент, ты тоже молодец.
>>5300
>проще скриптинга, не нужно учить api, кликаешь на объект, вылезает окошечко с его свойствами
Твоя ошибка в том, что ты пытаешься нас убедить, что мышкой скроллить километровые менюшки и таскать из них блоки - это проще, чем простой текст.
API никуда не девается. Пример - вывести текст:
1. Открыть меню - "список доступных функций".
2. Пролистать колёсиком до функции "print text".
3. Перетащить мышкой функцию в окно кода.
4. Набрать желаемый текст на клавиатуре.
Классическим кодом будет примерно так:
1. Нажимаешь "p", "r", "i" или что-то вроде того.
2. Видишь - подсказка "print()" - жмёшь enter.
3. Набираешь желаемый текст на клавиатуре.
Как можешь заменить, во втором случае не нужно трогать мышь, листать километровые меню, что-то куда-то таскать. Но в обоих случаях ты добавляешь функцию с одинаковым названием и одинаково вынужден набирать текст на клавиатуре. Т.е. твой "блочный код" не даёт никаких преимуществ даже пользователям, не знакомым с клавиатурой.
Удобный визуальный язык должен абстрагировать пользователя от таких действий полностью. Как? Например, у тебя есть два объекта: "динамик" и "генератор звуков" - просто соединяешь динамик с генератором звуков и можешь слышать звуки. Без необходимости каким-либо способом вызывать API команды уровня "play sound: path to sound".
С таким языком ты можешь глянуть на монитор и мгновенно осознать: "ага, динамик соединяется с генератором звуков, значит, должно что-то звучать". Вместо необходимости искать глазами и читать текстовую строку "play sound", независимо от её внешности - цветная рамка её суть не меняет.
Но подобные языки - это DSL, а не что-то общее.
https://en.wikipedia.org/wiki/Domain-specific_language
Поэтому движок может предоставить только общие средства создания таких языков (GraphEdit в Godot).
>>5375
Спасибо за комплимент, ты тоже молодец.
>>5300
Твоя ошибка в том, что ты пытаешься нас убедить, что мышкой скроллить километровые менюшки и таскать из них блоки - это проще, чем простой текст.
API никуда не девается. Пример - вывести текст:
1. Открыть меню - "список доступных функций".
2. Пролистать колёсиком до функции "print text".
3. Перетащить мышкой функцию в окно кода.
4. Набрать желаемый текст на клавиатуре.
Классическим кодом будет примерно так:
1. Нажимаешь "p", "r", "i" или что-то вроде того.
2. Видишь - подсказка "print()" - жмёшь enter.
3. Набираешь желаемый текст на клавиатуре.
Как можешь заменить, во втором случае не нужно трогать мышь, листать километровые меню, что-то куда-то таскать. Но в обоих случаях ты добавляешь функцию с одинаковым названием и одинаково вынужден набирать текст на клавиатуре. Т.е. твой "блочный код" не даёт никаких преимуществ даже пользователям, не знакомым с клавиатурой.
Удобный визуальный язык должен абстрагировать пользователя от таких действий полностью. Как? Например, у тебя есть два объекта: "динамик" и "генератор звуков" - просто соединяешь динамик с генератором звуков и можешь слышать звуки. Без необходимости каким-либо способом вызывать API команды уровня "play sound: path to sound".
С таким языком ты можешь глянуть на монитор и мгновенно осознать: "ага, динамик соединяется с генератором звуков, значит, должно что-то звучать". Вместо необходимости искать глазами и читать текстовую строку "play sound", независимо от её внешности - цветная рамка её суть не меняет.
Но подобные языки - это DSL, а не что-то общее.
https://en.wikipedia.org/wiki/Domain-specific_language
Поэтому движок может предоставить только общие средства создания таких языков (GraphEdit в Godot).
>Душнила с ним спорящий тоже не меньше.
Спасибо за комплимент, ты тоже молодец.
>>5300
>проще скриптинга, не нужно учить api, кликаешь на объект, вылезает окошечко с его свойствами
Твоя ошибка в том, что ты пытаешься нас убедить, что мышкой скроллить километровые менюшки и таскать из них блоки - это проще, чем простой текст.
API никуда не девается. Пример - вывести текст:
1. Открыть меню - "список доступных функций".
2. Пролистать колёсиком до функции "print text".
3. Перетащить мышкой функцию в окно кода.
4. Набрать желаемый текст на клавиатуре.
Классическим кодом будет примерно так:
1. Нажимаешь "p", "r", "i" или что-то вроде того.
2. Видишь - подсказка "print()" - жмёшь enter.
3. Набираешь желаемый текст на клавиатуре.
Как можешь заменить, во втором случае не нужно трогать мышь, листать километровые меню, что-то куда-то таскать. Но в обоих случаях ты добавляешь функцию с одинаковым названием и одинаково вынужден набирать текст на клавиатуре. Т.е. твой "блочный код" не даёт никаких преимуществ даже пользователям, не знакомым с клавиатурой.
Удобный визуальный язык должен абстрагировать пользователя от таких действий полностью. Как? Например, у тебя есть два объекта: "динамик" и "генератор звуков" - просто соединяешь динамик с генератором звуков и можешь слышать звуки. Без необходимости каким-либо способом вызывать API команды уровня "play sound: path to sound".
С таким языком ты можешь глянуть на монитор и мгновенно осознать: "ага, динамик соединяется с генератором звуков, значит, должно что-то звучать". Вместо необходимости искать глазами и читать текстовую строку "play sound", независимо от её внешности - цветная рамка её суть не меняет.
Но подобные языки - это DSL, а не что-то общее.
https://en.wikipedia.org/wiki/Domain-specific_language
Поэтому движок может предоставить только общие средства создания таких языков (GraphEdit в Godot).
>>5402
Никто тебя ни в чем не пытался убедить, я сейчас на юнити прогаю сишарпой, конечно, это гораздо лучше. Дальше писанину твою не читал, ты шизоид
>Твоя ошибка в том, что ты пытаешься нас убедить, что мышкой скроллить километровые менюшки и таскать из них блоки - это проще, чем простой текст.
Никто тебя ни в чем не пытался убедить, я сейчас на юнити прогаю сишарпой, конечно, это гораздо лучше. Дальше писанину твою не читал, ты шизоид
>>5402
В трёшке было так. В четвёрке почему-то поменяли порядок сортировки подсказок и проще принт целиком напечатать, чем прокручивать его в списке. Подскажите, может это можно как-то отменить? Вернуть как было в трёшке?
> Классическим кодом будет примерно так:
> 1. Нажимаешь "p", "r", "i" или что-то вроде того.
> 2. Видишь - подсказка "print()" - жмёшь enter.
> 3. Набираешь желаемый текст на клавиатуре.
В трёшке было так. В четвёрке почему-то поменяли порядок сортировки подсказок и проще принт целиком напечатать, чем прокручивать его в списке. Подскажите, может это можно как-то отменить? Вернуть как было в трёшке?
>>5405
Щас понял. Оно при сортировке ставит подчёркивание первее конца строки. И это, походу, баг, а не фича. Если его пофиксить, то сортировка вернётся в норму. Возможно, даже как-то супер-просто фиксится, надо просто найти в исходниках функцию сортировки.
Щас понял. Оно при сортировке ставит подчёркивание первее конца строки. И это, походу, баг, а не фича. Если его пофиксить, то сортировка вернётся в норму. Возможно, даже как-то супер-просто фиксится, надо просто найти в исходниках функцию сортировки.
>>5405 >>5414
На мой взгляд, сейчас всё правильно работает. Тебе значительно дольше печатать "print_orphan_nodes", чем тот же print, printerr и т.п. Даже если ты редко используешь эту функцию, иметь её ближе удобно.
Изменения сортировки подсказок в 4.0 касались в первую очередь наследования классов, и с этим всё хорошо. Раньше ты получал рандомные встроенные функции и константы сверху списка, а сейчас - то, что объявлено тобой в унаследованном классе.
Изменения произошли здесь:
https://github.com/godotengine/godot/pull/58931
Там же ссылки на обсуждения проблем 3.x.
Здесь жалоба, аналогичная твоей:
https://github.com/godotengine/godot-proposals/issues/9808
С обсуждением, почему откатывать не нужно.
На мой взгляд, сейчас всё правильно работает. Тебе значительно дольше печатать "print_orphan_nodes", чем тот же print, printerr и т.п. Даже если ты редко используешь эту функцию, иметь её ближе удобно.
Изменения сортировки подсказок в 4.0 касались в первую очередь наследования классов, и с этим всё хорошо. Раньше ты получал рандомные встроенные функции и константы сверху списка, а сейчас - то, что объявлено тобой в унаследованном классе.
Изменения произошли здесь:
https://github.com/godotengine/godot/pull/58931
Там же ссылки на обсуждения проблем 3.x.
Здесь жалоба, аналогичная твоей:
https://github.com/godotengine/godot-proposals/issues/9808
С обсуждением, почему откатывать не нужно.
>>5419
Что дольше: 1 раз напечатать nt_orphan_nodes или 10 раз напечатать nt? Как по мне, print нужен даже чаще.
Да, с этим хорошо, и к этому никаких претензий. Претензии только к подчёркиваниям.
Тащемта да, откатывать не нужно, нужна опция.
Хотя я не видел в интернетах ни одного довольного новой сортировкой, но вот недовольных хватает. Это повод задуматься.
Но, я смотрю, воз и ныне там.
>дольше печатать
Что дольше: 1 раз напечатать nt_orphan_nodes или 10 раз напечатать nt? Как по мне, print нужен даже чаще.
>в первую очередь наследования классов, и с этим всё хорошо
Да, с этим хорошо, и к этому никаких претензий. Претензии только к подчёркиваниям.
>С обсуждением, почему откатывать не нужно.
>Calinou changed the title Change autocompletion sort order to purely alphabetical or give an option for it in settings. Change autocompletion sort order to be purely alphabetical or add an editor setting for it on May 23
Тащемта да, откатывать не нужно, нужна опция.
Хотя я не видел в интернетах ни одного довольного новой сортировкой, но вот недовольных хватает. Это повод задуматься.
Но, я смотрю, воз и ныне там.
Сколько миллионов было потрачено потому что какой-то шизик с манией решил свой язык придумать. Теперь они нахуй сортировки автодополнения фиксят туда-сюда.
Бляяяя.
Бляяяя.
>>5446
Godotaны такой вопрос.
Если спрайт, допустим, размером 500x500, но в движке мы его скейлим на 0.1,
то есть в игре он будет 50x50, то как этот спрайт себя ведет?
Он так и остается 500x500, просто визуально отображается как 50x50?
Или он скейлится один раз а затем сохраняется где-то в памяти и используется с меньшим размером?
Или он пересчитывается каждый кадр?
Просто надоело постоянно вручную менять спрайты в GIMP.
Godotaны такой вопрос.
Если спрайт, допустим, размером 500x500, но в движке мы его скейлим на 0.1,
то есть в игре он будет 50x50, то как этот спрайт себя ведет?
Он так и остается 500x500, просто визуально отображается как 50x50?
Или он скейлится один раз а затем сохраняется где-то в памяти и используется с меньшим размером?
Или он пересчитывается каждый кадр?
Просто надоело постоянно вручную менять спрайты в GIMP.
>>5463
Остается, движок же не знает, вдруг ты потом из скрипта скейлишь.
Надоело вручную - автоматизируй. Тул скриптами, или батником каким нибудь с imagemagick.
Погуглил, и оказывается в 4 годоте есть такая опция импорта.
Она индивидуальная для каждой картинки, но если нажать Preset - set as default, то такие настройки импорта будут распространяться на последующие добавленные картинки.
Остается, движок же не знает, вдруг ты потом из скрипта скейлишь.
Надоело вручную - автоматизируй. Тул скриптами, или батником каким нибудь с imagemagick.
Погуглил, и оказывается в 4 годоте есть такая опция импорта.
Она индивидуальная для каждой картинки, но если нажать Preset - set as default, то такие настройки импорта будут распространяться на последующие добавленные картинки.
>>5463
В дебаггере есть вкладка video ram, в ней показывается разрешение каждой картинки и сколько памяти она ест.
Алсо 500х500 не так страшно. У тебя же не 4к текстуры.
В дебаггере есть вкладка video ram, в ней показывается разрешение каждой картинки и сколько памяти она ест.
Алсо 500х500 не так страшно. У тебя же не 4к текстуры.
https://godotengine.org/article/dev-snapshot-godot-4-4-dev-5/
Хуан UID завез, теперь любителям бесконечного рефакторинга жить легче станет.
Хуан UID завез, теперь любителям бесконечного рефакторинга жить легче станет.
>>5477
Статья на сайте Godot Engine представляет собой обзор текущего состояния разработки Godot 4.4, в частности, версии Dev 5. В ней обсуждаются новые функции и улучшения, включая оптимизацию производительности и обновления в редакторе. Также авторы подчеркивают важность обратной связи от сообщества для дальнейшего совершенствования движка.
Ясно спасибо.
Статья на сайте Godot Engine представляет собой обзор текущего состояния разработки Godot 4.4, в частности, версии Dev 5. В ней обсуждаются новые функции и улучшения, включая оптимизацию производительности и обновления в редакторе. Также авторы подчеркивают важность обратной связи от сообщества для дальнейшего совершенствования движка.
Ясно спасибо.
>>5477
>>5478
ГПТ головного мозга, плез. Сказали же тебе - UID у каждого скрипта/файла/ресурса, позволяет надежно отслеживать все переименования/перемещения файлов, затрудняя твоим кривым рукам поломку твоей инди-дрочильни при рефакторинге твоей говеной структуры проекта. Ясно-понятно, принял-понял, как слышно? Прием, шшш.
>>5478
ГПТ головного мозга, плез. Сказали же тебе - UID у каждого скрипта/файла/ресурса, позволяет надежно отслеживать все переименования/перемещения файлов, затрудняя твоим кривым рукам поломку твоей инди-дрочильни при рефакторинге твоей говеной структуры проекта. Ясно-понятно, принял-понял, как слышно? Прием, шшш.
>>5480
Я не поленился и почитал, просто ноль полезной информации. . . . . .. . .
Я не поленился и почитал, просто ноль полезной информации. . . . . .. . .
>>5480
Если бы было, то не было бы нытья "я поперемещал кучу всего, и все зависимости сломались!"
Если бы было, то не было бы нытья "я поперемещал кучу всего, и все зависимости сломались!"
>>5482
Я уже привык и каждый раз проверю. И обычно только если на паку выше перемешаешь, случаться проблемы.
Я уже привык и каждый раз проверю. И обычно только если на паку выше перемешаешь, случаться проблемы.
>>5482
А если в целом то ладно молодцы хоть что то делают.
А если в целом то ладно молодцы хоть что то делают.
>>5482
Дык оно просто криво работало. Но было же. Зависимости отслеживаются, если перемещать файлы из редактора. Но не всегда. Если цепочка вложенных зависимостей слишком сложная, может поломаться. Желательно держать открытыми все сцены, где используется перемещаемый файл.
Изменение не в том, что УИДы добавили, а в том, что их добавили для всего, в том числе для импортируемого всякого.
Дык оно просто криво работало. Но было же. Зависимости отслеживаются, если перемещать файлы из редактора. Но не всегда. Если цепочка вложенных зависимостей слишком сложная, может поломаться. Желательно держать открытыми все сцены, где используется перемещаемый файл.
Изменение не в том, что УИДы добавили, а в том, что их добавили для всего, в том числе для импортируемого всякого.
>>5465
о, нихуя, такое и мне полезно будет
о, нихуя, такое и мне полезно будет
>>5478
Всмысле 4.5 или 5.0? Если 5.0, то известны мин. требования к пеке для 2д разработки, что бы не было больно? Для меня это как бы новое хобби, и если требования возрастут, не хочется на пеку много тратиться. А пока черная пятница, я могу подевешле что-то найти.
>обзор текущего состояния разработки Godot 4.4, в частности, версии Dev 5
>Dev 5
Всмысле 4.5 или 5.0? Если 5.0, то известны мин. требования к пеке для 2д разработки, что бы не было больно? Для меня это как бы новое хобби, и если требования возрастут, не хочется на пеку много тратиться. А пока черная пятница, я могу подевешле что-то найти.
>>5512
не ссы, пока поддержка веба есть режим совместимости на опенжл3 никуда не уйдет
не ссы, пока поддержка веба есть режим совместимости на опенжл3 никуда не уйдет
>>5512
Да в любом случае имеет смысл брать что-инбудь, цены будут расти
Да в любом случае имеет смысл брать что-инбудь, цены будут расти
>>5512
4.4 dev 5 это сырая пятая пре-бета версии 4.4, потом какие-нибудь 4.4 beta1-2-3 пойдут, потом release candidate (RC1-2-3), потом, наконец, релиз 4.4.
До 5.0 еще лет 5, так что не трясись.
4.4 dev 5 это сырая пятая пре-бета версии 4.4, потом какие-нибудь 4.4 beta1-2-3 пойдут, потом release candidate (RC1-2-3), потом, наконец, релиз 4.4.
До 5.0 еще лет 5, так что не трясись.
>>5429
Нам что, открывать новые issue?
Конечно, чаще всего пишут о том, чем недовольны.
>не видел в интернетах ни одного довольного
Нам что, открывать новые issue?
>Здравствуйте, работаю над попенворлд 3д экшн, суть не важна, хотел только сказать, что доволен новой сортировкой подсказок в коде. Спасибо!
>100500 лайков, один комментарий
>Комментарий: Это не проблема, закрываю
>Комментарии ограничены до проверенных
Конечно, чаще всего пишут о том, чем недовольны.
>>5446
https://duckduckgo.com/?q=how+many+programming+languages+exists
Давай, поплачь ещё, что кто-то свой язык делает.
>Сколько миллионов было потрачено
https://duckduckgo.com/?q=how+many+programming+languages+exists
>There are estimates of over 8,000 programming languages in existence, with some sources suggesting the number could be as high as 9,000. However, only a small fraction of these are widely used in practice today.
Давай, поплачь ещё, что кто-то свой язык делает.
>>5463
Если сгенерированы mipmap, то будет использован наиболее подходящий по размеру вариант. Без них получается сжатие с возможными артефактами.
Mipmap позволяет создать несколько качественно уменьшенных вариантов, чтобы уменьшить число артефактов при сжатии полигонов в реалтайме:
https://ru.wikipedia.org/wiki/MIP-текстурирование
Это выгодно, если ты планируешь делать сильное приближение и/или отдаление камеры в 2D игре.
Но если планируешь использовать только 1/10 от изначального размера, т.е. в игре камера не будет приближаться к спрайтам, лучше сжать оригинал.
>будет 50x50, то как этот спрайт себя ведет?
Если сгенерированы mipmap, то будет использован наиболее подходящий по размеру вариант. Без них получается сжатие с возможными артефактами.
Mipmap позволяет создать несколько качественно уменьшенных вариантов, чтобы уменьшить число артефактов при сжатии полигонов в реалтайме:
https://ru.wikipedia.org/wiki/MIP-текстурирование
Это выгодно, если ты планируешь делать сильное приближение и/или отдаление камеры в 2D игре.
Но если планируешь использовать только 1/10 от изначального размера, т.е. в игре камера не будет приближаться к спрайтам, лучше сжать оригинал.
>>5446
Ты про c++? Там ракеты и самроеиы падали.
Или про C#? Он в банкинге и трейдинге использовался, а значит точно наносил убытки в миллионы.
>Сколько миллионов было потрачено потому что какой-то шизик с манией решил свой язык придумать.
Ты про c++? Там ракеты и самроеиы падали.
Или про C#? Он в банкинге и трейдинге использовался, а значит точно наносил убытки в миллионы.
>>5512
Подробнее о нумерации и поддержке версий Godot:
https://docs.godotengine.org/en/latest/about/release_policy.html
Прогресс разработки актуальных версий Godot:
https://github.com/godotengine/godot/milestones
Как видишь, ни 4.5, ни 5.0 пока не планируется.
На версию 5.0 откладывают только предложения:
https://github.com/godotengine/godot-proposals/milestones
Godot всегда делали с упором на то, чтобы он был максимально доступен всем, включая детей нищих африканских стран или что-то в этом роде. Должно быть достаточно компьютера 2007-го года, разве что видеокарта должна быть помоложе (2013+).
А разве это не развод перед новым годом? Перед распродажей всегда завышают цены, как и перед новогодними праздниками. К лету снова снижают.
Подробнее о нумерации и поддержке версий Godot:
https://docs.godotengine.org/en/latest/about/release_policy.html
Прогресс разработки актуальных версий Godot:
https://github.com/godotengine/godot/milestones
>3.7 - 48% complete, 24 open, 23 closed
>4.4 - 66% complete, 1145 open, 2271 closed
Как видишь, ни 4.5, ни 5.0 пока не планируется.
На версию 5.0 откладывают только предложения:
https://github.com/godotengine/godot-proposals/milestones
>5.0 - 0% complete, 40 open, 0 closed
>если требования возрастут
Godot всегда делали с упором на то, чтобы он был максимально доступен всем, включая детей нищих африканских стран или что-то в этом роде. Должно быть достаточно компьютера 2007-го года, разве что видеокарта должна быть помоложе (2013+).
>А пока черная пятница
А разве это не развод перед новым годом? Перед распродажей всегда завышают цены, как и перед новогодними праздниками. К лету снова снижают.
>>5555
Так с мипмапом оригинал никуда не девается, вроде.
Фишка мипмапа в матемтическом свойстве, что 1/4+1/16+1/256... ~= 1/3, иными словами, размер оригинала увеличивается на треть, но в этой трети можно хранить ВСЕ шаги уменьшения картинки вдвое.
То есть это другая оптимизация, не размера, а скорости (чтобы не масштабировать в реалтайме, а доставать уже уменьшенную картинку и при надобности интерполировать между двумя соседними шагами до нужного нецелого размера).
Так с мипмапом оригинал никуда не девается, вроде.
Фишка мипмапа в матемтическом свойстве, что 1/4+1/16+1/256... ~= 1/3, иными словами, размер оригинала увеличивается на треть, но в этой трети можно хранить ВСЕ шаги уменьшения картинки вдвое.
То есть это другая оптимизация, не размера, а скорости (чтобы не масштабировать в реалтайме, а доставать уже уменьшенную картинку и при надобности интерполировать между двумя соседними шагами до нужного нецелого размера).
107 Кб, 1284x741>>5429
Погуглил, так и старой многие не довольны.
https://github.com/godotengine/godot-proposals/issues/9808
https://github.com/godotengine/godot/issues/21726
https://github.com/godotengine/godot-proposals/issues/4189
https://github.com/godotengine/godot/pull/58931
Я так понимаю, что можно придумать примеры которые ломают то одну, то другую схему, и надо делать вообще более сложную систему, которая учитывает не только, какой класс сейчас редактируешь, но и какие слова часто использовал (в VsCode вроде так, последнее использованное начнет подниматься вверх по списку - но это значит, что сортировка станет непостоянной, и когда ты пойдешь работать над другой частью проекта, может запутать)
Погуглил, так и старой многие не довольны.
https://github.com/godotengine/godot-proposals/issues/9808
https://github.com/godotengine/godot/issues/21726
https://github.com/godotengine/godot-proposals/issues/4189
https://github.com/godotengine/godot/pull/58931
Я так понимаю, что можно придумать примеры которые ломают то одну, то другую схему, и надо делать вообще более сложную систему, которая учитывает не только, какой класс сейчас редактируешь, но и какие слова часто использовал (в VsCode вроде так, последнее использованное начнет подниматься вверх по списку - но это значит, что сортировка станет непостоянной, и когда ты пойдешь работать над другой частью проекта, может запутать)
115 Кб, 478x479>>5562
Придётся ждать следующую версию, когда пофикс... Так, падажжи. А ведь в VSCode есть поддержка гдскрипта.
Придётся ждать следующую версию, когда пофикс... Так, падажжи. А ведь в VSCode есть поддержка гдскрипта.
>>5570
Божечьки, какой каеф!
Божечьки, какой каеф!
>>5562
Это неудобно в долгосрочной перспективе.
В идеале нужен ИИ, который держит в контексте не только весь проект, но и твои идеи/рассуждения.
>>5570
Какой же у VSCode дурацкий гуй... Откуда эта мода на боковое меню иконками? Виндувс же вроде уже отказалась от размещения таскбара сбоку экрана.
>>5572
Куда собрался? Ты теперь навсегда годотер.
>какие слова часто использовал
Это неудобно в долгосрочной перспективе.
В идеале нужен ИИ, который держит в контексте не только весь проект, но и твои идеи/рассуждения.
>>5570
Какой же у VSCode дурацкий гуй... Откуда эта мода на боковое меню иконками? Виндувс же вроде уже отказалась от размещения таскбара сбоку экрана.
>>5572
Куда собрался? Ты теперь навсегда годотер.
>В идеале нужен ИИ
Rider несколько методов которые ты недавно использовал или часто используешь вроде бы держит всехда сверху.
>>5261 (OP)
Каково состояние годота в качестве инструмента разработки мобильных дрочилок на ведроид/айкос?
Каково состояние годота в качестве инструмента разработки мобильных дрочилок на ведроид/айкос?
>>5585
В vs code, боковую панель, можно переместить
В vs code, боковую панель, можно переместить
>>5594
Меня никто не спрашивал но я выскажу своё скромное мнение.
Вроде как есть но я сам лично не пробовал.
Но если чтото не будет работать. То можно портировать под веб html5.
А с него уже другими свистелками переделка можно на что угодно портировать.
Примеров успешных проэктов на js и ts фреймворках в мире полно.
Меня никто не спрашивал но я выскажу своё скромное мнение.
Вроде как есть но я сам лично не пробовал.
Но если чтото не будет работать. То можно портировать под веб html5.
А с него уже другими свистелками переделка можно на что угодно портировать.
Примеров успешных проэктов на js и ts фреймворках в мире полно.
>>5594
А вообще об этом наверно стоит беспокоиться только в последнюю очередь на любом движке. Ты хотя бы доживи до стадии релиза. А как сбилдить или портировать на куда тебе надо ты точно потом точно разберешься.
А вообще об этом наверно стоит беспокоиться только в последнюю очередь на любом движке. Ты хотя бы доживи до стадии релиза. А как сбилдить или портировать на куда тебе надо ты точно потом точно разберешься.
>>5594
Я пробовал, далеко не зашёл, но пока нормально.
Из хорошего:
- сборка APK на готовом шаблоне быстрая;
- UI работает практически так же, как на ПК;
- легко регулировать FPS даже в рантайме;
- легко настроить действие кнопки back.
Пока не пробовал, но хорошо:
- remote debug без установки всех файлов;
- поддержка мультитача, разных датчиков;
- можно включать разрешения галочкой;
- встроенная поддержка микротранзакций;
- можно собирать с нуля и это несложно.
Подводные:
- для многих фишек ОС нужна будет сборка с нуля;
- костные анимации Polygon не работают в GLES3;
- Vulkan пока слабо поддерживается смартфонами;
- запуск простой Vulkan игры долгий (3+ секунды);
- какие-то сложности с виртуальной клавиатурой;
- какие-то сложности с общей файловой системой.
Но моему смартфону уже почти 4 года, если что.
По экспорту смотри сам, в целом несложно:
https://docs.godotengine.org/en/stable/tutorials/export/exporting_for_android.html
https://docs.godotengine.org/en/stable/tutorials/export/android_gradle_build.html
>>5597
Билд под веб самый ограниченный и медленный. Примитивные игры лучше писать на голом JS, чем использовать движок, а тяжёлые игры в браузере типичной домохозяйки/ребёнка будут тормозить. Поддержка веба тут скорее маркетинговая уловка.
>>5598
Для мобильных игр это категорически неправильно. Мобильные игры должны всегда тестироваться на реальных устройствах с самого раннего прототипа, буквально когда у тебя только меню и квадратик по экрану ползает. Потому что геймплей на мобилках чрезвычайно завязан на сенсорный экран, плюс неудобное положение пользователя в окружающем пространстве, и оценить это всё возможно только плейтестом на реальном устройстве. Желательно нескольких с разными разрешениями экрана. Иначе получится фигня и придётся менять даже игровые механики. Поэтому порты с ПК редко взлетают - изначальный дизайн игры не заточен для мобилок. Особенно это важно для твоей первой мобильной игры, и для первой игры на новом для тебя движке.
Поэтому первым должен идти билд, а уже потом - разработка игровых механик, что будут на этом устройстве тестироваться так, как должен играть потенциальный игрок. Если игра, например, для расслабления в автобусе - нужно симулировать обстановку автобуса или тестировать в нём, чтоб убедиться в читаемости и удобстве интерфейса и геймплейных механик. Впрочем, если ты просто копипастишь успешную игру, это уже не так важно.
>Каково состояние годота в качестве инструмента разработки мобильных дрочилок на ведроид
Я пробовал, далеко не зашёл, но пока нормально.
Из хорошего:
- сборка APK на готовом шаблоне быстрая;
- UI работает практически так же, как на ПК;
- легко регулировать FPS даже в рантайме;
- легко настроить действие кнопки back.
Пока не пробовал, но хорошо:
- remote debug без установки всех файлов;
- поддержка мультитача, разных датчиков;
- можно включать разрешения галочкой;
- встроенная поддержка микротранзакций;
- можно собирать с нуля и это несложно.
Подводные:
- для многих фишек ОС нужна будет сборка с нуля;
- костные анимации Polygon не работают в GLES3;
- Vulkan пока слабо поддерживается смартфонами;
- запуск простой Vulkan игры долгий (3+ секунды);
- какие-то сложности с виртуальной клавиатурой;
- какие-то сложности с общей файловой системой.
Но моему смартфону уже почти 4 года, если что.
По экспорту смотри сам, в целом несложно:
https://docs.godotengine.org/en/stable/tutorials/export/exporting_for_android.html
https://docs.godotengine.org/en/stable/tutorials/export/android_gradle_build.html
>>5597
>портировать под веб html5
>свистелками переделка можно на что угодно
Билд под веб самый ограниченный и медленный. Примитивные игры лучше писать на голом JS, чем использовать движок, а тяжёлые игры в браузере типичной домохозяйки/ребёнка будут тормозить. Поддержка веба тут скорее маркетинговая уловка.
>>5598
>потом точно разберешься
Для мобильных игр это категорически неправильно. Мобильные игры должны всегда тестироваться на реальных устройствах с самого раннего прототипа, буквально когда у тебя только меню и квадратик по экрану ползает. Потому что геймплей на мобилках чрезвычайно завязан на сенсорный экран, плюс неудобное положение пользователя в окружающем пространстве, и оценить это всё возможно только плейтестом на реальном устройстве. Желательно нескольких с разными разрешениями экрана. Иначе получится фигня и придётся менять даже игровые механики. Поэтому порты с ПК редко взлетают - изначальный дизайн игры не заточен для мобилок. Особенно это важно для твоей первой мобильной игры, и для первой игры на новом для тебя движке.
Поэтому первым должен идти билд, а уже потом - разработка игровых механик, что будут на этом устройстве тестироваться так, как должен играть потенциальный игрок. Если игра, например, для расслабления в автобусе - нужно симулировать обстановку автобуса или тестировать в нём, чтоб убедиться в читаемости и удобстве интерфейса и геймплейных механик. Впрочем, если ты просто копипастишь успешную игру, это уже не так важно.
>>5594
Я пробовал, далеко не зашёл, но пока нормально.
Из хорошего:
- сборка APK на готовом шаблоне быстрая;
- UI работает практически так же, как на ПК;
- легко регулировать FPS даже в рантайме;
- легко настроить действие кнопки back.
Пока не пробовал, но хорошо:
- remote debug без установки всех файлов;
- поддержка мультитача, разных датчиков;
- можно включать разрешения галочкой;
- встроенная поддержка микротранзакций;
- можно собирать с нуля и это несложно.
Подводные:
- для многих фишек ОС нужна будет сборка с нуля;
- костные анимации Polygon не работают в GLES3;
- Vulkan пока слабо поддерживается смартфонами;
- запуск простой Vulkan игры долгий (3+ секунды);
- какие-то сложности с виртуальной клавиатурой;
- какие-то сложности с общей файловой системой.
Но моему смартфону уже почти 4 года, если что.
По экспорту смотри сам, в целом несложно:
https://docs.godotengine.org/en/stable/tutorials/export/exporting_for_android.html
https://docs.godotengine.org/en/stable/tutorials/export/android_gradle_build.html
>>5597
Билд под веб самый ограниченный и медленный. Примитивные игры лучше писать на голом JS, чем использовать движок, а тяжёлые игры в браузере типичной домохозяйки/ребёнка будут тормозить. Поддержка веба тут скорее маркетинговая уловка.
>>5598
Для мобильных игр это категорически неправильно. Мобильные игры должны всегда тестироваться на реальных устройствах с самого раннего прототипа, буквально когда у тебя только меню и квадратик по экрану ползает. Потому что геймплей на мобилках чрезвычайно завязан на сенсорный экран, плюс неудобное положение пользователя в окружающем пространстве, и оценить это всё возможно только плейтестом на реальном устройстве. Желательно нескольких с разными разрешениями экрана. Иначе получится фигня и придётся менять даже игровые механики. Поэтому порты с ПК редко взлетают - изначальный дизайн игры не заточен для мобилок. Особенно это важно для твоей первой мобильной игры, и для первой игры на новом для тебя движке.
Поэтому первым должен идти билд, а уже потом - разработка игровых механик, что будут на этом устройстве тестироваться так, как должен играть потенциальный игрок. Если игра, например, для расслабления в автобусе - нужно симулировать обстановку автобуса или тестировать в нём, чтоб убедиться в читаемости и удобстве интерфейса и геймплейных механик. Впрочем, если ты просто копипастишь успешную игру, это уже не так важно.
>Каково состояние годота в качестве инструмента разработки мобильных дрочилок на ведроид
Я пробовал, далеко не зашёл, но пока нормально.
Из хорошего:
- сборка APK на готовом шаблоне быстрая;
- UI работает практически так же, как на ПК;
- легко регулировать FPS даже в рантайме;
- легко настроить действие кнопки back.
Пока не пробовал, но хорошо:
- remote debug без установки всех файлов;
- поддержка мультитача, разных датчиков;
- можно включать разрешения галочкой;
- встроенная поддержка микротранзакций;
- можно собирать с нуля и это несложно.
Подводные:
- для многих фишек ОС нужна будет сборка с нуля;
- костные анимации Polygon не работают в GLES3;
- Vulkan пока слабо поддерживается смартфонами;
- запуск простой Vulkan игры долгий (3+ секунды);
- какие-то сложности с виртуальной клавиатурой;
- какие-то сложности с общей файловой системой.
Но моему смартфону уже почти 4 года, если что.
По экспорту смотри сам, в целом несложно:
https://docs.godotengine.org/en/stable/tutorials/export/exporting_for_android.html
https://docs.godotengine.org/en/stable/tutorials/export/android_gradle_build.html
>>5597
>портировать под веб html5
>свистелками переделка можно на что угодно
Билд под веб самый ограниченный и медленный. Примитивные игры лучше писать на голом JS, чем использовать движок, а тяжёлые игры в браузере типичной домохозяйки/ребёнка будут тормозить. Поддержка веба тут скорее маркетинговая уловка.
>>5598
>потом точно разберешься
Для мобильных игр это категорически неправильно. Мобильные игры должны всегда тестироваться на реальных устройствах с самого раннего прототипа, буквально когда у тебя только меню и квадратик по экрану ползает. Потому что геймплей на мобилках чрезвычайно завязан на сенсорный экран, плюс неудобное положение пользователя в окружающем пространстве, и оценить это всё возможно только плейтестом на реальном устройстве. Желательно нескольких с разными разрешениями экрана. Иначе получится фигня и придётся менять даже игровые механики. Поэтому порты с ПК редко взлетают - изначальный дизайн игры не заточен для мобилок. Особенно это важно для твоей первой мобильной игры, и для первой игры на новом для тебя движке.
Поэтому первым должен идти билд, а уже потом - разработка игровых механик, что будут на этом устройстве тестироваться так, как должен играть потенциальный игрок. Если игра, например, для расслабления в автобусе - нужно симулировать обстановку автобуса или тестировать в нём, чтоб убедиться в читаемости и удобстве интерфейса и геймплейных механик. Впрочем, если ты просто копипастишь успешную игру, это уже не так важно.
>>5594
Под айос не знаю, под андроид полет нормальный - 3 приложения за последние пару лет опубликовал в гугл плей без какого-либо геморроя, одна из приложений гуевая менюха-менеджер с low process mode. Сейчас делаю четвертую в 3д, по тестам на локальных девайсах тоже норм.
Под айос не знаю, под андроид полет нормальный - 3 приложения за последние пару лет опубликовал в гугл плей без какого-либо геморроя, одна из приложений гуевая менюха-менеджер с low process mode. Сейчас делаю четвертую в 3д, по тестам на локальных девайсах тоже норм.
>>5603
Спасибо, анон, именно поэтому я и спрашивал
>Для мобильных игр это категорически неправильно. Мобильные игры должны всегда тестироваться на реальных устройствах с самого раннего прототипа
Спасибо, анон, именно поэтому я и спрашивал
>>5594
Хуевая, лучше не стоит. Проблемы есть и с мультипоточностью, и с шейдерами, и с поддержкой взаимодействия с системой. Всё довольно криво и косо, юнити в этом плане подойдёт лучше.
Хуевая, лучше не стоит. Проблемы есть и с мультипоточностью, и с шейдерами, и с поддержкой взаимодействия с системой. Всё довольно криво и косо, юнити в этом плане подойдёт лучше.
>>5618
Пошел нахуй, лжец
Пошел нахуй, лжец
М>>5635
Неприятно, годотя?
Неприятно, годотя?
Годаны, два вопроса.
1. Вот в 2д есть нода CanvasGroup, чтобы за один дравколл отрисовывать всех её детей. А есть что-нибудь подобное для 3д?
2. Шейпы коллизий. Они по умолчанию рисуются только рёбрами, и не видно, особенно когда пытаешься подогнать к модельке. Как сделать, чтобы у коллижоншейпов отрисовывались ещё и грани?
1. Вот в 2д есть нода CanvasGroup, чтобы за один дравколл отрисовывать всех её детей. А есть что-нибудь подобное для 3д?
2. Шейпы коллизий. Они по умолчанию рисуются только рёбрами, и не видно, особенно когда пытаешься подогнать к модельке. Как сделать, чтобы у коллижоншейпов отрисовывались ещё и грани?
В прошлом треде я бухтел по поводу террейнов. Дескать, хули нету в ядре движка. Обещал попробовать плагины и блендер.
Итак. Единственный (в ассетлибе) террейн-плагин на гдскрипте, поддерживающий скульптинг и дырки, это Heightmap Terrain от Zylann. И у него есть две проблемы:
1. Ублюдский скульптинг. Прямо вот как будто автор сам им не пользуется. Точечное аккуратное редактирование отдельными кликами невозможно, гизмо рисуется неправильно, настройки кисти в виде полосок прокрутки без текстового поля.
2. Всратая работа с текстурами. Сука ну почему нельзя StandardMaterial3D использовать? Ну нахуя эти вот извращения с запихиванием бампмапы в альфу текстуры альбедо? Или это какое-то принципиальное ограничение террейнов?
Все остальные плагины либо на плюсах (при экспорте ждёт ебля с пересборкой темплейта), либо на б-гомерзком шарпе.
И я всё ещё считаю, что движок, стремящийся в нишу тридэ, должен иметь встроенный террейн. И старфилдовское "модами допилят" тут не прокатит - мододелы делают только то, что надо лично им, ровно так, как надо им, а если тебе не нравится - ну сделай сам. И отмазка про малую востребованность тоже мимо: среди трёхмерных игр таких, которым террейны не нужны, меньшинство; а поддержку вулкана, а рендерер для чего пилили, чтобы так и вариться дальше в двадэ?
Карочи аргх.
А в блендере я потыкался и понял, что в годоте левелдизайнить гораздо комфортнее. Блендер охуенен для моделирования, но на больших сценах всё же Годот и шустрее, и удобнее. Воттаквот.
Итак. Единственный (в ассетлибе) террейн-плагин на гдскрипте, поддерживающий скульптинг и дырки, это Heightmap Terrain от Zylann. И у него есть две проблемы:
1. Ублюдский скульптинг. Прямо вот как будто автор сам им не пользуется. Точечное аккуратное редактирование отдельными кликами невозможно, гизмо рисуется неправильно, настройки кисти в виде полосок прокрутки без текстового поля.
2. Всратая работа с текстурами. Сука ну почему нельзя StandardMaterial3D использовать? Ну нахуя эти вот извращения с запихиванием бампмапы в альфу текстуры альбедо? Или это какое-то принципиальное ограничение террейнов?
Все остальные плагины либо на плюсах (при экспорте ждёт ебля с пересборкой темплейта), либо на б-гомерзком шарпе.
И я всё ещё считаю, что движок, стремящийся в нишу тридэ, должен иметь встроенный террейн. И старфилдовское "модами допилят" тут не прокатит - мододелы делают только то, что надо лично им, ровно так, как надо им, а если тебе не нравится - ну сделай сам. И отмазка про малую востребованность тоже мимо: среди трёхмерных игр таких, которым террейны не нужны, меньшинство; а поддержку вулкана, а рендерер для чего пилили, чтобы так и вариться дальше в двадэ?
Карочи аргх.
А в блендере я потыкался и понял, что в годоте левелдизайнить гораздо комфортнее. Блендер охуенен для моделирования, но на больших сценах всё же Годот и шустрее, и удобнее. Воттаквот.
>>5651
Молодец, возьми с полки пирожок.
Я хотел написать, >сделай сам, это опенсорц< но вспомнил, что деланье ты называешь
Поэтому полка, поэтому пирожок.
> считаю, что движок
> должен иметь встроенный террейн
Молодец, возьми с полки пирожок.
Я хотел написать, >сделай сам, это опенсорц< но вспомнил, что деланье ты называешь
> ебля с пересборкой темплейта
Поэтому полка, поэтому пирожок.
Беру свои слова назад. Шейдеры красота неописуемая.
Вот только как их самому писать, это какой там язык используется?
Вот только как их самому писать, это какой там язык используется?
>>5658
бред
бред
>>5661
Скоро на slang перейдут.
Скоро на slang перейдут.
Привет, я друг.
Меня тут три месяца не было. Скажи, на Годовом уже появились игры (ну, знаешь, такие программки, в которые играют больше 1000 человек)?
Меня тут три месяца не было. Скажи, на Годовом уже появились игры (ну, знаешь, такие программки, в которые играют больше 1000 человек)?
>>5671
К сожалению есть только недоделанный кал. Это же Годо, у них сейчас другая задача, вместо создания движка для игр они собирают донаты с ГЛГБТК++ фондов.
К сожалению есть только недоделанный кал. Это же Годо, у них сейчас другая задача, вместо создания движка для игр они собирают донаты с ГЛГБТК++ фондов.
Порепортил каникульного движкосрачера
>>5261 (OP)
Вот в чем дело, загружаю скрипт в коде таким образом
load(путь к скрипту).new(аргумент), но получаю ошибку, что мой скрипт не принимает аргументы.
При этом в скрипте есть _init, который принимает аргумент и если сделать этот скрипт классом, то все работает, но при использовании load выскакивает ошибка.
Что я делаю не так?
Вот в чем дело, загружаю скрипт в коде таким образом
load(путь к скрипту).new(аргумент), но получаю ошибку, что мой скрипт не принимает аргументы.
При этом в скрипте есть _init, который принимает аргумент и если сделать этот скрипт классом, то все работает, но при использовании load выскакивает ошибка.
Что я делаю не так?
>>5730
Что? Я, вроде, в актуальный тред пишу
Что? Я, вроде, в актуальный тред пишу
Поясните.
Вот я делаю StandardMaterial3D -> преобразовать в ShaderMaterial. Дальше смотрю код этого шейдера и вижу, что карта высот (heightmap_texture) в нём не используется вообще. Хотя в исходном материале она была задана.
Шозанах? Я как раз эту часть шейдера хотел поменять, а её внезапно нету.
Вот я делаю StandardMaterial3D -> преобразовать в ShaderMaterial. Дальше смотрю код этого шейдера и вижу, что карта высот (heightmap_texture) в нём не используется вообще. Хотя в исходном материале она была задана.
Шозанах? Я как раз эту часть шейдера хотел поменять, а её внезапно нету.
29 Кб, 807x212>>5726
Объект уже существует и просто меняет скрипт у себя. У него не отрабатывает init и аргументы оттуда игнорируются. https://docs.godotengine.org/en/stable/classes/class_object.html#class-object-private-method-init
Чтобы инстанцировать с аргументами, тебе нужно создавать объекты, а не грузить скрипт в существующие.
1. В скрипте делаешь class_name ClassName
2. В целевом участке кода:
Тока так.
> загружаю скрипт в коде таким образом
> load
Объект уже существует и просто меняет скрипт у себя. У него не отрабатывает init и аргументы оттуда игнорируются. https://docs.godotengine.org/en/stable/classes/class_object.html#class-object-private-method-init
Чтобы инстанцировать с аргументами, тебе нужно создавать объекты, а не грузить скрипт в существующие.
1. В скрипте делаешь class_name ClassName
2. В целевом участке кода:
> var cn := ClassName.new(arg)
> add_child(cn)
Тока так.
>>5724
Опять управлять тянкой, которую насилуют в случае поражения. То есть фап-контент противоречит игре.
Почему так мало игр, где ТЫ насилуешь монстров? И побеждаешь в бою, если изнасилуешь правильно.
>Годнота
Опять управлять тянкой, которую насилуют в случае поражения. То есть фап-контент противоречит игре.
Почему так мало игр, где ТЫ насилуешь монстров? И побеждаешь в бою, если изнасилуешь правильно.
>>5646
Не, там другая суть. Сначала твои ноды рендерятся по отдельности, а потом CanvasGroup копирует результат, применяя к нему закреплённый на нём шейдер.
В смысле, чтобы применить эффект для копипасты? Конечно. Используй SubViewport, там transparent_bg установи true, чтобы фон был прозрачный. Текстуру обработаешь как обычно с 2D шейдерами. Вроде бы можно как-то вытащить отдельно буфер глубины...
Ставь камеру ортогонально спереди/сверху/сбоку. Будет намного проще, чем с перспективным видом. Хоткеи +/- как в блендере: на клавишах нумпада.
Создай тестовый MeshInstance с примитивом. У сфер, капсул, цилиндров и параллелепипедов одинаковые параметры (должны быть). Как настроишь, значения можно скопировать, кликнув в инспекторе правой кнопкой мыши (копирует с учётом типа поля, т.е. скопированный Vector3 вставится в любой Vector3).
>CanvasGroup, чтобы за один дравколл отрисовывать
Не, там другая суть. Сначала твои ноды рендерятся по отдельности, а потом CanvasGroup копирует результат, применяя к нему закреплённый на нём шейдер.
>А есть что-нибудь подобное для 3д?
В смысле, чтобы применить эффект для копипасты? Конечно. Используй SubViewport, там transparent_bg установи true, чтобы фон был прозрачный. Текстуру обработаешь как обычно с 2D шейдерами. Вроде бы можно как-то вытащить отдельно буфер глубины...
>Шейпы коллизий
>пытаешься подогнать к модельке
Ставь камеру ортогонально спереди/сверху/сбоку. Будет намного проще, чем с перспективным видом. Хоткеи +/- как в блендере: на клавишах нумпада.
>отрисовывались ещё и грани
Создай тестовый MeshInstance с примитивом. У сфер, капсул, цилиндров и параллелепипедов одинаковые параметры (должны быть). Как настроишь, значения можно скопировать, кликнув в инспекторе правой кнопкой мыши (копирует с учётом типа поля, т.е. скопированный Vector3 вставится в любой Vector3).
>>5758
А если сделать так?
Так должно работать...
>>5726
Не знаю, попробуй сделать так:
Чтобы понять, что у тебя там загрузилось.
А зачем грузишь скрипты через load? Моддинг?
>Объект уже существует
А если сделать так?
>var script: Script = load("res://script.gd")
>var object = script.new(args)
Так должно работать...
>>5726
>ошибку, что мой скрипт не принимает аргументы
Не знаю, попробуй сделать так:
>print(load("res://script.gd"))
Чтобы понять, что у тебя там загрузилось.
А зачем грузишь скрипты через load? Моддинг?
>>5736
Попробуй выключить uv1_triplanar:
https://docs.godotengine.org/en/stable/classes/class_basematerial3d.html#class-basematerial3d-property-heightmap-enabled
Если что-то из стандартных функций не нужно, Godot генерирует облегченную версию шейдера.
Попробуй выключить uv1_triplanar:
https://docs.godotengine.org/en/stable/classes/class_basematerial3d.html#class-basematerial3d-property-heightmap-enabled
>Note: Height mapping is not supported if triplanar mapping is used on the same material. The value of heightmap_enabled will be ignored if uv1_triplanar is enabled.
Если что-то из стандартных функций не нужно, Godot генерирует облегченную версию шейдера.
>>5651
Помню, тебе какая-то трава нужна была вдоль дорог.
Скульптинг... Травы? А не много ли тебе нужно?
...травы? Травы ведь? Вдоль дороги, да?
Это нужно, чтобы оптимизировать рендеринг.
Куда StandardMaterial3D засунешь, если у тебя там несколько разных текстур альбедо? У тебя текстура травы, земли, камней, песка. Их нужно смешивать в разных пропорциях в зависимости от того, что там нарисовано на твоём ландшафте. Для этого нужен специальный шейдер, а не тот, что в Godot.
Если тебе достаточно одной текстуры травы, то тебе вообще не нужен никакой ландшафт. Просто слепи модельку травы в блендере и импортируй как меш.
Если плагин типа такого, то сборка не нужна:
https://github.com/TokisanGames/Terrain3D
Т.к. там уже готовые .dll/.so в папке /bin лежат.
А если разработчики Godot Engine его сделают?
Ага. А если новичок попытается сделать копание? Классические террейны сейчас мало используются. Посмотри на количество 3D игр на мобилках... Там летающие в пространстве меши, иногда GridMap. А большинство игр с террейном - это клоны майна, а значит, воксельные со сглаживанием.
Никто тебя не заставляет весь уровень в блендере лепить. Слепи свою траву там, импортируй в Godot.
>прошлом треде я бухтел
Помню, тебе какая-то трава нужна была вдоль дорог.
>Ублюдский скульптинг
Скульптинг... Травы? А не много ли тебе нужно?
>Точечное аккуратное редактирование отдельными кликами
...травы? Травы ведь? Вдоль дороги, да?
>Всратая работа с текстурами
Это нужно, чтобы оптимизировать рендеринг.
>нельзя StandardMaterial3D использовать?
Куда StandardMaterial3D засунешь, если у тебя там несколько разных текстур альбедо? У тебя текстура травы, земли, камней, песка. Их нужно смешивать в разных пропорциях в зависимости от того, что там нарисовано на твоём ландшафте. Для этого нужен специальный шейдер, а не тот, что в Godot.
Если тебе достаточно одной текстуры травы, то тебе вообще не нужен никакой ландшафт. Просто слепи модельку травы в блендере и импортируй как меш.
>ебля с пересборкой темплейта
Если плагин типа такого, то сборка не нужна:
https://github.com/TokisanGames/Terrain3D
Т.к. там уже готовые .dll/.so в папке /bin лежат.
>тут не прокатит - мододелы делают только то, что надо лично им, ровно так, как надо им
А если разработчики Godot Engine его сделают?
>среди трёхмерных игр таких, которым террейны не нужны, меньшинство
Ага. А если новичок попытается сделать копание? Классические террейны сейчас мало используются. Посмотри на количество 3D игр на мобилках... Там летающие в пространстве меши, иногда GridMap. А большинство игр с террейном - это клоны майна, а значит, воксельные со сглаживанием.
>в блендере
>левелдизайнить
Никто тебя не заставляет весь уровень в блендере лепить. Слепи свою траву там, импортируй в Godot.
>>5651
Помню, тебе какая-то трава нужна была вдоль дорог.
Скульптинг... Травы? А не много ли тебе нужно?
...травы? Травы ведь? Вдоль дороги, да?
Это нужно, чтобы оптимизировать рендеринг.
Куда StandardMaterial3D засунешь, если у тебя там несколько разных текстур альбедо? У тебя текстура травы, земли, камней, песка. Их нужно смешивать в разных пропорциях в зависимости от того, что там нарисовано на твоём ландшафте. Для этого нужен специальный шейдер, а не тот, что в Godot.
Если тебе достаточно одной текстуры травы, то тебе вообще не нужен никакой ландшафт. Просто слепи модельку травы в блендере и импортируй как меш.
Если плагин типа такого, то сборка не нужна:
https://github.com/TokisanGames/Terrain3D
Т.к. там уже готовые .dll/.so в папке /bin лежат.
А если разработчики Godot Engine его сделают?
Ага. А если новичок попытается сделать копание? Классические террейны сейчас мало используются. Посмотри на количество 3D игр на мобилках... Там летающие в пространстве меши, иногда GridMap. А большинство игр с террейном - это клоны майна, а значит, воксельные со сглаживанием.
Никто тебя не заставляет весь уровень в блендере лепить. Слепи свою траву там, импортируй в Godot.
>прошлом треде я бухтел
Помню, тебе какая-то трава нужна была вдоль дорог.
>Ублюдский скульптинг
Скульптинг... Травы? А не много ли тебе нужно?
>Точечное аккуратное редактирование отдельными кликами
...травы? Травы ведь? Вдоль дороги, да?
>Всратая работа с текстурами
Это нужно, чтобы оптимизировать рендеринг.
>нельзя StandardMaterial3D использовать?
Куда StandardMaterial3D засунешь, если у тебя там несколько разных текстур альбедо? У тебя текстура травы, земли, камней, песка. Их нужно смешивать в разных пропорциях в зависимости от того, что там нарисовано на твоём ландшафте. Для этого нужен специальный шейдер, а не тот, что в Godot.
Если тебе достаточно одной текстуры травы, то тебе вообще не нужен никакой ландшафт. Просто слепи модельку травы в блендере и импортируй как меш.
>ебля с пересборкой темплейта
Если плагин типа такого, то сборка не нужна:
https://github.com/TokisanGames/Terrain3D
Т.к. там уже готовые .dll/.so в папке /bin лежат.
>тут не прокатит - мододелы делают только то, что надо лично им, ровно так, как надо им
А если разработчики Godot Engine его сделают?
>среди трёхмерных игр таких, которым террейны не нужны, меньшинство
Ага. А если новичок попытается сделать копание? Классические террейны сейчас мало используются. Посмотри на количество 3D игр на мобилках... Там летающие в пространстве меши, иногда GridMap. А большинство игр с террейном - это клоны майна, а значит, воксельные со сглаживанием.
>в блендере
>левелдизайнить
Никто тебя не заставляет весь уровень в блендере лепить. Слепи свою траву там, импортируй в Godot.
>>5758
Но я не меняю никакой скрипт, я просто загружаю новый и передаю ссылку на него в переменную.
Я про это знаю, но это сильно забивает автодополнение. Десяток лишних классов, экземпляры которых нужно создавать не так уж и часто, мне не нужны в автодополнение.
>>5762
Тоже самое. Ошибка, что new не принимает аргументы.
Загрузился этот самый скрипт. Я могу с ним нормально работать, просто я не могу передать аргументы в конструктор.
Не, не для этого. Просто у некоторых айтемов, которые у игрока в инвентаре, должны быть уникальные функции, сначала я делал это через class_name, но потом меня стало напрягать замусореность автодополнения.
Но я не меняю никакой скрипт, я просто загружаю новый и передаю ссылку на него в переменную.
>1. В скрипте делаешь class_name ClassName
Я про это знаю, но это сильно забивает автодополнение. Десяток лишних классов, экземпляры которых нужно создавать не так уж и часто, мне не нужны в автодополнение.
>>5762
>var script: Script = load("res://script.gd")
>var object = script.new(args)
Тоже самое. Ошибка, что new не принимает аргументы.
>Чтобы понять, что у тебя там загрузилось.
Загрузился этот самый скрипт. Я могу с ним нормально работать, просто я не могу передать аргументы в конструктор.
>А зачем грузишь скрипты через load? Моддинг?
Не, не для этого. Просто у некоторых айтемов, которые у игрока в инвентаре, должны быть уникальные функции, сначала я делал это через class_name, но потом меня стало напрягать замусореность автодополнения.
192 Кб, 750x750>>5792
Ебать пиздец.
Просто пиздец.
Я не знаю, чему тут еще помочь.
Автодополнение у него замусорено, ёб твою мать. Это толстота такая?
> меня стало напрягать замусореность автодополнения
Ебать пиздец.
Просто пиздец.
Я не знаю, чему тут еще помочь.
Автодополнение у него замусорено, ёб твою мать. Это толстота такая?
>>5646
Если ты про батчинг, то для 3-ки есть Mesh Merge (вручную/скриптами). https://github.com/godotengine/godot/pull/57661 Для одинаковых объектов MeshInstance. А в 4-ке это вроде не так важно, там автоматический mesh instancer, а для разных дроуколлы дешевле, так что тут стоит вообще проверить, надо ли с этим париться.
Если же ты про порядок рендера, то для 3д есть render priority.
>Вот в 2д есть нода CanvasGroup, чтобы за один дравколл отрисовывать всех её детей. А есть что-нибудь подобное для 3д?
Если ты про батчинг, то для 3-ки есть Mesh Merge (вручную/скриптами). https://github.com/godotengine/godot/pull/57661 Для одинаковых объектов MeshInstance. А в 4-ке это вроде не так важно, там автоматический mesh instancer, а для разных дроуколлы дешевле, так что тут стоит вообще проверить, надо ли с этим париться.
Если же ты про порядок рендера, то для 3д есть render priority.
>>5809
Поэтому либо все один аки человек-оркестр плюс свободные ассеты, либо плоти людям. Ситуация типичная, не переживай, справишься. Геймлпей энивей важнее арта.
Поэтому либо все один аки человек-оркестр плюс свободные ассеты, либо плоти людям. Ситуация типичная, не переживай, справишься. Геймлпей энивей важнее арта.
>>5934
Все, нашел в доке
Все, нашел в доке
>>5651
Оптимизация шейдера. В доках же описано почему. https://hterrain-plugin.readthedocs.io/en/latest/#packing-textures-manually
Чтение текстуры в шейдере - дорогая операция. Так бы пришлось читать 2 текстуры, притом что из первой используется только RGB (3 из 4 каналов), а неровности - 1 канал из 4. Логично объединить их 3+1.
>Ну нахуя эти вот извращения с запихиванием бампмапы в альфу текстуры альбедо? Или это какое-то принципиальное ограничение террейнов?
Оптимизация шейдера. В доках же описано почему. https://hterrain-plugin.readthedocs.io/en/latest/#packing-textures-manually
Чтение текстуры в шейдере - дорогая операция. Так бы пришлось читать 2 текстуры, притом что из первой используется только RGB (3 из 4 каналов), а неровности - 1 канал из 4. Логично объединить их 3+1.
>>5896
Этот человек пытался выжать максимум выгоды, ведя сразу три проекта с одними и теми же спрайтами. Если кому интересно, могу скинуть ссылку на Discord-сервер, где всё это задокументировано. Возможно, кому-то пригодится, чтобы в будущем не наступить на те же грабли.
Я, между тем, две недели работал, как одержимый: по 12 часов в день, с утра до вечера, вкладывая в проект всю душу.
Теперь даже не знаю, что делать. Идея была его, спрайты тоже его. Перерисовывать? Ну, честно говоря, совсем не хочется. У меня были планы выпустить игру в Steam в раннем доступе, довести её до ума и сделать по-настоящему крутой продукт. А ему, как оказалось, важнее было всё сделать быстро и по-своему, но при этом он ни разу об этом прямо не сказал.
Позже выяснилось, что он крайне болезненно реагирует на любую критику. Начал придираться буквально ко всему, без причины, просто из-за собственного настроения.
Этот человек пытался выжать максимум выгоды, ведя сразу три проекта с одними и теми же спрайтами. Если кому интересно, могу скинуть ссылку на Discord-сервер, где всё это задокументировано. Возможно, кому-то пригодится, чтобы в будущем не наступить на те же грабли.
Я, между тем, две недели работал, как одержимый: по 12 часов в день, с утра до вечера, вкладывая в проект всю душу.
Теперь даже не знаю, что делать. Идея была его, спрайты тоже его. Перерисовывать? Ну, честно говоря, совсем не хочется. У меня были планы выпустить игру в Steam в раннем доступе, довести её до ума и сделать по-настоящему крутой продукт. А ему, как оказалось, важнее было всё сделать быстро и по-своему, но при этом он ни разу об этом прямо не сказал.
Позже выяснилось, что он крайне болезненно реагирует на любую критику. Начал придираться буквально ко всему, без причины, просто из-за собственного настроения.
>>5975
Нахуй с таким вообще связываться, он потом тупо тебя засудит.
> Идея была его, спрайты тоже его.
Нахуй с таким вообще связываться, он потом тупо тебя засудит.
>>5977
Если честно, я бы хотел, чтобы кто-нибудь почитал чат дискорда. Мне интересно ваше мнение, чтобы понять, в чём я был неправ.
Если честно, я бы хотел, чтобы кто-нибудь почитал чат дискорда. Мне интересно ваше мнение, чтобы понять, в чём я был неправ.
>>5977
Ну смотри, допустим идея не копирайтится. Но есть ли у тебя договор с ним на передачу прав на спрайты?
Ну смотри, допустим идея не копирайтится. Но есть ли у тебя договор с ним на передачу прав на спрайты?
>>5760
Ты перепутал с BackBufferCopy, буквально его описал.
https://docs.godotengine.org/en/stable/classes/class_canvasgroup.html
Батчинг крч.
Не работает с более-менее сложными формами, становится непонятно, что там и как.
Вот это годный воркароунд, спасибо.
>CanvasGroup
Ты перепутал с BackBufferCopy, буквально его описал.
https://docs.godotengine.org/en/stable/classes/class_canvasgroup.html
>Merges several 2D nodes into a single draw operation.
Батчинг крч.
>Ставь камеру ортогонально
Не работает с более-менее сложными формами, становится непонятно, что там и как.
>Создай тестовый MeshInstance с примитивом
Вот это годный воркароунд, спасибо.
>>5983
Да не хочу продолжать с его спрайтами, их там было совсем немного: всего пара мобов с одной анимацией, бонус и спавны.
Да не хочу продолжать с его спрайтами, их там было совсем немного: всего пара мобов с одной анимацией, бонус и спавны.
>>5975
Я бы пересобрал проект со свободными спрайтами, на итче хватает, выложил бы что получилось и двигался дальше получив экспириенс. Потому что, будем честны, ваша первая игра, даже если бы вы не разосрались, нихуя не взлетела бы. Как и вторая. И третья.
И советую снять розовые очки, иначе геймдев тебя пережует и выплюнет. Что, впрочем, уже и происходит. Дискорд ваш читать лень. Просто продолжай работать.
Я бы пересобрал проект со свободными спрайтами, на итче хватает, выложил бы что получилось и двигался дальше получив экспириенс. Потому что, будем честны, ваша первая игра, даже если бы вы не разосрались, нихуя не взлетела бы. Как и вторая. И третья.
>всю душу
>по-настоящему крутой продукт
И советую снять розовые очки, иначе геймдев тебя пережует и выплюнет. Что, впрочем, уже и происходит. Дискорд ваш читать лень. Просто продолжай работать.
25 Кб, 777x392>>5765
Нет. Участки неровной земли между асфальтированными дорогами и домами в городе. Щас выгляни в окно и посмотри на землю во дворе. Вот оно и надо. Точечно редактировать - чтобы подогнать к тротуарам, бордюрам, заборам и стенам.
А как раз именно трава НЕ нужна.
Понян. >>5966 понятно объяснил.
Ну, сам уровень и заставляет. Террейн, дороги, бордюры дома - основа, в общем.
Ну хуй знает, мне как-то казалось всегда, что кусок плоскости, гнутый субдивизией с дисплейсментом, - это простой и дешёвый способ придать живости и естественности любой карте.
Олсо, вылезла ещё одна проблема террейнов-плагинов. Пикрил, блядский уголок. Как от него избавиться - хз. Судя по всему, никак, это ограничение логики прорезания дыр.
Я от безнадёги стал курить, как завелосипедить свой простенький террейн, и чот прихуел. Шейдером?! Шейдером сука. Вот эту абсолютно статичную хуйню, которая делается ровно один раз и никогда более (в рантайме) не меняется - вот её изгибают шейдером?! Но зачем, а главное нахуя? Это ж бред, считать такое каждый кадр - это хуже NFT. Походу, запекание шейпа - это утерянная технология древних.
>трава
Нет. Участки неровной земли между асфальтированными дорогами и домами в городе. Щас выгляни в окно и посмотри на землю во дворе. Вот оно и надо. Точечно редактировать - чтобы подогнать к тротуарам, бордюрам, заборам и стенам.
А как раз именно трава НЕ нужна.
>оптимизировать рендеринг
Понян. >>5966 понятно объяснил.
>А если разработчики Godot Engine его сделают?
>если
>Никто тебя не заставляет весь уровень в блендере лепить
Ну, сам уровень и заставляет. Террейн, дороги, бордюры дома - основа, в общем.
>Классические террейны сейчас мало используются
Ну хуй знает, мне как-то казалось всегда, что кусок плоскости, гнутый субдивизией с дисплейсментом, - это простой и дешёвый способ придать живости и естественности любой карте.
Олсо, вылезла ещё одна проблема террейнов-плагинов. Пикрил, блядский уголок. Как от него избавиться - хз. Судя по всему, никак, это ограничение логики прорезания дыр.
Я от безнадёги стал курить, как завелосипедить свой простенький террейн, и чот прихуел. Шейдером?! Шейдером сука. Вот эту абсолютно статичную хуйню, которая делается ровно один раз и никогда более (в рантайме) не меняется - вот её изгибают шейдером?! Но зачем, а главное нахуя? Это ж бред, считать такое каждый кадр - это хуже NFT. Походу, запекание шейпа - это утерянная технология древних.
363 Кб, 1337x845>>6014
Шейдер - это то, что рисует материалы. Они и так везде используются в рендере. Запекание в zylann hterrain есть, но смысл террейна то в динамических лодах - когда детально рисуется та поверхность, что ближе к камере. В zylann hterrain запекание есть, там будет меш на выходе, но движку потом придется рисовать его целиком.
Шейдер - это то, что рисует материалы. Они и так везде используются в рендере. Запекание в zylann hterrain есть, но смысл террейна то в динамических лодах - когда детально рисуется та поверхность, что ближе к камере. В zylann hterrain запекание есть, там будет меш на выходе, но движку потом придется рисовать его целиком.
>>5989 пара спрайтов - это считай ничего, просто выкинь их и все.
>>5813
Не он один от этого страдает:
https://github.com/godotengine/godot-proposals/issues/1566
>>5792
Ну, похоже на баг, т.к. по идее должно работать.
А тебе они действительно нужны в _init()?
Можно попробовать цеплять к ним ноду...
Добавляй префиксы, будет как-то так:
И т.д. Это, конечно, костыль, но лучше, чем ничего.
С рабочими name space было бы как-то так:
Так что особой разницы в ощущениях как бы и нет.
>Это толстота такая?
Не он один от этого страдает:
https://github.com/godotengine/godot-proposals/issues/1566
>👍142 🚀29 👀25
>>5792
>Ошибка, что new не принимает аргументы.
Ну, похоже на баг, т.к. по идее должно работать.
>не могу передать аргументы в конструктор.
А тебе они действительно нужны в _init()?
>должны быть уникальные функции
Можно попробовать цеплять к ним ноду...
>напрягать замусореность автодополнения.
Добавляй префиксы, будет как-то так:
>class_name Inventory
>class_name InventoryItem
>class_name InventoryItemHint
>class_name InventoryItemEffect
>class_name InventoryItemEdible
>class_name InventoryItemTool
>class_name InventoryItemWeapon
>class_name InventoryItemThrowable
И т.д. Это, конечно, костыль, но лучше, чем ничего.
С рабочими name space было бы как-то так:
>class_name Inventory.Item.Effect
Так что особой разницы в ощущениях как бы и нет.
>>5813
Не он один от этого страдает:
https://github.com/godotengine/godot-proposals/issues/1566
>>5792
Ну, похоже на баг, т.к. по идее должно работать.
А тебе они действительно нужны в _init()?
Можно попробовать цеплять к ним ноду...
Добавляй префиксы, будет как-то так:
И т.д. Это, конечно, костыль, но лучше, чем ничего.
С рабочими name space было бы как-то так:
Так что особой разницы в ощущениях как бы и нет.
>Это толстота такая?
Не он один от этого страдает:
https://github.com/godotengine/godot-proposals/issues/1566
>👍142 🚀29 👀25
>>5792
>Ошибка, что new не принимает аргументы.
Ну, похоже на баг, т.к. по идее должно работать.
>не могу передать аргументы в конструктор.
А тебе они действительно нужны в _init()?
>должны быть уникальные функции
Можно попробовать цеплять к ним ноду...
>напрягать замусореность автодополнения.
Добавляй префиксы, будет как-то так:
>class_name Inventory
>class_name InventoryItem
>class_name InventoryItemHint
>class_name InventoryItemEffect
>class_name InventoryItemEdible
>class_name InventoryItemTool
>class_name InventoryItemWeapon
>class_name InventoryItemThrowable
И т.д. Это, конечно, костыль, но лучше, чем ничего.
С рабочими name space было бы как-то так:
>class_name Inventory.Item.Effect
Так что особой разницы в ощущениях как бы и нет.
>>5986
Батчинг в 2D происходит автоматически, и это не то.
Это ты невнимательно читаешь.
Читай внимательно:
Т.е. эта нода каждый кадр копирует с экрана...
Пример того, для чего нужен CanvasGroup:
https://www.reddit.com/r/godot/comments/xrfkc5/
>Батчинг крч.
Батчинг в 2D происходит автоматически, и это не то.
>Ты перепутал с BackBufferCopy
Это ты невнимательно читаешь.
Читай внимательно:
>The CanvasGroup uses a custom shader to read from the backbuffer to draw its children.
>To duplicate the behavior of the builtin shader in a custom Shader use the following:
>void fragment() {
>vec4 c = textureLod(screen_texture, SCREEN_UV, 0.0);
Т.е. эта нода каждый кадр копирует с экрана...
Пример того, для чего нужен CanvasGroup:
https://www.reddit.com/r/godot/comments/xrfkc5/
>>6025
А, нет, копирует из "back buffer", которых у приложения может быть несколько. Но вот вопрос, как часто этот буфер обновляется? Когда ноды двигаются? Каждый кадр? Батчинг имеет смысл только если уменьшает количество вызовов отрисовки, а если каждый кадр рендерить в задний буфер - будет больше вызовов.
Например, если использовать это:
https://docs.godotengine.org/en/stable/classes/class_subviewport.html#enum-subviewport-updatemode
Тогда у тебя вместо 9000 вызовов будет только 1 - копирование готовой картинки из ViewportTexture.
Но если у тебя стоит:
У тебя будет 9001 вызов отрисовки: сначала сами объекты, а потом их копирование из текстуры.
Поэтому я сомневаюсь на счёт роли CanvasGroup.
>копирует
А, нет, копирует из "back buffer", которых у приложения может быть несколько. Но вот вопрос, как часто этот буфер обновляется? Когда ноды двигаются? Каждый кадр? Батчинг имеет смысл только если уменьшает количество вызовов отрисовки, а если каждый кадр рендерить в задний буфер - будет больше вызовов.
Например, если использовать это:
https://docs.godotengine.org/en/stable/classes/class_subviewport.html#enum-subviewport-updatemode
>UpdateMode UPDATE_ONCE = 1
>Update the render target once, then switch to UPDATE_DISABLED.
Тогда у тебя вместо 9000 вызовов будет только 1 - копирование готовой картинки из ViewportTexture.
Но если у тебя стоит:
>UPDATE_WHEN_VISIBLE
>UPDATE_WHEN_PARENT_VISIBLE
>UPDATE_ALWAYS
У тебя будет 9001 вызов отрисовки: сначала сами объекты, а потом их копирование из текстуры.
Поэтому я сомневаюсь на счёт роли CanvasGroup.
>>6026
Я прочитал твою портянку. Тебя конечно тяжело читать. Ну да ладно.
Вот поэтому и нужен договор с художниками. Причем с прописанными эксклюзивными правами, чтобы арт и персонажей нельзя было использовать где-то еще.
Договоры на то и нужны. Поскольку вы не смогли определиться кто из вас главный (да-да, из двоих кто-то главнее).
Я прочитал твою портянку. Тебя конечно тяжело читать. Ну да ладно.
Вот поэтому и нужен договор с художниками. Причем с прописанными эксклюзивными правами, чтобы арт и персонажей нельзя было использовать где-то еще.
Договоры на то и нужны. Поскольку вы не смогли определиться кто из вас главный (да-да, из двоих кто-то главнее).
>>6029
Спасибо за совет
Спасибо за совет
>>6026
Ты только что случайно (пункт 1 правил Двача):
Чтоб понимали, это алкаш-гомофоб из >>981122 (OP)
В переписке объективные претензии к тебе. На его месте я б с тобой разорвал контакт раньше, молча.
>>5975
Это нормальная практика на фрилансе. Юридически проблемы нет, ведь это его проект, а не твой личный.
Это ты по настроению всё делаешь. Не проецируй проблемы со своими гомоэмоциями на других.
>>6029
Не защищай этого токсика - получил, что заслужил. Неожиданно, что кто-то с ним вообще связался.
Ты только что случайно (пункт 1 правил Двача):
>УК РФ Статья 138
>УК Украины Статья 163
Чтоб понимали, это алкаш-гомофоб из >>981122 (OP)
В переписке объективные претензии к тебе. На его месте я б с тобой разорвал контакт раньше, молча.
>>5975
>три проекта с одними и теми же спрайтами.
Это нормальная практика на фрилансе. Юридически проблемы нет, ведь это его проект, а не твой личный.
>Начал придираться буквально ко всему, без причины, просто из-за собственного настроения.
Это ты по настроению всё делаешь. Не проецируй проблемы со своими гомоэмоциями на других.
>>6029
Не защищай этого токсика - получил, что заслужил. Неожиданно, что кто-то с ним вообще связался.
>>6029
Я, кстати, вообще нашел его случайно по скриншоту с Двача, а потом нашел сайт.
https://gamin.me/posts/22832
Как выяснилось, до меня он уже с кем-то не сработался, потому что скидывал другую демку в тг.
И потом оказалось, что он работал еще с двумя людьми параллельно со мной.
То есть, он нашел как минимум четырех "лохов", включая меня.
На такую мразь надо вообще везде объявления расклеивать, чтобы с ним не работали. Нахуй таких пинком под жопу вытравливать из геймдева.
Я, кстати, вообще нашел его случайно по скриншоту с Двача, а потом нашел сайт.
https://gamin.me/posts/22832
Как выяснилось, до меня он уже с кем-то не сработался, потому что скидывал другую демку в тг.
И потом оказалось, что он работал еще с двумя людьми параллельно со мной.
То есть, он нашел как минимум четырех "лохов", включая меня.
На такую мразь надо вообще везде объявления расклеивать, чтобы с ним не работали. Нахуй таких пинком под жопу вытравливать из геймдева.
>>6032
Ты не лох, ты токсичный агрессор. Остынь.
У тебя уже были фантазии что между вами любовь?
Понимаю, тяжело переживать измену любовника...
В чём он виноват? В том, что просил твоей помощи?
>лохов, включая меня.
Ты не лох, ты токсичный агрессор. Остынь.
>с двумя людьми параллельно со мной.
У тебя уже были фантазии что между вами любовь?
Понимаю, тяжело переживать измену любовника...
>такую мразь
В чём он виноват? В том, что просил твоей помощи?
>>6035
Он же вроде ясно выразился:
Что ты ожидал? Что между вами внезапно вспыхнут интимные отношения, только он да ты наедине?
Мог бы заранее спросить, не работает ли он с кем-то, если тебя настолько волнует этот интимный момент.
А вот твой пост:
Никаким законом всё это не запрещено. Трудового договора между вами, как я понимаю, не было. Если рассчитывал на что-то большее - заключал бы сразу договор, потом было бы на что жаловаться (в суд).
Это неправда, поскольку:
1. Код у тебя никто не отбирал - ты можешь просто поменять графику и продолжить работу один или с другими людьми. Учитывая разногласия, ты явно собирался делать что-то другое - вот и делай сам.
2. Ты за это время набрался опыта и навыков. Даже если ты не будешь больше использовать Godot, опыт разработки игр ценен вне зависимости от движка. И кроме того, опыт работы в команде - даже если он был неудачным. Делай выводы и станешь лучше.
>сразу не предупредил
Он же вроде ясно выразился:
>Целей заработать нет, только приятно провести время во время разработки и получить фан от процесса и общения.
Что ты ожидал? Что между вами внезапно вспыхнут интимные отношения, только он да ты наедине?
Мог бы заранее спросить, не работает ли он с кем-то, если тебя настолько волнует этот интимный момент.
А вот твой пост:
>Этот человек использует одну и ту же идею игры и одинаковые спрайты, параллельно работая с несколькими программистами.
>По сути, он просто тестирует, кто ему больше подходит, а затем избавляется от остальных.
>Меня он отсеял, прекратив сотрудничество спустя две недели активной работы.
Никаким законом всё это не запрещено. Трудового договора между вами, как я понимаю, не было. Если рассчитывал на что-то большее - заключал бы сразу договор, потом было бы на что жаловаться (в суд).
>Все усилия и время, вложенные в проект, оказались потраченными впустую.
Это неправда, поскольку:
1. Код у тебя никто не отбирал - ты можешь просто поменять графику и продолжить работу один или с другими людьми. Учитывая разногласия, ты явно собирался делать что-то другое - вот и делай сам.
2. Ты за это время набрался опыта и навыков. Даже если ты не будешь больше использовать Godot, опыт разработки игр ценен вне зависимости от движка. И кроме того, опыт работы в команде - даже если он был неудачным. Делай выводы и станешь лучше.
>>6031
Я его и не защищал, я просто не стал комментировать его личность, а ответил только по существу. У нас же тред дружбы и взаимопомощи, а еще он новичок в годоте, мы же не гейткиперы, и помогаем всем годотерам. К тому же он двачер.
Я его и не защищал, я просто не стал комментировать его личность, а ответил только по существу. У нас же тред дружбы и взаимопомощи, а еще он новичок в годоте, мы же не гейткиперы, и помогаем всем годотерам. К тому же он двачер.
>>6032
Я тебе по программистски логично объясню.
Если ты пробуешь и покупаешь помидоры в одном магазине, это не означает что у тебя пропадает право покупать их в других магазинах.
Если ты выбираешь, скачиваешь картинки для своей игры, это не значит что ты не можешь больше скачивать картинки других художников.
Тут произошло то же самое. Он выбирал программиста, и это не значит что он не имеет права пробовать других. Договор то вы не заключали, значит и обязанности продолжать сотрудничать нет.
Если у вас не было договора какого-то, получается ты код ему сам добровольно писал. В следующий раз заключай на нужных тебе условиях, раз тебе так не нравится, нанимайся по договору, где будет написано что делаешь ты и что ты за это получаешь - например деньги.
В любом случае для вас это к лучшему, потому что представь, что было бы если бы так без договора выпустили игру и потом начали бы делить прибыль. Это ж пиздец. Если не знаешь как оно бывает - посмотри сериал "кремниевая долина", там понятно и доступно показаны такие переделы.
Я тебе по программистски логично объясню.
Если ты пробуешь и покупаешь помидоры в одном магазине, это не означает что у тебя пропадает право покупать их в других магазинах.
Если ты выбираешь, скачиваешь картинки для своей игры, это не значит что ты не можешь больше скачивать картинки других художников.
Тут произошло то же самое. Он выбирал программиста, и это не значит что он не имеет права пробовать других. Договор то вы не заключали, значит и обязанности продолжать сотрудничать нет.
Если у вас не было договора какого-то, получается ты код ему сам добровольно писал. В следующий раз заключай на нужных тебе условиях, раз тебе так не нравится, нанимайся по договору, где будет написано что делаешь ты и что ты за это получаешь - например деньги.
В любом случае для вас это к лучшему, потому что представь, что было бы если бы так без договора выпустили игру и потом начали бы делить прибыль. Это ж пиздец. Если не знаешь как оно бывает - посмотри сериал "кремниевая долина", там понятно и доступно показаны такие переделы.
>>6031
хотя если почитать тот тред, а как с ним будет заключать договор петербуржец в казахстане? Подозреваю что neekaque
хотя если почитать тот тред, а как с ним будет заключать договор петербуржец в казахстане? Подозреваю что neekaque
>>6014
Обычно газоны в городах сильно ограничены и спроектированы как прямоугольники. Т.е. если твой уровень - исключительно город (современный), то выгоднее будет вставлять кусочки неровной земли в промежутки между дорогами, домами и тротуарами, а не наоборот, как ты предлагаешь. Поэтому не вижу проблемы намоделить эти кусочки отдельно.
Кстати, современные газоны делают в виде рулонов, поэтому укладывать их удобнее всего именно в такие прямоугольные участки. И в целом там нет каких-то особенных неровностей, разве что склон дороги.
Потом, возникает вопрос: какова роль в геймплее у данных участков неровной земли? На чём у игры геймплейный фокус: автомобилях, пешеходах, или, возможно, менеджменте города? Может ли игрок взаимодействовать с неровными участками?
Если тебе не нужен фотореализм графики, то можно обойтись программной тряской автомобиля, когда сходит с дороги на обочину - без буквальных кочек. Простое замедление тоже может оказаться более естественным по ощущениям, чем точная модель взаимодействия с бугорками на обочине дороги.
Ты хочешь простое и быстрое решение, что как бы намекает, что это вообще не важный элемент. Если неровности только декоративные, может, их стоит отложить на потом, сфокусировав силы на отладке основного геймплея игры? Скажем, вдруг задумка геймплея окажется скучной, забьёшь на проект...
Речь шла о плоской текстуре травы.
У тебя есть 2D эскизы/наброски/концепт уровня? Референсы? Похожие уровни из других игр? Не волнуйся, если что, никому не интересны чьи-то каракули типа пикрила. Но так нам будет проще подсказать более удобное решение проблемы.
>Участки неровной земли между асфальтированными дорогами и домами в городе. Щас выгляни в окно и посмотри на землю во дворе. Вот оно и надо. Точечно редактировать - чтобы подогнать к тротуарам, бордюрам, заборам и стенам.
Обычно газоны в городах сильно ограничены и спроектированы как прямоугольники. Т.е. если твой уровень - исключительно город (современный), то выгоднее будет вставлять кусочки неровной земли в промежутки между дорогами, домами и тротуарами, а не наоборот, как ты предлагаешь. Поэтому не вижу проблемы намоделить эти кусочки отдельно.
Кстати, современные газоны делают в виде рулонов, поэтому укладывать их удобнее всего именно в такие прямоугольные участки. И в целом там нет каких-то особенных неровностей, разве что склон дороги.
Потом, возникает вопрос: какова роль в геймплее у данных участков неровной земли? На чём у игры геймплейный фокус: автомобилях, пешеходах, или, возможно, менеджменте города? Может ли игрок взаимодействовать с неровными участками?
Если тебе не нужен фотореализм графики, то можно обойтись программной тряской автомобиля, когда сходит с дороги на обочину - без буквальных кочек. Простое замедление тоже может оказаться более естественным по ощущениям, чем точная модель взаимодействия с бугорками на обочине дороги.
Ты хочешь простое и быстрое решение, что как бы намекает, что это вообще не важный элемент. Если неровности только декоративные, может, их стоит отложить на потом, сфокусировав силы на отладке основного геймплея игры? Скажем, вдруг задумка геймплея окажется скучной, забьёшь на проект...
>А как раз именно трава НЕ нужна.
Речь шла о плоской текстуре травы.
>>Никто не заставляет в блендере лепить
>Ну, сам уровень и заставляет
У тебя есть 2D эскизы/наброски/концепт уровня? Референсы? Похожие уровни из других игр? Не волнуйся, если что, никому не интересны чьи-то каракули типа пикрила. Но так нам будет проще подсказать более удобное решение проблемы.
>>6014
А ты не думал в сторону модульности/тайловости? Не обязательно квадратно гнездовой, главное что делать не так много частей то надо. Ну например у тебя могут быть замоделены куски канавы, а остальная земля будет плоскостью.
А ты не думал в сторону модульности/тайловости? Не обязательно квадратно гнездовой, главное что делать не так много частей то надо. Ну например у тебя могут быть замоделены куски канавы, а остальная земля будет плоскостью.
8,8 Мб, mp4,1280x658, 0:24
Сап анончики, Прошу помощи
Каким образом лучше всего сделать линию от пули
ЧТобы как в утракиле
Сидел пердел над партиклами но они дают не тот эффект
Каким образом лучше всего сделать линию от пули
ЧТобы как в утракиле
Сидел пердел над партиклами но они дают не тот эффект
>>6066
Просто цилиндр, а то и вообще банальная прямоугольная плоскость.
Вот это глянь https://docs.godotengine.org/en/stable/tutorials/3d/particles/trails.html
Раньше надо было аддон качать
Просто цилиндр, а то и вообще банальная прямоугольная плоскость.
Вот это глянь https://docs.godotengine.org/en/stable/tutorials/3d/particles/trails.html
Раньше надо было аддон качать
Привет всем. Делаю игру, где есть всякие НПС. И у них есть диалоги при взаимодействии. Как эти диалоги грамотно хранить и менеджить? Сейчас храню их в CSV/Translation, и вот не знаю как красиво (масштабируемо) архитектурно сделать так, чтоб какие-то из этих диалогов проигрывались один раз, другие повторялись, и чтоб эти диалоги (в том числе повторяющиеся) в целом менялись в соответствии с общим прогрессом игрока по сюжету. Пока только придумал сохранять "биты" сюжета для каждого из НПС как ресурсы с полями ключей "от" и "до" csv-файла диалогов, которые будут вложены в "мета-биты" сюжета, которые можно будет засовывать в экспорты квестов и событий. Еще можно сделать массив "битов" у каждого из НПС свой, и он будет обновлять текущий "бит", смотря на поля, на которые ему нужно смотреть. Какой вариант лучше? И самое главное - как это можно еще сделать? Мне мои варианты не очень нравится. Что-то мне подсказывает, что можно проще и удобнее.
>>6084
Я для сложных веток диалогов использую дополнительные ноды с embedded скриптами, дальше уже от конкретного диалога зависит. Тебе посоветую не повторять мой путь, не костылять и взять готовый плагин диалогов.
Я для сложных веток диалогов использую дополнительные ноды с embedded скриптами, дальше уже от конкретного диалога зависит. Тебе посоветую не повторять мой путь, не костылять и взять готовый плагин диалогов.
Есть ли способ заебашить в годот каких-нибудь клёвый ИИ-алгосов, типо генетических алгоритмов или обучение с подкреплением?
>>6023
Когда я учился это был хороший тон в кодинге. А нынче вона чо, кастыли!
> Добавляй префиксы
> Это, конечно, костыль
Когда я учился это был хороший тон в кодинге. А нынче вона чо, кастыли!
>>6191
Не, это не всегда было костылём, как раз когда я учился это было хорошим тоном в кодинге.
Не, это не всегда было костылём, как раз когда я учился это было хорошим тоном в кодинге.
>>6225
Вот прям так и говорили, не надо использовать классы и неймспейсы, замусоривайте имена переменных? Такое может быть, если учился на бейские каком нибудь. Потому что если уже были неймспейсы или классы, то за Inventory.InventoryItemEffect бы били по рукам в приличном заведении.
Вот прям так и говорили, не надо использовать классы и неймспейсы, замусоривайте имена переменных? Такое может быть, если учился на бейские каком нибудь. Потому что если уже были неймспейсы или классы, то за Inventory.InventoryItemEffect бы били по рукам в приличном заведении.
>>6254
У тебя каша в голове. Охуенную антирекламу своего учебного заведения ты щас сделал. Где учился?
> Inventory.InventoryItemEffect
У тебя каша в голове. Охуенную антирекламу своего учебного заведения ты щас сделал. Где учился?
>>6046
Город ВСЖ. Не облагороженный мегаполис с ровными газонами, а кривой-косой артефакт уходящих времён.
Научиться их делать :3
Весь этот проект затевался с целью вкатиться в 3д. Так что я просто поставил себе задачу: хочу сделать такой вот уровень, соответственно и ищу инструменты под это.
Вообще, я почитал про ArrayMesh и всё сопутствующее, вроде не оч сложно. Попробую навелосипедить простенький террейн под свои задачи. Существующие плагины нацелены на огромные открытые миры и ЛОДы, а мой будет сделан под запекание меша, точечное редактирование и маленькие локации. Примерно как они используются в Халфлайфе.
Олсо, была даже мысль слепить уровень в Хаммере, а потом импортировать через VMF-импортер. Но это не даст мне новых знаний, а велосипединг - даст.
Да не, просто надеялся успеть слепить к определённой дате. А теперь уже точно не успеваю.
>>6060
Не. Панелькам надо давать не-панельное окружение, только тогда они раскрываются во всей своей чужеродности.
>исключительно город (современный)
Город ВСЖ. Не облагороженный мегаполис с ровными газонами, а кривой-косой артефакт уходящих времён.
>какова роль в геймплее у данных участков неровной земли?
Научиться их делать :3
Весь этот проект затевался с целью вкатиться в 3д. Так что я просто поставил себе задачу: хочу сделать такой вот уровень, соответственно и ищу инструменты под это.
Вообще, я почитал про ArrayMesh и всё сопутствующее, вроде не оч сложно. Попробую навелосипедить простенький террейн под свои задачи. Существующие плагины нацелены на огромные открытые миры и ЛОДы, а мой будет сделан под запекание меша, точечное редактирование и маленькие локации. Примерно как они используются в Халфлайфе.
Олсо, была даже мысль слепить уровень в Хаммере, а потом импортировать через VMF-импортер. Но это не даст мне новых знаний, а велосипединг - даст.
>Ты хочешь простое и быстрое решение, что как бы намекает, что это вообще не важный элемент
Да не, просто надеялся успеть слепить к определённой дате. А теперь уже точно не успеваю.
>>6060
>А ты не думал в сторону модульности/тайловости?
Не. Панелькам надо давать не-панельное окружение, только тогда они раскрываются во всей своей чужеродности.
Анон с кашей в голове, в силу своей некомпетентности, говорит мне
>>6267
Забавно.
>>6267
> тебе не стоит закапывать себя еще глубже
Забавно.
>>6273
Ну ок, ты решил закапываться. Не буду мешать.
Ну ок, ты решил закапываться. Не буду мешать.
>>6023
Попробовал в пустом проекте, точно так же не работает.
Не хотелось бы
Я все таки тоже решил сделать костылем. Сразу после создания вызываю собственную функцию "инициализации". Конечно, возможно, я в будущем об этом пожалею, но пока что это самый логичный вариант, который пришел мне в голову.
>Ну, похоже на баг, т.к. по идее должно работать.
Попробовал в пустом проекте, точно так же не работает.
>Можно попробовать цеплять к ним ноду...
Не хотелось бы
>И т.д. Это, конечно, костыль, но лучше, чем ничего.
Я все таки тоже решил сделать костылем. Сразу после создания вызываю собственную функцию "инициализации". Конечно, возможно, я в будущем об этом пожалею, но пока что это самый логичный вариант, который пришел мне в голову.
>>6291
так и есть. есть issue на гитхабе, в гдскрипте нет перегрузки функций, а значит нет разных конструкторов. А значит редактор не сможет создать экземпляр с дефолтным конструктором без параметров. Нерешенная проблема, так и советуют делать свою функцию инициализации.
так и есть. есть issue на гитхабе, в гдскрипте нет перегрузки функций, а значит нет разных конструкторов. А значит редактор не сможет создать экземпляр с дефолтным конструктором без параметров. Нерешенная проблема, так и советуют делать свою функцию инициализации.
>>6032
Поцоны это просто эпик!
Похоже, что художник еще и персонажа полностью сплагиатил. Просто вбейте в Яндекс.Картинки название: Not Involved “Survived”.
https://www.youtube.com/watch?v=898Yqyte8qo
https://play.google.com/store/apps/details/Not+Involved?id=com.strayfeet.notinvolved
https://strayfeetgames.itch.io/not-involved
Поцоны это просто эпик!
Похоже, что художник еще и персонажа полностью сплагиатил. Просто вбейте в Яндекс.Картинки название: Not Involved “Survived”.
https://www.youtube.com/watch?v=898Yqyte8qo
https://play.google.com/store/apps/details/Not+Involved?id=com.strayfeet.notinvolved
https://strayfeetgames.itch.io/not-involved
>>6336
Ладно, я, можетскуфпротивный и алкоголик. Но он украл у тяночки писечки. Это нельзя так просто оставить.
Ладно, я, можетскуфпротивный и алкоголик. Но он украл у тяночки писечки. Это нельзя так просто оставить.
>>6336
Это его новелла, как выяснилось, и он уже давно получает какие-никакие донаты.
Но кодеры ему нужны чисто за бесплатно, которых потом можно легко отсеять.
Короче, ушлый человек пытается развести по максимуму "лохов", при этом не рассказывая всех подробностей.
Такой себе Мориарти — гений преступного мира, дергает из тени за ниточки, манипулируя глупцами.
Теперь понятно, почему его так триггерило, когда я не хотел звать звукоря и предлагал нагенерить нейронкой.
Это его новелла, как выяснилось, и он уже давно получает какие-никакие донаты.
Но кодеры ему нужны чисто за бесплатно, которых потом можно легко отсеять.
Короче, ушлый человек пытается развести по максимуму "лохов", при этом не рассказывая всех подробностей.
Такой себе Мориарти — гений преступного мира, дергает из тени за ниточки, манипулируя глупцами.
Теперь понятно, почему его так триггерило, когда я не хотел звать звукоря и предлагал нагенерить нейронкой.
>>6341
Спросил у команды разрабов посмотрим что ответит.
Похоже что команда минимум из четырёх человек и они давно делают похожие игры.
Спросил у команды разрабов посмотрим что ответит.
Похоже что команда минимум из четырёх человек и они давно делают похожие игры.
>>6391
У тебя не хватит мощностей и видео памяти.
Что бы их хотя бы каждые 10 минут обучать.
По сравнению, это то же самое что криптовалюту майнить.
У тебя не хватит мощностей и видео памяти.
Что бы их хотя бы каждые 10 минут обучать.
По сравнению, это то же самое что криптовалюту майнить.
>>6391
Алгоритмов нет, там просто рандом.
В указанном тебе диапазоне из нескольких триллионов варинатов.
Которые понравились тебе.
Если варианты правильные - лак.
Нейронка двигается в указанном направление.
Алгоритмов нет, там просто рандом.
В указанном тебе диапазоне из нескольких триллионов варинатов.
Которые понравились тебе.
Если варианты правильные - лак.
Нейронка двигается в указанном направление.
>>6391
Но если говорить о конкретном видео, то оно просто собрало разные LLM под разными именами,
которые указаны в константах, чтобы было понятно,
к кому обращаются.
И всё равно, даже не зная имён и обращений, они поняли, кто человек.
Сука, я как будто в некоторые моменты думаю, что сам с нейронками общаюсь на дваче.
А иногда и сам собой, когда забываю старые свои сообщения.
Но если говорить о конкретном видео, то оно просто собрало разные LLM под разными именами,
которые указаны в константах, чтобы было понятно,
к кому обращаются.
И всё равно, даже не зная имён и обращений, они поняли, кто человек.
Сука, я как будто в некоторые моменты думаю, что сам с нейронками общаюсь на дваче.
А иногда и сам собой, когда забываю старые свои сообщения.
>>6410
если я вам всем не нравлюсь
я могу уйти навсегда с двача
мне не сложно бдут
и варитесь сами в своем говне без меня
если я вам всем не нравлюсь
я могу уйти навсегда с двача
мне не сложно бдут
и варитесь сами в своем говне без меня
>>6412
я не первый раз в интернете.
И большая половина моей жизни прошла на дваче и общение с двачерами в скайпе и дискорде. Не рассказывай мне сказки мальчик кто тут шизик.
я не первый раз в интернете.
И большая половина моей жизни прошла на дваче и общение с двачерами в скайпе и дискорде. Не рассказывай мне сказки мальчик кто тут шизик.