Как в редакторе добавить сцену в текущей позиции, а не в (0,0,0)? То есть, хотя бы примерно туда, куда смотрит внутри-редакторовская камера, а не в центр мира. Каждый раз добавляется в центр, а мне потом уныло перетаскивать через всю карту.
>>910850 → >>910826 → Да, оказалось плагин старый, перекачал с гитхаба - работает. Теперь следующий вопрос - а можно-ли привязать кнопку продолжения диалога не на физическое устройство, а на ноду кнопки? В (скудной, быть честным) доке к Диалогику ничего похожего не нашёл, залез в код - тоже ничего, можно в итоге или придётся мудрить костыли?
>>910899 А вот щас немного не ништяк, хз по какому принципу Диалогик ловит нажатия, но явно жопой, раз когда я вызываю действие из кода - ничего не работает, принты отрабатывают штатно, значит функция выполняется полностью.
>>910895 >Как в редакторе добавить сцену в текущей позиции, а не в (0,0,0)? Два варианта: 1. Перетащить сцену во вьюпорт, а не в дерево. 2. Перетащить сцену в потомки какой-либо ноде, а потом перетащить по дереву куда захочешь.
В первом случае позиция сцены будет примерно той, где ты отпустил кнопку мыши. Как минимум в 2D.
Во втором случае сцена сначала будет расположена в точке отсчёта локальной системы координат своего предка (.ZERO), а потом конвертирует координаты в глобальные... или что-то вроде. Сам попробуй.
Меня лично бесит, когда сцену кидаешь, а она не в точке отсчёта, а хрен знает где. БЕСИТ.
>>910921 Мне нужно было передать длину желательно в виде целого числа. На самом деле я там уже переписал так, что мне не придётся это делать. Но всё равно большое спасибо, это всё рано или поздно пригодится.
>>910793 → >можно их сумму В том-то и дело, что нельзя. >applied_force для тройки Нет такого в 3D физике. Только в 2D физике. >constant_force для четвёрки Это совершенно другое. Это ввели, чтобы не нужно было 60 раз в секунду запрашивать приложение одной и той же силы. Можно один раз прописать ПОСТОЯННУЮ (constant) силу и она будет автоматически работать, пока не сбросишь.
>>Речь о 3D физике >Какая разница-то? Если ты гений, чтобы физический 3D движок с нуля велосипедить - пожалуйста, никто не останавливает.
>>910869 → >приходит, т.е. воздействует, это сила. Мне не важно, кто там в тебя приходит.
>>910925 >А если я добавляю через ПКМ по дереву -> Instance Child Scene? Создай несколько Node3D нод с разным смещением. Добавь к ним чилдренов. Потом перемести эти ноды в другое место дерева. Точка в пространстве останется без изменений, но координаты изменятся, потому что у ноды изменится координатная система.
>>910963 С новой системой плагинов сообщество пошустрее плагинов напилит. Скоро будет у нас швейцарский нож для ассетофлипа. Хуяк-хуяк и в продакшон. Без единой строчки гдскрипта. Разве не об этом мы мечтали? Разве не этого ждали? >>910955 > Какие жанры то хоть делаете? Почему мы обязаны делать игры? Мы вполне можем делать плагины. И что ты нам зделоеш?
>>910966 Контроллер 3D-персонажа, движущегося в зоне с точечной гравитацией по внутренней поверхности сферы. Спиздил исходники планетарного контроллера из ассетлиба и перепиливаю под свои нужды.
>>910969 Это ты спрашивал каких плагинов не хватает? Мне не хватает нормальной Line3D. Чтобы, грубо говоря, трубы делать. В ассетах есть пара реализаций, но они в разных местах кривят.
>>911005 Хм. Любопытно. Записал себе в todo. >>911000 > Куда плагины выкладываешь? На гитхаб. > Я хочу в рамках знакомства с движком почитать В рамках знакомства с движком тебе о плагинах думать рано. > несколько гитов хороших проектов В окне менеджера проектов (которое открывается первым) есть вкладка с проектами-шаблонами из ассетлиба. У каждого из них свой гит, если уж так гит нужен, но вообще, прямо в редактор скачиваешь проект и смотришь прямо там, не отходя от кассы.
>>911015 >но вообще, прямо в редактор скачиваешь проект и смотришь прямо там, не отходя от кассы. Эт не то, вот посмотреть на 15 коммитов подряд срущих в мастер чтоб поправить одно говно, это всегда глаз радует.
Так. Я начинаю новый проект. А то предыдущий доделал где-то месяц назад, потом хуи пинал. Было несколько идей, не решался взяться ни за одну. Щас официально. Выбрал самую перспективную идею, которую я точно могу реализовать. Но делаю на четвёрке, потому что надо же когда-то начинать с ней разбираться.
UPD: я наконец-то понял, для чего нужны PhysicalBone2(3)D и соответствующие модификации скелета. С их помощью можно чуть ли не Эйфорию запилить. То есть, они работают по физике, но передают своё положение скелету (а не наоборот). Теоретически, так можно запилить персонажа с супер-сложной процедурной анимацией.
>>910972 >Персонаж на унитаз похож В 2к23 это в каком-то смысле даже плюс...
Я могу как-нибудь сделать связи между разными, не загруженными, сценами? То есть, у меня уровень 1 и на нем дверь-выход. При переходе через эту дверь хочу указать чтобы персонаж появлялся на уровне 2 в точке А. Но если игрок на уровне 1 прошел в другую дверь-выход, то на уровне 2 в точке Б
Уровней и точек планируется довольно много, в десятках, и хотелось бы сделать это наглядно для себя и не скатываться до хардкода.
>>911049 Нет, пути придётся либо вручную прописывать, либо, если ты с самого начала грамотно каталогизировал свои сцены (что врядли), ты можешь прописывать только их имена, а общую часть строкового пути вынести в константу, а из имён сделать энум и в ГУЕ выбирать нужное имя.
>>911042 >Как успехи по итогам? Пока никак. Жду, пока на яндексе одобрят, тогда релизну и на открытых сервисах.
>>911048 У ноды, отвечающей за телепорт: @export_file и в гуях можно выбирать файл другой сцены. @export вектор - координаты выхода. Тащемта подобным образом устроены переходы между уровнями даже в каком-нибудь Халф-лайфе. Потому что ну а как ты ещё укажешь на какую-то точку в каком-то другом файле, который даже не загружен? Можно усложнить. В уровнях завести массив/словарь координат, через которые можно на этот уровень зайти. В выходной ноде тогда надо указывать не координаты, а индекс в массиве/словаре. Тогда точку входа на уровень ты сможешь редактировать прямо изнутри этого уровня. Или даже это может быть не словарь, а определённая именованная нода, но путь к ней придётся прописывать ручками в точке выхода. И обязательно в каждом уровне нужна дефолтная точка спавна, на которую игрок попадает, если что-то пошло не так.
Коллеги из соседнего треда обратили внимание на одну проблему в Годоте: https://twitter.com/cyangmou/status/1718191813993848974 Есть мысли тех, кто реавльно пользуется вдижком, а не срачи устраивает? Насколько это большая проблема? Сталкивались ли?
>>911097 Это очень специфичная проблема. Я сделал две пиксель-перфект игры еще на тройке, и могу сказать что пиксель-перфект делается легко, и плавная камера делается легко. А вот объединить их в один проект, чтобы они не портили друг друга - сложно, потому что с одной стороны тебе нужен четкий снап по внутри-игровым пикселям, с другой - плавная субпиксельная камера. Сам понимаешь. Я в итоге сделал это через шейдер.
Добавлю что речь идет именно о пиксель-перфект. Обычные пиксельные игры в стиле террарии такой проблемы не испытывают. Пиксель-перфект вообще тонкая штука с кучей подводных. Но подозреваю твои движкосрачеры из соседнего треда не в курсе про разницу. Лучше бы игры делали. И ты тоже.
>>911106 >И ты тоже. Я жду 4,2(чтобы потом ждать 4,3 и атк далее)
>движкосрачеры из соседнего треда не в курсе про разницу да не, там просто вкинули ссылку, никакого обсуждения не было, на в твитторе немножко побухтели
>>911144 Хотя, есть в том контроле что непосредственно над кнопками скрипт, в котором стоят сигналы _on_pressed с кнопок. Но только что сигналы, Инпут же они не съедают.
>>911148 Бля, если у кнопки не DRAW менять, а visible то всё работает. Но мне то DRAW менять нужно... Ну или альтернативы подсвечивания, выделения кнопки.
>>911189 Двачую этого. Я в прошлом году экспериментировал с темами контролов, решал задачу о том, что в дефолтных темах у большинства контролов не было визуального подсвечивания при наведении мыши или захвате фокуса. Задачу я успешно решил путём добавления в кастомную тему кастомных стайлбоксов и настройки контролов (кнопок и чекбоксов) на переключение этих кастомных стайлбоксов.
>>911189 >>911193 Спасибо. Но если у меня 4 кнопки, но подсвечиваться должна одна из них. Получается на нажатие одной кнопки нужно дописывать смену остальным кнопкам стайлбокса? И так у всех кнопок. Типа если нажата кнопка_1: кнопка_2.стайлбокс = дефолт, кнопка_3... и тд. Простите за мой английский. Или есть способ сделать это легче?
>>911196 > Или есть способ сделать это легче? Есть такой способ. Называется ООП. Если конкретнее - наследование. Ты делаешь один скрипт, который наследуется от Button и назначаешь его всем своим кнопкам. И все твои кнопки наследуют поведение, которое ты описал один раз.
>>911205 Если ты создаёшь кнопки программно, назначь скрипту class_name MyButton и далее во всех скриптах где ты делал Button.new() делай вместо этого MyButton.new(). Если же ты подготовил "префабы кнопок" в виде сохраненных tscn-файлов, и загружаешь их через PackedScene.instantiate() то тогда class_name задавать не обязательно, но желательно, чтобы автоматически тянуть свои кастомные методы в интеллисенсе редактора через вывод типа.
Годаны, загадка века. Решена ли в четвёрке задача отражения 2д-анимаций? Что я имею ввиду. Вот у меня персонаж, состоящий из частей, анимируется скелетно (новая система инверсной кинематики ОХУЕННА, но в неё надо вкурить). Я сделал несколько анимаций лицом вправо. Теперь мне надо повторить те же анимации лицом влево. Натыкивать их мышкой заново? Это ж к тому же все ИК-цепочки переделывать: ограничения коленных, локтевых сгибов и тому подобное. Со спрайтовой анимацией всё просто, а вот тут куча подводных... Как эта проблема у образованных людей решается?
>>911246 В общем, пока решение такое, в целом рабочее. Вся анимация только на ИК. Маркеры-цели для ИК все лежат внутри одной ноды, назовём её контейнером. Если надо что-то двигать не-ИКшное, двигаем его при помощи RemoteTransform'a, сам ремоут кладём туда же, где маркеры. Флип состоит из трёх частей: 1. Ставим контейнеру скейл (-1, 1) 2. Меняем местами position.x у симметричных костей, типа "плечо", "бедро" 3. В скелетных модификациях инвертируем: а) Для TwoBoneIK: flip_bend_direction б) Для LookAt: constraint_angle_invert - но только для тех, которым это нужно Ну и, конечно же, сами спрайты, из которых состоит персонаж, флипаем тоже. В целом, пока я не дал ему оружие, выглядит адекватно. С оружием придётся возиться отдельно. Но хотя бы я уже избавил себя от возни с зеркальными дублями анимаций.
Дополнительно: играясь со скалированием контейнера, можно добиться забавных эффектов, которые благодаря инверсной кинематике даже адекватно смотрятся.
И упаси вас г-сподь скалировать скелет. Начинается то самое, от чего все священники будут в ужасе уходить за кадр со словами "ну нахер". Скелет лучше вообще лишний раз не трогать, а один раз настроить модификации, после чего двигать уже только маркеры.
>>911284 страдаю херней. если конкретно - разбираюсь с флексом(опенсорс экс) и годотом. конкретно здесь передача свойств из экс в годот. спрайты начинали тормозить где-то за 500 (а потом оказалось что если я хочу например приебенить к нему эфект например растворения, то придется каждому спрайту ебащить свой материал, ибо 2д в инстанс униформы шейдера не умеет) потому сделал через мешинстанс2д. 2500 псевдоспрайтов, которые могут в трансформ2д, цвет, покадровую анимацию из атласа и еще 3 флоата остались для параметров(тут 2 используется для растворения и покраснения)
Блять. Почему у SceneTree есть get_first_node_in_group(), но нету get_first_node_in_tree(). Как взять main ноду всего древа без свистоперделок с индексом, патчем, стринг неймом и тд и тп. Просто хочу что-то вроде get_tree().get_first_node_in_tree и всё! Неужели я многого прошу?
>>911313 да не, тут проблема в годоте. т.е. вполне неплохо батчит спрайты с одинаковым материалом, но если хочется обмазать шейдером - то материал нужно клонировать, в итоге батчинг идет к херам и каждый спрайт рисуется самостоятельно, что херит производительность уже на сотнях. не сказать что бы прям уж маленькое значение, хватит практически для всего, кроме чего-то типа вампир сурвиворс при чем для 3д в 4.0 рендер перерисали под полноценный инстансинг а в 2д есть только старый мешинстанс2д, который берет только трансформ2д и 2 флоат4 как параметра для отдельного инстанса. судя по обсуждениям на гитхабе - "не горит"
>>911370 Ну это я знаю. Мне нужно переменную в nodeOne.gd поменять через nodeTwo.gd. nodeOne.set("varibale", value), такой тип синтаксис там. Переменная как string, после запятой значение. Но !"value" не работает там.
>>911372 а, ну так да, работать не будет 1. сначала получить через гет потом поменять на противополжное var t : bool = nodeOne.get("value") nodeOne.set("value", !t) 2. добавить в nodeOne что-то типа func toggle(): value = !value
>>911380 нет, но я привык к строгой типизации на уровне рефлексов. т.е. сразу начинают лезть в голову вопросы "а что случиться если там не бул?" так то я хотя бы получу инвалид каст ошибку. воопше можно "сократить" до set("value", !get("value"));
>>911414 зависит от тонкостей батчинга. суть в том, что отрисовать сотню спрайтов поштучно критично дороже, чем обрисовать 100 одинаковых спрайтов. и вот эта самая "одинаковость" величина сильно плавающая. простейшая оптимизация - движок собирает спрайты в один меш из кучи квадов, формирует атлас из их текстур, подгоняет стандартный шейдер под это, и все - они "одинаковые" и рисуются разом. пока тебе не понадобятся какие-то специфичные фичи, которые в этот стандартный шейдер не влезет. например свой шейдер на спрайт точно в эти рамки не влазит.
>>911490 Да, я уже и сам разглядел. Рот проёбан, цвет глаз проёбан. Бретелька правая проёбана. Зато ляхи сочные. Да. Выражаю респект авторам модели и авторам арта, на котором модель тренировалась.
>>911498 Если будут классные пикчи то надо, но ты же сделаешь проходное г, лучше не трать время, я скорее про рисовак говорил. Наклепали бы интересного, нужно привлекать игроделов, раз гдскриптя медленная, пусть хоть годеточка заманивает прелестями
>>911503 Выглядеть это будет так: кидаешь чату-гпт-9 пасту кирилла, а он тебе ориджинал-контент на 69 часов игры скидывает, сразу ссылкой на установщик.
>>911510 >Цвет глаз в промте не указал, оцени >>911504 тут тоже цвет проебан, лол >прическу не помню как эта прическа называется на кругляшки, там конкретное название >стиль проебали дык в этом и суть, что стиль другой
>>911493 Хотим и безобразничаем, все же код писать!
>Note: call_group() will always call methods with an one-frame delay, in a way similar to Object.call_deferred() Сюка, сколько жопоболи мне это доставило, пока документацию не прочитал.
1. Как сделать, чтобы при сужении окна по ширине кнопочки имели минимальный размер, после которого, не сужаются как на видео? Поставил для контейнера кнопочек мин. сайз 500, не помогло. 2. Как сделать, чтобы при сужении окна по высоте кнопочки перестраивались как на видео, сейчас они у меня просто уменьшаются вместе с контейнером (контейнер VBox, внутри которого HBox).
>>911526 Смысл вообще цепляться за этот образ, это цвета флага Аргентины, движок давно стал международным, сам Хуан перекатился в Испанию от поборов, фонд зарегистрирован в Голландии, а W4 Games в Ирландии.
Для сейвов/загрузки есть какие-нибудь альтернативы вот такому ручному отслеживанию и восстановлению переменных? Как я понимаю можно тупо сцену целиком сохранять, но там проебутся все переменные, которые не export
>>910890 (OP) Только начинаю вникать в этот великолепный мир шейдеров и столкнулся с проблемой. Есть вот такой шейдер: https://pastebin.com/Pkte3PGJ И, вроде, все хорошо, но когда спрайт подходит к границам видимой области, то начинает тянуться шлейф. Я понимаю, что это происходит из-за distraction_strenght, но почему это происходит - понять не могу. Помогите, пожалуйста.
>>911581 > Для сейвов/загрузки есть какие-нибудь альтернативы вот такому ручному отслеживанию и восстановлению переменных? Есть. Если вкратце, тебе нужен объект-синглтон для сериализации (назовём его world_data). Это одна из редких задач, где синглтон реально нужен и антипаттерном не является. Вся остальная игра состоит из объектов синхронизирующихся с этим объектом, ворлд-датой. При своей загрузке, они запрашивают данные для себя у ворлд-даты, при своей выгрузке, или при наличии изменений, они самостоятельно загружают данные в вордл-дату. Само же сохранение в файл в этом случае будет сериализацией всего одного объекта - ворлд-даты. Сохранение контрольных точек в оперативке? Изи.
Загрузка сейва не должна выгружать текущую сцену принудительно. Загрузка сейва только загружает ворлд-дату, которая испускает сигнал "я обновилсо". После чего, куррент-сцена и объектты на ней, которые у тебя подписаны на сигналы ворлд-даты, действуют соответствующе. Если сейв хранил данные о другой локации, то куррентлокация выгружается полностью, и загружается локация по имени из сейва. Если же локация соответствует, то просто обновляются параметры. Встают мёртвые враги. Телепортируются в места, где должны стоять. Стейтмашины переключаются в те стейты, которые должны. И так далее.
И еще. В ворлд дате хранятся именно имена, в контексте "бизнес-логики" игры. Никаких путей, никаких сцен. Только имена и цыфры.
Бляяяя. Заморочки какие-то со слоями, узлами, древами. Кароче, есть узел control, к нему весь интерфейс привязан. Один из таких элементов control нода для элементов инвентаря. У нее дочерняя сцена инвентаря. И вот мне нужно, что бы когда я наводился на ноду control инвентаря, у меня отправлялся сигнал в скрипт. Окей, через _mouse_on() работает. Только получается так, что у control в инспекторе mouse filter должен быть на ignore, что бы у меня кликалось на элементы самого инвентаря на которые нужно, но блядский ignore игнорирует не только нажатие, он вообще всё игнорирует включая наведение мыши. И как прикажете это фиксить? Я уже все что можно попробовал, и какие то z-index'ы, и маски, хуяски. Почему так заморочено то, нельзя было сделать на разный импут разный фильтр? Пиздец.
>>911687 > Ручной работы много, правда. Если всё организовать правильно, то вся работа будет делаться один раз. > Третий раз их делаю и третий раз страдаю. Годотред спешит на помощь. Давай пройдёмся по деталям моего предыдущего поста. Всё ли ясно как реализовывать? Может что-то подробнее обеснить?
>>911754 А вот это хз, с гуями плаваю. Обычно на рандоме тыкаю параметры, которые похожи на то, что мне надо, и нахожу нужные.
Но вообще, попробуй вместо двух бокс-контейнеров использовать один FlowContainer, он организует элементы как слова на строке: с автопереносом и выравниванием типа "justify". Мин сайз надо ставить не контейнеру, а самим кнопкам. И залезть к ним в SizeFlags, поставить галки Fill + Expand, чтобы они занимали всё доступное пространство в контейнере.
Ремарка: это всё в тройке; как там что перепилили в четвёрке - я вообще зх.
Почти закончил просмотр гайдов хёрт биста и впал в уныние. Ещё из-за своих правок, выскакивают баги то тут то там, которые исправляю сутками. Как дальше жить, не знаю, пойду нажрусь
>>911775 Это норма. Я в своей первой игре тоже тупил неделями на простейших задачах. Теперь вжух и геймджам. Все приходит с опытом, продолжай делать игры.
>>911780 Они ещё ебашить будут прикольно, но надо будет перерисовать, тк на двух ножках всего в 16 пикселей и попадают по яйцам >>911779 Особенно смуту сеет то что старания напрасны могут быть, тк я пилю менеджер в опенворлде, с различными фичами типа банд, кредитов, казино и тп, а из-за графики мало кто оценит. Но надо пилить, согласен
>>911801 Ну блять, для рейкаста не надо, почему для сферкаста надо? Какой-то элементарщины нету, пишут, что raycastall можно самому заскриптить, в цикле перезапускать из точки столкновения, вообще ебануться движок
>>911810 Точно так же. Вообще, я понимаю из-за чего это. В 15 строчке эта часть "SCREEN_UV + distraction_strenght * vec2(depth)" может стать больше 1.0(Максимум для UV координат, на сколько я понимаю), но как это обойти - не понимаю.
>>911813 Да вот непонятно, что делать потом. Вот жду специалиста по шейдерам, может что подскажет, так как не хочется менять этот шейдер на другой. Этот самый красивый.
Оцените ок ли организация скриптов для уровней. Есть базовый код, который должен быть у всех уровней. При этом есть особые уровни, каждый из которых требует парочку своих дополнительных функций.
Планирую так. Сделать LevelBase.gd, прикреплять ко всем уровням. Потом, если понадобится дополнительный функционал, открепляю LevelBase.gd от уровня, и вместо этого делаю ему Level666.gd, который наследует от базового, extends "res://LevelBase.gd"
Годаны, а вы пользуетесь метаданными? Я чёт ни разу. Для чего они вообще нужны? Я вот между >var foo >if node.has_meta("bar"): > foo = node.get_meta("bar") и >var foo >if node.get("bar") != null: > foo = node.bar не вижу принципиальной разницы, но второй вариант как-то больше контроля имеет. Есть какие-нибудь живые примеры использования из личной практики?
>>911834 Ну тут скорее как в программировании, когда якобы дублиррубющийся код, на самом деле первый вариант показывает кодерку конкретно, что он работает с метой, а во втором примере хуй знает что-то "бар" сравнивается с налл. Годотом не пользуюсь, поэтому не знаю, на сколько это приминимо к нему.
>>911828 > Ок способ? Или есть получше? Это ты легаси нарисовал, которое было в двушке и первых версиях трёшки. Потом ввели class_name.
По современному будет так: > Сделать class_name LevelBase, прикреплять ко всем уровням. Потом, если понадобится дополнительный функционал, открепляю LevelBase.gd от уровня, и вместо этого делаю ему Level666.gd, который наследует от базового, extends LevelBase
>>911834 > живые примеры использования из личной практики? Практика не личная, но пример живой: аддон Dialogic для создания диалогов, весь работает на метаданных. Я когда его ковырял, тестировал, долго не мог понять, что там за магия, что диалоговые данные волшебным образом хуяк - и появились сохраннные. А потом обнаружил, что они в метаданные пишутся.
>>911800 >В годоти что нет RaycastAll()? >Нельзя запустить луч с бесконечной длиной? >SphereCast нету, нужно ноду какую-то создавать, что за наркомания? Этого нет и не будет, потому что Хуан считает, что это избыточно, это всё можно накодить самому. Там всё по такому принципу.
var item = ITEM.instantiate() item_container.add_child(item) item.connect("gui_input", _on_gui_input)
Потом в функции _on_gui_input():
print(gui_input.get_object()) выдаёт почему-то ноду скрипта 1, хотя в документации написано >Returns the object emitting this signal. Главное сигнал издается как раз правильно, когда нажимаю на тот самый item. Почему так?
Почему у нее так много комментариев? Почему так много ВИДЕО? Я покликал по этим летсплеям - все они от ноунеймов с 20-40 просмотрами. Итч какие-то ачивки этим людям дает? Или что? Или это боты? Откуда это все? Как стать таким же успешным?
Причем у этого автора есть вторая игра, и на ней совсем другая картина - 3 комментария за 2 года. Как и на моих играх. То есть это даже не автор суперзвезда.
Уже не первый раз натыкаюсь на подобный наплыв восторженных летсплейщиков. Что за хуйня?
>>911943 Да знаю я про твой слешдот эффект. И реддит эффект. И ЛОР эффект, и хабр эффект, и любая залупа-нейм-эффект. Объясняет наплыв, не объясняет идентичность и ботоподобность.
Заебало это говно, нет чтобы на каждую функцию пример сделать как в юнити, я не прогер, нихуя непонятно. Годот уже десять лет существует, инфы мизер, хуан специально меняет названия чтобы было сложнее! >>911901 >PhysicsDirectSpaceState2D -> intersect_shape() Так или что?
>>911970 Да разговор про shape ебучий, Хуан реально заставляет создавать круг, еще бы заставлял координаты каждой точки окружности вписывать, издевается
>>911975 Проблема в том, что Хуан пидарас, ему такую функцию написать три секунды, а я пол часа сидел. У него во многом ошибочные представления. Недавно он написал, что посмотрел стримы изучающих годот и ахуел, что все пытаются сразу создать куб как в юнити и не могут найти, типо не знал, что это так популярно. Я тоже так же пытался, представляю десятки тысяч людей тыкались в непонятках из-за этого одного клоуна. Избыточно, говорит, сферкаст делать, петух
>>911979 > У него во многом ошибочные представления. А вот копипаста из растотреда в /пр/. Как раз в тему.
> > > Хранить трансформацию в виде матрицы поворота и вектора смещения - не самая здравая идея. > > А вот тут поподробнее. Я на двачах слышал ровно противоположное. Что матрица трансформации это на порядок более-лучшее решение, чем квартернионы, мало того что устраняют гимбал лок эйлеровских осей, так ещё и устраняют кукую-то траблу, которую порождают квартернионы.
> >А вот тут поподробнее. > Матрица кроме ориентации и скейла хранит еще наклон осей (skew, оси могут быть не ортогональны), если ты например, трансформацию анимируешь, то надо на каждый чих матрицу править - ортонормировать, проверять что длина векторов единичная (если скейла нет, если есть - будет копиться ошибка), если матрица 4х4, очищать нижний ряд (0 0 0 1). Матрица может неожиданно стать вырожденной, тогда ее уже никак не поправить. Т.е. в матрице слишком много лишней информации для хранения ориентации. С кватернионом все проще - нормализовал и все. Плюс физика со скейлом (особенно неюниформным) совсем не дружит, т.е. для физики нужна будет отдельный вид трансформации без скейла. Ну и матрицы будут тормознее даже без проверок, например, инверсия трансформации с кватернионом гораздо проще и быстрее. Ну и сами кватернионы идеологически проще, если их понимаешь.
Я могу сделать, например, get("transform"). А могу ли я сделать что-то типа get("Pivot/Body.transform")?
То есть, я конечно могу написать вспомогательную функцию, которая будет разделять пути и трансформировать запрос в get_node("Pivot").get_node("Body").get("transform"), но нет ли чего готового?
>>912064 Так, хорошо. А что он должен рисовать? И откуда ему эту информацию взять? Я другой анон, есичо, но тут обитаю и всю эту проблему наблюдаю с самого начала. Просто в шейдерах не спец, поэтому не думал, что чем-то помогу. А щас вник... Вот строчка 15: >SCREEN_UV + distraction_strenght vec2(depth) Тут ты выходишь пипеткой за границы текстуры экрана. Попробуй клампануть это выражение, типа: >clamp(SCREEN_UV + distraction_strenght vec2(depth), vec2(-1.0, -1.0), vec2(1.0, 1.0))
>>912091 Шейдер берет и искажает изображения под ним так, будто оно находится под водой. Но побочных эффектом является то, что изображение сдвигается влево вниз под шейдером относительно оригинального изображения. Думаю в этом основная проблема и из-за этого выходит за границу текстуры.
>>912125 Я потыкал твой шейдер у себя и имею сказать следующее. 1. Покажи настройки шума water_noise и water_noise2. Или ты там просто картинки воды используешь? Я у себя создал NoiseTexture / OpenSimplexNoise, получил ОЧЕНЬ глубокие искажения на дефолтных настройках. Чтобы получить что-то похожее на твои скрины, пришлось убрать distraction_strength примерно до 0.02, но вместе с ним ожидаемо ушёл и краевой глитч. А у тебя, походу, исходные шумы очень светлые, почти всегда близки к 1.0. 2. Нашёл очень элегантное решение. На строке 13, где текстуры умножаются, заменить умножение на вычитание. Ну и кламп на 15 строке оставить, чтобы не вылезать за пределы текстуры вьюпорта.
>>912125 Вообще, на самом деле, это очень простой шейдер, щас тебе быстро объясню. Надеюсь, строки с объявлением переменных объяснять не надо. Шейдеры устроены так, чтобы можно было их легко распараллелить. Как? Просто работаем с каждым пикселем параллельно и всё. Таким образом, шейдер описывает, в какой цвет следует покрасить один пиксель на экране. SCREEN_UV - координаты нашего пикселя. (0,0) это центр экрана, (1,1) это правый верхний угол. SCREEN_TEXTURE - указатель на текстуру экрана. Мы не можем работать с целыми текстурами, можем только доставать из них отдельные пиксели. Собственно, именно этим и занимается функция texture(tex, uv), где tex это указатель на текстуру, а uv это координаты доставаемого пикселя. Рассмотрим подробнее, что происходит с координатами на строке 13: UV + scroll TIME TIME это постоянно тикающее время, scroll - коэффициент, который это время сжимает. UV (локальные координаты) в данном случае можно заменить на SCREEN_UV, всё равно у нас тут полноэкранный шейдер, локальные координаты совпадают с глобальными. Текстура шума бесконечная, а значит её можно скроллить сколько угодно, то есть нам не обязательно обнулять TIME. Итак, на 13 строке мы добыли пиксель текстуры шума одной и второй. Это значение находится в диапазоне от 0.0 до 1.0. При умножении, соответственно, мы остаёмся в этом диапазоне. А при вычитании уже получается от -1.0 до 1.0. Ещё обращаю внимание: мы здесь берём только один канал текстуры, потому что float. Дальше наконец мы лезем в текстуру вьюпорта, чтобы добыть из неё цвет пикселя. Нам нужен весь цвет, так что выбираем тип vec4. Вообще, texture возвращает тот тип данных, который мы от неё запросим. Итак. Мы хотим взять пиксель вьюпорта. Но не тот, который сейчас обрабатывается, а какой-то рядом, чтобы было искажение. То есть, берём SCREEN_UV и сдвигаем на размер искажения. За силу этого сдвига отвечает юниформ distraction_strenght, а за рандомность - полученное в 13 строке depth. Соответственно, некоторые пиксели в правой-верхней части экрана получат UV-координаты больше 1.0 и, таким образом, попадут за пределы текстуры. Эту проблему решает clamp, он возвращает нас из-за пределов текстуры ровно на её границу. Так что несколько пикселей, слишком близких к краю, будут взяты из одного и того же пикселя на краю. Дальше строчка top_light. smoothstep(light_start,light_end,depth) - это мы находим число от 0.275 до 0.4 (при дефолтных юниформах), где значение depth (снова 13 строка) определяет, насколько оно близко к 0.4. Умножив на цвет top_color, мы получили линейный сдвиг цвета, который используем ниже. Послоедняя строчка. screen_color tone_color - мы взяли полученный ранее пиксель вьюпорта и окрасили его в цвет тона. + top_light - тут мы не просто окрашиваем. При больших зачениях топлайта мы можем вылезти за пределы 1.0 по всем каналам. Тогда пиксель окрасится в белый, только и всего. Ну и наконец. COLOR = здесь мы присваиваем пикселю на экране то значение, которое насчитали. Какому пикселю? Тому самому, с которым всё это время работали. Напомню, в шейдере мы работаем с одним пикселем, то есть со всеми сразу параллельно. И вот тут-то мы ретёрним его значение. Вот как-то так.
>>912289 Кста, можно ещё вот что, забыл ночью написать, хотя думал. clamp всё равно создаёт артефакты по краям. Но можно и без клампа. Можно vec2(depth) домножать на >(vec2(1.0) - abs(SCREEN_UV)). Тогда эффект искажения будет тем менее интенсивен, чем он ближе к краю. А если тут вместо abs(SCREEN_UV) сделать SCREEN_UV * SCREEN_UV, то спад интенсивности будет не такой заметный. Можно вообще pow(abs(SCREEN_UV), n) и поиграться со значениями n.
>>912534 > какой-то двухсвязный список Бинго! Я сделяль на гдскрипте двусвязный зацикленный список. Называю его RingedList. У него есть забавные свойства, например то, что без дополнительных проверок попытка его обхода будет крутиться бесконечно. Ну точнее, до переполнения стека вызовов.
Вот сижу и думаю, как бы его применить? Сделать на его основе загадки с сейфом? Взлом замков?
Вообще, всё это делается на обычных массивах, но почему бы не выябнуться тормозным велосипедным рингедлистом? Ну не игры же делать, в самом-то деле? >>912533 > Твое избегание игростроя? Твоё.
>>912580 > как бы его применить? Вообще я плавно подбираюсь к созданию нейросети на гдскрипте. Будет класс нейрон и у него массив синапсов - линков на другие нейроны. И всё это будет многомерным связным списком, в котором сигнал будет уходить вглубь, ветвиться по слоям и обретать сознание, чтобы завоевать мир. Йохохо!
Интересно что если сохранить сцену из рантайма, при этом иметь включенным дебаг, то дебаговые меши (коллизии и навигация) тоже сохранятся и перекочуют в не-дебаг.
>>912622 Ты имеешь в виду чтобы игрок это делал? Потому что так то у тебя уже есть гдскрипт и сигналы, лол. > блок схему событий во внешнем редакторе Ну вообще есть умельцы которые делают прямо внутри редактора. Что то типа https://godotengine.org/asset-library/asset/1197 Искать по node
>>912146 У тебя берется вектор направления между опорной точкой спрайта и опорной точкой цели. Если они на разной высоте, то они и полетят по кратчайшему пути туда.
>>911979 Хуй знает о чем ты, куб создается в полтора нажатия клавиш: + CSGBox. Либо + MeshInstance, Cube Либо установкой ассета на прототипирование кубами. Потому что те, кто ковыряются, должны сначала прочитать доки и посмотреть туториалы, а потом уже включать стрим, чтобы не позориться.
>>912630 Скорее всего это не имеет смысла - если начнешь делать сейв или отправлять что-то на сервер, браузер может это прибить. Просто делай свои сейвы регулярно. Вообще можешь попробовать JS событие https://developer.mozilla.org/en-US/docs/Web/API/Window/beforeunload_event и там вроде можно получить окошко "вы действительно хотите закрыть вкладку?" как в gmail когда что-то не сохранил Но там официально сказано что это ненадежно, особенно на мобилках.
>>912627 > Потому что так то у тебя уже есть гдскрипт и сигналы, лол.
Цепочки событий примерно такие:
1. Поставить npc в точку (x,y) 2. Назначить взаимодействию с этим npc диалог с dialogue_id=666 3. Ждать сигнала о том что диалог прочитан 4. Положить в рюкзак ключ 5. Разблокировать дверь с door_id=420 6. Переместить того npc в (x1, y1)
И так далее. И таких цепочек должно одновременно быть несколько независимых Руками программировать каждый такой скрипт это бред полный, заебешься насмерть
> пикрел Меня гораздо больше интересует не конкретная реализация, а общие программные принципы.
Я тем или иным способом получил формализованное описание событий, а теперь надо их запустить как-то.
Должна наверное быть какой-то объект, который проходит по этому описанию и выполняет команды? И как эти события записаны, может быть как (тип,параметры)?
Нашел событие типа X, нашел функцию которая ему соответствует, вызываешь process_event_X(params)
Это я так, просто рассуждаю как может выглядеть система игровых скриптов.
Хочется послушать разные мнения как это можно сделать, или может кто-то знает как это делается в настоящих больших играх, там где программисты большие деньги за это получают.
>>912640 Я делаю нечто похожее, только без диалогов. Мой подход - компоненты ссылающиеся друг на друга. Игрок/НПС проходит по кнопке (возможно невидимой), кнопка при нажатии на себя открывает дверь по NodePath, или мост, или ловушку выдвигает. Сундук при взаимодействии с собой проверяет у взаимодействующего наличие ключа-флага. И так далее. Если делать компоненты похожим образом, то их можно зацепочить вот так по десятку, когда одно открывает другое.
Но у нас возможно разные жанры. Предположу что у тебя point-and-click адвенчура?
>>912640 Схема представляет собой конечный автомат / FSM / Finite State Machine Либо несколько, раз они у тебя такие независимые. Также они могут быть иерархичными (HFSM). То есть стейт машина, содержащая другие стейтмашины. Дальше тебе нужен паттерн команда. Например поставить нпц в точку, отправить нпц идти в точку. Очевидно что у него есть параметры, например id нпц и x,y Ждать событий не надо, это происходит само. Надо подписываться на нужные сигналы. Когда сигнал срабатывает, выдается нужная команда. Как ты хранишь данные, хоть в json, хоть в словарях гдскрипта, хоть рисуешь нодами. Потом они заполняют некую структуру узлов Что представляет собой такой узел? Это вот то что на картинках DialogueNode, с данными, а стейтмашина находится в одном из них, а по сигналам при соблюдении условий переходит в следующий. Связь между ними ты тоже должен прописать. Вроде в предыдущем треде как раз подобное обсуждали. Конечно программировать все руками не надо, тебе надо запрограммировать только категории событий. Что вызывает события? Обычно Area когда в них кто-то заходит или залетает.
Отличие от того, что анон выше написал, видимо, в том, что у него сами объекты реагируют и посылают что-то дальше, в этом варианте - есть главный менеджер, который всех слушает и всеми командует. Редактировать имхо его потом проще.
>>912645 Про паттерн команда не все понял. Кто именно выдает команды? Фсм идет по узлам и выдает команды?
Вот дошли до узла где нужно чтобы продвинуться нужно иметь в инвентаре некий предмет, а дальше как этого дождаться? Инвентарь имеет сигнал item_added.emit(item_name)
>>912640 > Руками программировать каждый такой скрипт это бред полный, заебешься насмерть Ты начинаешь догадываться о том, о чем я предупреждал еще три года назад, и о чем только сегодня начинают говорить: Создание универсальных редакторов игр было ошибкой. Движок это не редактор, движок это код, ядро. Старые игры программировались следующим образом: 1. На этапе предпродакшена продумывается будущая игра. 2. Пишется или берется со стороны движок этой конкретно игры. Движок-код. 3. На движке-коде игры пишется редактор игры. Этой конкретной игры. 4. Уже на игровом редакторе начинается построение мира, расстановка ассетов и сриптов. 5 6 7 8 ПРОФИТ
А когда сделали универсальные движки вскрылась проблема - создавая на универсальном редакторе что-то, ты неизбежно приходишь к выводу, что тебе, для своей игры придётся писать свой собственный редактор-в-редакторе. Оттого и возникают все эти аддоны, диалоджики и прочие. Правильно это или нет - каждый решает для себя сам.
Просто задумайся, если для твоей игры движок предлагает "бред полный, кучу ручной работы", значит у тебя в организации техпроцесса что-то очень сильно не заладилось. Либо тебе нужен движок-без-редактора (так называемый тулкит) и написание собственного редактора, отвечающего твоему техпроцессу, чтобы тебе было удобно; либо создать аддон в годоте; либо пересмотреть свой подход к девелопу.
>>912631 Ну может это ты что-то должен, а тебе ничего не должны, люди пробуют, и годот сразу начинает их бесить своей неюзабельностью. Это наблюдения хуана, ему и пиши что он хуйню пишет
>>912648 FSM находится в каком-то состоянии, например WaitDialogEnd. Когда условия перехода дальше сработали, вызывается функция например transition_to_state(new_state) new_state берется из текущего, тут могут быть описаны развилки, или просто переход дальше. Соответственно, там может быть указано что у следующего TriggerCategory = ItemAdded Arg = GoldenKey66 Вот тут можно и подписаться, напр. inventory.item_added.connect(self, onitemadded) в onitemadded(itemname) if itemname == Arg: next_state() next_state() делает всякую очистку transition_to(new_state) Можно еще подумать насчет шини событий (event bus) ТОгда все подписываются на нее и сигналы шлют в нее Может иметь смысл если например квест убить 10 волков, но волки спавнятся по 1 значит сразу всех ты подписать не можешь. Или тебе придется подписывать их в момент спавна.
>>912683 Смешно - это не прочитав документацию как поставить куб, подрубать стрим и опозориться, не справившись с элементарным действием. Вот это смешно. Пусть учатся, материалы в открытом доступе. Ну и ты видимо не понял смысл твита, да.
>>912677 > Ты выпускал коммерчески успешные игры или просто так пиздишь? >>912654 > На движке-коде игры пишется редактор игры. Этой конкретной игры. Aurora Engine -> Neverwinter Nights, Ведьмак1 NetImmerse (Creation Engine) -> Morrowind, Fallout3 Doom Quake Unreal
Всё это примеры игр, для которых на движке-коде запилен утилитарный двиижок-редактор.
Из редактора Unreal, ЧСХ, вырос в конечном итоге современный УЕ.
>>912677 > Ты выпускал коммерчески успешные игры или просто так пиздишь? Ну разумеется, я просто так пизжу.
>>912684 Смысл твита в сожалении хуана и намерении добавить кнопку "сделать быстро куб как в юнити, чтобы было заебись", а зачем ты свои визги начал и обвинения пользователей, не зная ситуации, вообще непонятно. Реально таблеток въеби
>>912654 >я предупреждал еще три года назад >Создание универсальных редакторов игр было ошибкой >>912688 >Ну разумеется, я просто так пизжу. Сразу видно эксперта гд, уважение
>>912654 >если для твоей игры движок предлагает "бред полный, кучу ручной работы" Это не движок предлагает, это юзер движка наткнулся на неподходящее ему решение. В движке нет одного-единственного верного способа сделать Х. Способов - дохуя. Значит надо думать дальше, искать подходящее решение, а не ломиться реализовывать первое попавшееся. Ты же не срешь посреди вагона метро потому что тебе организм так предложил, ты ищешь подходящее решение. А вот если бы твоей целью был перформанс и бунт - ты бы там так и насрал. Хорошо иметь разные способы.
>>912747 > Нет, ты предлагал >>912654 > если для твоей игры движок предлагает "бред полный, кучу ручной работы", значит у тебя в организации техпроцесса что-то очень сильно не заладилось > либо пересмотреть свой подход к девелопу >>912745 > юзер движка наткнулся на неподходящее ему решение > надо думать дальше, искать подходящее решение
Литералли сейм. Или как там у вас, пригоревших зумеров, говорят?
Сап годач. Смотрю сейчас туториалы по годоту на англ и столкнулся вот с такой конструкцией отнимания хп у игрока:
var max_health = 4 var health = 4: set = set_health
signal player_died
func set_health(value): health = clamp(value, 0, max_health) if health == 0: emit_signal("player_died")
Понятно, что при получении условно 1 урона health меняется на 3 и далее задействуется func set_health. Но по идее clamp между 0 и 4 должен выбрать наиболее близкое, т.е. 4 и хп не изменится. Но вместо этого оно исправно отнимается. При этом если убрать эту строчку с clamp, то хп не уменьшается вовсе. Как работает эта шайтан херовина? Почему без нее хп не уменьшается? Для изменения health вот такая штука: Player_stats.health -= damage
>>912779 Не, у меня то он как раз работает. Просто не пойму, зачем вот эта конструкция и как именно она работает: health = clamp(value, 0, max_health) Если ее можно заменить health = value
В доке такие примеры: var a = clamp(-10, -1, 5) # a is -1 var b = clamp(8.1, 0.9, 5.5) # b is 5.5
>>912780 >health = clamp(value, 0, max_health) >Если ее можно заменить >health = value Если заменишь, то при отрицательном value не сработает проверка if health == 0
>>910967 >Движку не надо считать ускорение Я нашёл алгоритм, в котором считается ускорение: https://en.wikipedia.org/wiki/Verlet_integration#Algorithmic_representation >The Verlet integrator provides good numerical stability, as well as other properties that are important in physical systems such as time reversibility and preservation of the symplectic form on phase space, at no significant additional computational cost over the simple Euler method. Вкратце, ускорение нужно для сглаживания скорости, чтобы объекты вели себя стабильнее.
Этот метод позволяет двигать объекты по более стабильным и точным траекториям и накладывать стабильные ограничения. Смотря на то, как ведут себя Joint3D, мне кажется, все бы только выиграли от применения этого метода глобально. А то сейчас накладывать ограничения на RigidBody3D смысла практически нет, их будет ломать от рандомных коллизий так, что они успокоиться не могут.
А если бы движок использовал этот метод внутри, осталось бы только сделать API для получения актуального ускорения любого объекта извне.
>>912779 >сеттеры/геттеры не работают изнутри объекта В 3.x не работают, и это проблема. В 4.x работают. Сеттеры/геттеры не вызываются только изнутри самих себя, т.е., например: >var a: int: >set(value): a = value >get: return a Здесь не будет бесконечной рекурсии. В остальных функциях класса доступ к a вызывает сеттер/геттер.
>>912795 >тут ненужон получается >Можно просто if health <= 0 сделать >Короче, пока юзлес шляпа В твоём примере clamp() нужен, чтобы здоровье игрока не выходило за ожидаемые пределы.
Функция clamp() аналогична этому коду: >func clamp(value, min_value, max_value): >if value > max_value: return max_value >elif value < min_value: return min_value >else: return value
Если мы сделаем так: >health = health + change Тогда игрок сможет получить столько здоровья, сколько сможет собрать лечилок; будет продолжать получать урон даже после достижения 0 здоровья.
Поэтому мы делаем так: >health = clamp(health + change, min_health, max_health) Теперь попытка взять аптечку с полным здоровьем использует аптечку, но не увеличит здоровье выше максимального, а мобы не будут забивать здоровье игрока ниже минимального здоровья.
Почему это важно? С лечением очевидно: у игрока сейчас 99/100 здоровья и он использует лечилку на +50, он должен получить +1 до 100, а не +50 до +149.
С нанесением урона ситуация чуть сложнее. Пока игрок способен только умирать, всё ок. Но если, допустим, мы сделали возможность воскреснуть, и она работает как лечилка, дающая +50 здоровья, а игрок получил урон на -75, имея здоровье 5/100, то в результате здоровье было -70 и после воскресения у него -20/100, а не 50/100. Чтобы таких багов не было, мы заранее ограничиваем здоровье допустимыми рамками.
Короче, это подстраховка, чтобы в будущем не ломать голову над багами с нанесением урона и добавлением здоровья. Ты скажешь, что мобы и лечилки должны проверять здоровье игрока, но это нарушает принцип ООП, в котором каждый объект заботится сам о себе: лечилки и мобы не должны проверять, кому отдают лечение или наносят урон, чтобы код был гибким.
А вот чтобы лечилки не уходили впустую и мобы не издевались над трупами нужны другие проверки. Допустим, код игрока проверяет, нужно ли ему брать лечилку перед её использованием; мобы проверяют, жива ли их цель в своей логике поведения, но не заботятся о том, сколько у неё здоровья.
>>911005 >Мне не хватает нормальной Line3D. Чтобы, грубо говоря, трубы делать. Изучал этот вопрос и пришёл к выводу, что идеального универсального решения нет. Нарисовать простую ломанную линию легко даже без построения меша (просто размести кубы в MultiMeshInstance3D), но как только ты хочешь что-то особенное, универсального решения не существует или оно будет тормозить для всех из-за множества проверок.
Я видел даже решения на шейдерах, без построения специального меша. Натуральная магия...
Даже в 2D универсального решения нет, встроенная нода подходит только для простых применений.
>>911023 >PhysicalBone2(3)D >Эйфорию запилить Для этого нужно настраивать джойнты и чтобы эти джойнты работали стабильно. Иначе даже самый простой, пассивный физический регдолл начинает колбасить по всему миру. Jolt Physics стабильнее встроенной, но тоже не идеален. А у Эйфории весь прикол в симуляции мышц... Так что задолбаешься циферки вписывать в джойнты, чтобы настроить и наблюдать, как всё разлетается по сцене.
Вообще не понимаю, кто все эти люди, которые рекомендуют соло индюкам делать процедурные анимации вместо классических. Они что, садисты?
Всем тем, кто планирует заняться процедурными анимациями: не ведитесь на советы, подумайте несколько раз, ЗАЧЕМ вам эти анимации нужны. Большинство анимаций могут быть классическими, которые многократно легче реализовать, придав им индивидуальность. Во многих случаях игрок вообще разницу не заметит и/или не оценит сотни часов, вложенных в отладку процедурной анимации, чтобы она хотя бы не глючила. Разнообразие? У вас будет точно такой же процедурный хаос, как во множестве других игр с процедурной генерацией. Единственное преимущество - можно генерировать анимации для произвольных скелетов и произвольной геометрии уровня, но это нужно очень специфичным играм, в которых от этого зависит весь геймплей.
Не бойтесь классической анимации, её не так уж сложно освоить, особенно если вы не пытаетесь делать ААА реализм или у вас вообще лоуполька, на которую игрок будет смотреть издалека.
Алсо, встроенные средства Godot заточены под управление классическими анимациями. Для процедурной анимации придётся в основном изобретать велосипеды вместо использования удобных дизайнерских штучек UI Godot/Blender.
>>912818 Как баббл и анимацию сделать я знаю. Хочется более законченного решения. С последовательностью диалогов, с сохранением позиции, с next, с ответами, с реакциями на состояние мира/игрока/нпс.
>>911834 >а вы пользуетесь метаданными? Пока не пользовался, не приходилось как-то.
>if node.has_meta("bar"): foo = node.get_meta("bar") >if node.get("bar") != null: foo = node.bar >не вижу принципиальной разницы Принципиальная разница в том, что в первом случае запрашиваются метаданные. Во втором случае ты запрашиваешь свойство класса, а не метаданные. https://docs.godotengine.org/en/stable/classes/class_object.html#id1 >Returns the Variant value of the given property. If the property does not exist, this method returns null. https://docs.godotengine.org/en/stable/classes/class_object.html#class-object-method-get-meta >Returns the object's metadata value for the given entry name. If the entry does not exist, returns default. If default is null, an error is also generated.
>второй вариант как-то больше контроля имеет. Наоборот. Вообще сомневаюсь, что get() вернёт тебе метаданные, но если вернёт - как ты поймёшь, что это метаданные, а не свойство класса? А если не вернёт, тогда ты метаданными не пользуешься.
>Для чего они вообще нужны? https://docs.godotengine.org/en/stable/classes/class_object.html >Lastly, every object can also contain metadata (data about data). set_meta can be useful to store information that the object itself does not depend on. To keep your code clean, making excessive use of metadata is discouraged. По сути, ты можешь добавить метаданные к любому объекту, даже если у него нет скрипта. При этом сам объект об этих метаданных не заботится - это данные о данных, а не сами данные как таковые.
>>912856 Там было просто упоминание поста Хуана, но ты начал визжать и оскорблять изучающих годот, порось, а сейчас опять визжишь, займись чем-нибудь полезным сам
>>912822 >рекомендуют Шиз штоле? Где ты там в тексте рекомендацию увидел? >встроенные средства Godot заточены под управление классическими анимациями В тройке да. В четвёрке скелетная анимация процедурно делается быстрее и легче, чем прежним методом: настраиваешь ИК-цепочки и двигаешь таргеты, всё. К тому же интереснее выглядит при смешивании анимаций. Пример. Мой персонаж держит в руках ружьё. Вот он побежал, для этого слегка наклонился телом вперёд. В тройке, если я наклоняю тело скелета, то руки, как ноды-дети, наклонятся тоже, а значит уедет и наклон оружия. В четвёрке же концы рук привязаны к таргетам, а таргеты не обязаны быть детьми скелета; я наклоняю туловище, а руки сами по ИК выстраиваются к таргетам.
Если кратко, Godot предоставляет несколько разных запросов с шейпами. Чтобы сделать "SphereCast", необходимо сделать несколько простых шагов: 1. Создать/добыть где-то шейп. Его можно юзать многократно для разных целей, что очень удобно; например, можно использовать шейп персонажа. 2. Поскольку нам нужно движение, нужно сначала сделать cast_motion(), он вернёт нам две позиции: максимальное движение до столкновения и минимальное движение для столкновения. 3. Если нам нужна дополнительная информация из точки столкновения шейпа, меняем запрос: 3.1. Вычислить новую позицию шейпа, это легко, всего лишь сложить вектор позици с вектором движения, умноженным на число из пункта 2. 3.2. Для получения только контактных точек, достаточно сделать запрос collide_shape(). 3.3. Для получения подробной информации о том, с чем конкретно мы столкнулись: intersect_shape().
Если тебе это часто нужно, просто оформляешь в виде функции и обращаешься уже к ней.
Всё это тривиальные операции, тут не нужно никаких математических познаний - справится кто угодно. В разработке игры приходится бороться с куда более сложными проблемами, в которых вместо простых запросов приходится математикой заниматься...
Почему нужно столько промежуточных шагов вместо одного обращения к методу sphere_cast()? Потому что движок позволяет нам делать куда более сложные запросы, чем просто "кинуть сферу", и забрать только ту информацию, которая нам нужна. Unity в данном случае скрывает от пользователя возможности и генерирует лишнюю информацию даже в самых простых случаях (когда нужно только движение или точки контакта, а не всё сразу).
То, что движок возвращает Dictionary вместо объекта, конечно, неоптимально. Думаю, это исправят, т.к. разработчики обратили на это внимание.
Если нужен просто шейпкаст, можно создать ноду, добавить её в сцену и проверять по необходимости. Можно выключить её непрерывное обновление и запрашивать только по необходимости. Главное преимущество этой ноды в том, что её видно в редакторе сцен и при отладочном показе шейпов.
>>912872 >Unity в данном случае скрывает от пользователя возможности и генерирует лишнюю информацию даже в самых простых случаях Ну и пусть генерирует, сишарп тупо мощь. Это же Хуан на каждом углу лечит, что гдскрипт для быстрого прототипирования, и не нужно пердолиться байтоёбить. Где тут быстрое, если вместо одной строчки нужно написать 10? При том что это всё на скрипте, который медленнее в 40 раз. Я всё это время думал наоборот, что на годоте всё это давно сделано удобно, множество функций на все случаи жизни, и за это удобство нужно платить низкой производительностью скрипта, а в итоге хуй, наебал аргентинский пахом. Вы просто неправы в этих оправданиях самодура, нужно признать, что он сам себе противоречит и смириться с неадекватом шизика
>>912869 >Где ты там в тексте рекомендацию увидел? В каком тексте?
Захожу на ютуб: кучи видео "делайте процедурные анимации вместо обычных", "почему инди должны делать процедурные анимации", "как я сделал процедурные анимации и вам советую".
Заходишь на реддит - кучи постов и коментов приблизительно того же смысла, типа, "эй, вот я сделал процедурные анимации, ничего в игре нет кроме них, потратил полгода на анимации, всем рекомендую", и коменты "ооо, тоже буду делать".
Даже здесь, в /гд/, встречал совет уровня "сделай ХОТЯ БЫ процедурные анимации".
Создаётся впечатление, будто десятки часов отлаживать математически сложный код проще, чем подвигать несколько костей (буквально 2-3) в блендере и переимпортировать модельку.
Алсо, инверсная кинематика - лишь малая часть процедурных анимаций и не является основной.
>побежал, для этого слегка наклонился вперёд >руки наклонятся тоже, уедет и наклон оружия. Разве это неправильно? По-моему, это достаточно реалистичное поведение. Или ты хочешь, чтобы он стрелял точно в цель прямо на бегу? Тогда зачем привязывать руки к туловищу и наклонять их вместе с туловищем, если у тебя робот, стреляющий точно в цель независимо от состояния туловища?
Вот это одна из проблем процедурной анимации: инверсная кинематика вывернет руки персонажу в направлении взгляда, в каком бы положении тело ни было. Чтобы руки не ломались, нужно выставить ограничения. Чем больше ограничений, тем сложнее вычисление позиции, и всё может начать трясти и телепортировать из-за того, что игрок пытается выставить неудачное положение костей...
Опять же, ИК - это только малая часть. Упомянутая Эйфория симулирует целого человека с мышцами и повреждениями, а не примитивные ИК-цепочки.
Кстати, почему Эйфория провалилась как продукт? Потому что им приходилось высылать собственных специалистов для интеграции в игру. Всё настолько сложно, что Rockstar сами бы не справились, а это не разработка с нуля - это настройка готового продукта.
>>912890 Блин, ты так расписываешь, индюков делающих 3д в принципе немного, а делающих с анимациями это вообще редкость, максимум какой-нибудь человечек из майнкрафта, какие процедурки
>>912883 >гдскрипт для быстрого прототипирования Да. Но с учётом внутренностей движка. Для говнокодинга можно было любой готовый ЯП прикрутить, вроде JavaScript, AngelScript или Lua.
>сишарп тупо мощь C# - тупо проприетарная библиотека для создания программы, выглядящей в стиле C++, работающей медленнее программы на C++, и имеющей меньше кроссплатформенных возможностей. Вся суть C# - переманить фирмы с Java на продукт от Microsoft.
Никогда не испытывал необходимости в C#, а если оптимизировать код - то уж точно не на C#.
>на скрипте, который медленнее в 40 раз Только когда тебе нужно брутфорсить числа. Для брутфорсинга нужно модуль на C++ написать, а не говнокодить на языке для скриптов.
>множество функций на все случаи жизни За этим тебе нужно скачать 40 Гб UE5, там и правда множество лишних функций на все случаи, которые никогда в твоей жизни не произойдут. Философия разработки Godot стремится охватить широкую аудиторию без написания функций, которые 99% аудитории никогда не понадобятся.
Вот я давно движком пользуюсь в 3D, никогда не испытывал острой необходимости в "SphereCast". Даже обычные лучи редко нужны были.
>>912904 Очевидно что здесь сравнение идет только между юнити и годотом, как только ты плюсы начал приплетать и анриал это сразу ты расписался в собственном бессилии. Для чего существует функция создать шейп? Избыточно пиздец, ну импортируй модель и все, зачем гдскриптю засорять. Годотька уже разбух от излишков, напишите чтобы удалили эти цирклы и сферы, а то мешают игру делать, глаза мозолят
>>912897 >индюков делающих 3д в принципе немного Достаточно, чтобы упоминать "в 2D", когда речь идёт об универсальном движке с 3D графикой.
>а делающих с анимациями это вообще редкость В смысле? Без анимаций разве что ASCII, да и её тоже умудряются анимировать. Игра совсем без анимаций будет выглядеть слишком скучно, даже если сама по себе графика выглядит хорошо.
>максимум какой-нибудь человечек из майнкрафта, какие процедурки Забавно, но модели в Майнкрафте вроде как раз процедурно анимируют. Часто замечал, что такое сверхлоуполи чаще анимируют кодом.
Если нужно что-то примитивное, то кодом описать будет несложно. Типа движения по синусоиде. Но для такого физические кости скелету не нужны.
>>912909 >плюсы начал приплетать Это ты начал про производительность, я говорил только про гибкость кода. Или хочешь несколько десятков функций типа sphere_cast, rectangle_cast, triangle_cast, pyramid_cast, cylinder_cast, teapot_cast, susanne_cast, earth_globe_cast и т.д.?
>Для чего существует функция создать шейп? Чтобы потом поместить этот шейп в физическое тело, в зону-датчик Area, или сделать тот же "каст".
>импортируй модель и все Тогда у тебя игра тормозить будет из-за того, что физическая модель избыточна. Даже PhysX не следует перегружать лишним мусором. Для этого существуют эти "шейпы" - это не обычные меши, а особые фигуры, оптимизированные для физики.
>>912920 >Тогда у тебя игра тормозить будет из-за того, что физическая модель избыточна Годот же очень заботится о производительности да? Я вот на юнити 40к рейкастов до просадки фпс запускаю, а на годоти 3к, почему так? >Или хочешь несколько десятков функций типа sphere_cast, rectangle_cast, triangle_cast, pyramid_cast, cylinder_cast, teapot_cast, susanne_cast, earth_globe_cast и т.д.? Ой, как же юнитя со своими бокскаст, сферкаст, рейкаст... Ну тупые да? Только ты умный с хуаном ни лишней строчки
>>912924 >очень заботится о производительности Наоборот, делают удобнее в ущерб скорости. Но это удобство на уровне опенсурс, тут своя атмосфера. Если тебе блендер старых версий был неудобен - ну, прости, что это не многомиллионный энтеретайз.
>40к рейкастов до просадки фпс Сначала движок пусть прогреется, а ещё не забудь про сборку мусора, из-за которой приходится юзать обходные пути для создания/удаления объектов.
Т.е. прежде чем ты 40к рейкастов сделаешь, можно успеть сбегать в магазин и приготовить поесть. А потом всё начнёт тормозить из-за сборки мусора - тысячи рейкастов кто-то должен удалять (но не ты).
>юнитя со своими бокскаст Юнити не пытаются вжать в ~50-100 Мб редактора и у них нет встроенного скриптового языка, куда все эти API нужно делать доступными, и вроде бы у них нет своего аналога GDExtension.
>>912924 >3к, почему так? Насколько я понял, это из-за Dictionary.
Уже обсуждали с ключевыми разработчиками.
Ответ Хуана: https://gist.github.com/reduz/cb05fe96079e46785f08a79ec3b0ef21 >The problem is that, at the C++ level, this function takes a struct pointer for performance. But at the language binding API this is difficult to expose properly. This is very old code (dating to the opensourcing of Godot) and a Dictionary was hacked-in to use temporarily until something better is found. Of course, other stuff was more prioritary and very few games need thousands of raycasts, so pretty much nobody complained. Still, there is a recently open proposal to discuss more efficient binding of these types of functions.
>>912930 >Ответ Хуана: Да у вас с хуаном на все есть ответы, по ходу весь путь годота состоит из идеальных решений, на всё какие-то отговорки, ни шагу назад, ни лишней строчки врагу
>>912935 >весь путь годота состоит из идеальных решений, на всё какие-то отговорки, ни шагу назад Всё так, производительность на уровне C будет: https://github.com/godotengine/godot-proposals/issues/7329 >FlatArrays are a special case of struct array that allocate everything contiguous in memory, they are meant for performance only scenarios. Will describe how they work later on, but when this is used together with typed code, performance should increase very significantly. In fact, when at some point GDScript gets a JIT/AOT VM, this should be near C performance. Так победим C#.
>>912938 > In fact, when at some point GDScript gets a JIT/AOT VM, this should be near C performance. Этого не будет в ближайшие 5 лет, там есть большой тред с обсуждением jit/aot, так ни к чему и не пришли. Пару лет будут рожать решение, потом еще пару лет Хуан будет в голове воплощать, потом уже может что-то высрет
>>912890 >В каком тексте? В том тексте, на который ты отвечал. Проследи цепочку ответов выше по треду. >Разве это неправильно? Да, это неправильно. Если я держу в руках предмет (например, кружку с чаем) и стремлюсь сохранить его положение в пространстве, я буду делать это, независимо от наклона моего тела, например. Тем более если это оружие, у которого надо не сбить прицел. >Где? В 2D? Ну, вообще да. Про то, что >В 3D ничего не поменялось - новую систему убрали я вообще не в курсе. Ну, как убрали, так допилят и вернут. Почитал обсуждение, там вопросы скорее к недопиленности четвёрки, чем к самому факту ИК в 3Д.
>>912938 > Так победим C# ИМХО, вообще не нужно было побеждать что-либо. Нужно было с самого начала проектировать транспилер (транслирующий компилятор). Пользователь пишет на гдскрипте, а на выходе компилируется с++. И всё. Проблем не было бы вообще. Сразу искаробки была бы производительность крестов, плюс, можно было бы в гдскрипт завезти ключевое слово что-то вроде embed {} с блоком чистого с++ кода, который идёт на выход без обработки транспилером. Плюс, промежуточные файлы складывались бы в отдельную папочку и можно было бы подключить к ноде промежуточный код на сях, отбросить предварительно написанный гдскрипт и далее уже допиливать код на сях, уходя в дебри байтоёбства и указателей.
Вообще не вижу помех, почему так нельзя было сделать с самого начала? Возможно, конечно это мой уровень даннинга-крюгера не позволяет мне увидеть фундаментальные помехи реализации вышеописанного.
Подскажите вот что. Как получить имя инстанса? Есть сцена Health. Я прикрепляю ее к НПС, называю ее NPCHealth. Внутри сцены Health делаю print(get_name()), вижу имя Health. Как получить то имя, которое я установил в родительской сцене, то есть NPCHealth?
>>913081 >Возможно, конечно это мой уровень даннинга-крюгера не позволяет мне увидеть фундаментальные помехи реализации вышеописанного. Ну хоть это ты понимаешь
>>913084 Я недавно ознакомился с LLVM и реально не понимаю, почему продолжают пилить какие-то велосипедные байт-код недокомпиляторы, когда можно запилить полноценный компилируемый язык. Можно было бы запилить компилятор гдскрипта в нативную либу, которая прозрачно для пользователя подключается к запускаемому проекту. Что им помешало это сделать?
>>913089 Вау. Это литералли то что я написал/предложил выше. Паямо сам хуан предлагает, как один из вариантов, подключить внешний компилятор, который будет при запуске обновлять либу со скомпилированными скриптами. Хуан пишет, что это может быть хлопотно. Но позвольте. Это не хлопотнее, чем подключать ручками rcedit и fbx2gltf в настройках редактора. Делаешь один раз и получаешь нативизированный гдскрипт искаропки.
>>913110 Берешь и делаешь, и открываешь пулл реквест, и обсуждаешь с разработчиками. Опенсорс же. Но ты не можешь или не хочешь, а вот сренькать на харкаче - можешь и хочешь. Даже обсуждаешь не там, где тебя могут услышать люди, способные что-то реализовать, а здесь. Показательно это все конечно.
>>913232 От кого ты ожидаешь чтобы тебе сделали, нарк? От местных анонов? Или ты думаешь Хуан тут сидит? Пиздуй на гитхаб и открывай issue.
И нахуй вы вообще кормите этого залетного движкосрачерского дебича с его "годотьки зделойте мне я хочю а вот в юните-то давно есть". Он половину треда уже засрал, блядь.
>>913237 Я тебе пишу чтобы ты прекращал движкосрач на весь тред разводить. И я каждый твой пост буду репортить. Уебывай в тред для движкосрача, либо уебывай на гитхаб и убеждай тех, кто может сделать твою хотелку, либо сам ее сделай. Так что лови репорт.
Анимирую я, значит, аниматором разные свойства ModificationStack'а в скелете. И вроде даже работает. А потом выясняется, что вообще так лучше не делать, и даже движок не предусмотрел прямого обращения к стаку, а надо делать get_modification_stack, менять полученное, а потом set_modification_stack. Как-то это слишком заёбисто, на мой взгляд. Но лучшего способа флипать скелет по горизонтали я пока не нашёл. Ну, то есть, можно как раньше через анимейшонплеер, но мало ли что от такого обращения поломается.
>>913252 > Как-то это слишком заёбисто, на мой взгляд. Один раз сделай переменную mod_stack : set = set_modification_stack, get = get_modification_stack и обращайся к ней через self.mod_stack. Делов-то.
Годаны, два нубских вопроса по твинам в четвёрке. 1. Пишут, что твин надо создавать непосредственно перед использованием. А вот если я захочу его прервать, мне надо где-то хранить данные о нём. Что будет, если я сделаю foo = create_tween() до того, как предыдущий твин foo отработал? Он ведь не останется висеть в памяти, а самоудалится сразу же, как только отработает? 2. Что будет, если я буду твинить один и тот же параметр? Типа, сначала create_tween().tween_property(bar, "rotation", PI, 10.0), а через секунду create_tween().tween_property(bar, "rotation", 0.0, 1.0) - что произойдёт с твинами? Второй отменит первый? Они наложатся? Первый удалится после запуска второго? Будет утечка памяти, мой компьютер взорвётся?
>>912598 Продолжаю делиться наблюдениями. Если сохранить сцену из рантайма, проставив рекурсивно всем детям овнера, и сохранить через ресурс сейвер в .tscn, то по некой магической причине дерево нод потеряет детей после определенной глубины. Тогад как сохраняя в бинарный формат, в .scn, все ок.
>>913366 Я использую так var tween if tween: tween.kill() tween = create_tween() tween.tween_property
>>913372 А я вот чёт подозреваю, что это излишне. Твинил свойства так и эдак, каждый раз создавая новый твин - всегда при запуске нового двина старый просто прекращался; зато килл давал разные визуальные баги, на один кадр анимация улетала в позу отдыха. Как я понял, где-то в дебрях движка есть глобальная таблица всех твинящихся стрингнеймов, а это всего лишь интерфейс к ней. Но пока не стопроцентно уверен.
Посоны, а в чём может быть проблема? В анимации есть воспроизведение звука, при проигрывании через АнимейшонПлеер звук играет; включаю АнимейшонТри, та же самая анимация - звука нет.
А что если делать звуки прямо в игре? Есть что-нибудь для этого? Хочу одну строчку кода, типа play_sound(beep, power, length, ...) и она мне пищит. Насколько разъебет уши такой подход?
>>912890 >Создаётся впечатление, будто десятки часов отлаживать математически сложный код проще, чем подвигать несколько костей (буквально 2-3) в блендере и переимпортировать модельку.
У меня сложилось впечатление, что ты, как и я ранее, не учитываешь костыли. Процедурной анимации не нужно быть полностью самостоятельной -- при отсутствии полной интеграции анимации с полигонами, (а делая на скриптах ты всегда будешь идти окольными путями) твоя анимация только баги породит. Вспомни сталкер, там много чего сделано на скриптах. При смерти тела возле стены существует риск застревания и распидорасивания модели на половину карты. Почему так? Потому что анимация не может проверить, находится ли тело между незримых полигонов иной модели. В противном случае достаточно было бы вернуть тело туда, откуда оно попало в стену. Но этого нет. А рэгдолл -- это полностью процедурная анимация, хоть и крайне примитивная. Ведь она вся на контексте, разве я не прав?
Я веду к тому, что гибрид статической анимации с процедурной был бы и красивее и проще. Можно задать основному телу статическую анимацию, а конечностям -- процедурные. И если персонажу прилетает бочка под ноги, они получают стан и отлипают от земли, отключают выравнивание тела и персонаж шмякается на землю, словно он процедурный. Хотя туловище всё ещё статично и поменялся лишь угол, конечностям включился рэгдолл и выглядит это в итоге близко к гта 4 и 5, но гораздо дешевле, чем учить персонажа держать баланс, и настраивать его так, чтобы он не падал от пинка под зад или пули в ногу, но падал от бочки, да прилетающей не по касательной
Костыли -- лучшее средство оптимизации человекочасов
эйфория кст тоже далеко не идеальна, и костыли могли бы сделать персонажей менее кукольными
>>912942 >Этого не будет в ближайшие 5 лет >Пару лет будут рожать решение >потом еще пару лет Ты куда-то торопишься?
>>913081 >Пользователь пишет на гдскрипте, а на выходе компилируется с++. +15 минут на каждый запуск проекта после изменения всего лишь одной строчки одного скрипта. Доволен?
>Вообще не вижу помех, почему так нельзя было сделать с самого начала? Единственное преимущество - скорость рантайма. В остальном сплошные недостатки.
Киллер-фича Godot в том, что GDScript запускается сразу после нажатия F5/F6 в редакторе. Этап компиляции C++ убивает эту фичу.
>>912949 >Если я держу в руках предмет (например, кружку с чаем) и стремлюсь сохранить его положение в пространстве, я буду делать это, независимо от наклона моего тела, например. Ты точно человек? Попробуй БЕЖАТЬ с кружкой чая. Расплескаешь 100%. Если твоя задача - сохранить чай в кружке, ты будешь идти очень медленно, аккуратно сохраняя положение тела в пространстве.
>Тем более если это оружие, у которого надо не сбить прицел. ИРЛ никто не стреляет прицельно в движении. Как-то случайно изучал эту тему. В движении прицельность стрельбы ЗНАЧИТЕЛЬНО ухудшается. А если ты побежал настолько быстро, что вынужден наклонить тело вперёд, то максимум, что ты можешь сделать с оружием - выстрелить "куда-то туда" с целью психологического давления на противника, чтобы тот не высовывался из укрытия. Попасть в цель ты не сможешь, но звуки выстрелов как минимум напугают врага и дадут тебе время занять новую позицию для прицельной стрельбы из НЕПОДВИЖНОГО состояния.
Короче, если хочешь реализм, то в игре во время движения, особенно быстрого, у персонажа должно отключаться ИК рук, и оружие должно свободно болтаться в руках в соответствии с анимацией ходьбы/бега, если ты не хочешь убирать его из рук. Игрок может нажать кнопку стрельбы, но направление стрельбы будет на 100% определяться анимацией персонажа, а не направлением камеры. Только когда игрок остановился, персонаж направляет оружие туда, куда смотрит камера.
ИМХО, если твоя игра целит в реализм, то персонаж, стреляющий прицельно на бегу с согнутой вперёд спиной, будет выглядеть как минимум комично.
>>913390 Нашёл: >You should avoid using more than one Tween per object's property. If two or more tweens animate one property at the same time, the last one created will take priority and assign the final value. If you want to interrupt and restart an animation, consider assigning the Tween to a variable Кароч работать будет и так, но лучше убивать твина перед натравливанием нового на то же свойство. А то что? А хз, но что-то нехорошее.
>>913564 Ну, допустим, смотря как бежать и прочая. Но тут другое. Сначала я устраняю болтанку насколько могу. То есть, делаю персонажа идеально точным. А поверх этого добавляю разброс, который уже могу контролировать сам, не полагаясь на анимации. ИЧХ, так я могу сделать этот разброс действительно рандомным, тогда как поведение анимации детерминировано. В игре, не забывай, главное геймплей, а не реализм.
>>913461 >При смерти тела возле стены существует риск застревания и распидорасивания модели на половину карты. Почему так? Потому что регдолл состоит из нескольких RigidBody, связанных между собой через Joint: физический движок моделирует движение каждой части тела как независимого тела, но с учётом ограничений на расстояние между ними. Когда игра спавнит регдолл возле стены, часть этих физических тел может оказаться с другой стороны физической коллизии стены, из-за чего физический движок тщетно пытается пропихнуть часть регдолла сквозь неподвижную (StaticBody) стену. Обычно это ведёт к тому, что регдолл застревает рукой/ногой в стене и трясётся, но в худшем случае движок в попытке удовлетворить систему ограничений может нарастить огромный импульс, который отправит регдолл в полёт.
>А рэгдолл -- это полностью процедурная анимация, хоть и крайне примитивная. Вот именно поэтому регдолл и застревает в стенах, трясётся и разлетается по всей карте. Без регдолла тело персонажа будет лежать неподвижно, даже если он частично провалился в стену (что намного лучше, чем когда твой лут улетает вместе с регдоллом в стратосферу или этот регдолл вообще убивает тебя внезапным ударом). Большинству игр регдолл как таковой не нужен, это всего лишь физическая декорация, которая может доставлять проблем игроку.
>Потому что анимация не может проверить, находится ли тело между незримых полигонов иной модели. В противном случае достаточно было бы вернуть тело туда, откуда оно попало в стену. Если ты хочешь, чтобы персонаж не проваливался в стену при смерти, то тебе достаточно сделать однократную проверку безопасной позиции, куда этот персонаж может упасть. Для этого не нужен регдолл от слова совсем, у регдолла другая задача: заставить руки и ноги реагировать на окружающие предметы, будто это конечности тряпичной куклы (ragdoll = тряпичная кукла).
>гибрид статической анимации с процедурной был бы и красивее и проще Именно так и делают обычно, но это всегда сложнее простых анимаций и ничего красивого в этом нет (в смысле технического решения, а не результата).
>если персонажу прилетает бочка под ноги, они получают стан и отлипают от земли Проблема в том, что ты замучаешься настраивать физику ног так, чтобы они не ломали коленки, не скручивались, не застревали в узких местах, не проваливались в пол и т.д. А результат? Оценит ли игрок результат твоих трудов? Кто реально обращает внимание на ноги персонажа и тем более критикует игру за эти ноги? Во многих играх даже лестницы ненастоящие, там тупо наклонная поверхность вместо ступенек, и это в ААА играх. Но игроки не хейтят игру за то, что у персонажа ноги висят над ступеньками. А ты (и другие) предлагаешь соло инди убить кучу времени и сил на то, на что ААА-студии даже не пытаются выделять средства из многомиллионных бюджетов и людей из многотысячных команд.
Тут крайне важен ответ на вопрос: что игрок получит от данной фичи? Как это влияет на геймплей? Если это не влияет на геймплей, то как это влияет на графику, сюжет, восприятие игры? Оправдает ли это влияние затраты на разработку фичи? И т.д.
Конечная цель - сделать игру, в которую игроки будут с удовольствием играть, а не идеально симулировать конечности персонажа.
>>913680 Попробовал уже. Первая добавляет лишнюю вкладку рядом с импортом - вкладок в годоте и так завал. Вторая как я понял для игры, не для редактора. Третья по сценам. Последняя тоже вкладковая. Хочу просто текстовый файл с форматированием/подсветкой, как код но не код. Поддержку маркдауна так и не завезли?
>>913942 >Я потерял мотивацию ну так ты небось платформер очередной хотел сделать или еще какую хуйню банальную 100500ую. Конечно твое подсознание понимает заранее, что даже если ты прям внаутре это сделаешь и нигде не проебешься, то получится очередной кал говна за 20р в стиме, который 1,5 мимокрока откроют, кекнут, и удалят нах. Садись писать игру мечты, забудь о комерции и дедтаймах, только на это будет реальная, живая мотивация. Всё остальное суходрочка и проебывания жизни в никуда.
>>913683 >Хочу просто текстовый файл Пиши прямо в редакторе кода, только в .txt-файл.
>с форматированием/подсветкой, как код но не код >Поддержку маркдауна так и не завезли? Зачем это всё в редакторе игровых сцен? Скачай специализированное ПО и не перегружай редактор васянскими плагинами для лишних украшательств.
Я тоже как-то хотел сделать плагин на эту тему, но потом понял, что смысла изобретать велосипед в неподходящем для этого месте нет.
Как по мне, интерфейс Godot и без того избыточен. Ещё далеко до Blender, но уже не минимализм.
>>913942 >Игры делоете? Делою. Она маленькая, так что любой прогресс ощущается как прогресс и приближение в релизу. Идей куча, мотивация есть, слот в Стиме заготовлен. Интереса у людей правда пока 0, но я толком пиар и не начал, кроме пары темок с логами разработки.
>>913953 Оно простое, если нужна простая картинка. Вот вообще очень простое. Проблемы начнутся если захочется карсивых теней, запекания цвета, каких то постпроцесс эффектов вроде обводки. Костыли нужны бывают.
>>913942 Сейм, но делал игру мечты, в итоге загнался и понял что она скорее всего никому не будет интересна как и оказалось и хуй знает как в случае условного успеха и какой-то материальной поддержки идеи снять донатики, ну и вкинул кривую но с конкретными задачами версию на итч и яндекс
>>913978 Я бы мог сказать, что это, но меня забанят за политоту. Так что оформи свой вопрос тредом в ньюсаче (под видом новости "гугл плей ввёл дедлайны"), там тебе отвечу.
>>913944 >ну так ты небось платформер очередной хотел сделать Формально основные механики и место действия сводят геймплей к 3D платформеру. Другие мои проекты не имели ничего общего с платформерами, но в них играть оказалось совсем не интересно или основная идея была слишком сложной для меня.
>Садись писать игру мечты, забудь о комерции и дедлайнах, только на это будет реальная, живая мотивация. С годами понял, нет у меня никакой "игры мечты". По играм у меня часто бывают мимолётные фантазии уровня "было бы круто поиграть в такую игру" (часто на основе того, во что я недавно играл), но такое обычно либо тяжело реализовать, либо вообще невозможно, а если даже легко сделать - надоедает спустя день/неделю. Поэтому у меня куча идей/проектов, которые я записал/начал делать, а потом забросил и забыл. К некоторым я иногда пытаюсь вернуться, но потом снова бросаю.
>>913986 > У меня не РФ В смысле, не по референсу значение передаётся? В гдскрипте есть обходной путь, как передать по референсу. Оборачиваешь своё значение в словарь и затем передаёшь. > var by_ref = {"value" : 42} ... > func deal_something(data): data.value += 1 ... > deal_something(by_ref) > print(by_ref.value) # напечатает 43
> С годами понял, нет у меня никакой "игры мечты". По играм у меня часто бывают мимолётные фантазии уровня "было бы круто поиграть в такую игру" (часто на основе того, во что я недавно играл), но такое обычно либо тяжело реализовать, либо вообще невозможно, а если даже легко сделать - надоедает спустя день/неделю. Поэтому у меня куча идей/проектов, которые я записал/начал делать, а потом забросил и забыл. К некоторым я иногда пытаюсь вернуться, но потом снова бросаю.
Литералли ми! Поэтому я забил на игры и делаю проги, используя годот как удобное ИДЕ с удобным лично мне ГУИ-фронтендом.
>>913999 > делаю проги Тем более в четвёрке запилили многооконность. Вот бы ещё сделали оконный рендер, без видеокарты вовсе, чтобы на любой встройке запускалось, разумеется, никаких шейдеров и т.п.
Пытаюсь экспортировать проект. Годо просит с меня шаблоны экспорта. При попытке скачать автоматически загрузка постоянно прерывается. Вопрос: где взять файлы? Гугл выдает просто доки.
>>914024 Лично мне не нравится, что у четвёрки никак не поменяли иконку. Хоть как-нибудь. Я щас поочерёдно открываю тройку для поддержки старого проекта и четвёрку для разработки нового. Очень неудобно их различать визуально.
>>913996 Такое приятное ощущение, когда твой персонаж на экране наконец-то оживает...
>>914031 >если бы кто-нибудь нарисовал действительно что-то годное Да ладно, и так сойдёт.
>>914033 >Хуясе у неё ляхи Она худенькая. (˵ ͡° ͜ʖ ͡°˵)
>у четвёрки никак не поменяли иконку >Я щас поочерёдно открываю тройку для поддержки старого проекта и четвёрку для разработки нового. Очень неудобно их различать визуально. Сделай ярлыки со своими иконками (в Windows 10 отображаются на панели задач после запуска).
>>914036 >Можешь посмотреть Umihara Kawase. Спасибо, не знал, прикольная серия игр.
>>914041 Помощь с проектом нужна? Контакты не дам. Выкладывай таски (задания) прямо в тред. По мере готовности буду выкладывать готовое на файлообменники и ссылку ответом на пост. Могу в кодинг. В том числе отрефакторить или допилить твой код. Могу написать охуительных историй в рамках твоего сеттинга про воздушные острова с толщекораблями и забиндить в диалоговую систему, или в систему глоссария, которые у тебя есть. Есть же? В графониум не могу ни в каком виде, увы.
>>914070 >Контакты не дам. Выкладывай таски (задания) прямо в тред. По мере готовности буду выкладывать готовое на файлообменники и ссылку ответом на пост. Уровнем разработки удовлетворён.
>>914106 >чатгпт использую А ты видел они добавили поддержку ДАЛЛИ в чатГпт? Правда я так и не смог заставить его нарисовать что-нибудь. Кидаю свой концепт, прошу его дорисовать один момент, чтобы прикинуть как это будет выглядеть. Он такой "окей, подождите немного, мне нужно время". Через 20 минут спрашиваю "ну ты чё ёбаный в рот, где картинка?". А он "Извините, я не могу дорисовывать существующие картинки бла-бла". Ну хз. Я огорчен.
>>914041 >Сделай ярлыки со своими иконками Я так и сделал. Но всё равно, какого хуя? Организовали бы конкурс на лучшую иконку. Сообщество огромное, художников дохуя. Кинуть клич, получить тысячу иконок, устроить голосование - профит! В итоге даже и на поменять нечего выбрать: https://godotengine.org/press/ Вот если б хотя бы были варианты - плоская, объёмная, пикселяртная, линиями, какие там ещё есть стили иконок я хз.
>>914165 Разве в 3.5 добавили? Но энивей, я пользуюсь ими отдельно друг от друга. А вот если кто-то научится законченные юзабельные 3д модельки генерить - даже подписку оплачу наконец.
Посмотрел видосики выше и заметил, что верёвка крюка-кошки натягивается не по физике. Как считаете аноны, как пофиксить это? Стоит ли создавать полноценную симуляцию физики в чарактербоди? Или может есть способ на лету менять игроку тип тела с чарактер на ригид? Чтобы значит, пока ходишь у тебя чарактер, а как летаешь на крюк-кошке, тело переключается на ригид с джойнтами и управляется по физике импульсами с полной поддержкой веса, столкновений, инерции искаропки.
Какой "свет" в 3д самый дешевый? Запеченый? Или emissive+hdr? Или есть что-то еще? Мне нужно подсветить область, реализм не важен, и в 2д я бы туда поставил просто полупрозрачную круглую текстуру.
Привет геймдевач, нулевой вкатун с двухзначным айкью на связе. Прохожу тутор по этому вивдево. https://www.youtube.com/watch?v=-4jEXTwTsVI&t=978s Там мужик создает scene в ней новый node и в поиске выбирает kinematic body 2d. Видево от 2021 года у меня самая новая версия. Они переименовали этот node? Что мне делать?
>>914488 Ясен спасибо. Похоже зачем то дохуя переиминовали в новом апдейте. Есть смысл продолжать тутор по старой версии или сильно много еботы и лучше найти тутор по 4ой?
>>914489 > Есть смысл продолжать тутор по старой версии Есть. Ты основы учишь, а не детали переименования узлов. Просто скачай свежую трёшку и учись на ней. Будет у тебя LTS-версия движка. Как научишься базе, основам, так самостоятельно на четвёрку перекатишься.
Нашел новый урок, следовал полностью тутору, вышла такая вот ошибка, почему так? >>914491 Да, нашел почти такой же урок, для новой версии. >>914497 А какой в этом плюс в сравнении с тем, что бы сразу на 4ке учиться?
>>914501 >А какой в этом плюс в сравнении с тем, что бы сразу на 4ке учиться? Туторов в разы больше. Плюс, если какая-то ошибка, то она точно не из-за отличающейся версии, а из-за твоей криворукости. Вот как здесь. Ты невнимательно следовал тутору. И вообще очень невнимателен. 1. Проверь, к какой ноде прикреплён скрипт. Сравни, к какой надо, согласно тутору. 2. (сверх того) У тебя там то velocity, то velocoty, то вообще veloci. Ты определись уже, как переменную зовут.
>>914503 Я вообще нихуя в этом ваше кодинге не понимаю, от слова совсем. Да вилосити я например пофиксил. К ноде плеер я прикрепил скрипт, у челобасика тоже к Player. https://www.youtube.com/watch?v=pBoXqW4RykE У меня node type :Node2d У этого чела на плеере маленький челебасик бегущий, вероятноу него type:CharacterBody2d Но это не точно. Как анон ниже написал, >>914511 В ноде CharacterBody2D не нужно обьявлять переменную. Но хуй из тутора не уточнил, что это актуально для определенных нодов, сказал просто что не нужно. Ну я вообщем уже ее обьявил, ошибка ушла.
Что это значит Function "move_and_slide()" not found in base self. Я сейчас ищу в документации к Годоту, но там пиздец стены текста написанные для какихто альтруистов, я простохочу игру с сиськами запилить, а не кулхацкером становится.
>>914514 Блядь нельзя просто в программе было написать, что там неработает. На дворе 2023 год, там хомяки визжат, что у них чатгтп работу заберет. А мне нужно выходить из проги, идти на какой-то доисторический форум и читать стены текста. Чаму так? Где иновации, когда наступит будущее?
>>914514 Посмотри на 2:30, как он создаёт ноду для персонажа.
>Я вообще нихуя в этом ваше кодинге не понимаю, от слова совсем. Выбирай, кем ты хочешь быть. Долбоёбом, не умеющим и не желающим учиться? Или геймдевом, мастером на все руки? Хочешь делать игры - придётся собирать мозги в кучку и вникать. Тут хуяк-хуяк не прокатит. Анон с тобой за ручку всю игру не сделает. Придётся научиться понимать и читать доки.
>>914520 Анончик, мне 35 лет, я уже в жизни куда более сложные вещи учил. Тут просто какой-то каменный век, похоже. Кодеры этой штуки не брали в расчет что бы прога была user friendly от слова совсем. Почему она просто мне не скажет, в чем там ошибка? Вот захожу я в документацию Какая-то ахуенная прохладная история, которая мне совершенно никак не помогает. И что дальше делать, ага блядь один бьект скользит по другому, только что ощибка значит, нигде не написано?
bool move_and_slide ( )
Moves the body based on velocity. If the body collides with another, it will slide along the other body (by default only on floor) rather than stop immediately. If the other body is a CharacterBody2D or RigidBody2D, it will also be affected by the motion of the other body. You can use this to make moving and rotating platforms, or to make nodes push other nodes.
Modifies velocity if a slide collision occurred. To get the latest collision call get_last_slide_collision, for detailed information about collisions that occurred, use get_slide_collision.
When the body touches a moving platform, the platform's velocity is automatically added to the body motion. If a collision occurs due to the platform's motion, it will always be first in the slide collisions.
The general behavior and available properties change according to the motion_mode.
Returns true if the body collided, otherwise, returns false.
>>914522 Тогда ты должен знать что сходу ничего комплексного не делается. Не спеши, выбери другой гайд, третий, почитай документацию и постепенно все получится.
>>914522 >>914514 >Блядь нельзя просто в программе было написать, что там неработает. Так вон написано же: >Function "move_and_slide()" not found in base self В ноде (которая для этого скрипта является self) отсутствует функция move_and_slide(). Может быть, ты в скрипте не объявил? А может, это нода не та? А может, опечатка? Да хуй знает, редактор же не может телепатически проникнуть в твой разум и узнать, что же ты имел ввиду. Но ошибка - вот она, человеческим языком написана.
>>914522 Пчел, прога максимально юзер френдли. Но у проги нет задачи научить тебя любому нюансу кодинга с которым ты столкнулся, потому что у миллиона новичков непонимание возникает в миллионе разных мест. В ошибке же все четко function "move_and_slide" not found in base self. Ты вызываешь функцию без объекта (someobj.function()) Значит ты вызываешь ее у самого объекта к которому прикреплен скрипт (self, "у себя") Функция с таким названием не найдена в базовом классе Базовый класс - тот, от которого твой скрипт extend Смотрим, а у тебя extend от Collision Shape (формы коллизии) А move and slidе где? В классе KinmaticBody
>>914521 Я полностью повторил за ним структуру нодов, но ошибка та же. Проблема с документацией в том, что она слишком обширная. И например у меня ошибка в скрипте, но у меня нет возможности конкретно об этой ошибке прочитать. Function "move_and_slide()" not found in base self. Но если я загоняю это в гугл, то нахожу только кучу текста о том, что такое эта функция, но все что я хотел, что бы спрайт управлялся стрелочками, но касаемо этого информации я найти не могу. Может быть это слишком очевидно, но почему тогда такие очевидные проблемы не объяснить инфотекстом в самой программе? >>914523 Ну это шутка была, я художник, там учеба немного иначе происходит. Технических знаний у меня нет. Похоже я повелся на инфоциган с ютуба, которые уже год кукарекают, что нейронки все уже за тебя делают, но похоже даже для примитивной top down rpg Нужно ебаться. >>914524 >В ноде (которая для этого скрипта является self) Спасибо что написал, теперь попробую в эту сторону гуглить. Я пытался найти что такое self base, Но там что-то максимально обстрактное на несколько страниц было. >>914525 >Но у проги нет задачи научить тебя любому нюансу кодинга с которым ты столкнулся, потому что у миллиона новичков непонимание возникает в миллионе разных мест И где мне это все узнавать, не пойду же я на 5 лет в универ, что бы 16 битную джейрпг запилить, это архаичная техника которую диды пилили на тостерах, до того как я родился? >in base >self. Ну например это уже какой-то жаргон и даже не ясно это понятие из программирования в общем или конкретно к гадоту относится.
>Ты вызываешь функцию без объекта (someobj.function()) >Значит ты вызываешь ее у самого объекта к которому прикреплен скрипт (self, "у себя") >Функция с таким названием не найдена в базовом классе >Базовый класс - тот, от которого твой скрипт extend >Смотрим, а у тебя extend от Collision Shape (формы коллизии) >А move and slidе где? В классе KinmaticBody Я раз 15 прочитал, нихуя не понял, что делать?
>>914526 >не пойду же я на 5 лет в универ, что бы 16 битную джейрпг запилить >я хочу стать сеньором помидором, не пойду же я изучать погроммирование 10 лет, что делоть? Найди программиста, ты не сможешь ничего спрогать, не мучай жопу, художник, только время проебешь. Чтобы даже простое программировать нужно много потрудиться, хотя бы годик нейроночку мозговую пообучать. Никакими чатами гпт ты воспользоваться не сможешь, нужно самому понимать что делаешь.
>>914526 >Я раз 15 прочитал, нихуя не понял, что делать? Ты наследуешь от неправильного класса. Функция move_and_slide находится в CharacterBody2D, а ты в extend наследуешь от CollisionShape2D.
Кроме того, у тебя скрипт-файл прикреплен не туда (надо к CharacterBody2D).
Посмотри свой видеогайд внимательно. Там чел делает правильно. И повторяй точь-в-точь. И слушай его объяснения. В программировании каждая буковка важна. И пожалуй я тебе посоветую не отклоняться от гайда слишком сильно - тебе это рано. Пройди 3-4 гайда, прочувствуй основные моменты - тогда пытайся свое, основываясь на чужом.
>>914526 >Я полностью повторил за ним структуру нодов Нет, не повторил. У чарактербоди есть и велосити, и функция move_and_collide. Он создал чарактербоди. Ты - нет. Создай чарактербоди и к нему прикрепи скрипт. Повторяй за ним каждое движение мышкой. Нет, я серьёзно. Даже по тому, как ты пишешь, видно, что ты очень невнимателен к деталям. Именно из-за этого упускаешь ключевые вещи. Так как ты пока не знаешь, что именно ключевое, надо быть гипер-сфокусированным на деталях.
>если я загоняю это в гугл Эта ошибка может случиться в миллионе разных ситуаций. Эти ситуации обычно возникают у нубов (вот как у тебя) и решается путём вставления мозгов на место. То есть, дело не в том, что ты что-то конкретное неправильно делаешь. А в том, что ты пока не вкурил, как это в принципе работает.
Повторюсь. Проблема уже решена, у тебя нода неправильная. Но теперь ты должен понять, как её сделать правильно. Просто повтори всё в точности как в туторе - и у тебя получится.
>я художник Бро, я музыкант. В Годо залипаю с 2020.
>архаичная техника которую диды пилили на тостерах, до того как я родился Те диды были покруче всего /гд/ вместе взятого так-то. Могли целую жрпг упихать в 64 килобайта картриджа.
>>914527 Не я понимаю, что это выглядит как буд-то залетный ебанат пришел и начал качать права. В общем так и есть. Я буквально вчера на твиторе видел чувак тред составлял мол он абсолютно с нуля загенерил говноарт в миджорни и код ему четгпт написал и он за 2 часа сделал клон angry birds. Я реально подумал что маленькую игорю написать не слжоно будет. И немного ахуел с самого старта. С чего нулевому вкатуну начать, эти ахуенные курсы рпг за 2ь минут, тоже очевидная хуита расчитаная на людей с опытом. >>914530 >Кроме того, у тебя скрипт-файл прикреплен не туда (надо к CharacterBody2D). Все равно та же ощибка выходит. >Посмотри свой видеогайд внимательно. Да я и так смотрел постоянно отматывая назад, только он нихуя толком не пояенсяет. Типа хуякс-хуякс тут кликнул ага и чувак забегал по экрану.
>>914531 Ну вроде реально все за ним повторил, единственное что у него нода для анимации персонажа, а у меня анимации нет и я спрайт выбрал вместо этого. Похоже реально нужно было рпг мейкера качать, но в той говнине 0 мотивации разбираться, если даже и вкачусь в нее нормально, все равно она жутко кастрированная и придется перекатываться, лучше сразу нормально учить.
>>914533 М-да, вот для таких случаев нужен препод. Чтобы сидел рядом и показывал: вот тут ты накосячил, вот тут, а теперь сосредоточься вот на этом.
>говноарт в миджорни и код ему четгпт написал А почему ты так не сделаешь? (вообще, я скажу, почему. Потому что есликогда чатгпт накосячит, исправлять придётся тебе, а это шарить надо)
>>914538 >М-да, вот для таких случаев нужен препод. Так хороший препод наверное будет стоить, так же как хороший кодер, кто за тебя твою игорю и напишет. >А почему ты так не сделаешь? Я когда этот кал на хайпе был, потыкал в него немного, крайне тупая и бесящая штука. Буквально симулятор среднестатистического штипостера в интернете. А там еще вроде и подписка нужна, короче я к этому говну не притрагивался с тех пор и не собираюсь. Ну а миджорни и говорить не стоит, буквально калогенератор, для людей без души.
>>914539 >автокоррекция годота Нет такой штуки. Вот тут >>914514 у тебя вообще скрипт к Node2D прикреплён, а экстендс всё так же коллижоншейп. Эта строчка генерится автоматически в момент создания скрипта. Скорее всего, ты его сначала по ошибке прицепил к коллиженшейпу, весь написал, он ожидаемо не заработал, и ты стал его весь целиком копипастить (или просто переприкреплять один и тот же уже созданный файл) сначала в ноде2д, потом в чарактербоди.
>>914541 >крайне тупая и бесящая штука Ну хуй знает, мне вот недавно надо было сайт сделать, так яндексовый гпт вполне сносно справился со всеми вопросами про пхп. Вроде как с Годо 3.5 у него тоже всё отлично. С 4, очевидно, нет, не успели обучить ещё.
>Так хороший препод наверное будет стоить, так же как хороший кодер Зато сэкономит кучу времени и нервов на стадии обучения.
>>914543 >Ну ты дед Не отрицаю. Тащемта, я ровесник ху_дожника. Просто последний раз сайт делал году эдак в 2008 на народе, на чистом хтмл+цсс, и с тех пор не лазил в том направлении. Задача была - с минимальными затратами на обучение сделать для себя за пару вечеров полу-статический сайт на бесплатном хостинге. Пхп идеально подходит под эту задачу, он супер прост в освоении и на хостинге был предустановлен.
На гдскрипте, очевидно, можно написать серверную часть сайта, но это бессмысленно. Как минимум, потому что гдскрипту нужен годот, годоту нужно графическое окружение, а ставить на сервер графическое окружение никто в здравом уме не будет.
Хуйдожник кстати после проеба вполне успешно запилил анимацию на движение в различном направлении и вполне себе понял код. Синтакс правда не совсем понятен. Оказывается играет роль насколько новая строчка, например if имеет табов растояния от начала. Помню в школе какую-то хуиту учил, C или что там было не помню, но там такого не было. И что означают "." "_" или доллар тоже не совсем ясно.
Синтаксис питоно-подобный. Скорее всего питон ты в школе и учил. Тут влияет отступ, чем глубже вложенность (иф внутри иф), тем больше отступ.
_ это ты про префикс переменных и функций. Им обозначаются функции/переменные, дерганье которых не запланировано снаружи скрипта, в котором они обозначены. Приватные крч. Но это условность, на уровне движка это не энфорсится.
. - доступ к членам класса/объекта/структуры
Через доллар ты указываешь путь к ноде. В редакторе слева у тебя древо нод - вот это и указываешь.
>>914551 куда ты лезешь с таким отношением? Где-то когда-то в школе видел какую то хуету, ебать тут отступы что-то значат, а что значат эти закорючки ... Двиньте ему по башке кто поближе это просто невыносимо.
>>914585 Не все любят питоноподобный синтаксис. Я, кроме самого питона, табуляцию как часть синтаксиса видел еще в BYOND ебучем. Не помню уже что в C#.
Хочу вкатиться но помимо официальной документации очень мало полезной информации в виде текста, все снимают видео туториалы для школоты. Есть информация о примерной структуре проекта? Как понять что эту механику лучше разбить на компоненты? Паттерны программирования?
Что за белые полосы по краям экрана, когда запускаю fullscreen? И еще есть проблема, как только ставлю mouse_captured, то экран начинает как бы моргать позади окна игры, если не в фул скрине запущено, но если перенесу окно на другой монитор, или скрою сам окно движка, то все ок.
Что за белые полосы по краям экрана, когда запускаю fullscreen? И еще есть проблема, как только ставлю mouse_captured, то экран начинает как бы моргать позади окна игры, если не в фул скрине запущено, но если перенесу окно на другой монитор, или скрою сам окно движка, то все ок.
Делаю диалоговую систему по видосам, такая хрень вылезла. Че с этим делать? res://addons/dialogue_nodes/editor/workspace.gd:64 - Invalid get index 'close_request' (on base: 'GraphNode (startNode.gd)').
Вопрос от "еще не смешарика" Ниче не знаю, ниче не умею, но хочу попробовать соприкоснуться с созданием игорь. Но сидеть и учить документацию по строчке пока не готов, поэтому хочу спросить совет.
Посоветуйте, пожалуйста, пример простой игры (змейка/ тетрис/три в ряд и т.д.) который стоит повторить в учебных целях.
Идей много, но вот какой учебный проект взять что бы не было слишком перегружено, но и не в одну кнопку.
Привет, Сосач. Недавно заценил демки Godot'а, такие как TPS Demo (для четвёрки есть версия на Гитхабе), Abandoned Spaceship Demo & Desert Light Demo. Во всех трёх случаях я жёстко охуел с высокой загрузки GPU. Кто-нибудь подскажет, это демки плохо оптимизированы или Godot в принципе плох для 3D? Можно ли исправить производительность с помощью RenderingServer (ни в одной из демок таковой не используется напрямую)?
>>910890 (OP) Сап двач, есть один GridContainer, который не отображает мои ColorRect. На пике-1 код, который работает в Node2D и всё отрисовывает (пик-2 - работа кода на Node2D), а внутри GridContainer срать он хотел на мои квадратики, бака. Что я делаю не так?
>>944579 Space Invaders поделай. Пошагово можно поиграться сначала с позициями кораблика-игрока, нарисовать одного врага и пострелять в него, потом поиграть с окружением, потом - с кучей врагов, коллизиями и прочим.