Этого треда уже нет.
Это копия, сохраненная 31 июля 2021 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
Это копия, сохраненная 31 июля 2021 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
61 Кб, 270x270С чего начать?
С изучения документации. Если не можешь в инглиш, и даже в гугл-переводчик, то начат перевод официальной документации: https://docs.godotengine.org/ru/latest/
Но вообще, будь мужиком и изучи английский: https://godot.readthedocs.io/en/stable/
Вместе с движком обязательно смотри примеры, там есть всё - от платформера до чата. Примеры качаются прямо в движке через свой магазин.
Скачать движок: https://godotengine.org/download/ или http://store.steampowered.com/app/404790/Godot_Engine/
FAQ: https://docs.godotengine.org/ru/latest/about/faq.html
Игры, созданные глобальными кириллами: https://godotengine.org/showcase или https://steamcommunity.com/app/404790/discussions/0/412448792354265655/
Скажи "Годот круто!" https://github.com/Calinou/awesome-godot - подборка дополнений, модулей и минишоукейс от одного из авторов.
Годнота от анона:
Для приверженцев опенсорца существует возможность распрострянять проекты в незапакованном формате. Просто скачай темплейт с оф.сайта и положи экзешник/эльфешник в папку с проектом, этого достаточно. Дополнительно можешь вшить свою иконку в экзешник. После этого, запустившийся файл темплейта обнаружит рядом с собой файл project.godot и начнет грузить проект из него и из файлов, лежащих в распакованном виде в той же директории.
Редактор персонажей на основе makehuman: https://github.com/Lexpartizan/Go_MakeHuman_dot
Все языки в одном месте: https://vk.com/topic-70467171_35982467
Тест-бенчмарк:
Веб-версия - https://govdot.herokuapp.com
Вишмастер для винды - https://govdot.herokuapp.com/4Anon.rar
Предыдущий тонет там: >>635427 (OP)
Архивы:
1 http://arhivach.ng/thread/207802/
2 http://arhivach.ng/thread/388500/
3 http://arhivach.ng/thread/388501/
4 http://arhivach.ng/thread/388502/
5 http://arhivach.ng/thread/388503/
6 http://arhivach.ng/thread/432708/
7 http://arhivach.ng/thread/433902/
8 http://arhivach.ng/thread/436355/
9 http://arhivach.ng/thread/455461/
10 http://arhivach.ng/thread/479963/
11 http://arhivach.ng/thread/489815/
12 http://arhivach.ng/thread/494513/
13 http://arhivach.ng/thread/515567/
С изучения документации. Если не можешь в инглиш, и даже в гугл-переводчик, то начат перевод официальной документации: https://docs.godotengine.org/ru/latest/
Но вообще, будь мужиком и изучи английский: https://godot.readthedocs.io/en/stable/
Вместе с движком обязательно смотри примеры, там есть всё - от платформера до чата. Примеры качаются прямо в движке через свой магазин.
Скачать движок: https://godotengine.org/download/ или http://store.steampowered.com/app/404790/Godot_Engine/
FAQ: https://docs.godotengine.org/ru/latest/about/faq.html
Игры, созданные глобальными кириллами: https://godotengine.org/showcase или https://steamcommunity.com/app/404790/discussions/0/412448792354265655/
Скажи "Годот круто!" https://github.com/Calinou/awesome-godot - подборка дополнений, модулей и минишоукейс от одного из авторов.
Годнота от анона:
Для приверженцев опенсорца существует возможность распрострянять проекты в незапакованном формате. Просто скачай темплейт с оф.сайта и положи экзешник/эльфешник в папку с проектом, этого достаточно. Дополнительно можешь вшить свою иконку в экзешник. После этого, запустившийся файл темплейта обнаружит рядом с собой файл project.godot и начнет грузить проект из него и из файлов, лежащих в распакованном виде в той же директории.
Редактор персонажей на основе makehuman: https://github.com/Lexpartizan/Go_MakeHuman_dot
Все языки в одном месте: https://vk.com/topic-70467171_35982467
Тест-бенчмарк:
Веб-версия - https://govdot.herokuapp.com
Вишмастер для винды - https://govdot.herokuapp.com/4Anon.rar
Предыдущий тонет там: >>635427 (OP)
Архивы:
1 http://arhivach.ng/thread/207802/
2 http://arhivach.ng/thread/388500/
3 http://arhivach.ng/thread/388501/
4 http://arhivach.ng/thread/388502/
5 http://arhivach.ng/thread/388503/
6 http://arhivach.ng/thread/432708/
7 http://arhivach.ng/thread/433902/
8 http://arhivach.ng/thread/436355/
9 http://arhivach.ng/thread/455461/
10 http://arhivach.ng/thread/479963/
11 http://arhivach.ng/thread/489815/
12 http://arhivach.ng/thread/494513/
13 http://arhivach.ng/thread/515567/
>>43197
Не в моём случае.
Не в моём случае.
>>643179 →
Нашел способ воспроизвести краш с 100% вероятностью. Надо войти в режим прокладывания маршрута, и начать быстро кликать по своим зданиям, возможно, при этом немного прокручивая карту
Не знаю точно, что происходит, но в один момент вылетает ошибка. Игре кажется, что после этого с ней все в порядке, но на самом деле ей уже настал omae wa mou shindeiru.
Текст ошибки намекает на обработчик мыши и его параметры. Возможно, ты где-то не дописал аргументы?
P.s. игра не выносит ресайз окна, но это ты исправишь покурив http://docs.godotengine.org/en/3.2/tutorials/viewports/multiple_resolutions.html
Нашел способ воспроизвести краш с 100% вероятностью. Надо войти в режим прокладывания маршрута, и начать быстро кликать по своим зданиям, возможно, при этом немного прокручивая карту
Не знаю точно, что происходит, но в один момент вылетает ошибка. Игре кажется, что после этого с ней все в порядке, но на самом деле ей уже настал omae wa mou shindeiru.
Текст ошибки намекает на обработчик мыши и его параметры. Возможно, ты где-то не дописал аргументы?
P.s. игра не выносит ресайз окна, но это ты исправишь покурив http://docs.godotengine.org/en/3.2/tutorials/viewports/multiple_resolutions.html
>>43212
Ввёл логирование с помощью файла. Доступ к логам в игровом меню (которое раньше было пустым). Если на сайте с созданием файлов все ок, то в скором времени отладка у пользователей будет без проблем. Спасибо за детальный разбор ошибки! В скором времени её поправлю и выложу новую версию.
Ввёл логирование с помощью файла. Доступ к логам в игровом меню (которое раньше было пустым). Если на сайте с созданием файлов все ок, то в скором времени отладка у пользователей будет без проблем. Спасибо за детальный разбор ошибки! В скором времени её поправлю и выложу новую версию.
>>43212
Твой баг поправил, новую версию залил. Логирование через файл на html-5 не пашет.
Твой баг поправил, новую версию залил. Логирование через файл на html-5 не пашет.
Короче сделал сигналы и привёл в порядок queue_free, теперь всё зробит
Допустим у меня есть очень много button которые делают одно и тоже, можно как-то объединить их? Чтобы при нажатии любой они давали один сигнал, а не для каждой прописывать.
157 Кб, 1502x606>>43292
Ты можешь поступить так, как я показывал в прошлом треде.
Пройтись в цикле по всем кнопкам и всем им подключить один сигнал.
Ты можешь поступить так, как я показывал в прошлом треде.
Пройтись в цикле по всем кнопкам и всем им подключить один сигнал.
>>43295
Двачую этого.
Кроме того, у сигналов есть возможность привязки к ним любых дополнительных данных, в качестве которых можно указывать ссылку на кнопку. Таким образом, все кнопки будут выполнять один обработчик сигнала, но подавать на вход ссылку на себя:
for button in buttons.get_children():
-> button.connect("pressed", self, "on_arraybtn_pressed", [button])
func on_arraybtn_pressed(sender):
-> print(sender.name)
Двачую этого.
Кроме того, у сигналов есть возможность привязки к ним любых дополнительных данных, в качестве которых можно указывать ссылку на кнопку. Таким образом, все кнопки будут выполнять один обработчик сигнала, но подавать на вход ссылку на себя:
for button in buttons.get_children():
-> button.connect("pressed", self, "on_arraybtn_pressed", [button])
func on_arraybtn_pressed(sender):
-> print(sender.name)
Пополняем библиотеку ассетов
https://godotengine.org/asset-library/asset/514
https://godotengine.org/asset-library/asset/514
>>43331
Тому що ты пидар
Тому що ты пидар
>>43331
хтмл5? Там какие-то проблемы с схоронением. При работе в браузере сохранение в файлы должно прозрачно заменяться схоронением метаданных в локальное хранилище браузера. Однако там есть куча подводных камней, с которыми я попытался разобраться, но потом хзабил.
хтмл5? Там какие-то проблемы с схоронением. При работе в браузере сохранение в файлы должно прозрачно заменяться схоронением метаданных в локальное хранилище браузера. Однако там есть куча подводных камней, с которыми я попытался разобраться, но потом хзабил.
Я не вкатывальщик и вкатываться не планировал. Просто так вышло что я здесь. Если кто-то хочет потешить свое самолюбие за счет моей глупости или получить плюсик в карму, пожалуйста поотвечай на мои слишком тупые вопросы.
Пока только два :
1)Как ограничить движение 2д камеры? Камера передвигается перетаскиванием мышкой и wasd со стрелочками, и если как ограничить передвижение у стрелочек я понимаю, то как с перетаскиванием неебу. Желательно чтобы при отдалении камеры колесиком я не выходил за пределы.
2) Нужно перелистывание слайдов, я примерно понимаю как это можно сделать. Нажимаешь на кнопку - выключает видимость X, включает видимость Y, еще раз выкл Y вкл Z. Но как это сделать покрасивее и удобнее? Не прописывать же вкл/выкл для 15 слайдов допустим.
Пока только два :
1)Как ограничить движение 2д камеры? Камера передвигается перетаскиванием мышкой и wasd со стрелочками, и если как ограничить передвижение у стрелочек я понимаю, то как с перетаскиванием неебу. Желательно чтобы при отдалении камеры колесиком я не выходил за пределы.
2) Нужно перелистывание слайдов, я примерно понимаю как это можно сделать. Нажимаешь на кнопку - выключает видимость X, включает видимость Y, еще раз выкл Y вкл Z. Но как это сделать покрасивее и удобнее? Не прописывать же вкл/выкл для 15 слайдов допустим.
>>43347
В смысле UWP? Приложение шындовс-маркета штоле? Вообще не пробовал туда экспортить.
В любом случае, смотри директорию, в которую выгружаешь на наличие ожидаемых тобой файлов.
В смысле UWP? Приложение шындовс-маркета штоле? Вообще не пробовал туда экспортить.
В любом случае, смотри директорию, в которую выгружаешь на наличие ожидаемых тобой файлов.
>>43352
win32 или как его (exe)
Оказалась какая-то проблема с правами доступа у годота.
С ноута и компа знакомого всё работает, хз.
>В смысле UWP
win32 или как его (exe)
Оказалась какая-то проблема с правами доступа у годота.
С ноута и компа знакомого всё работает, хз.
>>43346
1. Ограничить движение камеры точно так же, как ограничить любую переменную по диапазону: проверяешь выход за границы диапазона и отменяешь изменение.
2. Максимально абстрактный вопрос. Как сделать красиво? Нужно обладать вкусом. И сделаешь красиво. Чтобы обладать вкусом, нужно перелопатить определенное количество контента, в нашем случае игр. И тогда начнёшь понимать, что красиво, а что нет.
1. Ограничить движение камеры точно так же, как ограничить любую переменную по диапазону: проверяешь выход за границы диапазона и отменяешь изменение.
2. Максимально абстрактный вопрос. Как сделать красиво? Нужно обладать вкусом. И сделаешь красиво. Чтобы обладать вкусом, нужно перелопатить определенное количество контента, в нашем случае игр. И тогда начнёшь понимать, что красиво, а что нет.
>>43353
Не может этого быть. Директория user://в корректно работающей винде это директория к которой у данного юзера полные права. Значит у тебя винда зверь-сиди.
Не может этого быть. Директория user://в корректно работающей винде это директория к которой у данного юзера полные права. Значит у тебя винда зверь-сиди.
>>43346
1. Да в общем то так же. У тебя где то выставляется координата x и y.
Насчет колесика - ну ты можешь высчитать сколько пикселей видно на экране, и на столько отступить от лимита. Наверняка и готовое решение можно нагуглить. Какую нибудь rts камеру.
2. Можно много чего сделать, во-первых массив или список. Опять же смотри пример >>43295
Эффекты можно разные сделать, затухания там.
А можно вообще просто сделать большой "уровень" и выставить твои слайды по порядку, и летать камерой.
1. Да в общем то так же. У тебя где то выставляется координата x и y.
Насчет колесика - ну ты можешь высчитать сколько пикселей видно на экране, и на столько отступить от лимита. Наверняка и готовое решение можно нагуглить. Какую нибудь rts камеру.
2. Можно много чего сделать, во-первых массив или список. Опять же смотри пример >>43295
Эффекты можно разные сделать, затухания там.
А можно вообще просто сделать большой "уровень" и выставить твои слайды по порядку, и летать камерой.
>>43353
Нет пробелов или русских букв в имени пользователя? Выведи в отладку как полностью путь к файлу получается.
Нет пробелов или русских букв в имени пользователя? Выведи в отладку как полностью путь к файлу получается.
>>43358
У меня сохранения формата "файл1.сохранение".
Может быть в этом дело, но на других компьютерах с такими русскими буквами в названии все нормально.
У меня сохранения формата "файл1.сохранение".
Может быть в этом дело, но на других компьютерах с такими русскими буквами в названии все нормально.
>>43359
Я ещё раз пересмотрел твой код и обратил внимание на то, что у тебя сначала открывается сейв, прочитывается, парсится в переменную, вносятся изменения и затем файл открывается на запись и записываются новые данные.
Дело твоё, конечно, но я бы не рекомендовал модифицировать сейв файлы. Только если игра предполагает. Типа, как в Андертейле, когда главный злодей игроку сейвы трёт.
В основном же, я предлагаю тебе хранить актуальные данные в том же globaldata и просто брать их оттуда для сохранения.
Я ещё раз пересмотрел твой код и обратил внимание на то, что у тебя сначала открывается сейв, прочитывается, парсится в переменную, вносятся изменения и затем файл открывается на запись и записываются новые данные.
Дело твоё, конечно, но я бы не рекомендовал модифицировать сейв файлы. Только если игра предполагает. Типа, как в Андертейле, когда главный злодей игроку сейвы трёт.
В основном же, я предлагаю тебе хранить актуальные данные в том же globaldata и просто брать их оттуда для сохранения.
Кстати, насчёт сейвов, годаны. Вот как вы решаете проблему нумерации? Скажем, игра начинает сохранять сейвы по эф-пяточке. Файл1, файл2, файл3. Потом игрок зафейлил игру и загрузился с точки в несколько сейвов назад. Крайний сейв это, скажем Файл100, а игрок загрузил Файл90 и играет дальше. Теперь задача, как только игрок нажимает ф5, нужно определить, что сохраняться надо не в Файл91, а в Файл101. Как?
Если брутфорсом перебирать названия файлов на существование, не будет ли это слишком долго в случаях, когда игрок наплодил ТЫСЯЧИ ФАЙЛОВ?
Если внутри игры хранить счётчик, получится перезапись существующих файлов.
Можно ли кроссплатформенно получать от системы уникальное имя файла и юзать его как сейв?
Если брутфорсом перебирать названия файлов на существование, не будет ли это слишком долго в случаях, когда игрок наплодил ТЫСЯЧИ ФАЙЛОВ?
Если внутри игры хранить счётчик, получится перезапись существующих файлов.
Можно ли кроссплатформенно получать от системы уникальное имя файла и юзать его как сейв?
>>43359
Я писал про имя пользователя. user:// это C:/Users/<username>/AppData/Roaming/Godot/GameName, ~/.local/share/godot/app_userdata/GameName
Я писал про имя пользователя. user:// это C:/Users/<username>/AppData/Roaming/Godot/GameName, ~/.local/share/godot/app_userdata/GameName
>>43372
Ну да, тоже думал об этом. Только в довесок ко времени ещё имя игрока: Player1_20200216_203145.sav перезапись файлов будет только если игрок начнёт бешено спамить кнопку сохранения. Впрочем, его пыл можно ограничить таймером в пару секунд, а можно и не ограничивать.
Ну да, тоже думал об этом. Только в довесок ко времени ещё имя игрока: Player1_20200216_203145.sav перезапись файлов будет только если игрок начнёт бешено спамить кнопку сохранения. Впрочем, его пыл можно ограничить таймером в пару секунд, а можно и не ограничивать.
>>43362
Тащемта я подобный трюк в одной старенькой ааа игре видел, только не помню в какой. Вроде в халве подобное
Тащемта я подобный трюк в одной старенькой ааа игре видел, только не помню в какой. Вроде в халве подобное
>>43397
Это зависит от настроек шынды. Годот, как типичное кроссплатформенное приложение, имеет модуль ОС, который в хостовой системе использует её хостовые функции, в случае с виндой - винАПИ, которые могут возвращать совершенно разные результаты в зависимости от настроек. Очевидно, что модуль спроектирован под дефолтную винду с настройками искаропки и не учитывает, что какой-то ZVER в реестре отключил длинные имена в путях файлов.
Это зависит от настроек шынды. Годот, как типичное кроссплатформенное приложение, имеет модуль ОС, который в хостовой системе использует её хостовые функции, в случае с виндой - винАПИ, которые могут возвращать совершенно разные результаты в зависимости от настроек. Очевидно, что модуль спроектирован под дефолтную винду с настройками искаропки и не учитывает, что какой-то ZVER в реестре отключил длинные имена в путях файлов.
Годнота продолжает поступать
https://youtu.be/twodQHm0gxw
https://youtu.be/twodQHm0gxw
думаю начать пилить видосы по сабжу и выложить на тытрубу, есть идеи про что сделать?
>>43751
Обзор годных игор на годоте - вот это ещё никто не делал.
Обзор годных игор на годоте - вот это ещё никто не делал.
>>43751
Тоже думаю, но денег нет на хороший микрофон, а имеющиеся микрофоны в гарнитурах записывают говняно.
Из идей: Курс по скриптам для продвинутых (типизация, оптимизация, бенчмарки, обзоры и применение скриптовых ассетов и аддонов, конпеляция с дополнительными модулями самого редактора и экспортных шаблонов). Курс по архитектуре игор (как что называть, в какие папки что складывать, как организовать главное меню, как грузить локации в игровой мир, как сохранять прогресс, по чекпоинтам, по квиксейвам, как организовывать хранение файлов сохранений, как настраивать звук в игре, чтобы фон играл отдельно и плавно переключался на экшн-саундрек в схватках с врагами). Курс по тридэ (как организовать эргономичное передвижение по лестницам, чтобы игрок видел перед собой свои руки, перехватывающие перекладины лестницы и мог в случае чего остановиться, достать ствол и отстреливаться от вражин, сюда же механики падения при ранении и отстреливании врагов лёжа, реализованное в популярных шутанах, комбинированный 1/3person контроллер с плавным масштабированием камеры и переключением плеча, реализация режимов ходьбы, ползанья, полётов (левитации и на крыле), распознавание стен, ступеней, потолков рейкастами и зонами, и адекватная реакция коллиженшейпа на них, реализация пойнт и клик управления в стиле РТС, передвижение по навигационному полигону и переключение с этого режима в режим WASD и много лругое).
Курс по двадэ (подробные разборы платформенных и топдаунных механик, проектирование уровней с расстановкой по ним секретов и активностей, разбор популярных подходов к реализации оных активностей, примеры реализаций каждого в гдскрипте, создание мини-игор и интеграция их в тридэ через вьюпорт-текстуру и многое другое).
Если обладаешь поставленным голосом, студийным микрофоном, можем посотрудничать. Напишу тебе планы лекций, а ты зачитаешь и выложишь. Если ты согласен с утверждением, что авторитет создаётся годами, а рушится за секунду, если готов долго и кропотливо работать чисто по фану, без отдачи, то пиши в личку, обсудим.
Тоже думаю, но денег нет на хороший микрофон, а имеющиеся микрофоны в гарнитурах записывают говняно.
Из идей: Курс по скриптам для продвинутых (типизация, оптимизация, бенчмарки, обзоры и применение скриптовых ассетов и аддонов, конпеляция с дополнительными модулями самого редактора и экспортных шаблонов). Курс по архитектуре игор (как что называть, в какие папки что складывать, как организовать главное меню, как грузить локации в игровой мир, как сохранять прогресс, по чекпоинтам, по квиксейвам, как организовывать хранение файлов сохранений, как настраивать звук в игре, чтобы фон играл отдельно и плавно переключался на экшн-саундрек в схватках с врагами). Курс по тридэ (как организовать эргономичное передвижение по лестницам, чтобы игрок видел перед собой свои руки, перехватывающие перекладины лестницы и мог в случае чего остановиться, достать ствол и отстреливаться от вражин, сюда же механики падения при ранении и отстреливании врагов лёжа, реализованное в популярных шутанах, комбинированный 1/3person контроллер с плавным масштабированием камеры и переключением плеча, реализация режимов ходьбы, ползанья, полётов (левитации и на крыле), распознавание стен, ступеней, потолков рейкастами и зонами, и адекватная реакция коллиженшейпа на них, реализация пойнт и клик управления в стиле РТС, передвижение по навигационному полигону и переключение с этого режима в режим WASD и много лругое).
Курс по двадэ (подробные разборы платформенных и топдаунных механик, проектирование уровней с расстановкой по ним секретов и активностей, разбор популярных подходов к реализации оных активностей, примеры реализаций каждого в гдскрипте, создание мини-игор и интеграция их в тридэ через вьюпорт-текстуру и многое другое).
Если обладаешь поставленным голосом, студийным микрофоном, можем посотрудничать. Напишу тебе планы лекций, а ты зачитаешь и выложишь. Если ты согласен с утверждением, что авторитет создаётся годами, а рушится за секунду, если готов долго и кропотливо работать чисто по фану, без отдачи, то пиши в личку, обсудим.
>>43751
Тоже думаю, но денег нет на хороший микрофон, а имеющиеся микрофоны в гарнитурах записывают говняно.
Из идей: Курс по скриптам для продвинутых (типизация, оптимизация, бенчмарки, обзоры и применение скриптовых ассетов и аддонов, конпеляция с дополнительными модулями самого редактора и экспортных шаблонов). Курс по архитектуре игор (как что называть, в какие папки что складывать, как организовать главное меню, как грузить локации в игровой мир, как сохранять прогресс, по чекпоинтам, по квиксейвам, как организовывать хранение файлов сохранений, как настраивать звук в игре, чтобы фон играл отдельно и плавно переключался на экшн-саундрек в схватках с врагами). Курс по тридэ (как организовать эргономичное передвижение по лестницам, чтобы игрок видел перед собой свои руки, перехватывающие перекладины лестницы и мог в случае чего остановиться, достать ствол и отстреливаться от вражин, сюда же механики падения при ранении и отстреливании врагов лёжа, реализованное в популярных шутанах, комбинированный 1/3person контроллер с плавным масштабированием камеры и переключением плеча, реализация режимов ходьбы, ползанья, полётов (левитации и на крыле), распознавание стен, ступеней, потолков рейкастами и зонами, и адекватная реакция коллиженшейпа на них, реализация пойнт и клик управления в стиле РТС, передвижение по навигационному полигону и переключение с этого режима в режим WASD и много лругое).
Курс по двадэ (подробные разборы платформенных и топдаунных механик, проектирование уровней с расстановкой по ним секретов и активностей, разбор популярных подходов к реализации оных активностей, примеры реализаций каждого в гдскрипте, создание мини-игор и интеграция их в тридэ через вьюпорт-текстуру и многое другое).
Если обладаешь поставленным голосом, студийным микрофоном, можем посотрудничать. Напишу тебе планы лекций, а ты зачитаешь и выложишь. Если ты согласен с утверждением, что авторитет создаётся годами, а рушится за секунду, если готов долго и кропотливо работать чисто по фану, без отдачи, то пиши в личку, обсудим.
Тоже думаю, но денег нет на хороший микрофон, а имеющиеся микрофоны в гарнитурах записывают говняно.
Из идей: Курс по скриптам для продвинутых (типизация, оптимизация, бенчмарки, обзоры и применение скриптовых ассетов и аддонов, конпеляция с дополнительными модулями самого редактора и экспортных шаблонов). Курс по архитектуре игор (как что называть, в какие папки что складывать, как организовать главное меню, как грузить локации в игровой мир, как сохранять прогресс, по чекпоинтам, по квиксейвам, как организовывать хранение файлов сохранений, как настраивать звук в игре, чтобы фон играл отдельно и плавно переключался на экшн-саундрек в схватках с врагами). Курс по тридэ (как организовать эргономичное передвижение по лестницам, чтобы игрок видел перед собой свои руки, перехватывающие перекладины лестницы и мог в случае чего остановиться, достать ствол и отстреливаться от вражин, сюда же механики падения при ранении и отстреливании врагов лёжа, реализованное в популярных шутанах, комбинированный 1/3person контроллер с плавным масштабированием камеры и переключением плеча, реализация режимов ходьбы, ползанья, полётов (левитации и на крыле), распознавание стен, ступеней, потолков рейкастами и зонами, и адекватная реакция коллиженшейпа на них, реализация пойнт и клик управления в стиле РТС, передвижение по навигационному полигону и переключение с этого режима в режим WASD и много лругое).
Курс по двадэ (подробные разборы платформенных и топдаунных механик, проектирование уровней с расстановкой по ним секретов и активностей, разбор популярных подходов к реализации оных активностей, примеры реализаций каждого в гдскрипте, создание мини-игор и интеграция их в тридэ через вьюпорт-текстуру и многое другое).
Если обладаешь поставленным голосом, студийным микрофоном, можем посотрудничать. Напишу тебе планы лекций, а ты зачитаешь и выложишь. Если ты согласен с утверждением, что авторитет создаётся годами, а рушится за секунду, если готов долго и кропотливо работать чисто по фану, без отдачи, то пиши в личку, обсудим.
Что там с системой мультиплеера в версии 3.2? Стал ли он достаточно простым уровня другого движка, который нельзя называть?
>>43788
Не щупал, но вроде он и был простой, как rpc.
Не щупал, но вроде он и был простой, как rpc.
>>43792 (Del)
В загон, срачер.
В загон, срачер.
https://gotm.io/podotchet/space
Добавил простенькую кнопку скипа хода и пару новых подсказок во время игры с low bot.
Теперь заблоченные другими строениями пути перерасчитываются не полностью, а частично (до заблоченной клетки), сохраняя дальнейший путь выстроенный игроком. (Теперь не будет казаться, что пути не сохраняются)
Добавлен новый спрайт ангара.
Добавлены логи, которые можно смотреть в game_menu.
Правки мелких багов и недоработок.
Добавил простенькую кнопку скипа хода и пару новых подсказок во время игры с low bot.
Теперь заблоченные другими строениями пути перерасчитываются не полностью, а частично (до заблоченной клетки), сохраняя дальнейший путь выстроенный игроком. (Теперь не будет казаться, что пути не сохраняются)
Добавлен новый спрайт ангара.
Добавлены логи, которые можно смотреть в game_menu.
Правки мелких багов и недоработок.
>>43795
Вахтёр, ты берега попутал, хули ты тут разжигаешь? Пора жаловаться на тебя Абу.
Вахтёр, ты берега попутал, хули ты тут разжигаешь? Пора жаловаться на тебя Абу.
>>43959
Это всё замечательно, ты молодец. Я не любитель подобных игор, но желаю тебе успехов. Работай над анимациями, чтобы домики красиво строились и разрушались. Чтоб кораблики красиво разлетались на обломки. Чтобы динамичное меню свистело и пердело. И музон бодрый поставь.
Это всё замечательно, ты молодец. Я не любитель подобных игор, но желаю тебе успехов. Работай над анимациями, чтобы домики красиво строились и разрушались. Чтоб кораблики красиво разлетались на обломки. Чтобы динамичное меню свистело и пердело. И музон бодрый поставь.
Гонки доставляет годноту:
https://www.youtube.com/watch?v=STenRTku4GY
https://www.youtube.com/watch?v=STenRTku4GY
>>44042
Спасибо за поддержку!
У меня есть геймдиз-док где расписано уже с десяток строений, вроде как даже забаланшеных на бумаге и механизм "открывания уровней/кораблей", прилепливания любых способностей к корабликам через словари. По факту внедрение одного корабля со стандартной механикой дело 5 минут и он даже будет работать в сети.
Но вот активного рисовалы, который выдавал бы контент в виде корабликов/интерфейса включая и "за денежку" - нет (ответы вроде "не специализируюсь на космических кораблях" или проблемы с нормалмапами). Аутсорс меня отпугивает тем, что если контракт разорвется, то стиль надо будет перерисовывать заново, и я подсяду на иглу.
Так что это задерживает внедрение контента.
Чуть позже, когда на 99% отлажу/оптимизирую некоторые модули, постараюсь вкинуть сюда/гит/ассеты (network,логгер, класс для быстрой работы с хексами и т.п.).
Вчера затестил на игру с одного клиента на андроиде, против второго с компа. Все работает отлично. Только HTML-5 ругается.
Если кто-то знает, почему put_packet выдает 1 ошибку, поделитесь решением (FAILED = 1 — Generic error).
Спасибо за поддержку!
У меня есть геймдиз-док где расписано уже с десяток строений, вроде как даже забаланшеных на бумаге и механизм "открывания уровней/кораблей", прилепливания любых способностей к корабликам через словари. По факту внедрение одного корабля со стандартной механикой дело 5 минут и он даже будет работать в сети.
Но вот активного рисовалы, который выдавал бы контент в виде корабликов/интерфейса включая и "за денежку" - нет (ответы вроде "не специализируюсь на космических кораблях" или проблемы с нормалмапами). Аутсорс меня отпугивает тем, что если контракт разорвется, то стиль надо будет перерисовывать заново, и я подсяду на иглу.
Так что это задерживает внедрение контента.
Чуть позже, когда на 99% отлажу/оптимизирую некоторые модули, постараюсь вкинуть сюда/гит/ассеты (network,логгер, класс для быстрой работы с хексами и т.п.).
Вчера затестил на игру с одного клиента на андроиде, против второго с компа. Все работает отлично. Только HTML-5 ругается.
Если кто-то знает, почему put_packet выдает 1 ошибку, поделитесь решением (FAILED = 1 — Generic error).
>>44114
Возможно, сетевые ошибки?
> Если кто-то знает, почему put_packet выдает 1 ошибку, поделитесь решением (FAILED = 1 — Generic error).
Возможно, сетевые ошибки?
Когда в движок приходят дизайнеры:
https://www.youtube.com/watch?v=0oQ5yignti4
https://www.youtube.com/watch?v=0oQ5yignti4
>>44120
На андроид и винде в приложухе пашет даже при задержках в 10сек. Ощущение, что gotm.io блочит. Либо я чего то не шарю.
На андроид и винде в приложухе пашет даже при задержках в 10сек. Ощущение, что gotm.io блочит. Либо я чего то не шарю.
>>44145
Ну это уже ящитаю повод им в саппорт постучаться.
Ну это уже ящитаю повод им в саппорт постучаться.
Есть у кого напримете иконки энергии (электричества) квадратного типа в центр которой можно вставить число?
>>44253
opengameart.org
opengameart.org
Идеи для вката целой минитимы 3 долбаёба, чтобы было минимум рисовашки и чтоб экшон был.
Естесна, 2Д нужны.
Ну и чтобы по максимум изучить годот.
Естесна, 2Д нужны.
Ну и чтобы по максимум изучить годот.
>>44324
Идей куча. Фейкомыльце найдешь при грамотном прочтении треда. Недавних постов. Сейчас занимаемся туториалами, но на организацию реального девелопа ресурсы тоже найдутся.
Идей куча. Фейкомыльце найдешь при грамотном прочтении треда. Недавних постов. Сейчас занимаемся туториалами, но на организацию реального девелопа ресурсы тоже найдутся.
>>44371
Вообще всем. Хорошо знать нельзя, но кто что знает - тому хватает.
Вообще всем. Хорошо знать нельзя, но кто что знает - тому хватает.
Хей, анончики! Поясните по использованию .gdignore: Например, я делаю эрпогэ с корованами и много моделирую. В проекте свалены файлы blend, референсы, вспомогательное барахло (старые версии и бэкапы) все это я прячу в папочке с маркером .gdignore и годот их не видит, и все вроде нормально, но зачем мне всё это держать внутри проекта? Допустим, к разработке подключились новые люди, занимаются кодингом и им гигабайты модельного барахла качать не айс.
И тут возникает вопрос. А кто вообще придумал хранить это внутри проекта? Может лучше вынести модели блендера и документы фотошопа наверх, а внутрь только забрасывать экспорт из них, glb, png.
Получается .gdignore вообще не нужен?
И тут возникает вопрос. А кто вообще придумал хранить это внутри проекта? Может лучше вынести модели блендера и документы фотошопа наверх, а внутрь только забрасывать экспорт из них, glb, png.
Получается .gdignore вообще не нужен?
Господа, в честь Вашего теплого приема, особенно от >>44042, на 23 февраля, я запилил Вам хардкор лвл в https://gotm.io/podotchet/space и мне очень интересно, сможете ли Вы его пройти.
Если все же Вас это заинтересует, и Вы вдруг пройдете, сбрасывайте сюда тактику, скриншот победы и пожелание награды в разумных пределах: (
- Подписка на новые apk для андроид, где можно поиграть по сети?
- Рублей 300 на карту?
- Занесение Вашего ника куда-нибудь?).
Всем хорошего дня и настроения!
Если все же Вас это заинтересует, и Вы вдруг пройдете, сбрасывайте сюда тактику, скриншот победы и пожелание награды в разумных пределах: (
- Подписка на новые apk для андроид, где можно поиграть по сети?
- Рублей 300 на карту?
- Занесение Вашего ника куда-нибудь?).
Всем хорошего дня и настроения!
>>44423
Рублей 300 скину только первым трем, потому что он чет иногда играет нормально, а иногда багает, сук. И именно когда я выложил!
Рублей 300 скину только первым трем, потому что он чет иногда играет нормально, а иногда багает, сук. И именно когда я выложил!
Какой последний положняк годота + ведро? Год назад когда заходил было дико неоптимизировано. Изменилось ли за год что нибудь? Если нет, продолжу ковырять свой платформер на libgdx
>>44425
ОП предлагает делать игры для пекабояр. На ведро похуй. Желает Хуану выпилить поддержку ведра и ябла. Если анонимус желает делать игры на ведро, от ОПа он не получит здесь ни поддержки, ни помощи.
> Какой последний положняк годота + ведро?
ОП предлагает делать игры для пекабояр. На ведро похуй. Желает Хуану выпилить поддержку ведра и ябла. Если анонимус желает делать игры на ведро, от ОПа он не получит здесь ни поддержки, ни помощи.
>>44430
А порицание и струи мочи?
А порицание и струи мочи?
>>44425
Да, с версии 3.2 стало практически летать. Ведроид стал неплохой платформой для годота. Единственное, что пока сосет - html5.
Да, с версии 3.2 стало практически летать. Ведроид стал неплохой платформой для годота. Единственное, что пока сосет - html5.
Вопрос. Допустим я хочу сделать общий класс/ноду (пока не очень понимаю, как это лучше сделать в годоте) item и наследовать от него все предметы. Стоит ли делать это с помощью "extends ..." на наследуемом объекте?
>>44486
В документации пример как раз про твои айтемы
В документации пример как раз про твои айтемы
>>44430
Анон же, в свою очередь, советует ОПу свернуться калачиком и сосать свой собственный стручок. Ну и не указывать анону, что и как ему делать.
Анон же, в свою очередь, советует ОПу свернуться калачиком и сосать свой собственный стручок. Ну и не указывать анону, что и как ему делать.
>>44425
Если будешь использовать тайлмапы, то получишь 10 fps на выходе. Остальное вроде норм.
Если будешь использовать тайлмапы, то получишь 10 fps на выходе. Остальное вроде норм.
47 Кб, 741x691>>44515
>Анон же, в свою очередь, советует ОПу свернуться калачиком и сосать свой собственный стручок
>>44529
Всегда.
Всегда.
>>44425
>>44518
->
>>642666 →
>>642076 →
git fetch origin pull/35957/head:batch-2d
git cherry-pick d04cd4a
>>44518
->
>>642666 →
>>642076 →
git fetch origin pull/35957/head:batch-2d
git cherry-pick d04cd4a
> Потестил сегодня вечером немного, результат не то чтобы впечатлил, но около x2 прироста на простейшем примере мигания клеточками дает.
> карта 40x80 клеток (тайл 8x8 пикс)
> 14 fps Debug, no batch
> 26 fps Debug, batch
> 17 fps Release, no batch
> 33 fps Release, batch
> карта 20x40 (тайл 16x16 пикс)
> 19 fps Debug, no batch
> 26 fps Debug, batch
> 23 fps Release, no batch
> 33 fps Release, batch
>>44648
Если прям срочно надо, прям горит, то можешь юзать ручную отрисовку на канве (холсте, канвасе, canvas) Решение было в прошлом треде, со скрином готового кода на 50 строк.
Если прям срочно надо, прям горит, то можешь юзать ручную отрисовку на канве (холсте, канвасе, canvas) Решение было в прошлом треде, со скрином готового кода на 50 строк.
Те кто говорит о плохой производительности - использовать многопоточность в коде пробовали?
>>44936
Чтобы пробовать треды, нужно быть программистом, а у нас в основном геймдизайнеры-директора.
https://godotengine.org/qa/30262/how-to-properly-use-threads
Чтобы пробовать треды, нужно быть программистом, а у нас в основном геймдизайнеры-директора.
> Many people think they will magically speed up your code. But just creating threads because they are cool could well slow your code down.
https://godotengine.org/qa/30262/how-to-properly-use-threads
>>44962
только 3.2.1 на подходе
только 3.2.1 на подходе
>>44962
Вроде бы там прорывов нет. Да и сколько устройств на андроиде поддерживает вулкан? Нагуглил что 10-30% максимум.
Вроде бы там прорывов нет. Да и сколько устройств на андроиде поддерживает вулкан? Нагуглил что 10-30% максимум.
>>45066
Честно говоря, похуй сколько их там.
Вулкан нужен для десктопной платформы, пекабоярам.
> устройств на андроиде
Честно говоря, похуй сколько их там.
Вулкан нужен для десктопной платформы, пекабоярам.
>>45068
ГЛ ЕС позиционировался как мобильная платформа, Вулкан же как полностью глобальная, иначе говоря, на пека она будет работать (и работает, что это я) без мобильных ограничений. На мобилах тоже, ибо к 2020 мобилы для мобильных игродебилов уже сравнялись по мощщи с мемными игровыми ноутбуками.
ГЛ ЕС позиционировался как мобильная платформа, Вулкан же как полностью глобальная, иначе говоря, на пека она будет работать (и работает, что это я) без мобильных ограничений. На мобилах тоже, ибо к 2020 мобилы для мобильных игродебилов уже сравнялись по мощщи с мемными игровыми ноутбуками.
Научите ставить декали на объекты.
Следы от пуль, от покрышек, кровь, вино, кетчуп, вода - вот это всё. Предполагаю, что принцип, как с наложением теней?
Следы от пуль, от покрышек, кровь, вино, кетчуп, вода - вот это всё. Предполагаю, что принцип, как с наложением теней?
>>43188 (OP)
Помогите разобраться с рейкастами. Как сделать, чтобы персонаж стрелял не из центра камеры, а из ствола оружия, при этом, ствол оружия должен при стрельбе быть направлен в точку пересечения вектора, направленного из центра камеры на цель, помеченную прицелом на камере в центре. Не могу разобраться, есть какая-то формула?
Вообще, при стрельбе рейкастом это как бы и не актуально. Но если делать ракетницу, то стрельба будет идти объектами-ракетами же. Или бластер, где стрельба будет производиться видимым лучом, повторяющим ранее произведённый прицельный рейкаст.
Помогите разобраться с рейкастами. Как сделать, чтобы персонаж стрелял не из центра камеры, а из ствола оружия, при этом, ствол оружия должен при стрельбе быть направлен в точку пересечения вектора, направленного из центра камеры на цель, помеченную прицелом на камере в центре. Не могу разобраться, есть какая-то формула?
Вообще, при стрельбе рейкастом это как бы и не актуально. Но если делать ракетницу, то стрельба будет идти объектами-ракетами же. Или бластер, где стрельба будет производиться видимым лучом, повторяющим ранее произведённый прицельный рейкаст.
>>45242
Ухх, лень полностью расписывать, что-то вроде такого:
Нода персонажа
-Нода оружия
--Нода кончика ствола
Таким образом они все вместе двигаются
Дальше ноде ствола делаешь look_at ( Vector3 target, Vector3 up ) или look_at_from_position ( Vector3 position, Vector3 target, Vector3 up ) - это в Spatial
Ну и рейкаст кидать от объекта кончика ствола, а не от камеры
Ухх, лень полностью расписывать, что-то вроде такого:
Нода персонажа
-Нода оружия
--Нода кончика ствола
Таким образом они все вместе двигаются
Дальше ноде ствола делаешь look_at ( Vector3 target, Vector3 up ) или look_at_from_position ( Vector3 position, Vector3 target, Vector3 up ) - это в Spatial
Ну и рейкаст кидать от объекта кончика ствола, а не от камеры
Так, ну экспортнул я на линух dodge the creeps, 41 стыдливый мегабайт, динамическая о линковка.
Где я обосраля, неужели дефолтный шаблон настолько плох?
Где я обосраля, неужели дефолтный шаблон настолько плох?
77 Кб, 904x682Блеать, ну как так? Откуда там циклическая ссылка? Класс это же не инстанс.
>>45338
Чому неюзабельно? ЧЯДНТ? Я хочу чтобы каждый свичер мог ссылаться на такой же свичер и если в нодпач левый объект (левого класса) то чтоб игнорировался.
Чому неюзабельно? ЧЯДНТ? Я хочу чтобы каждый свичер мог ссылаться на такой же свичер и если в нодпач левый объект (левого класса) то чтоб игнорировался.
102 Кб, 1109x837>>45338
Переопределил to_string но это такая дикость, пиздец.
Переопределил to_string но это такая дикость, пиздец.
>>45341
Да не, ты все делаешь логично, но гдскрипт пока такое не переваривает. Пишут что работают над этим, обещают в 4.0. На всякий случай попробуй переименовать Switcher во что то другое, а потом обратно, вдруг подхватит.
Да не, ты все делаешь логично, но гдскрипт пока такое не переваривает. Пишут что работают над этим, обещают в 4.0. На всякий случай попробуй переименовать Switcher во что то другое, а потом обратно, вдруг подхватит.
>>45339
Под линухом тоже, но столько же весит и шаблон экспорта.
Короче, соберу свой годот, тем более там очень изи.
Я только не понима, как собрать шаблоны, исходников для них отдельных не нашел, они в дереве проекта в директории platform.
Мб он мне их при сборе движка тоже соберет, было бы заебись.
Под линухом тоже, но столько же весит и шаблон экспорта.
Короче, соберу свой годот, тем более там очень изи.
Я только не понима, как собрать шаблоны, исходников для них отдельных не нашел, они в дереве проекта в директории platform.
Мб он мне их при сборе движка тоже соберет, было бы заебись.
>>45346
Да, это сработало! И код стал элегантнее. И при наличии левой ноды в параметрах она игнорируется, как я и хотел.
Да, это сработало! И код стал элегантнее. И при наличии левой ноды в параметрах она игнорируется, как я и хотел.
>>45348
Просто отдельная сборка с флагами tools=no
https://gist.github.com/Calinou/ceb6d24b16d85bc47f9c5de9c9ae341d
Чтобы сильно уменьшить размер надо уже конкретно фичи отключать - 3d, видеокодеки. На ведре у меня сейчас 7Mb для 2d.
Впрочем если ты пытаешься сделать что то вроде dll (.so?) И пользоааться установленным в систему движком, то тут не знаю, не пробовал.
Просто отдельная сборка с флагами tools=no
https://gist.github.com/Calinou/ceb6d24b16d85bc47f9c5de9c9ae341d
Чтобы сильно уменьшить размер надо уже конкретно фичи отключать - 3d, видеокодеки. На ведре у меня сейчас 7Mb для 2d.
Впрочем если ты пытаешься сделать что то вроде dll (.so?) И пользоааться установленным в систему движком, то тут не знаю, не пробовал.
>>45350
Запутался, что такое tools?
Я итак собираю с tools=no отключаю нщн всякие модули, после этого в bin только бинарник годота.
Запутался, что такое tools?
Я итак собираю с tools=no отключаю нщн всякие модули, после этого в bin только бинарник годота.
>>45366
Ну это упрощенно, наверняка есть какие то тонкости. Тот же андроид там еще свои ресурсы в темплейт куда то сует.
Ну это упрощенно, наверняка есть какие то тонкости. Тот же андроид там еще свои ресурсы в темплейт куда то сует.
>>45366
С чего проорал-то?
>>45357
https://en.wikipedia.org/wiki/Toolset
Есть такое понятие в программистском укладе - тулсет. В него входят редакторы и средства отладки. Нынче зумеры не чтят лапти дидов и под "движком" подразумевают тулсет движка. А Хуан - олдфаг, матчасть знает. Поэтому компиляция с tools=no как раз и даёт нам чистый движок без редактора (тулсета).
С чего проорал-то?
>>45357
> Запутался, что такое tools?
https://en.wikipedia.org/wiki/Toolset
Есть такое понятие в программистском укладе - тулсет. В него входят редакторы и средства отладки. Нынче зумеры не чтят лапти дидов и под "движком" подразумевают тулсет движка. А Хуан - олдфаг, матчасть знает. Поэтому компиляция с tools=no как раз и даёт нам чистый движок без редактора (тулсета).
>>45369
С зависимостей между опциями.
Я не могу собрать tools=yes с некоторыми disable*-опциями, но при в сборкогайде написано, что я всего должен пересобирать шаблоны, если пересобираю двигло.
Т.е. мутные возможности таковы, как я понял:
- собрать эдитор и шаблоны, но не вырубить некоторые опции у шаблонов.
Следствие - минимальные шаблоны.
Еще я не могу target=release сделать, тому шо для шаблонов можно debug или release_debug. Но я могу собрать tools=yes target=release_debug debug_symbols=no на деле похуй, стрипну
В
- собрать отдельно с tools=no, без 3д, отключается всё, а потом пытаться собрать эдитор с tools=yes, убирая disablы, пока не соберется. Вопрос в совместимости остается открытым, хотя это один продукт.
И еще хотелось бы хотя бы один комментарий в коде модулей увидеть, я молчу про их краткое описание.
С зависимостей между опциями.
Я не могу собрать tools=yes с некоторыми disable*-опциями, но при в сборкогайде написано, что я всего должен пересобирать шаблоны, если пересобираю двигло.
Т.е. мутные возможности таковы, как я понял:
- собрать эдитор и шаблоны, но не вырубить некоторые опции у шаблонов.
Следствие - минимальные шаблоны.
Еще я не могу target=release сделать, тому шо для шаблонов можно debug или release_debug. Но я могу собрать tools=yes target=release_debug debug_symbols=no на деле похуй, стрипну
В
- собрать отдельно с tools=no, без 3д, отключается всё, а потом пытаться собрать эдитор с tools=yes, убирая disablы, пока не соберется. Вопрос в совместимости остается открытым, хотя это один продукт.
И еще хотелось бы хотя бы один комментарий в коде модулей увидеть, я молчу про их краткое описание.
>>45370
Да, не можешь, у него в зависимостях, вроде бы, 3d и advanced gui (rich textbox и подобное)
>Я не могу собрать tools=yes с некоторыми disable*-опциями
Да, не можешь, у него в зависимостях, вроде бы, 3d и advanced gui (rich textbox и подобное)
>>45370
Ты собираешь минимальный шаблон, в котором есть только те классы, которые ты экстендил скриптами своего проекта. А в редакторе нет смысла отключать модули. Потом запускаешь свой проект на дебаг-шаблоне и проверяешь, если какая хуйня - он в консоль напишет, чего ему не хватило. Пересобираешь или исключаешь из проекта. Когда всё работает, запускаешь на релизном шаблоне. Если всё норм - релизишь. Если не норм - ещё раз всё перепроверяешь.
Редактор пересобирать есть смысл только если ты добавляешь модули третьей стороны. Тогда да, они должны быть и в тулзовой сборке и в сборке-шаблоне.
> Вопрос в совместимости остается открытым, хотя это один продукт.
Ты собираешь минимальный шаблон, в котором есть только те классы, которые ты экстендил скриптами своего проекта. А в редакторе нет смысла отключать модули. Потом запускаешь свой проект на дебаг-шаблоне и проверяешь, если какая хуйня - он в консоль напишет, чего ему не хватило. Пересобираешь или исключаешь из проекта. Когда всё работает, запускаешь на релизном шаблоне. Если всё норм - релизишь. Если не норм - ещё раз всё перепроверяешь.
Редактор пересобирать есть смысл только если ты добавляешь модули третьей стороны. Тогда да, они должны быть и в тулзовой сборке и в сборке-шаблоне.
>>45377
Кто? Только что собрал только шаблон без дебага, заменил оригинальный, godot gui при экспорте сказал, что шаблон инвалид. Подробностей не было.
> в консоль напишет
Кто? Только что собрал только шаблон без дебага, заменил оригинальный, godot gui при экспорте сказал, что шаблон инвалид. Подробностей не было.
>>45377
>>45382
Разобрался, но не совсем.
Понял, что если скормить в виде шаблонов релиз и дебаг мой собранный релиз (т.е. один и тот же), то все будет норм.
Но я не понимаю, зачем ему при экспорте пути к двум шаблонам, как он выбирает нужный, зачем он вообще их сравнивает. Т.е. как мне, допустим, попросить релизный только или только отладочный юзать?
>>45382
Разобрался, но не совсем.
Понял, что если скормить в виде шаблонов релиз и дебаг мой собранный релиз (т.е. один и тот же), то все будет норм.
Но я не понимаю, зачем ему при экспорте пути к двум шаблонам, как он выбирает нужный, зачем он вообще их сравнивает. Т.е. как мне, допустим, попросить релизный только или только отладочный юзать?
>>45383
Нашел эту галочку. При экспорте. Ладно, когда игру сделаю, тогда уже подберу.
Нашел эту галочку. При экспорте. Ладно, когда игру сделаю, тогда уже подберу.
87 Кб, 777x647Так. Возникла проблем по этому вопросу >>45349 указывающие друг на друга ноды устраивают циклический вызов друг друга и весело переполняют стек. Я уже и так думал и эдак, туплю, не могу найти приемлемого решения.
Код теперь выглядит так. Я убрал все велосипеды и задействовал встроенный механизм из ветки Control. Обошлось без самодельных классов вообще. Однако о циклический вызов таки споткнулся. Мне надо как-то ограничить перебор ссылочных списков по направлениям, но перебранные мною способы не помогают этого добиться. Вводил флаги. Добавлял состояния. Ничего не помогает. Либо не работает перебор, либо при циклическом вызове флаги сами меняются и происходит опять переполнение стека.
Примерное развитие моей мысли таково:
1. Как-то отделить первый вызванный свичер от остальных.
2. В первом обработчике отдать команду во все 4 направления.
3. В остальных обработчиках отдавать направления только в противоположном направлении от триггернувшего.
Код теперь выглядит так. Я убрал все велосипеды и задействовал встроенный механизм из ветки Control. Обошлось без самодельных классов вообще. Однако о циклический вызов таки споткнулся. Мне надо как-то ограничить перебор ссылочных списков по направлениям, но перебранные мною способы не помогают этого добиться. Вводил флаги. Добавлял состояния. Ничего не помогает. Либо не работает перебор, либо при циклическом вызове флаги сами меняются и происходит опять переполнение стека.
Примерное развитие моей мысли таково:
1. Как-то отделить первый вызванный свичер от остальных.
2. В первом обработчике отдать команду во все 4 направления.
3. В остальных обработчиках отдавать направления только в противоположном направлении от триггернувшего.
>>45435
Пазл из взаимосвязанных ключей, которые могут переключаться группами и по отдельности. Распространённая штука во множестве игор. Интересно решить именно так, через ссылочный список из соседних элементов. Если ничего не выйдет сделаю по старинке - массивом и набором правил.
Пазл из взаимосвязанных ключей, которые могут переключаться группами и по отдельности. Распространённая штука во множестве игор. Интересно решить именно так, через ссылочный список из соседних элементов. Если ничего не выйдет сделаю по старинке - массивом и набором правил.
>>45439
сделай два метода - просто переключение и переключение по нажатию. То что по нажатию - вызывает простое переключение как у нажатого так и у соседей. Метод простого переключения ничего не знает о соседях.. и замени pressed = !pressed на вызов метода
просто есть вероятность что при такой манипуляции годо генерит сигнал и у тебя по нажатию преключаются соседи, которые начинают переключать соседей и так до бесконечности..
сделай два метода - просто переключение и переключение по нажатию. То что по нажатию - вызывает простое переключение как у нажатого так и у соседей. Метод простого переключения ничего не знает о соседях.. и замени pressed = !pressed на вызов метода
просто есть вероятность что при такой манипуляции годо генерит сигнал и у тебя по нажатию преключаются соседи, которые начинают переключать соседей и так до бесконечности..
>>45667
Самое время. Но это же не исправит ошибку
Самое время. Но это же не исправит ошибку
>>45666
Черт, что ты там шатаешь.
Черт, что ты там шатаешь.
36 Кб, 1343x708>>45666
н-н-ничего( Я просто установил годот. Он начал выдавать ошибку что нет билдера С# какого то. Я же не глупый, зашёл на офф сайт, скачал билдер какой то. Всё заработало, но теперь выдаёт ошибку что ему не известно пространство имён godot
н-н-ничего( Я просто установил годот. Он начал выдавать ошибку что нет билдера С# какого то. Я же не глупый, зашёл на офф сайт, скачал билдер какой то. Всё заработало, но теперь выдаёт ошибку что ему не известно пространство имён godot
>>45671
УМВР. Внимательно доустанови чего не хватает.
Также рекомендую научиться гуглить https://github.com/godotengine/godot/issues/19060
У нас тред не совсем тред техподдержки, скорее тред обмена опытом.
УМВР. Внимательно доустанови чего не хватает.
Также рекомендую научиться гуглить https://github.com/godotengine/godot/issues/19060
У нас тред не совсем тред техподдержки, скорее тред обмена опытом.
>>45677
Просто задавая такие вопросы здесь, отдавай себе отчёт, что в треде может не быть людей, способных ответить оперативно, день или два. За это время можно горы сайтов в гугле перелопатить. Ну и инглиш. Даже не пытайся вкатываться в геймдев без минимального знания.
Просто задавая такие вопросы здесь, отдавай себе отчёт, что в треде может не быть людей, способных ответить оперативно, день или два. За это время можно горы сайтов в гугле перелопатить. Ну и инглиш. Даже не пытайся вкатываться в геймдев без минимального знания.
>>45671
Там надо Visual Studio или VS Build Tools, + .NET Framework 4.5. Плюс Mono 5.18 который он вроде бы ставит сам.
Там надо Visual Studio или VS Build Tools, + .NET Framework 4.5. Плюс Mono 5.18 который он вроде бы ставит сам.
Как правильно грузить опенворлд, чтоб не тормозило?
Я для себя наметил такие наметки:
1. Основой сцены является т.н. distant land - огромный низкополигональный террейн 8х8 километров (8Кх8К движковых юнитов) с мыльнейшей текстурой травы и гор, без нормалмапы. По этому террейну расставлены низкополигональные деревья, горы, камни.
2. Вся эта структура видна только издалека, при приближении к любой её части она будет заполняться автоподгружаемыми чанками с высоким левелом детализации.
3. Каждый чанк имеет фиксированный размер. Он имеет в себе скрипты и всё интерактивное наполнение. И здесь главный вопрос, как лучше построить политику компоновки:
3.1. Как в ГТА - Чанки имеют размер 1х1 юнит (метр), грузятся быстро целыми пачками по мере приближения к ним, причём, когда ты быстро летишь на машине, они пропускаются из загрузки, что экономит ресурсы пеки.
3.2. Как в Скайриме - Чанки (ячейки) это логически цельные локации разных размеров. Интерьерные локации грузятся путём предзагрузки через загрузочный экран. Экстерьерные подгружаются автоматически при приближении и внимательный игрок может поймать их на этом, когда горы поблизости резко обрастают деталями.
4. Динамические объекты живут как формулы мировой логики (логики игрового мира) и наполняются телами в виде моделей при приближении игрока. Материализовавшиеся модели получают от мировой логики инфу, что они делают в данный момент, на этапе материализации. Чтоб ранее убитые враги не падали замертво на глазах кекающего от такой хуйни игрока, а чтоб материализовывались сразу мёртвыми.
Дополняйте поправляйте. И примерчиками кода порадуйте.
Я для себя наметил такие наметки:
1. Основой сцены является т.н. distant land - огромный низкополигональный террейн 8х8 километров (8Кх8К движковых юнитов) с мыльнейшей текстурой травы и гор, без нормалмапы. По этому террейну расставлены низкополигональные деревья, горы, камни.
2. Вся эта структура видна только издалека, при приближении к любой её части она будет заполняться автоподгружаемыми чанками с высоким левелом детализации.
3. Каждый чанк имеет фиксированный размер. Он имеет в себе скрипты и всё интерактивное наполнение. И здесь главный вопрос, как лучше построить политику компоновки:
3.1. Как в ГТА - Чанки имеют размер 1х1 юнит (метр), грузятся быстро целыми пачками по мере приближения к ним, причём, когда ты быстро летишь на машине, они пропускаются из загрузки, что экономит ресурсы пеки.
3.2. Как в Скайриме - Чанки (ячейки) это логически цельные локации разных размеров. Интерьерные локации грузятся путём предзагрузки через загрузочный экран. Экстерьерные подгружаются автоматически при приближении и внимательный игрок может поймать их на этом, когда горы поблизости резко обрастают деталями.
4. Динамические объекты живут как формулы мировой логики (логики игрового мира) и наполняются телами в виде моделей при приближении игрока. Материализовавшиеся модели получают от мировой логики инфу, что они делают в данный момент, на этапе материализации. Чтоб ранее убитые враги не падали замертво на глазах кекающего от такой хуйни игрока, а чтоб материализовывались сразу мёртвыми.
Дополняйте поправляйте. И примерчиками кода порадуйте.
>>45443
Сделол. Было сложно, но я нагородил велосипед из байтоёбства вперемешку со строкоёбством.
Только я сделал несколько иначе. Я в упор не нашёл в документации корректно работающего поля у потомков Control отвечающего за хранение состояния "нажатости". Фокус контролы самовольно передают друг другу. Состояние графической "продавленности" тоже передают. Поэтому пришлось добавить в метаданные кнопкам велосипедное поле, хранящее всё что мне нужно - набор флагов направлений. После чего пришлось подписать все кнопки не на один сигнал, а на целых три: button_down задаёт флаг из всех направлений, button_up снимает все флаги, pressed работает исходя из флага в данный момент, если флагов нет - ничего не делает, если флаги все - обходит всех имеющихся соседей, соседям слева устанавливает флаг "влево", справа - вправо, сверху - вверх, снизу - вниз, если есть только определенный набор флагов, обходит только эти указанные направления. Таким образом я исключил циклический вызов и кодом в 90 строк делаю то же самое, что на массиве я же сделал за 30 строк. Но теперь, оперируя простановкой соседей контролам, я могу гибко менять правила обхода контролов. Что для варианта с массивом потребовало бы другого велосипеда с правилами обхода.
Не, мне того и надо, чтобы присвоением значения дёргались сигналы.
Сделол. Было сложно, но я нагородил велосипед из байтоёбства вперемешку со строкоёбством.
Только я сделал несколько иначе. Я в упор не нашёл в документации корректно работающего поля у потомков Control отвечающего за хранение состояния "нажатости". Фокус контролы самовольно передают друг другу. Состояние графической "продавленности" тоже передают. Поэтому пришлось добавить в метаданные кнопкам велосипедное поле, хранящее всё что мне нужно - набор флагов направлений. После чего пришлось подписать все кнопки не на один сигнал, а на целых три: button_down задаёт флаг из всех направлений, button_up снимает все флаги, pressed работает исходя из флага в данный момент, если флагов нет - ничего не делает, если флаги все - обходит всех имеющихся соседей, соседям слева устанавливает флаг "влево", справа - вправо, сверху - вверх, снизу - вниз, если есть только определенный набор флагов, обходит только эти указанные направления. Таким образом я исключил циклический вызов и кодом в 90 строк делаю то же самое, что на массиве я же сделал за 30 строк. Но теперь, оперируя простановкой соседей контролам, я могу гибко менять правила обхода контролов. Что для варианта с массивом потребовало бы другого велосипеда с правилами обхода.
> и замени pressed = !pressed на вызов метода
> просто есть вероятность что при такой манипуляции годо генерит сигнал и у тебя по нажатию преключаются соседи
Не, мне того и надо, чтобы присвоением значения дёргались сигналы.
>>46173
Код вдогонку. Может кому интересно будет.
Мелкие пояснения:
1. Учусь работать с битовыми масками. Пора бы уж. 2020 год! Число & Маска == Маска - возвратит тру, если в числе есть указанные в маске биты.
2. Очень удобно константы направлений пошли как ключи для словаря соседей (nb).
3. Принцип метаданных оказался очень удобен для расширения функционала объектов. Даже наследование не нужно. Но насколько это отличается по скорости от поиска метода в классе?
Код вдогонку. Может кому интересно будет.
Мелкие пояснения:
1. Учусь работать с битовыми масками. Пора бы уж. 2020 год! Число & Маска == Маска - возвратит тру, если в числе есть указанные в маске биты.
2. Очень удобно константы направлений пошли как ключи для словаря соседей (nb).
3. Принцип метаданных оказался очень удобен для расширения функционала объектов. Даже наследование не нужно. Но насколько это отличается по скорости от поиска метода в классе?
73 Кб, 789x422>>46176
Хех. Запостил код и сразу же обнаружил критическую ошибку. При простом задании правил обработки соседей будет обработан только первый обнаруженный сосед. Так как иф со всеми элифами - это один оператор. Быстрофикс.
Хех. Запостил код и сразу же обнаружил критическую ошибку. При простом задании правил обработки соседей будет обработан только первый обнаруженный сосед. Так как иф со всеми элифами - это один оператор. Быстрофикс.
>>46180
Что-то мне подсказывает, что первый иф вообще лишний. Но проверить пока что не смогу. От компа ушёл.
Что-то мне подсказывает, что первый иф вообще лишний. Но проверить пока что не смогу. От компа ушёл.
31 Кб, 793x161>>46185
Таки да. Код ужался вот так:
Таки да. Код ужался вот так:
75 Кб, 778x541Просто оставлю это здесь. Вдруг кому-то понадобится.
Правильно ли я понимаю, что галка Local to scene фактически включает мне инстансинг материала?
>>47765
Правильно понимаешь.
Правильно понимаешь.
>>48397
Я хотел запилить, но ниасиливаю.
Я хотел запилить, но ниасиливаю.
>>48397
Я прям в движке на плюсах писал. Но в результате время линковки оказалось долгим, так что я перешел просто на гдскрипт
Я прям в движке на плюсах писал. Но в результате время линковки оказалось долгим, так что я перешел просто на гдскрипт
>>48406
Ну так правильно. Официально рекомендовано писать модули, линковать их один раз, и дальше работать с ними через скрипт.
Ну так правильно. Официально рекомендовано писать модули, линковать их один раз, и дальше работать с ними через скрипт.
>>48410
Вообще я хочу освоить "нейтивскрипт" - традиционные динамические библиотеки. Но ниасиливаю. Раньше, в дельфи это как-то всё намного проще было.
А так для меня этот вариант самый удобный. Движок пересобирать не надо. Пересобираешь только библиотеки свои. Распространяешь вместе с конечной игрой.
Вообще я хочу освоить "нейтивскрипт" - традиционные динамические библиотеки. Но ниасиливаю. Раньше, в дельфи это как-то всё намного проще было.
А так для меня этот вариант самый удобный. Движок пересобирать не надо. Пересобираешь только библиотеки свои. Распространяешь вместе с конечной игрой.
>>48410
То есть всю игру чисто на нетив никто не пишет?
То есть всю игру чисто на нетив никто не пишет?
>>48410
Сама игра спокойно запихивается в модуль. Плюс в том, что нейтив либу нельзя подключить к html экспорту, а модуль можно.
Сама игра спокойно запихивается в модуль. Плюс в том, что нейтив либу нельзя подключить к html экспорту, а модуль можно.
Господи, вы только поглядите, какие навигационные полигоны красивые!
Построение маршрута одной функцией!
https://www.youtube.com/watch?v=KU1PslMiZ98
Построение маршрута одной функцией!
https://www.youtube.com/watch?v=KU1PslMiZ98
Разрабы годота платят создающим игры на их движке как фалько? По сути платить не придется
(Автор этого поста был предупрежден.)
(Автор этого поста был предупрежден.)
Курс создания игор в стиле первой плойки. От одного из авторов годота, Мизизиза.
https://youtu.be/azH4LD6lMpo
https://youtu.be/azH4LD6lMpo
Хёртбист начал новый курс эрпогэ мечты:
https://www.youtube.com/watch?v=mAbG8Oi-SvQ
https://www.youtube.com/watch?v=mAbG8Oi-SvQ
257 Кб, 1485x868>>49705
За 800р научат делать модельки в из кубов в стиле гнома. Это же уровень бесплатных туториалов для новичков.
За 800р научат делать модельки в из кубов в стиле гнома. Это же уровень бесплатных туториалов для новичков.
>>49985 (Del)
Хреновая (очень) производительность с тайлмапами на чем-либо отличном от PC.
Хреновая (очень) производительность с тайлмапами на чем-либо отличном от PC.
>>49985 (Del)
Чел, ну пять секунд в гугле же, ёпта!
https://www.gamedesigning.org/engines/unity-vs-godot/
Чел, ну пять секунд в гугле же, ёпта!
https://www.gamedesigning.org/engines/unity-vs-godot/
117 Кб, 771x820>>49038
Нелехко игоры кодировать!
Нелехко игоры кодировать!
>>43188 (OP)
Как импортировать GLTF2/0 в MeshInstance?
Как импортировать GLTF2/0 в MeshInstance?
>>43188 (OP)
Бля буду, баг нашёл. При открытом микшере громкости на переднем плане фпс в редакторе отпускается до 10 кадров в секунду на 1080Ti.
Бля буду, баг нашёл. При открытом микшере громкости на переднем плане фпс в редакторе отпускается до 10 кадров в секунду на 1080Ti.
>>50168
В редакторе сниженный фпс, by design.
В редакторе сниженный фпс, by design.
>>50167
Напрямую не нашел.
Либо импортишь как obj и выбираешь во вкладке Import - OBJ as Mesh
Либо как gltf, потом открываешь ее Open Anyway, выбираешь свой меш, и делаешь ему Save as
Напрямую не нашел.
Либо импортишь как obj и выбираешь во вкладке Import - OBJ as Mesh
Либо как gltf, потом открываешь ее Open Anyway, выбираешь свой меш, и делаешь ему Save as
Кто тут писал, что он не может сделать нормальный фпс контроллер, чтобы как в халве можно было адекватно взаимодействовать с rigidbody? У скамерсофта в начале неплохой отрывок кода, который вроде как исправляет эту проблему.
https://youtu.be/vVe_DsiWNOI
https://youtu.be/vVe_DsiWNOI
14,8 Мб, mp4,852x480, 0:10
>>50188
Эта проблема исправлена версией 3.2, заслуги мобилкодела-скамера здесь нет.
> вроде как исправляет эту проблему
Эта проблема исправлена версией 3.2, заслуги мобилкодела-скамера здесь нет.
>>43188 (OP)
Как правильно настроить вес rigidbody?
У меня предмет одинаково легкий при весе 300 и 30000
Как правильно настроить вес rigidbody?
У меня предмет одинаково легкий при весе 300 и 30000
>>50210
Вообще, как сказать. Я делаю прямо на канве func _draw(): draw_circle(Vector2.ZERO, diameter, color) технически это создаёт спрайт внутри движка. На моём уровне спрайта нет, а кинематик-пулька рисует сама себя.
>>50212
Одинаково лёгкие они у тебя, когда их кинематик-персонаж толкает, да? Внимательно изучи документацию по move_and_slide. Там есть один интересный параметр по умолчанию: бесконечная инерция.
Вообще, как сказать. Я делаю прямо на канве func _draw(): draw_circle(Vector2.ZERO, diameter, color) технически это создаёт спрайт внутри движка. На моём уровне спрайта нет, а кинематик-пулька рисует сама себя.
>>50212
Одинаково лёгкие они у тебя, когда их кинематик-персонаж толкает, да? Внимательно изучи документацию по move_and_slide. Там есть один интересный параметр по умолчанию: бесконечная инерция.
>>50174
На спрайтах не взлетит, надо смотреть в сторону multimesh или частиц а то и шейдеров, физику тоже скорее всего надо выбрасывать и писать свою на distance squared.
На спрайтах не взлетит, надо смотреть в сторону multimesh или частиц а то и шейдеров, физику тоже скорее всего надо выбрасывать и писать свою на distance squared.
9,5 Мб, mp4,1024x600, 0:23
>>50232
Тут даже не в спрайтах дело, я упёрся в производительность на количестве объектов. Даже если у них нет визуала, они всё равно просаживают фпс.
Про мультимешь знаю. Но мне-то не только визуал нужен, а детект коллизий. Сейчас пытаюсь реализовать такую логику:
Есть спавнер пуль. Он создаёт вокруг себя Area2D, которая детектирует координаты тел, находящихся в ней. Далее частицы летят, спавнер проверяет совпадение координат детектированных тел и пулек. Таким образом пульки отрисовываются одной функцией и для них не нужны тысячи объектов. Будем посмотреть, что получится.
Тут даже не в спрайтах дело, я упёрся в производительность на количестве объектов. Даже если у них нет визуала, они всё равно просаживают фпс.
Про мультимешь знаю. Но мне-то не только визуал нужен, а детект коллизий. Сейчас пытаюсь реализовать такую логику:
Есть спавнер пуль. Он создаёт вокруг себя Area2D, которая детектирует координаты тел, находящихся в ней. Далее частицы летят, спавнер проверяет совпадение координат детектированных тел и пулек. Таким образом пульки отрисовываются одной функцией и для них не нужны тысячи объектов. Будем посмотреть, что получится.
>>50234
Подозреваю что любые Area будет вносить оверхед, тебе надо просто поверять по формуле, что-то типа (x-px)✱(x-px) + (y-py)✱(y-py) < radius✱radius
Подозреваю что любые Area будет вносить оверхед, тебе надо просто поверять по формуле, что-то типа (x-px)✱(x-px) + (y-py)✱(y-py) < radius✱radius
5 Кб, 509x214>>50235
И действительно. Накладывающиеся друг на друга эреи создают пикрелейтед. Пойду изучать формулу.
И действительно. Накладывающиеся друг на друга эреи создают пикрелейтед. Пойду изучать формулу.
34 Кб, 762x593>>50218
Аж вспомнились уроки паскаля и си в моей школе, ухх какие kerbal space program уровня /б/ мы с помощью примитивов и графиков делали
>draw_circle(Vector2.ZERO, diameter, color)
Аж вспомнились уроки паскаля и си в моей школе, ухх какие kerbal space program уровня /б/ мы с помощью примитивов и графиков делали
64 Кб, 1184x732>>50238
Расстояние между двумя точками равно диагонали треугольника на координатной сетке (одна сторона это разница координат по x, вторая по y)
Это расстояние сравнивают с радиусом (или суммой радиусов если у тебя игрок тоже круг, а не точка)
Очевидно, что если расстояние меньше радиуса, то круги пересекаются.
Формула диагонали d = sqrt(a2+b2) по теореме Пифагора
Мы проверяем d < r
Но поскольку корень дорогая операция, в движках оперируют squared значениями
d2 < r2
Таким образом в левой части просто не извлекают корень, а в правой, если возможно, используют константу. Например, если размер пули не меняется.
Расстояние между двумя точками равно диагонали треугольника на координатной сетке (одна сторона это разница координат по x, вторая по y)
Это расстояние сравнивают с радиусом (или суммой радиусов если у тебя игрок тоже круг, а не точка)
Очевидно, что если расстояние меньше радиуса, то круги пересекаются.
Формула диагонали d = sqrt(a2+b2) по теореме Пифагора
Мы проверяем d < r
Но поскольку корень дорогая операция, в движках оперируют squared значениями
d2 < r2
Таким образом в левой части просто не извлекают корень, а в правой, если возможно, используют константу. Например, если размер пули не меняется.
>>50246
Ну дак! Яж и ностальгирую таким образом по старым добрым временам. Отыскиваю вот такие пасхалки от Хуана, который тоже их заложил, ностальгируя по старым временам.
>>50247
Ну дак! Либо стул с инерцией, либо стул с коллизиями. Любое упрощение в главном является усложнением в мелочах. Кинематик боди с его простыми функциями движения означает, что всю физику тебе придётся запиливать самому.
>>50248
Слава Хуану, скваред предусмотрительно вынесен в интерфейс и выполняется в скомпилированных потрохах движка на си++.
Ну дак! Яж и ностальгирую таким образом по старым добрым временам. Отыскиваю вот такие пасхалки от Хуана, который тоже их заложил, ностальгируя по старым временам.
>>50247
Ну дак! Либо стул с инерцией, либо стул с коллизиями. Любое упрощение в главном является усложнением в мелочах. Кинематик боди с его простыми функциями движения означает, что всю физику тебе придётся запиливать самому.
>>50248
Слава Хуану, скваред предусмотрительно вынесен в интерфейс и выполняется в скомпилированных потрохах движка на си++.
7 Кб, 218x196Блять, я такого говна накодил прошлой осенью, пиздец!
Проще всё заново переписать.
И главное, все мы знаем знаменитую пословицу, что когда возвращаешься к коду, который написан давно, то ничего не понятно. Мне-то понятно, как там и что. Но оно так мудацки написано, что у меня фейспалм с прошлогоднего себя. Например, была задача с компоновкой графического интерфейса. Я нахуярил CanvasLayer в который положил несколько Control, пикрелейтед. Потом прилепил к нему скрипт и в нём хуярил логику для всех ветвей этой сцены. Потом я сделал ветви отдельными сценами, но скрипт переделывать мне было лень и я продолжил хуярить говнокод туда. Результат немного предсказуем - глючная каша.
Сейчас сижу, сдерживая дым из горящего пердака копипащу в отдельные скрипты подсцен фрагменты оригинального скрипта, чтобы инкапсулировать поведение каждой субсцены.
Проще всё заново переписать.
И главное, все мы знаем знаменитую пословицу, что когда возвращаешься к коду, который написан давно, то ничего не понятно. Мне-то понятно, как там и что. Но оно так мудацки написано, что у меня фейспалм с прошлогоднего себя. Например, была задача с компоновкой графического интерфейса. Я нахуярил CanvasLayer в который положил несколько Control, пикрелейтед. Потом прилепил к нему скрипт и в нём хуярил логику для всех ветвей этой сцены. Потом я сделал ветви отдельными сценами, но скрипт переделывать мне было лень и я продолжил хуярить говнокод туда. Результат немного предсказуем - глючная каша.
Сейчас сижу, сдерживая дым из горящего пердака копипащу в отдельные скрипты подсцен фрагменты оригинального скрипта, чтобы инкапсулировать поведение каждой субсцены.
как заставить спрайт смотреть в ту сторону, куда направлен вектор? пилю топдаун, довольно важно
131 Кб, 768x392Есть способ сделать тени короче? Маску там наложить какую-нибудь, скрипт, не?
>>50833
Но это же совсем не то. Меня интересует именно уменьшение длины тени, чтоб она выглядела так, будто её сам объект отбрасывает от источника света, который находится где-то сверху, а не на уровне ног.
Но это же совсем не то. Меня интересует именно уменьшение длины тени, чтоб она выглядела так, будто её сам объект отбрасывает от источника света, который находится где-то сверху, а не на уровне ног.
>>50834
Это скорее всего тебе придется на красные ноды перейти с синих. ЕВПОЧЯ.
Это скорее всего тебе придется на красные ноды перейти с синих. ЕВПОЧЯ.
95 Кб, 942x674Посаны, велосипед или нет?
Ткните носом в АПИ, если есть, пока я не написал ещё сотню строк кода.
Ткните носом в АПИ, если есть, пока я не написал ещё сотню строк кода.
45 Кб, 751x402>>50883
Как будто на 20 лет назад вернулся, во времена старого доброго дельфи!
Двоеточие-равно сильно добавляет атмосферы.
Как будто на 20 лет назад вернулся, во времена старого доброго дельфи!
Двоеточие-равно сильно добавляет атмосферы.
>>50902
Шейдеры не так страшны, как ты их себе малюешь. Стоит освоить шейдеры и всё остальное отбросишь за ненадобностью и тормознутостью.
> Придётся с шейдерами пердолиться?
Шейдеры не так страшны, как ты их себе малюешь. Стоит освоить шейдеры и всё остальное отбросишь за ненадобностью и тормознутостью.
>>50902
Оба варианта с ссылками на исходники, я сам 2д не занимаюсь. В первом, вроде бы нет шейдера, просто полигон рисуется дублированно несколько раз разными градациями яркости. Но и выглядит похуже. Второй с шейдером.
Оба варианта с ссылками на исходники, я сам 2д не занимаюсь. В первом, вроде бы нет шейдера, просто полигон рисуется дублированно несколько раз разными градациями яркости. Но и выглядит похуже. Второй с шейдером.
Всем привет. Как Шейдеры нормально использовать на все элементы, а не только на 1? Когда делаю color-rect сверху, чтобы он что-то сделал со screen_texture выдает ошибку. 2D. Да и работать с полной screen_texture не удобно, хочу ограниченную рамку и менять все что под ней относительно этой рамки.
>>51196
LocalToScene
LocalToScene
>>51196
Или нет, падажжи. Тебя хуй поймёшь. Может имеется ввиду, что ограничить отрисовук рамкой? Тогда ClipContent
Или нет, падажжи. Тебя хуй поймёшь. Может имеется ввиду, что ограничить отрисовук рамкой? Тогда ClipContent
50 минут и вы начинаете делать игры:
https://www.youtube.com/watch?v=QftpPI5iYrY
https://www.youtube.com/watch?v=QftpPI5iYrY
273 Кб, 855x571Ля какую годноту нашёл!
Пикрелейтед. Взято отсюда: https://youtu.be/4xMaq-qVQGY?t=421
Пикрелейтед. Взято отсюда: https://youtu.be/4xMaq-qVQGY?t=421
>>43188 (OP)
Есть какой-то способ, как ускорить/оптимизировать сам Godot? У меня даже на зионе с 8 гб оперативы он умудряется тормозить. Сомневаюсь, что можно делать что-то сложнее хеллоуворлда с такими лагами. Я, конечно, понимаю, что движок целиком в одном exe под 50 метров, вряд ли из него что-то можно выкинуть, но ведь исходники открытые, должен быть способ перекомпилировать в облегченном режиме...
А ещё бы интерфейс по-проще, вместо "а-ля Блендер", но это неосуществимые мечты
Есть какой-то способ, как ускорить/оптимизировать сам Godot? У меня даже на зионе с 8 гб оперативы он умудряется тормозить. Сомневаюсь, что можно делать что-то сложнее хеллоуворлда с такими лагами. Я, конечно, понимаю, что движок целиком в одном exe под 50 метров, вряд ли из него что-то можно выкинуть, но ведь исходники открытые, должен быть способ перекомпилировать в облегченном режиме...
А ещё бы интерфейс по-проще, вместо "а-ля Блендер", но это неосуществимые мечты
>>51374
Время переустанавливать шындовс. Или что там у тебя. Потому что кроме тебя на тормоза редактора никто не жалуется.
Время переустанавливать шындовс. Или что там у тебя. Потому что кроме тебя на тормоза редактора никто не жалуется.
>>51380
Ничо не тормозит на вот таком конфиге.
Ничо не тормозит на вот таком конфиге.
>>51374
Пиши конкретику, тут вообще не ясно что именно у тебя тормозит. У меня на двух ядрах и 4 гб не тормозит, если не использовать еба постпроцессинг. Какая у тебя видеокарта? Возможно в ней затык.
У меня была история с тормозами когда я добавил ноду с ошибкой. Не помню, в чем там была причина, то ли моделька была неправильная, то ли скрипт, в результате в лог сыпалось много ошибок, и из за этого сцена запускалась в 10 раз дольше. После удаления ноды и добавления заново все исправилось.
Пиши конкретику, тут вообще не ясно что именно у тебя тормозит. У меня на двух ядрах и 4 гб не тормозит, если не использовать еба постпроцессинг. Какая у тебя видеокарта? Возможно в ней затык.
У меня была история с тормозами когда я добавил ноду с ошибкой. Не помню, в чем там была причина, то ли моделька была неправильная, то ли скрипт, в результате в лог сыпалось много ошибок, и из за этого сцена запускалась в 10 раз дольше. После удаления ноды и добавления заново все исправилось.
>>51244
Нет. Мне надо взять кусок экрана и размазать его со всеми элементами на нем. Но мне выдает ошибку буфера. Я ставлю copybuffer снизу, но мне все равно выдает ошибку и в игре все что было с шейдером черное. Я так понял из-за вечного шейдерного цикла. Чертов SCREEN_TEXTURE;
Нет. Мне надо взять кусок экрана и размазать его со всеми элементами на нем. Но мне выдает ошибку буфера. Я ставлю copybuffer снизу, но мне все равно выдает ошибку и в игре все что было с шейдером черное. Я так понял из-за вечного шейдерного цикла. Чертов SCREEN_TEXTURE;
>>43188 (OP)
Что ж, пришло время задавать очень глупые вопросы.
Статус: Новичок.
Что за управление в Godot ?
ПКМ - Вращение сцены. А Как двигаться ?
Что ж, пришло время задавать очень глупые вопросы.
Статус: Новичок.
Что за управление в Godot ?
ПКМ - Вращение сцены. А Как двигаться ?
>>51442
Управление в 3д редакторе:
Пр. кнопка мыши - вращать камерой
Ср. кнопка мыши - вращать вокруг выбранного объекта
Шифт + Ср. кнопка мыши - перетаскивание камеры редактора
Пр. кнопка мыши + WASD - движение как в шутере
Shift+F вкл/ввкл режим WASD
F - навести камеру на выбранный объект.
Управление в 3д редакторе:
Пр. кнопка мыши - вращать камерой
Ср. кнопка мыши - вращать вокруг выбранного объекта
Шифт + Ср. кнопка мыши - перетаскивание камеры редактора
Пр. кнопка мыши + WASD - движение как в шутере
Shift+F вкл/ввкл режим WASD
F - навести камеру на выбранный объект.
2,3 Мб, 1920x1080Хочу сделать игру типа Obsurity Huper light Drifter.
Что лучше выбрать, Годот или Гейммейкер?
Точно знаю, что гейммейкер подойдёт, ведь оригинал на нём и сделан, но это вроде очень ограниченный движок, а Годот позиционируется как что-то уровня Юнити, но без тормозов.
Может ли Годот в такое 2Д и есть ли тут какие-то подводные камни?
Просо если изучать с 0, то лучше уж что-то более продвинутое и мощное.
Не срача ради. Не надо сравнивать движки, просто ответе на вопрос, будет ли для этой цели Годот таким же подходящим как гейммейкер и есть ли у него какие-то плюсы в этом плане?
Что лучше выбрать, Годот или Гейммейкер?
Точно знаю, что гейммейкер подойдёт, ведь оригинал на нём и сделан, но это вроде очень ограниченный движок, а Годот позиционируется как что-то уровня Юнити, но без тормозов.
Может ли Годот в такое 2Д и есть ли тут какие-то подводные камни?
Просо если изучать с 0, то лучше уж что-то более продвинутое и мощное.
Не срача ради. Не надо сравнивать движки, просто ответе на вопрос, будет ли для этой цели Годот таким же подходящим как гейммейкер и есть ли у него какие-то плюсы в этом плане?
>>51467
Брать 3д движок для 2д игры и рассчитывать на то, что "будет быстрее"? Ну такое.
В любом случае результат зависит только от тебя. Движок за тебя игру не сделает.
Брать 3д движок для 2д игры и рассчитывать на то, что "будет быстрее"? Ну такое.
В любом случае результат зависит только от тебя. Движок за тебя игру не сделает.
>>51467
Кем? Где?
Да, конечно.
Есть, кое что придется оптимизировать самому.
>Годот позиционируется как что-то уровня Юнити, но без тормозов.
Кем? Где?
>Не срача ради. Не надо сравнивать движки, просто ответе на вопрос, будет ли для этой цели Годот таким же подходящим как гейммейкер
Да, конечно.
>Может ли Годот в такое 2Д и есть ли тут какие-то подводные камни?
Есть, кое что придется оптимизировать самому.
>>51411
Ты прав, что-то странное, то же самое. Попробую разобраться.
Ты прав, что-то странное, то же самое. Попробую разобраться.
>>51469
У него в классе. А может старшики из 5б просветили.
>Годот позиционируется как что-то уровня Юнити, но без тормозов.
>Кем? Где?
У него в классе. А может старшики из 5б просветили.
>>51469
Спасибо.
Спасибо.
Кто делал под андроид/ios, подскажите какой там минимальный размер apk файла с одним движком выходит.
2 Кб, 496x37>>51761
А что примерно и где настраивается для этого? А то сейчас в apk засовывается чудо таких размеров.
А что примерно и где настраивается для этого? А то сейчас в apk засовывается чудо таких размеров.
>>51764
Вот мой батник сборки
call d:\python36\Scripts\scons.bat p=android -j2 verbose=true tools=no target=release_debug ndk_platform=android-21 optimize=speed tools=no use_lto=no deprecated=no xaudio2=no disable_3d=yes disable_advanced_gui=yes no_editor_splash=yes builtin_bullet=no builtin_certs=no builtin_enet=no builtin_libtheora=no builtin_libvorbis=no builtin_libvpx=no builtin_libwebp=no builtin_libwebsockets=no builtin_mbedtls=no builtin_miniupnpc=no builtin_opus=no builtin_pcre2=no builtin_recast=no builtin_squish=no builtin_thekla_atlas=no builtin_xatlas=no debug_symbols=no separate_debug_symbols=no android_stl=no module_bmp_enabled=no module_bullet_enabled=no module_csg_enabled=no module_cvtt_enabled=no module_dds_enabled=no module_enet_enabled=no module_etc_enabled=no module_gdnative_enabled=no module_gridmap_enabled=no module_hdr_enabled=no module_jpg_enabled=no module_mbedtls_enabled=no module_mobile_vr_enabled=no module_mono_enabled=no module_opensimplex_enabled=no module_opus_enabled=no module_pvr_enabled=no module_recast_enabled=no module_regex_enabled=no module_squish_enabled=no module_stb_vorbis_enabled=no module_svg_enabled=no module_tga_enabled=no module_thekla_unwrap_enabled=no module_theora_enabled=no module_tinyexr_enabled=no module_upnp_enabled=no module_visual_script_enabled=no module_vorbis_enabled=no module_webm_enabled=no module_webp_enabled=no module_websocket_enabled=no module_xatlas_unwrap_enabled=no config=force
Плюс до сборки у меня накатываются
git fetch origin pull/35957/head:batch-2d
git cherry-pick --strategy-option=theirs d04cd4a
git fetch origin pull/36065/head:camera2d_helper_editor_only
git cherry-pick --strategy-option=theirs 69603e2
Плюс можно руками выкинуть GodotPaymentV3.java если не пользуешься.
Вот мой батник сборки
call d:\python36\Scripts\scons.bat p=android -j2 verbose=true tools=no target=release_debug ndk_platform=android-21 optimize=speed tools=no use_lto=no deprecated=no xaudio2=no disable_3d=yes disable_advanced_gui=yes no_editor_splash=yes builtin_bullet=no builtin_certs=no builtin_enet=no builtin_libtheora=no builtin_libvorbis=no builtin_libvpx=no builtin_libwebp=no builtin_libwebsockets=no builtin_mbedtls=no builtin_miniupnpc=no builtin_opus=no builtin_pcre2=no builtin_recast=no builtin_squish=no builtin_thekla_atlas=no builtin_xatlas=no debug_symbols=no separate_debug_symbols=no android_stl=no module_bmp_enabled=no module_bullet_enabled=no module_csg_enabled=no module_cvtt_enabled=no module_dds_enabled=no module_enet_enabled=no module_etc_enabled=no module_gdnative_enabled=no module_gridmap_enabled=no module_hdr_enabled=no module_jpg_enabled=no module_mbedtls_enabled=no module_mobile_vr_enabled=no module_mono_enabled=no module_opensimplex_enabled=no module_opus_enabled=no module_pvr_enabled=no module_recast_enabled=no module_regex_enabled=no module_squish_enabled=no module_stb_vorbis_enabled=no module_svg_enabled=no module_tga_enabled=no module_thekla_unwrap_enabled=no module_theora_enabled=no module_tinyexr_enabled=no module_upnp_enabled=no module_visual_script_enabled=no module_vorbis_enabled=no module_webm_enabled=no module_webp_enabled=no module_websocket_enabled=no module_xatlas_unwrap_enabled=no config=force
Плюс до сборки у меня накатываются
git fetch origin pull/35957/head:batch-2d
git cherry-pick --strategy-option=theirs d04cd4a
git fetch origin pull/36065/head:camera2d_helper_editor_only
git cherry-pick --strategy-option=theirs 69603e2
Плюс можно руками выкинуть GodotPaymentV3.java если не пользуешься.
>>51768
Да, естественно это без 3d, и без rich texteditor ну мало ли не очевидно
Да, естественно это без 3d, и без rich texteditor ну мало ли не очевидно
7 Кб, 303x130>>51771
Это удваивает размер сходу. А в плеймаркете, вроде, можно по отдельности заливать апк под каждую архитектуру.
Да.
>так делал дефолтную под две
Это удваивает размер сходу. А в плеймаркете, вроде, можно по отдельности заливать апк под каждую архитектуру.
>это надо движок пересобрать сам?
Да.
>>51772
да сборки под каждую понятно, что увеличивают на количество сборок в одном пакете, просто сама библиотека движка на 27 мб впечатлила
спасибо, буду разбираться
да сборки под каждую понятно, что увеличивают на количество сборок в одном пакете, просто сама библиотека движка на 27 мб впечатлила
спасибо, буду разбираться
59 Кб, 887x1003>>51776
Вот эта галочка, возможно если ты ее уберешь, тебе этого хватит.
Вот эта галочка, возможно если ты ее уберешь, тебе этого хватит.
Как правильно пользоваться Area? Я правильно понимаю, что Area можно использовать как зону-триггер? Вот с RayCast было несложно разобраться (у него много параметров, функций, etc), а назначение Area не ясно.
>>51779
Да, можно. Она посылает сигналы, если в нее вошла/вышла другая зона, вошло/вышло Kinematic/Rigid/Static Body. Можно вручную вызывать функции, которые перечисляют с какими area или body есть пересечение. Еще там можно задавать свою гравитацию и параметры звука, но с этим я пока не знаком.
>Area можно использовать как зону-триггер?
Да, можно. Она посылает сигналы, если в нее вошла/вышла другая зона, вошло/вышло Kinematic/Rigid/Static Body. Можно вручную вызывать функции, которые перечисляют с какими area или body есть пересечение. Еще там можно задавать свою гравитацию и параметры звука, но с этим я пока не знаком.
12 Кб, 225x300Просмотрел по диагонали это: https://godotengine.org/article/optional-typing-gdscript
Я так и не понял, есть в Годо типизированные массивы или нет?
Если есть, как они правильно объявляются? Без типа у меня так:
Но тогда при задании значений массива через GUI приходится для каждой (!) ячейки указывать тип из большого списка типов. Я задолбался даже с 6-ю ячейками. Есть какой-то способ указать редактору, что я планирую заполнять массив данными одного типа?
И какой извращенец придумал хранить в массивах variant'ы? Это же противоречит самой сути массива, предназначение которого - однородные данные...
>Jul 22, 2018
>...
>Future
>New instructions for typed code to allow faster execution. This includes avoiding the Variant evaluator and using typed arrays as well.
Я так и не понял, есть в Годо типизированные массивы или нет?
Если есть, как они правильно объявляются? Без типа у меня так:
>export var collection = []
Но тогда при задании значений массива через GUI приходится для каждой (!) ячейки указывать тип из большого списка типов. Я задолбался даже с 6-ю ячейками. Есть какой-то способ указать редактору, что я планирую заполнять массив данными одного типа?
И какой извращенец придумал хранить в массивах variant'ы? Это же противоречит самой сути массива, предназначение которого - однородные данные...
>>51818
Сам спросил @ сам ответил:
https://godotengine.org/qa/43783/static-typing-of-arrays-syntax
Короче, всё через жопу. Ну, хотя бы для строк есть PoolStringArray, и то ладно...
Сам спросил @ сам ответил:
>Type hints can't be used with arrays. The Array container in Godot is a variant container. If you have a particular need for a single-typed array, there are the Pool*Array types.
https://godotengine.org/qa/43783/static-typing-of-arrays-syntax
Короче, всё через жопу. Ну, хотя бы для строк есть PoolStringArray, и то ладно...
>>51851 (Del)
вот уж сисярп там точно не нужен, если надо скрипты, то надо брать что-то нормальное интерпретируемое вроде Lua
вот уж сисярп там точно не нужен, если надо скрипты, то надо брать что-то нормальное интерпретируемое вроде Lua
>>51820
Вроде в 4.0 что-то переделают в этом плане, и всякие Pool*Array тоже заменят на другое.
Вроде в 4.0 что-то переделают в этом плане, и всякие Pool*Array тоже заменят на другое.
>>51868
Ну там собственно сделать С API, дальше сами желающие будут пилить биндинги под нужные им языки.
Ну там собственно сделать С API, дальше сами желающие будут пилить биндинги под нужные им языки.
>>51868
Чорт, опять новая мажорная версия?
Помнится, когда я щупал 2.x, узнал, что скоро будет 3.0, в которой много чего поменяют, и в итоге забил на Годо более чем на год, ожидая выхода этой самой 3.0, чтобы не углубляться в заведомо устаревшую версию...
Хорошо бы сделали как в Pascal:
var A: array [n .. m] of String; // массив с фиксированными границами
var A: array of String; // динамический массив, можно изменять длину
Вот именно второй вариант я ожидал больше всего.
Если в GDScript есть Variant, то имеющиеся сейчас массивы должны описываться так:
var A: array of Variant
Можно было сделать этот тип массива типом по умолчанию, но уж точно не делать его единственным. -_-
>в 4.0 что-то переделают
Чорт, опять новая мажорная версия?
Помнится, когда я щупал 2.x, узнал, что скоро будет 3.0, в которой много чего поменяют, и в итоге забил на Годо более чем на год, ожидая выхода этой самой 3.0, чтобы не углубляться в заведомо устаревшую версию...
>всякие Pool*Array тоже заменят на другое
Хорошо бы сделали как в Pascal:
var A: array [n .. m] of String; // массив с фиксированными границами
var A: array of String; // динамический массив, можно изменять длину
Вот именно второй вариант я ожидал больше всего.
Если в GDScript есть Variant, то имеющиеся сейчас массивы должны описываться так:
var A: array of Variant
Можно было сделать этот тип массива типом по умолчанию, но уж точно не делать его единственным. -_-
Задумался тут: если мне нужно сместить точку крепления модели (origin point), я могу это только через дополнительный Spatial сделать, так ведь? Как движок относится к большому числу таких пустышек?
Ещё я такие пустышки использую как точки спавна, и меня беспокоит, должен ли я заменять эту точку на то, что спавнится, или пусть дальше висит... Удобно просто делать сцену дочерней от точки спавна, но я подозреваю, что с большим числом моделей это может сильно повлиять на производительность. Нет?
Вообще, сколько всего объектов (не полигонов, а вот этих сущностей) может держать Godot без просадок производительности?
Ещё я такие пустышки использую как точки спавна, и меня беспокоит, должен ли я заменять эту точку на то, что спавнится, или пусть дальше висит... Удобно просто делать сцену дочерней от точки спавна, но я подозреваю, что с большим числом моделей это может сильно повлиять на производительность. Нет?
Вообще, сколько всего объектов (не полигонов, а вот этих сущностей) может держать Godot без просадок производительности?
>>51881
Хуёво. Я десятком постов выше экспериментировал с буллетхеллом. Так вот там, если просто спавнить пустышки и добавлять их в дерево, то где-то на 5к штук начинает падать фпс. Экспоненциально. Я там отписался, что из-за спавна Area фпс падает, но потом заменил Area на пустышку, охуел и не стал ничего сообщать.
> Как движок относится к большому числу таких пустышек?
Хуёво. Я десятком постов выше экспериментировал с буллетхеллом. Так вот там, если просто спавнить пустышки и добавлять их в дерево, то где-то на 5к штук начинает падать фпс. Экспоненциально. Я там отписался, что из-за спавна Area фпс падает, но потом заменил Area на пустышку, охуел и не стал ничего сообщать.
>>51884
Это питон, а не луа. Луа это говноподелие без массивов, с индексами начинающимися с 1, и так далее.
Это питон, а не луа. Луа это говноподелие без массивов, с индексами начинающимися с 1, и так далее.
>>51887
Я не луашизик, срущий своим луа по всем тредам, если чо. Но, справедливости ради, луа при всех своих странностях является одним из быстрых скриптовых языков. И юзается в большом количестве игор. Примеры сам загуглишь.
> Луа это говноподели
Я не луашизик, срущий своим луа по всем тредам, если чо. Но, справедливости ради, луа при всех своих странностях является одним из быстрых скриптовых языков. И юзается в большом количестве игор. Примеры сам загуглишь.
>>51890
Только за счет того что в нем очень мало возможностей. А LuaJIT нечестно сравнивать, потому что даже Java обгоняет его в таком случае.
В основном доисторических 10+ лет назад.
>является одним из быстрых скриптовых языков.
Только за счет того что в нем очень мало возможностей. А LuaJIT нечестно сравнивать, потому что даже Java обгоняет его в таком случае.
>И юзается в большом количестве игор
В основном доисторических 10+ лет назад.
>>51891
Ну таки да. Но луашизику хуй чо докажешь. Второй год уже ноет, типа "почему луа не завезли?"
Ну таки да. Но луашизику хуй чо докажешь. Второй год уже ноет, типа "почему луа не завезли?"
>>51875
вообще-то питона и далеко не Lua
вообще-то питона и далеко не Lua
4 Кб, 217x116>>51885
Ну, это было ожидаемо. Ладно, от части Spatial я могу избавиться (хотя всё равно не ясно, можно ли как-то иначе изменять origin без плясок с бубном). Тогда следующий вопрос: возможно ли "выключать" отдельные ноды из общего дерева, чтобы они временно не тормозили игровой цикл, пока не потребуются? Собирался грубо кодом разрывать связь между предком и потомком, сохраняя потомка в отдельной переменной, чтобы потом возвращать когда понадобится, но мне на глаза постоянно попадается вот эта вкладка "Pause", и мне любопытно. Пауза ведь именно для такой заморозки объектов, которая мне нужна? Или она для чего-то другого? Если я поставлю на паузу дерево из, скажем, сотни веток - они все будут исключены из общего цикла, или будет что-то вроде if not entity.paused then entity.process else continue? В первом случае выигрыш примерно как в моём варианте, во втором всё равно каждый кадр будут лишние операции.
>где-то на 5к штук начинает падать фпс
Ну, это было ожидаемо. Ладно, от части Spatial я могу избавиться (хотя всё равно не ясно, можно ли как-то иначе изменять origin без плясок с бубном). Тогда следующий вопрос: возможно ли "выключать" отдельные ноды из общего дерева, чтобы они временно не тормозили игровой цикл, пока не потребуются? Собирался грубо кодом разрывать связь между предком и потомком, сохраняя потомка в отдельной переменной, чтобы потом возвращать когда понадобится, но мне на глаза постоянно попадается вот эта вкладка "Pause", и мне любопытно. Пауза ведь именно для такой заморозки объектов, которая мне нужна? Или она для чего-то другого? Если я поставлю на паузу дерево из, скажем, сотни веток - они все будут исключены из общего цикла, или будет что-то вроде if not entity.paused then entity.process else continue? В первом случае выигрыш примерно как в моём варианте, во втором всё равно каждый кадр будут лишние операции.
>>51898
Возможно. Буквально в прошлом треде и начале этого обсуждали такой трюк:
1. Делаешь ноду, не включенную в общее дерево. Она висит в памяти в спящем режиме, у неё и всех её потомков не вызываются колбэки и т.п.
2. Ноды, которые надо выключить, перекидываешь в потомки этой ноды.
3. Ноды, которые надо включить, возвращаешь на свои места в дереве.
4. С помощью этой нехитрой системы можно организовать пул для динамической подгрузки чанков локаций.
> возможно ли "выключать" отдельные ноды из общего дерева, чтобы они временно не тормозили игровой цикл, пока не потребуются?
Возможно. Буквально в прошлом треде и начале этого обсуждали такой трюк:
1. Делаешь ноду, не включенную в общее дерево. Она висит в памяти в спящем режиме, у неё и всех её потомков не вызываются колбэки и т.п.
2. Ноды, которые надо выключить, перекидываешь в потомки этой ноды.
3. Ноды, которые надо включить, возвращаешь на свои места в дереве.
4. С помощью этой нехитрой системы можно организовать пул для динамической подгрузки чанков локаций.
>>51891
Java не обгоняет LuaJIT
нет, его используют и сейчас все так же активно в индустрии, т.к. замены пока не сделали сопоставимой
Java не обгоняет LuaJIT
нет, его используют и сейчас все так же активно в индустрии, т.к. замены пока не сделали сопоставимой
>>51901
В некоторых бенчах обгоняет. Как и питон, и т.д.
Там где он уже есть в легаси, как например в ГТА потому что он у них там давно.
В новых играх - где?
>Java не обгоняет LuaJIT
В некоторых бенчах обгоняет. Как и питон, и т.д.
> его используют и сейчас
Там где он уже есть в легаси, как например в ГТА потому что он у них там давно.
В новых играх - где?
>>51902
в новых играх и скриптовые языки-то почти и не используют, т.к. там какой-либо моддинг не предусмотрен
roblox, factorio, don't starve.. почти везде, где есть какие-то моды и не используют свой язык, типа tes
в новых играх и скриптовые языки-то почти и не используют, т.к. там какой-либо моддинг не предусмотрен
roblox, factorio, don't starve.. почти везде, где есть какие-то моды и не используют свой язык, типа tes
>>51909
Другие не жалели, а roblox с учетом масштаба работы еще и прорабатывали обоснованность выбора каждого из языков.
Другие не жалели, а roblox с учетом масштаба работы еще и прорабатывали обоснованность выбора каждого из языков.
>>51910
Другие - это ноль, на уровне статистической погрешности. А уеблокс вообще не игра, а какое то кривляние для школьников, похуй.
Другие - это ноль, на уровне статистической погрешности. А уеблокс вообще не игра, а какое то кривляние для школьников, похуй.
>>51915
Так я делаю, к чему вообще это.
Так я делаю, к чему вообще это.
>>51900
О, ну почти именно так я и планировал. Только хотел извлекать одну ноду в переменную целиком, а не поштучно закидывать.
Хм, я это задумывал для подгрузки комнат в домах. Подходишь и открываешь дверь - комната появляется, закрываешь (снаружи) и отходишь - внутренности пропадают. А вот над чанками надо подумоть)
Так а для чего режим паузы нодов? Погуглил, жалуются, что паузить можно только всё дерево целиком...
О, ну почти именно так я и планировал. Только хотел извлекать одну ноду в переменную целиком, а не поштучно закидывать.
>можно организовать пул для динамической подгрузки чанков локаций
Хм, я это задумывал для подгрузки комнат в домах. Подходишь и открываешь дверь - комната появляется, закрываешь (снаружи) и отходишь - внутренности пропадают. А вот над чанками надо подумоть)
Так а для чего режим паузы нодов? Погуглил, жалуются, что паузить можно только всё дерево целиком...
>>51919
Помещения дома не критичны, на то, что ты их менеджерить будешь и выгружать/загружать скорее больше ресурсов и потратишь. Просто разбивай сам уровень на чанки по какому-то радиусу и сохраняй на диск ненужные, а все их ноды удаляй.
Помещения дома не критичны, на то, что ты их менеджерить будешь и выгружать/загружать скорее больше ресурсов и потратишь. Просто разбивай сам уровень на чанки по какому-то радиусу и сохраняй на диск ненужные, а все их ноды удаляй.
>>51920
Критичны, окклюжн куллинга то нет.
Критичны, окклюжн куллинга то нет.
>>51920
Только если:
1. В помещениях мало объектов
2. Мало домов с помещениями
я жта хочу, но чтоб в домики заходить можно было
Вопщем, надо просто тесты провести и самому убедиться.
>Помещения дома не критичны
Только если:
1. В помещениях мало объектов
2. Мало домов с помещениями
я жта хочу, но чтоб в домики заходить можно было
Вопщем, надо просто тесты провести и самому убедиться.
Продолжение >>51881 >>51898
Короч, если кому-то интересно, я немного поэкспериментировал и пришёл к таким выводам:
- отключение нод работает именно так, как я думал;
- подключение и отключение статикбади происходит мгновенно;
- подключение и отключение динамикбади вызывает фриз игры на секунду.
Похоже, что дело не в количестве нод, а в наличии подвижных объектов. В частности, пробовал наполнять жёлтую комнату как статичными, так и динамичными объектами (те же точки, то же количество) - статичные появляются мгновенно, динамические при появлении и исчезновении вызывают очень неприятную задержку, но после появления ведут себя как обычно (не тормозят).
Ещё заметил момент, важный конкретно для моей игры - если предмет выкатывается из комнаты, он по-прежнему остаётся привязанным к "исчезающим". То есть для игрока предмет на улице, но выходя на улицу предмет исчезает, таким образом становится недосягаемым. Знаю, как это можно исправить, да. Но вот от лага при добавлении/удалении хотелось бы избавиться. Я был бы согласен, если бы объекты появлялись постепенно, если б не вызывали лаг... А, ну, можно попробовать добавлять/удалять не в цикле for, а в _(physics)_process, но сомневаюсь, что получится норм.
Пока что Godot превосходит мои ожидания :D
Короч, если кому-то интересно, я немного поэкспериментировал и пришёл к таким выводам:
- отключение нод работает именно так, как я думал;
- подключение и отключение статикбади происходит мгновенно;
- подключение и отключение динамикбади вызывает фриз игры на секунду.
Похоже, что дело не в количестве нод, а в наличии подвижных объектов. В частности, пробовал наполнять жёлтую комнату как статичными, так и динамичными объектами (те же точки, то же количество) - статичные появляются мгновенно, динамические при появлении и исчезновении вызывают очень неприятную задержку, но после появления ведут себя как обычно (не тормозят).
Ещё заметил момент, важный конкретно для моей игры - если предмет выкатывается из комнаты, он по-прежнему остаётся привязанным к "исчезающим". То есть для игрока предмет на улице, но выходя на улицу предмет исчезает, таким образом становится недосягаемым. Знаю, как это можно исправить, да. Но вот от лага при добавлении/удалении хотелось бы избавиться. Я был бы согласен, если бы объекты появлялись постепенно, если б не вызывали лаг... А, ну, можно попробовать добавлять/удалять не в цикле for, а в _(physics)_process, но сомневаюсь, что получится норм.
Пока что Godot превосходит мои ожидания :D
>>51998
Думой над архитектурой.
Допустим по сюжету игры планируется появление и исчезновение объектов. Значит ты их все грузишь при загрузке локации, затем те, которых нет для игрока делаешь невидимыми/отключёнными в большом невидимом сундуке под землёй (привет, скайрим).
Полагаю ты про parents и owners говоришь сейчас? Если так, то сомнительно использовать механизм овнеров для динамической передачи нод между нодами. Возможно наткнуться на трудноотлавливаемые баги.
Я бы посоветовал делать одну общую ноду для "пропсов", которая по запросу игровой логики выдаёт из своего пула заранее загруженных объектов нужные локациям. Так ты избежишь проблем с
Чтобы была возможность дизайнить расположение объектов в редакторе, делай объекты-пустышки, которые уничтожают сами себя при загрузке сцены, а на их места ставятся реальные объекты из общей ноды, описанной выше.
Как-то так.
Думой над архитектурой.
Допустим по сюжету игры планируется появление и исчезновение объектов. Значит ты их все грузишь при загрузке локации, затем те, которых нет для игрока делаешь невидимыми/отключёнными в большом невидимом сундуке под землёй (привет, скайрим).
> Знаю, как это можно исправить, да.
Полагаю ты про parents и owners говоришь сейчас? Если так, то сомнительно использовать механизм овнеров для динамической передачи нод между нодами. Возможно наткнуться на трудноотлавливаемые баги.
Я бы посоветовал делать одну общую ноду для "пропсов", которая по запросу игровой логики выдаёт из своего пула заранее загруженных объектов нужные локациям. Так ты избежишь проблем с
> если предмет выкатывается из комнаты, он по-прежнему остаётся привязанным к "исчезающим"
Чтобы была возможность дизайнить расположение объектов в редакторе, делай объекты-пустышки, которые уничтожают сами себя при загрузке сцены, а на их места ставятся реальные объекты из общей ноды, описанной выше.
Как-то так.
>>51998
Короче, я ошибся. DynamicBody вообще не имел отношения к этим фризам.
Лень писать, опишу ситуацию кратко:
- динамические кубики CSGBox лагов не вызывали;
- сферы на скриншоте - CSGSphere с параметрами 24x12;
- снижение CSGSphere 24x12 -> 8x4 снизило нагрузку/лаги;
- 64 головы Suzanne из Blender (по 507 вершин) не тормозят.
Вывод - CSG перед появлением в дереве производит какую-то ресурсоёмкую операцию (пытается произвести слияние, даже если не с кем?), и именно она вызывает тормоза. После удаления из дерева тоже происходит какая-то операция, и снова тормоза. Всё остальное время лагов нет - меш, видимо, кэшируется. С обычными мешами такого нет.
Короче, короче... С одной стороны обидно, что так долго мучился, с другой - рад, что Годо на самом деле не такой тормоз, как я думал изначально. Теперь можно избавиться от мартышек продолжить маяться дурью делать игру.
>>52005
Именно так и делаю.
Так не пойдёт, Годо работает не так, хранить нужно отдельно от дерева сцены.
Точнее нужно хранить ссылку на вырезанную из общего дерева ветку в отдельной переменной.
Не знаю про owners, но я хотел передавать объект из одной ветки в другую.
Несколько раз перечитывал, много думал, но ничего не понял. Грубо говоря, мне нужно передать ветку "предмет" из ноды "квартира" в ноду "улица", потому что нода "квартира" скрывает своё содержимое, когда игрок выходит за пределы квартиры (в целях оптимизации дерева сцены, разумеется). Если так не сделать, то "предмет" исчезнет прямо в руках игрока, когда он перешагнёт порог квартиры/закроет дверь в квартиру снаружи.
Я так и сделал, но у меня эти пустышки нужны для спавна рандомных предметов (запилил универсальный скрипт).
Эм, а зачем их хранить в общей ноде? У меня они сразу появляются на точках спавна. Когда не нужны - скрываются во внутреннюю переменную скрывающей ноды (все сразу). Проблема в том, что делать общую ноду на всю сцену нерационально, у меня сейчас по сути каждая комната занимается скрытием/отображением предметов (генерация только при запуске сцены).
Вот, для примера, на скриншоте с мартышками 3.7К нод - это улица с многоэтажками, а 12.5К нод-сирот - это внутренности тех комнат, в которых игрока сейчас нет (поэтому они скрыты). Если выйти из комнаты с мартышками, они все будут скрыты. Комната сама принимает решение, когда скрывать (с помощью Area), и сама же хранит все свои внутренности. В данный момент всё это выглядит превосходно, проблема только в том, что предметы комнаты нельзя вынести за пределы комнаты. Хотя, я думаю, можно использовать ту же Area, что следит за игроком, чтобы "выпускать" предметы за пределы комнаты...
Вообще, мне главное придерживаться модульного дизайна, чтобы каждый элемент сцены был максимально независим от других. Иначе не получится так легко собирать рандомную сцену (хотя над алгоритмом сборки я всё ещё думаю). Поэтому, например, каждая комната, являясь отдельным модулем, сама заботится о генерации, отображении и скрытии находящихся в ней предметов. Такую систему легко масштабировать... контролировать, правда, трудно, но с этим я ещё разберусь.
>подключение и отключение динамикбади вызывает фриз игры на секунду.
Короче, я ошибся. DynamicBody вообще не имел отношения к этим фризам.
Лень писать, опишу ситуацию кратко:
- динамические кубики CSGBox лагов не вызывали;
- сферы на скриншоте - CSGSphere с параметрами 24x12;
- снижение CSGSphere 24x12 -> 8x4 снизило нагрузку/лаги;
- 64 головы Suzanne из Blender (по 507 вершин) не тормозят.
Вывод - CSG перед появлением в дереве производит какую-то ресурсоёмкую операцию (пытается произвести слияние, даже если не с кем?), и именно она вызывает тормоза. После удаления из дерева тоже происходит какая-то операция, и снова тормоза. Всё остальное время лагов нет - меш, видимо, кэшируется. С обычными мешами такого нет.
Короче, короче... С одной стороны обидно, что так долго мучился, с другой - рад, что Годо на самом деле не такой тормоз, как я думал изначально. Теперь можно избавиться от мартышек продолжить маяться дурью делать игру.
>>52005
>Значит ты их все грузишь при загрузке локации
Именно так и делаю.
>отключёнными в большом невидимом сундуке под землёй
Так не пойдёт, Годо работает не так, хранить нужно отдельно от дерева сцены.
Точнее нужно хранить ссылку на вырезанную из общего дерева ветку в отдельной переменной.
>Полагаю ты про parents и owners говоришь сейчас?
Не знаю про owners, но я хотел передавать объект из одной ветки в другую.
>одну общую ноду для "пропсов", которая по запросу игровой логики выдаёт из своего пула заранее загруженных объектов нужные локациям
Несколько раз перечитывал, много думал, но ничего не понял. Грубо говоря, мне нужно передать ветку "предмет" из ноды "квартира" в ноду "улица", потому что нода "квартира" скрывает своё содержимое, когда игрок выходит за пределы квартиры (в целях оптимизации дерева сцены, разумеется). Если так не сделать, то "предмет" исчезнет прямо в руках игрока, когда он перешагнёт порог квартиры/закроет дверь в квартиру снаружи.
>дизайнить расположение объектов в редакторе, делай объекты-пустышки
Я так и сделал, но у меня эти пустышки нужны для спавна рандомных предметов (запилил универсальный скрипт).
>реальные объекты из общей ноды
Эм, а зачем их хранить в общей ноде? У меня они сразу появляются на точках спавна. Когда не нужны - скрываются во внутреннюю переменную скрывающей ноды (все сразу). Проблема в том, что делать общую ноду на всю сцену нерационально, у меня сейчас по сути каждая комната занимается скрытием/отображением предметов (генерация только при запуске сцены).
Вот, для примера, на скриншоте с мартышками 3.7К нод - это улица с многоэтажками, а 12.5К нод-сирот - это внутренности тех комнат, в которых игрока сейчас нет (поэтому они скрыты). Если выйти из комнаты с мартышками, они все будут скрыты. Комната сама принимает решение, когда скрывать (с помощью Area), и сама же хранит все свои внутренности. В данный момент всё это выглядит превосходно, проблема только в том, что предметы комнаты нельзя вынести за пределы комнаты. Хотя, я думаю, можно использовать ту же Area, что следит за игроком, чтобы "выпускать" предметы за пределы комнаты...
Вообще, мне главное придерживаться модульного дизайна, чтобы каждый элемент сцены был максимально независим от других. Иначе не получится так легко собирать рандомную сцену (хотя над алгоритмом сборки я всё ещё думаю). Поэтому, например, каждая комната, являясь отдельным модулем, сама заботится о генерации, отображении и скрытии находящихся в ней предметов. Такую систему легко масштабировать... контролировать, правда, трудно, но с этим я ещё разберусь.
>>51998
Короче, я ошибся. DynamicBody вообще не имел отношения к этим фризам.
Лень писать, опишу ситуацию кратко:
- динамические кубики CSGBox лагов не вызывали;
- сферы на скриншоте - CSGSphere с параметрами 24x12;
- снижение CSGSphere 24x12 -> 8x4 снизило нагрузку/лаги;
- 64 головы Suzanne из Blender (по 507 вершин) не тормозят.
Вывод - CSG перед появлением в дереве производит какую-то ресурсоёмкую операцию (пытается произвести слияние, даже если не с кем?), и именно она вызывает тормоза. После удаления из дерева тоже происходит какая-то операция, и снова тормоза. Всё остальное время лагов нет - меш, видимо, кэшируется. С обычными мешами такого нет.
Короче, короче... С одной стороны обидно, что так долго мучился, с другой - рад, что Годо на самом деле не такой тормоз, как я думал изначально. Теперь можно избавиться от мартышек продолжить маяться дурью делать игру.
>>52005
Именно так и делаю.
Так не пойдёт, Годо работает не так, хранить нужно отдельно от дерева сцены.
Точнее нужно хранить ссылку на вырезанную из общего дерева ветку в отдельной переменной.
Не знаю про owners, но я хотел передавать объект из одной ветки в другую.
Несколько раз перечитывал, много думал, но ничего не понял. Грубо говоря, мне нужно передать ветку "предмет" из ноды "квартира" в ноду "улица", потому что нода "квартира" скрывает своё содержимое, когда игрок выходит за пределы квартиры (в целях оптимизации дерева сцены, разумеется). Если так не сделать, то "предмет" исчезнет прямо в руках игрока, когда он перешагнёт порог квартиры/закроет дверь в квартиру снаружи.
Я так и сделал, но у меня эти пустышки нужны для спавна рандомных предметов (запилил универсальный скрипт).
Эм, а зачем их хранить в общей ноде? У меня они сразу появляются на точках спавна. Когда не нужны - скрываются во внутреннюю переменную скрывающей ноды (все сразу). Проблема в том, что делать общую ноду на всю сцену нерационально, у меня сейчас по сути каждая комната занимается скрытием/отображением предметов (генерация только при запуске сцены).
Вот, для примера, на скриншоте с мартышками 3.7К нод - это улица с многоэтажками, а 12.5К нод-сирот - это внутренности тех комнат, в которых игрока сейчас нет (поэтому они скрыты). Если выйти из комнаты с мартышками, они все будут скрыты. Комната сама принимает решение, когда скрывать (с помощью Area), и сама же хранит все свои внутренности. В данный момент всё это выглядит превосходно, проблема только в том, что предметы комнаты нельзя вынести за пределы комнаты. Хотя, я думаю, можно использовать ту же Area, что следит за игроком, чтобы "выпускать" предметы за пределы комнаты...
Вообще, мне главное придерживаться модульного дизайна, чтобы каждый элемент сцены был максимально независим от других. Иначе не получится так легко собирать рандомную сцену (хотя над алгоритмом сборки я всё ещё думаю). Поэтому, например, каждая комната, являясь отдельным модулем, сама заботится о генерации, отображении и скрытии находящихся в ней предметов. Такую систему легко масштабировать... контролировать, правда, трудно, но с этим я ещё разберусь.
>подключение и отключение динамикбади вызывает фриз игры на секунду.
Короче, я ошибся. DynamicBody вообще не имел отношения к этим фризам.
Лень писать, опишу ситуацию кратко:
- динамические кубики CSGBox лагов не вызывали;
- сферы на скриншоте - CSGSphere с параметрами 24x12;
- снижение CSGSphere 24x12 -> 8x4 снизило нагрузку/лаги;
- 64 головы Suzanne из Blender (по 507 вершин) не тормозят.
Вывод - CSG перед появлением в дереве производит какую-то ресурсоёмкую операцию (пытается произвести слияние, даже если не с кем?), и именно она вызывает тормоза. После удаления из дерева тоже происходит какая-то операция, и снова тормоза. Всё остальное время лагов нет - меш, видимо, кэшируется. С обычными мешами такого нет.
Короче, короче... С одной стороны обидно, что так долго мучился, с другой - рад, что Годо на самом деле не такой тормоз, как я думал изначально. Теперь можно избавиться от мартышек продолжить маяться дурью делать игру.
>>52005
>Значит ты их все грузишь при загрузке локации
Именно так и делаю.
>отключёнными в большом невидимом сундуке под землёй
Так не пойдёт, Годо работает не так, хранить нужно отдельно от дерева сцены.
Точнее нужно хранить ссылку на вырезанную из общего дерева ветку в отдельной переменной.
>Полагаю ты про parents и owners говоришь сейчас?
Не знаю про owners, но я хотел передавать объект из одной ветки в другую.
>одну общую ноду для "пропсов", которая по запросу игровой логики выдаёт из своего пула заранее загруженных объектов нужные локациям
Несколько раз перечитывал, много думал, но ничего не понял. Грубо говоря, мне нужно передать ветку "предмет" из ноды "квартира" в ноду "улица", потому что нода "квартира" скрывает своё содержимое, когда игрок выходит за пределы квартиры (в целях оптимизации дерева сцены, разумеется). Если так не сделать, то "предмет" исчезнет прямо в руках игрока, когда он перешагнёт порог квартиры/закроет дверь в квартиру снаружи.
>дизайнить расположение объектов в редакторе, делай объекты-пустышки
Я так и сделал, но у меня эти пустышки нужны для спавна рандомных предметов (запилил универсальный скрипт).
>реальные объекты из общей ноды
Эм, а зачем их хранить в общей ноде? У меня они сразу появляются на точках спавна. Когда не нужны - скрываются во внутреннюю переменную скрывающей ноды (все сразу). Проблема в том, что делать общую ноду на всю сцену нерационально, у меня сейчас по сути каждая комната занимается скрытием/отображением предметов (генерация только при запуске сцены).
Вот, для примера, на скриншоте с мартышками 3.7К нод - это улица с многоэтажками, а 12.5К нод-сирот - это внутренности тех комнат, в которых игрока сейчас нет (поэтому они скрыты). Если выйти из комнаты с мартышками, они все будут скрыты. Комната сама принимает решение, когда скрывать (с помощью Area), и сама же хранит все свои внутренности. В данный момент всё это выглядит превосходно, проблема только в том, что предметы комнаты нельзя вынести за пределы комнаты. Хотя, я думаю, можно использовать ту же Area, что следит за игроком, чтобы "выпускать" предметы за пределы комнаты...
Вообще, мне главное придерживаться модульного дизайна, чтобы каждый элемент сцены был максимально независим от других. Иначе не получится так легко собирать рандомную сцену (хотя над алгоритмом сборки я всё ещё думаю). Поэтому, например, каждая комната, являясь отдельным модулем, сама заботится о генерации, отображении и скрытии находящихся в ней предметов. Такую систему легко масштабировать... контролировать, правда, трудно, но с этим я ещё разберусь.
>>52083
Так узнай. https://docs.godotengine.org/en/stable/classes/class_node.html#class-node-property-owner
Это часть механизма загрузки сцен. Её нельзя игнорировать, ибо при сохранении овнера твои ноды выгрузятся со своим овнером, даже если будут у другого парента. А может и не выгрузятся. А может и не сразу, но выгрузятся. В общем - всё проверяй.
Скрипт наследуется от Node? Вот-вот. По факту общая нода для объектов у тебя уже есть. Только она их не хранит, а спавнит. А теоретически эффективнее делать так: Если объект стал не нужен игроку и скрывается с его глаз, он не уничтожается, а возвращается в пул, где был создан и там, в "большом невидимом сундуке" лежит до тех пор, пока снова не понадобится игроку, после чего ему скрипт-менеджер пула, который нода, назначает новое имя, задаёт новые координаты и закладывает игроку в руки.
Не происходит дорогой операции выделения памяти в куче для нового объекта.
Не происходит дорогой операции выгрузки мусора сборщиком мусора.
Происходят относительно дешёвые операции по изменению координат объектов в пространстве (физический движок) и, возможно их видимости (графический движок).
Решительно двачую!
> Не знаю про owners, но я хотел передавать объект из одной ветки в другую.
Так узнай. https://docs.godotengine.org/en/stable/classes/class_node.html#class-node-property-owner
Это часть механизма загрузки сцен. Её нельзя игнорировать, ибо при сохранении овнера твои ноды выгрузятся со своим овнером, даже если будут у другого парента. А может и не выгрузятся. А может и не сразу, но выгрузятся. В общем - всё проверяй.
> Эм, а зачем их хранить в общей ноде?
> спавна рандомных предметов (запилил универсальный скрипт)
Скрипт наследуется от Node? Вот-вот. По факту общая нода для объектов у тебя уже есть. Только она их не хранит, а спавнит. А теоретически эффективнее делать так: Если объект стал не нужен игроку и скрывается с его глаз, он не уничтожается, а возвращается в пул, где был создан и там, в "большом невидимом сундуке" лежит до тех пор, пока снова не понадобится игроку, после чего ему скрипт-менеджер пула, который нода, назначает новое имя, задаёт новые координаты и закладывает игроку в руки.
Не происходит дорогой операции выделения памяти в куче для нового объекта.
Не происходит дорогой операции выгрузки мусора сборщиком мусора.
Происходят относительно дешёвые операции по изменению координат объектов в пространстве (физический движок) и, возможно их видимости (графический движок).
> главное придерживаться модульного дизайна
Решительно двачую!
>>52128
А, ну про это я уже читал: https://godotengine.org/qa/903/how-to-save-a-scene-at-run-time
Просто речь шла про передачу от родителя к родителю, а owner только к сохранению относится.
Ты, наверное, про что-то другое говоришь. У меня объект не уничтожается, а временно скрывается.
Я бы не сказал, что это дешёвые операции, я попытался расширить зону действия Area комнат на улицу, и заметил, что если игрок триггерит сразу несколько домов по два этажа, происходит небольшой лаг. Хотя, возможно, это опять из-за CSG, только теперь виноваты лестницы (каждая ступенька - CSGBox). Кстати, заодно протестировал удаление/вставку не всей ветки, а по одной ноде за тик физического движка - стало ещё хуже, но скорее всего это из-за CSGBox. Я понимаю, что по-хорошему нужно обычные меши вставить и уже на них тестировать, но т.к. это только тест - мне лень.
Чтобы было понятнее, вот скриншоты моего кода:
1 - "генератор" (заполняет точки спавна рандомными предметами);
2 - "оптимизатор интерьера" (переписывал несколько раз уже);
3 - "глобальный RNG" (хотелось упростить выбор из списка);
4 - "менеджер ресурсов" (должен ускорять генерацию, но сомневаюсь).
Есть некоторые недочёты, но это тест, а не финальная версия)
>Это часть механизма загрузки сцен
А, ну про это я уже читал: https://godotengine.org/qa/903/how-to-save-a-scene-at-run-time
Просто речь шла про передачу от родителя к родителю, а owner только к сохранению относится.
>Если объект стал не нужен игроку и скрывается с его глаз, он не уничтожается, а возвращается в пул
Ты, наверное, про что-то другое говоришь. У меня объект не уничтожается, а временно скрывается.
>относительно дешёвые операции по изменению координат объектов и их видимости
Я бы не сказал, что это дешёвые операции, я попытался расширить зону действия Area комнат на улицу, и заметил, что если игрок триггерит сразу несколько домов по два этажа, происходит небольшой лаг. Хотя, возможно, это опять из-за CSG, только теперь виноваты лестницы (каждая ступенька - CSGBox). Кстати, заодно протестировал удаление/вставку не всей ветки, а по одной ноде за тик физического движка - стало ещё хуже, но скорее всего это из-за CSGBox. Я понимаю, что по-хорошему нужно обычные меши вставить и уже на них тестировать, но т.к. это только тест - мне лень.
Чтобы было понятнее, вот скриншоты моего кода:
1 - "генератор" (заполняет точки спавна рандомными предметами);
2 - "оптимизатор интерьера" (переписывал несколько раз уже);
3 - "глобальный RNG" (хотелось упростить выбор из списка);
4 - "менеджер ресурсов" (должен ускорять генерацию, но сомневаюсь).
Есть некоторые недочёты, но это тест, а не финальная версия)
>>52156
Это безумие, анон. Ты настолько ленив, что не можешь открыть блендер и за 3.5 минуты набросать простейшую модель лестницы?
> лестницы (каждая ступенька — CSGBox)
Это безумие, анон. Ты настолько ленив, что не можешь открыть блендер и за 3.5 минуты набросать простейшую модель лестницы?
>>52156
В конце концов, там есть простые графические примитивы мешей. Они наверняка будут пошустрее CSG.
Я предпочитаю избавляться от сравнений строк со строками в своём коде. Впрочем, это моё, бумерское. Детская травма. Нынче я понимаю, что строки работают не медленнее числовых типов. Но, тем не менее.
В конце концов, там есть простые графические примитивы мешей. Они наверняка будут пошустрее CSG.
> вот скриншоты моего кода
Я предпочитаю избавляться от сравнений строк со строками в своём коде. Впрочем, это моё, бумерское. Детская травма. Нынче я понимаю, что строки работают не медленнее числовых типов. Но, тем не менее.
>>52159
Да.
https://docs.godotengine.org/en/stable/tutorials/3d/csg_tools.html
Ну вот я и exploring их limitations, пока пытаюсь design что-то вроде city.
Вообще всё началось с "а потянет ли Годо что-то эдакое, если потянет - можно будет думоть дальше".
Потянуть вроде потянул, теперь можно думоть. (думоет)
>>52160
Я тоже, но:
- экспортные строки ничем не заменишь (хотя надо посмотреть, есть ли функция length(string) > 0);
- я без понятия, чем отличаются body, кроме name, чтобы понять, которая из них Player;
- загрузка ресурсов идёт по адресу, адрес ничем другим не заменишь.
Я лично сомневаюсь только на счёт name == "Player", но альтернативы пока не вижу (не создавать же отдельный метод it_is_player() и проверять его наличие через has_method()?), да и это сравнение по идее должно тормозить только если в сцене существует множество объектов, чьё имя начинается на "Play...". Если строка начинается с любой буквы кроме "P", она заведомо не равна "Player", и может быть пропущена. Но как именно сравнивает строки Godot - не знаю. Кроме того, эта проверка происходит только на входе/выходе объекта из Area, вряд ли она будет вызываться достаточно часто.
У меня в предыдущей версии "оптимизатора" была функция is_player_indoor, которая перебирала все объекты, с которыми пересекается Area, и вызывалась она в _ready, чтобы проверить, нужно ли скрывать интерьер сразу после запуска. Я понял, что это совершенно лишняя операция, когда попробовал безусловно скрывать интерьер - вокруг игрока он отображается, даже если игрок появляется в комнате при загрузке сцены. С другой стороны, хотелось бы создавать сразу выключенные интерьеры (так можно избавиться от лишнего добавления/удаления в сцену), но я пока не уверен, как лучше это сделать.
>Ты настолько ленив, что не можешь открыть блендер
Да.
>Это безумие
https://docs.godotengine.org/en/stable/tutorials/3d/csg_tools.html
>CSG tools can be used for designing all kinds of levels, such as a maze or a city; explore its limitations when designing your game.
Ну вот я и exploring их limitations, пока пытаюсь design что-то вроде city.
Вообще всё началось с "а потянет ли Годо что-то эдакое, если потянет - можно будет думоть дальше".
Потянуть вроде потянул, теперь можно думоть. (думоет)
>>52160
>Я предпочитаю избавляться от сравнений строк со строками в своём коде
Я тоже, но:
- экспортные строки ничем не заменишь (хотя надо посмотреть, есть ли функция length(string) > 0);
- я без понятия, чем отличаются body, кроме name, чтобы понять, которая из них Player;
- загрузка ресурсов идёт по адресу, адрес ничем другим не заменишь.
Я лично сомневаюсь только на счёт name == "Player", но альтернативы пока не вижу (не создавать же отдельный метод it_is_player() и проверять его наличие через has_method()?), да и это сравнение по идее должно тормозить только если в сцене существует множество объектов, чьё имя начинается на "Play...". Если строка начинается с любой буквы кроме "P", она заведомо не равна "Player", и может быть пропущена. Но как именно сравнивает строки Godot - не знаю. Кроме того, эта проверка происходит только на входе/выходе объекта из Area, вряд ли она будет вызываться достаточно часто.
У меня в предыдущей версии "оптимизатора" была функция is_player_indoor, которая перебирала все объекты, с которыми пересекается Area, и вызывалась она в _ready, чтобы проверить, нужно ли скрывать интерьер сразу после запуска. Я понял, что это совершенно лишняя операция, когда попробовал безусловно скрывать интерьер - вокруг игрока он отображается, даже если игрок появляется в комнате при загрузке сцены. С другой стороны, хотелось бы создавать сразу выключенные интерьеры (так можно избавиться от лишнего добавления/удаления в сцену), но я пока не уверен, как лучше это сделать.
>>52159
Да.
https://docs.godotengine.org/en/stable/tutorials/3d/csg_tools.html
Ну вот я и exploring их limitations, пока пытаюсь design что-то вроде city.
Вообще всё началось с "а потянет ли Годо что-то эдакое, если потянет - можно будет думоть дальше".
Потянуть вроде потянул, теперь можно думоть. (думоет)
>>52160
Я тоже, но:
- экспортные строки ничем не заменишь (хотя надо посмотреть, есть ли функция length(string) > 0);
- я без понятия, чем отличаются body, кроме name, чтобы понять, которая из них Player;
- загрузка ресурсов идёт по адресу, адрес ничем другим не заменишь.
Я лично сомневаюсь только на счёт name == "Player", но альтернативы пока не вижу (не создавать же отдельный метод it_is_player() и проверять его наличие через has_method()?), да и это сравнение по идее должно тормозить только если в сцене существует множество объектов, чьё имя начинается на "Play...". Если строка начинается с любой буквы кроме "P", она заведомо не равна "Player", и может быть пропущена. Но как именно сравнивает строки Godot - не знаю. Кроме того, эта проверка происходит только на входе/выходе объекта из Area, вряд ли она будет вызываться достаточно часто.
У меня в предыдущей версии "оптимизатора" была функция is_player_indoor, которая перебирала все объекты, с которыми пересекается Area, и вызывалась она в _ready, чтобы проверить, нужно ли скрывать интерьер сразу после запуска. Я понял, что это совершенно лишняя операция, когда попробовал безусловно скрывать интерьер - вокруг игрока он отображается, даже если игрок появляется в комнате при загрузке сцены. С другой стороны, хотелось бы создавать сразу выключенные интерьеры (так можно избавиться от лишнего добавления/удаления в сцену), но я пока не уверен, как лучше это сделать.
>Ты настолько ленив, что не можешь открыть блендер
Да.
>Это безумие
https://docs.godotengine.org/en/stable/tutorials/3d/csg_tools.html
>CSG tools can be used for designing all kinds of levels, such as a maze or a city; explore its limitations when designing your game.
Ну вот я и exploring их limitations, пока пытаюсь design что-то вроде city.
Вообще всё началось с "а потянет ли Годо что-то эдакое, если потянет - можно будет думоть дальше".
Потянуть вроде потянул, теперь можно думоть. (думоет)
>>52160
>Я предпочитаю избавляться от сравнений строк со строками в своём коде
Я тоже, но:
- экспортные строки ничем не заменишь (хотя надо посмотреть, есть ли функция length(string) > 0);
- я без понятия, чем отличаются body, кроме name, чтобы понять, которая из них Player;
- загрузка ресурсов идёт по адресу, адрес ничем другим не заменишь.
Я лично сомневаюсь только на счёт name == "Player", но альтернативы пока не вижу (не создавать же отдельный метод it_is_player() и проверять его наличие через has_method()?), да и это сравнение по идее должно тормозить только если в сцене существует множество объектов, чьё имя начинается на "Play...". Если строка начинается с любой буквы кроме "P", она заведомо не равна "Player", и может быть пропущена. Но как именно сравнивает строки Godot - не знаю. Кроме того, эта проверка происходит только на входе/выходе объекта из Area, вряд ли она будет вызываться достаточно часто.
У меня в предыдущей версии "оптимизатора" была функция is_player_indoor, которая перебирала все объекты, с которыми пересекается Area, и вызывалась она в _ready, чтобы проверить, нужно ли скрывать интерьер сразу после запуска. Я понял, что это совершенно лишняя операция, когда попробовал безусловно скрывать интерьер - вокруг игрока он отображается, даже если игрок появляется в комнате при загрузке сцены. С другой стороны, хотелось бы создавать сразу выключенные интерьеры (так можно избавиться от лишнего добавления/удаления в сцену), но я пока не уверен, как лучше это сделать.
>>52165
Нет, конечно. Группы же есть (if body is_in_group("string_group_name") эээ, тоже строки, отпадает). Слои коллизий есть (тут соответственно уже можно либо вообще не ловить коллизии ни с кем кроме плеера, стало быть любое боди будет плеер, либо if body.get_collision_layer_bit(N) = M:). Приглашаю в документацию.
> не создавать же отдельный метод it_is_player() и проверять его наличие через has_method()?
Нет, конечно. Группы же есть (if body is_in_group("string_group_name") эээ, тоже строки, отпадает). Слои коллизий есть (тут соответственно уже можно либо вообще не ловить коллизии ни с кем кроме плеера, стало быть любое боди будет плеер, либо if body.get_collision_layer_bit(N) = M:). Приглашаю в документацию.
Уроки продолжаются https://www.youtube.com/watch?v=0nd1zNiy0C4
63 Кб, 561x519>>52170
Аааааа, точно, точно. Я многократно натыкался на эту табличку с переключателями слоёв, но думал "ну, это мне не нужно, наверное". Было бы логично настроить детекторы только на игрока...
А вот, кстати, на счёт коллизий и лестниц. Кажется, я когда-то где-то видел, что в играх лестницы физически на самом деле не лестницы вовсе, а наклонные плоскости - в современных играх это имеет смысл или нет? А то я тут починил коллизию персонажа-игрока и вдруг появились проблемы с движением по лестницам: вверх трясёт, вниз прыгает. Если же сделать просто наклонную плоскость, то персонаж съезжает вниз. Контроллер персонажа самодельный, его нужно рефакторить, много мусора... Может, есть какие-то советы (кроме "возьми готовое")? На картинке у меня один луч определяет, находится ли игрок на земле (регулирует гравитацию и способность двигаться и прыгать), другой проверяет, не пытается ли игрок забраться на лестницу (т.к. на лестнице центральный луч зависает над землёй). Так вот движения и прыжки по плоскости и с небольшими выступами происходят нормально, но на более-менее крутой лестнице всё выглядит как-то не очень (после починки коллизии капсулы)...
А ещё я хоть и сделал камеру, которая приближается к игроку, когда с чем-то сталкивается, но она всё равно то в стены проваливается, то трясётся на углах (ну, когда луч прерывается, но не полностью). Чувствую, что ещё долго буду настраивать комфортное поведение камеры, и что делаю что-то не так( У моей камеры есть луч, растянутый между камерой и моделькой игрока, и второй луч, направленный назад. Первый луч приближает камеру, если обзор что-нибудь загораживает, второй луч предотвращает удаление камеры слишком далеко. Хотя, наверное, можно было обойтись одним лучом (надо будет попробовать отодвинуть его чуть назад)... Но вот резкие "вибрации" на углах объектов сильно напрягают. Скажем, в дверном проёме в режиме от третьего лица вообще всё начинает вибрировать, да и просто в помещениях тоже...
>Слои коллизий есть (тут соответственно уже можно либо вообще не ловить коллизии ни с кем кроме плеера
Аааааа, точно, точно. Я многократно натыкался на эту табличку с переключателями слоёв, но думал "ну, это мне не нужно, наверное". Было бы логично настроить детекторы только на игрока...
А вот, кстати, на счёт коллизий и лестниц. Кажется, я когда-то где-то видел, что в играх лестницы физически на самом деле не лестницы вовсе, а наклонные плоскости - в современных играх это имеет смысл или нет? А то я тут починил коллизию персонажа-игрока и вдруг появились проблемы с движением по лестницам: вверх трясёт, вниз прыгает. Если же сделать просто наклонную плоскость, то персонаж съезжает вниз. Контроллер персонажа самодельный, его нужно рефакторить, много мусора... Может, есть какие-то советы (кроме "возьми готовое")? На картинке у меня один луч определяет, находится ли игрок на земле (регулирует гравитацию и способность двигаться и прыгать), другой проверяет, не пытается ли игрок забраться на лестницу (т.к. на лестнице центральный луч зависает над землёй). Так вот движения и прыжки по плоскости и с небольшими выступами происходят нормально, но на более-менее крутой лестнице всё выглядит как-то не очень (после починки коллизии капсулы)...
А ещё я хоть и сделал камеру, которая приближается к игроку, когда с чем-то сталкивается, но она всё равно то в стены проваливается, то трясётся на углах (ну, когда луч прерывается, но не полностью). Чувствую, что ещё долго буду настраивать комфортное поведение камеры, и что делаю что-то не так( У моей камеры есть луч, растянутый между камерой и моделькой игрока, и второй луч, направленный назад. Первый луч приближает камеру, если обзор что-нибудь загораживает, второй луч предотвращает удаление камеры слишком далеко. Хотя, наверное, можно было обойтись одним лучом (надо будет попробовать отодвинуть его чуть назад)... Но вот резкие "вибрации" на углах объектов сильно напрягают. Скажем, в дверном проёме в режиме от третьего лица вообще всё начинает вибрировать, да и просто в помещениях тоже...
63 Кб, 561x519>>52170
Аааааа, точно, точно. Я многократно натыкался на эту табличку с переключателями слоёв, но думал "ну, это мне не нужно, наверное". Было бы логично настроить детекторы только на игрока...
А вот, кстати, на счёт коллизий и лестниц. Кажется, я когда-то где-то видел, что в играх лестницы физически на самом деле не лестницы вовсе, а наклонные плоскости - в современных играх это имеет смысл или нет? А то я тут починил коллизию персонажа-игрока и вдруг появились проблемы с движением по лестницам: вверх трясёт, вниз прыгает. Если же сделать просто наклонную плоскость, то персонаж съезжает вниз. Контроллер персонажа самодельный, его нужно рефакторить, много мусора... Может, есть какие-то советы (кроме "возьми готовое")? На картинке у меня один луч определяет, находится ли игрок на земле (регулирует гравитацию и способность двигаться и прыгать), другой проверяет, не пытается ли игрок забраться на лестницу (т.к. на лестнице центральный луч зависает над землёй). Так вот движения и прыжки по плоскости и с небольшими выступами происходят нормально, но на более-менее крутой лестнице всё выглядит как-то не очень (после починки коллизии капсулы)...
А ещё я хоть и сделал камеру, которая приближается к игроку, когда с чем-то сталкивается, но она всё равно то в стены проваливается, то трясётся на углах (ну, когда луч прерывается, но не полностью). Чувствую, что ещё долго буду настраивать комфортное поведение камеры, и что делаю что-то не так( У моей камеры есть луч, растянутый между камерой и моделькой игрока, и второй луч, направленный назад. Первый луч приближает камеру, если обзор что-нибудь загораживает, второй луч предотвращает удаление камеры слишком далеко. Хотя, наверное, можно было обойтись одним лучом (надо будет попробовать отодвинуть его чуть назад)... Но вот резкие "вибрации" на углах объектов сильно напрягают. Скажем, в дверном проёме в режиме от третьего лица вообще всё начинает вибрировать, да и просто в помещениях тоже...
>Слои коллизий есть (тут соответственно уже можно либо вообще не ловить коллизии ни с кем кроме плеера
Аааааа, точно, точно. Я многократно натыкался на эту табличку с переключателями слоёв, но думал "ну, это мне не нужно, наверное". Было бы логично настроить детекторы только на игрока...
А вот, кстати, на счёт коллизий и лестниц. Кажется, я когда-то где-то видел, что в играх лестницы физически на самом деле не лестницы вовсе, а наклонные плоскости - в современных играх это имеет смысл или нет? А то я тут починил коллизию персонажа-игрока и вдруг появились проблемы с движением по лестницам: вверх трясёт, вниз прыгает. Если же сделать просто наклонную плоскость, то персонаж съезжает вниз. Контроллер персонажа самодельный, его нужно рефакторить, много мусора... Может, есть какие-то советы (кроме "возьми готовое")? На картинке у меня один луч определяет, находится ли игрок на земле (регулирует гравитацию и способность двигаться и прыгать), другой проверяет, не пытается ли игрок забраться на лестницу (т.к. на лестнице центральный луч зависает над землёй). Так вот движения и прыжки по плоскости и с небольшими выступами происходят нормально, но на более-менее крутой лестнице всё выглядит как-то не очень (после починки коллизии капсулы)...
А ещё я хоть и сделал камеру, которая приближается к игроку, когда с чем-то сталкивается, но она всё равно то в стены проваливается, то трясётся на углах (ну, когда луч прерывается, но не полностью). Чувствую, что ещё долго буду настраивать комфортное поведение камеры, и что делаю что-то не так( У моей камеры есть луч, растянутый между камерой и моделькой игрока, и второй луч, направленный назад. Первый луч приближает камеру, если обзор что-нибудь загораживает, второй луч предотвращает удаление камеры слишком далеко. Хотя, наверное, можно было обойтись одним лучом (надо будет попробовать отодвинуть его чуть назад)... Но вот резкие "вибрации" на углах объектов сильно напрягают. Скажем, в дверном проёме в режиме от третьего лица вообще всё начинает вибрировать, да и просто в помещениях тоже...
>>52176
Там, вроде, есть параметр угла наклона
> Если же сделать просто наклонную плоскость, то персонаж съезжает вниз.
Там, вроде, есть параметр угла наклона
>>52177
А конкретнее вот это
move_and_slide(... floor_max_angle
is the maximum angle (in radians) where a slope is still considered a floor (or a ceiling), rather than a wall. The default value equals 45 degrees.
А конкретнее вот это
move_and_slide(... floor_max_angle
is the maximum angle (in radians) where a slope is still considered a floor (or a ceiling), rather than a wall. The default value equals 45 degrees.
>>52176
Посмотри стримы по Half-Life: Alyx и сделай выводы: Пройдёт не более полугода и классические игоры уйдут в прошлое. Вангую, к лету китайцы резко опустят ценники на виар-комплекты в ответ на возросший спрос.
А в виаре никакие жульничества не прокатят ибо игроки сразу упрутся в них и высмеют разработчика на форумах. Всё придётся делать по честному: Лестницы со ступенями. Вёдра с вогнутой коллизией. Ноги и руки с кинематикой вместо капсульной коллизии.
Будущее всегда наступает незаметно. И Габен принёс нам будущее в этом марте.
> в современных играх это имеет смысл или нет?
Посмотри стримы по Half-Life: Alyx и сделай выводы: Пройдёт не более полугода и классические игоры уйдут в прошлое. Вангую, к лету китайцы резко опустят ценники на виар-комплекты в ответ на возросший спрос.
А в виаре никакие жульничества не прокатят ибо игроки сразу упрутся в них и высмеют разработчика на форумах. Всё придётся делать по честному: Лестницы со ступенями. Вёдра с вогнутой коллизией. Ноги и руки с кинематикой вместо капсульной коллизии.
Будущее всегда наступает незаметно. И Габен принёс нам будущее в этом марте.
>>52176
А, он предотвращает отдаление камеры колёсиком мыши, если позади камеры препятствие. Без этой дополнительной проверки камеру можно было задвинуть в стену, после чего она возвращалась назад, и поэтому пришлось сделать отдельный луч (сам по себе он камеру не сдвигает). Уже забывать начал))
>>52179
Значение по умолчанию floor_max_angle = 45 градусов. То есть оно и без дополнительных параметров должно считать лестницу полом (или потолком). Я проверил - похоже, этот параметр отвечает только за состояние функций is_on_floor и других, но у меня они всё равно не работают, поэтому я ими не пользуюсь (использую для этого лучи).
Мне, скорее всего, нужно это:
...но я проверил, и как-то не заметил особых отличий.
В общем, я подозреваю, что вся проблема либо в длине лучей, либо в логике моего кода. Сейчас смог немного отрегулировать лучи - вверх по лестнице вроде неплохо забирается, но вниз скачет. А ещё обнаружил, что в некоторых ситуациях модельку трясёт на месте (если упираться в наклонённую стенку). Скорее всего, нужно перед вызовом move_and_slide делать дополнительную проверку, но я уже устал и не хочу об этом думать сейчас.
А, вот ещё - мне хотелось добиться возможности прыгать при движении по лестнице, так вот иногда удаётся настроить возможность прыжков, а иногда настройка сбивается. Да и прыжки на лестнице почему-то получаются выше, чем на ровной земле, лол. Надо разбираться...
>второй луч предотвращает удаление камеры слишком далеко
А, он предотвращает отдаление камеры колёсиком мыши, если позади камеры препятствие. Без этой дополнительной проверки камеру можно было задвинуть в стену, после чего она возвращалась назад, и поэтому пришлось сделать отдельный луч (сам по себе он камеру не сдвигает). Уже забывать начал))
>>52179
>move_and_slide(... floor_max_angle
Значение по умолчанию floor_max_angle = 45 градусов. То есть оно и без дополнительных параметров должно считать лестницу полом (или потолком). Я проверил - похоже, этот параметр отвечает только за состояние функций is_on_floor и других, но у меня они всё равно не работают, поэтому я ими не пользуюсь (использую для этого лучи).
Мне, скорее всего, нужно это:
>If stop_on_slope is true, body will not slide on slopes if you include gravity in linear_velocity.
...но я проверил, и как-то не заметил особых отличий.
В общем, я подозреваю, что вся проблема либо в длине лучей, либо в логике моего кода. Сейчас смог немного отрегулировать лучи - вверх по лестнице вроде неплохо забирается, но вниз скачет. А ещё обнаружил, что в некоторых ситуациях модельку трясёт на месте (если упираться в наклонённую стенку). Скорее всего, нужно перед вызовом move_and_slide делать дополнительную проверку, но я уже устал и не хочу об этом думать сейчас.
А, вот ещё - мне хотелось добиться возможности прыгать при движении по лестнице, так вот иногда удаётся настроить возможность прыжков, а иногда настройка сбивается. Да и прыжки на лестнице почему-то получаются выше, чем на ровной земле, лол. Надо разбираться...
>>52183
Чел, ты несешь хуйню, в виаре одни только жульничества и канают, а твоя хуяликс это по меркам виар вообще ничто, сделанная для габеноутят.
Чел, ты несешь хуйню, в виаре одни только жульничества и канают, а твоя хуяликс это по меркам виар вообще ничто, сделанная для габеноутят.
>>52186
Старайся делать как можно меньше кода. На любую задачу сначала гугли документацию. А то ты много велосипедов изобретаешь. Для контроля камеры есть нода SpringArm
Старайся делать как можно меньше кода. На любую задачу сначала гугли документацию. А то ты много велосипедов изобретаешь. Для контроля камеры есть нода SpringArm
>>52186
Вот что, я посмотрел как сделано в каком-то контроллере, и там move_and_slide_with_snap
Работает примерно так - если ты передаешь snap вектор который смотрит вниз, то персонаж "прилипает" к полу. Если надо прыгнуть, передаешь нулевой вектор.
Вот что, я посмотрел как сделано в каком-то контроллере, и там move_and_slide_with_snap
Работает примерно так - если ты передаешь snap вектор который смотрит вниз, то персонаж "прилипает" к полу. Если надо прыгнуть, передаешь нулевой вектор.
>>52190
Скринь, хуле. Чел, я виаром уже пару лет занимаюсь. Там наоборот от реализма отходят в пользу телепортов, чтобы игроков не тошнило, к лоу поли чтобы игроков не укачивало, а та самая аликс приучает игроков что ничего не подвигать кроме того что геймдизайнер разрешил.
Скринь, хуле. Чел, я виаром уже пару лет занимаюсь. Там наоборот от реализма отходят в пользу телепортов, чтобы игроков не тошнило, к лоу поли чтобы игроков не укачивало, а та самая аликс приучает игроков что ничего не подвигать кроме того что геймдизайнер разрешил.
>>52183
Я пытаюсь сделать игру в первую очередь для себя.
Вот, кстати, уж где-где, а в современных VR-играх смысла в лестницах нет, там ведь игрок тупо телепортируется с места на место. Передвигаться в VR вообще сложно. А ещё я не представляю, как можно играть в VR, если у тебя в комнате и без него развернуться негде...
Только когда выйдут полноценные нейрошлемы. Тот VR, который есть сейчас, по сути обычная игра, только на двух мониторах и со сложными джойстиками. Я пробовал, мне не понравилось - хочу лежать в кровати и не двигаться, пока играю в игру, которая транслируется прямо мне в мозг. Вот когда будут нейрошлемы, тогда игрокам действительно будет неохота вставать и пялиться в монитор... А сейчас всё наоборот: запустить игру намного проще, чем подготовить VR-оборудование к работе. Если бы у меня был мощный беспроблемный ноутбук, я бы вообще с кровати не вставал, какой уж там VR.
>>52189
Так скучно. Я читаю встроенную справку, но остальное пытаюсь сначала сам сделать.
Написано "для 3 лица". Мой контроллер может переключать между первым и третьим) Но спасибо, посмотрю.
Это у меня по жизни так. Я вообще очень долго не хотел даже пробовать готовые движки.
>>52197
Заметил эту функцию, когда листал справку, надо будет проверить...
>ибо игроки сразу упрутся в них и высмеют разработчика на форумах
Я пытаюсь сделать игру в первую очередь для себя.
>Всё придётся делать по честному: Лестницы со ступенями
Вот, кстати, уж где-где, а в современных VR-играх смысла в лестницах нет, там ведь игрок тупо телепортируется с места на место. Передвигаться в VR вообще сложно. А ещё я не представляю, как можно играть в VR, если у тебя в комнате и без него развернуться негде...
>классические игоры уйдут в прошлое
Только когда выйдут полноценные нейрошлемы. Тот VR, который есть сейчас, по сути обычная игра, только на двух мониторах и со сложными джойстиками. Я пробовал, мне не понравилось - хочу лежать в кровати и не двигаться, пока играю в игру, которая транслируется прямо мне в мозг. Вот когда будут нейрошлемы, тогда игрокам действительно будет неохота вставать и пялиться в монитор... А сейчас всё наоборот: запустить игру намного проще, чем подготовить VR-оборудование к работе. Если бы у меня был мощный беспроблемный ноутбук, я бы вообще с кровати не вставал, какой уж там VR.
>>52189
>На любую задачу сначала гугли документацию
Так скучно. Я читаю встроенную справку, но остальное пытаюсь сначала сам сделать.
>Для контроля камеры есть нода SpringArm
Написано "для 3 лица". Мой контроллер может переключать между первым и третьим) Но спасибо, посмотрю.
>А то ты много велосипедов изобретаешь
Это у меня по жизни так. Я вообще очень долго не хотел даже пробовать готовые движки.
>>52197
>move_and_slide_with_snap
Заметил эту функцию, когда листал справку, надо будет проверить...
>>52199
Теперь ты хуйню несешь, чел занимающийся виаром, виара не видавший. Не позорься, посмотри, как её стримят хоть. Ясен хуй, сам ты в неё поиграть не сможешь. Гранаты в ведре поносить не сможешь.
> а та самая аликс приучает игроков что ничего не подвигать кроме того что геймдизайнер разрешил
Теперь ты хуйню несешь, чел занимающийся виаром, виара не видавший. Не позорься, посмотри, как её стримят хоть. Ясен хуй, сам ты в неё поиграть не сможешь. Гранаты в ведре поносить не сможешь.
>>52204
Что ж ты за отбитый долбоёб, а? Ясен хуй, сформулировать ты ответ на это не способен. Да и не видел ты, как в алихе можно ящики и бочки таскать руками. Что тебе на форумах написздели, то ты и ретранслируешь. А моменты, когда ты одной рукой лечишься в лечилке, а второй рукой держишь на прицеле угол из-за которого может комбайн выскочить - просто бесценны!
> 100500 других пропсов не дали
Что ж ты за отбитый долбоёб, а? Ясен хуй, сформулировать ты ответ на это не способен. Да и не видел ты, как в алихе можно ящики и бочки таскать руками. Что тебе на форумах написздели, то ты и ретранслируешь. А моменты, когда ты одной рукой лечишься в лечилке, а второй рукой держишь на прицеле угол из-за которого может комбайн выскочить - просто бесценны!
>>52200
1. Телепорты от тошноты - мера временная, потому что гироскопы не поспевают за головой.
2. Двигаться путём прожима аналогового стика на контроллере можно уже сейчас, но из-за 1. у многих возникает морская болезнь.
3. Согласно моему вангованию, эту проблему победят уже в этом году.
4. Раз двигаться можно стиком, от тебя требуется только сидеть во вращающемся кресле.
5. Однако в этом случае ты не сможешь пригибаться и уворачиваться. Так что встал и стой, сцкнх!
6. Согласно моему вангованию, ближе к концу года, возможно в начале следующего, китайцы выкинут на рынок недорогие и функциональные беговые дорожки и в виаре можно будет вообще полноценно бегать, прыгать, перекатываться.
7. Жирные тюлени вроде нас с тобой, несомненно соснут, но рыночек порешает нас, а не зумеров.
8. Так что, да, остаётся только
Потому что корпорации, по моему вангованию, повторюсь, не позднее, чем за пару лет, ПОЛНОСТЬЮ перепрофилируются на виар.
Всё, нах, можете скринить.
> Вот, кстати, уж где-где, а в современных VR-играх смысла в лестницах нет, там ведь игрок тупо телепортируется с места на место. Передвигаться в VR вообще сложно. А ещё я не представляю, как можно играть в VR, если у тебя в комнате и без него развернуться негде…
1. Телепорты от тошноты - мера временная, потому что гироскопы не поспевают за головой.
2. Двигаться путём прожима аналогового стика на контроллере можно уже сейчас, но из-за 1. у многих возникает морская болезнь.
3. Согласно моему вангованию, эту проблему победят уже в этом году.
4. Раз двигаться можно стиком, от тебя требуется только сидеть во вращающемся кресле.
5. Однако в этом случае ты не сможешь пригибаться и уворачиваться. Так что встал и стой, сцкнх!
6. Согласно моему вангованию, ближе к концу года, возможно в начале следующего, китайцы выкинут на рынок недорогие и функциональные беговые дорожки и в виаре можно будет вообще полноценно бегать, прыгать, перекатываться.
7. Жирные тюлени вроде нас с тобой, несомненно соснут, но рыночек порешает нас, а не зумеров.
8. Так что, да, остаётся только
> сделать игру в первую очередь для себя
Потому что корпорации, по моему вангованию, повторюсь, не позднее, чем за пару лет, ПОЛНОСТЬЮ перепрофилируются на виар.
Всё, нах, можете скринить.
>>52210
Туда им и дорога, у меня их игры даже на диск не помещаются, не говоря уж о запуске, так что вообще без разницы, какими эти игры будут.
Так-то принято считать, что зумеры самые малоподвижные... или миллениалы...
Повторяюсь, без нейрошлема все эти забеги, прыжки и перекаты не имеют никакого смысла. Я врастаю в клавиатуру не для того, чтобы бегать-прыгать-перекатываться, а для того, чтобы не бегать, не прыгать и не перекатываться в реальном мире. Кто вообще придумал использовать тело как контроллер? Это же неудобно.
Тогда чем это отличается от обычной игры? Только углом обзора как в подзорной трубе.
Всегда думал, что телепорты для того, чтобы сидеть/лежать неподвижно, а не топтаться стоя.
>>52211
Ну 120 фпс допустим вытянуть можно с лёгкостью, а 2-4К сделать тупо апскейлом.
Мне больше волнует, почему у меня контроллер камеры при повышении фпс до 700+ начинает замедляться. :C
>корпорации ПОЛНОСТЬЮ перепрофилируются на виар
Туда им и дорога, у меня их игры даже на диск не помещаются, не говоря уж о запуске, так что вообще без разницы, какими эти игры будут.
>Жирные тюлени вроде нас с тобой, несомненно соснут, но рыночек порешает нас, а не зумеров
Так-то принято считать, что зумеры самые малоподвижные... или миллениалы...
>в виаре можно будет вообще полноценно бегать, прыгать, перекатываться
Повторяюсь, без нейрошлема все эти забеги, прыжки и перекаты не имеют никакого смысла. Я врастаю в клавиатуру не для того, чтобы бегать-прыгать-перекатываться, а для того, чтобы не бегать, не прыгать и не перекатываться в реальном мире. Кто вообще придумал использовать тело как контроллер? Это же неудобно.
>Двигаться путём прожима аналогового стика на контроллере можно уже сейчас
Тогда чем это отличается от обычной игры? Только углом обзора как в подзорной трубе.
>Телепорты от тошноты
Всегда думал, что телепорты для того, чтобы сидеть/лежать неподвижно, а не топтаться стоя.
>>52211
>там же надо 120 фпс в 2-4К
Ну 120 фпс допустим вытянуть можно с лёгкостью, а 2-4К сделать тупо апскейлом.
Мне больше волнует, почему у меня контроллер камеры при повышении фпс до 700+ начинает замедляться. :C
>>43188 (OP)
Как видос записать и скинуть? Да, вопрос тупой, в инете 100000 ответов, но я не хочу среди них искать нормальный, куда проще если кто-то поделится проверенным
Как видос записать и скинуть? Да, вопрос тупой, в инете 100000 ответов, но я не хочу среди них искать нормальный, куда проще если кто-то поделится проверенным
>>50834
Добавь больше источников света, типо поставь их 3 рядом, тень не может быть "короче" или "длиннее", тень там где нет света, а заслоненный свет не может взять и появится через 2 метра
Добавь больше источников света, типо поставь их 3 рядом, тень не может быть "короче" или "длиннее", тень там где нет света, а заслоненный свет не может взять и появится через 2 метра
>>52226
Вот зачем писать чушь через неделю, не разбираясь в вопросе, когда уже даже показано как сделать.
Вот зачем писать чушь через неделю, не разбираясь в вопросе, когда уже даже показано как сделать.
>>50826
Возьми фонарик, коробку, и поэксперементируй как надо светить чтобы свет был какой нужно
Возьми фонарик, коробку, и поэксперементируй как надо светить чтобы свет был какой нужно
>>52229
Потому что свет это частица если она пропала то она не появится, всё ее нет, она умерла нахуй, откуда ей заного взятся то
Потому что свет это частица если она пропала то она не появится, всё ее нет, она умерла нахуй, откуда ей заного взятся то
23 Кб, 629x412>>52226
Может, зависит от высоты источника света над отбрасывающим тень объектом.
Предлагаю вернуться в 5-й класс и повторить чё вы ты там изучали про свет и тень)))
Ну или хотя бы выходи на улицу почаще, а то ты походу тени только в детстве в играх видел.
>тень не может быть "короче" или "длиннее",
Может, зависит от высоты источника света над отбрасывающим тень объектом.
Предлагаю вернуться в 5-й класс и повторить чё вы ты там изучали про свет и тень)))
Ну или хотя бы выходи на улицу почаще, а то ты походу тени только в детстве в играх видел.
>>52225
Я записываю GeForce Experience-м, одной кнопкой. Если нету, можно OBS-ом. Потом нарезаю в консольке ffmpeg-ом. Иногда Webm-converter for retards.
Я записываю GeForce Experience-м, одной кнопкой. Если нету, можно OBS-ом. Потом нарезаю в консольке ffmpeg-ом. Иногда Webm-converter for retards.
2д
короче, есть один спрайт палки
палкой можно будет махать в игре
можно ли как-то сделать анимацию махания палкой чем-то типа создания ключевых кадров? нужно чтоб просто менялся её угол наклона
не делать же мне анимацию для палки, ну
короче, есть один спрайт палки
палкой можно будет махать в игре
можно ли как-то сделать анимацию махания палкой чем-то типа создания ключевых кадров? нужно чтоб просто менялся её угол наклона
не делать же мне анимацию для палки, ну
>>52272
Ну да, в годоте все свойства анимируются примерно как в блендере
1. В AnimationPlayer в анимации добавляешь новый трек, Property Track
2. В всплывшем окне выбираешь объект, а в нем свойство rotation_degrees
3. Ставишь время на 0, кликаешь правой кнопкой по таймлайну и insert keyframe
4. Ставишь время в середину, крутишь объект как тебе надо, вставляешь новый keyframe
5. Ставишь время в конец, крутишь объект в начальное положение, еще один keyframe
Ну да, в годоте все свойства анимируются примерно как в блендере
1. В AnimationPlayer в анимации добавляешь новый трек, Property Track
2. В всплывшем окне выбираешь объект, а в нем свойство rotation_degrees
3. Ставишь время на 0, кликаешь правой кнопкой по таймлайну и insert keyframe
4. Ставишь время в середину, крутишь объект как тебе надо, вставляешь новый keyframe
5. Ставишь время в конец, крутишь объект в начальное положение, еще один keyframe
Как понять, почему сцена закрывается во время загрузки, но при этом никаких ошибок не вываливается?
>>52276
Тоже молчит. Выглядит, будто сцена штатно закрывается, но на самом деле это краш.
Происходит это со сценой, в которой я сделал такую штуку (вид сверху):
__с__
__д__
сдддс
__д__
__с__
Где д - блок дороги, с - точка спавна, _ - пустота.
На точке спавна должна спавниться точно такая же сцена с некоторым шансом, которая тоже что-то спавнит.
Методом тыка выяснил, что падение происходит только в определённых условиях, но определить точно эти условия не смог, потому что у меня даже print() из кода не успевает ничего вывести, когда эти условия срабатывают. Было предположение, что это происходит тогда, когда два блока накладываются друг на друга - но смещение точек спавна выше или ниже ничего не дало. Ещё было предположение, что происходит переполнение стека возвратов, но, судя по всему, в одном направлении генерироваться такая штука может достаточно долго. Пытался приделать проверку коллизий перед спавном, но они не работают в _ready, поэтому решил не мучиться. Короче, так и не понял, почему это происходит и почему без сообщений об ошибках. Версия Годо 3.2.1 stable.
Но это уже не важно, я решил отказаться от такой генерации. Нужно генерировать сначала меш ландшафта, а потом на нём расставлять домики, так должно быть правильнее...
Тоже молчит. Выглядит, будто сцена штатно закрывается, но на самом деле это краш.
Происходит это со сценой, в которой я сделал такую штуку (вид сверху):
__с__
__д__
сдддс
__д__
__с__
Где д - блок дороги, с - точка спавна, _ - пустота.
На точке спавна должна спавниться точно такая же сцена с некоторым шансом, которая тоже что-то спавнит.
Методом тыка выяснил, что падение происходит только в определённых условиях, но определить точно эти условия не смог, потому что у меня даже print() из кода не успевает ничего вывести, когда эти условия срабатывают. Было предположение, что это происходит тогда, когда два блока накладываются друг на друга - но смещение точек спавна выше или ниже ничего не дало. Ещё было предположение, что происходит переполнение стека возвратов, но, судя по всему, в одном направлении генерироваться такая штука может достаточно долго. Пытался приделать проверку коллизий перед спавном, но они не работают в _ready, поэтому решил не мучиться. Короче, так и не понял, почему это происходит и почему без сообщений об ошибках. Версия Годо 3.2.1 stable.
Но это уже не важно, я решил отказаться от такой генерации. Нужно генерировать сначала меш ландшафта, а потом на нём расставлять домики, так должно быть правильнее...
>>52303
Переполнение стека вызовов функций. Ищи, где у тебя бесконечная рекурсия. У меня такое бывает частенько, если с рекурсией проебусь. Ошибка возникает на долю секунды, после чего сеанс отладки прерывается.
> Тоже молчит. Выглядит, будто сцена штатно закрывается, но на самом деле это краш.
Переполнение стека вызовов функций. Ищи, где у тебя бесконечная рекурсия. У меня такое бывает частенько, если с рекурсией проебусь. Ошибка возникает на долю секунды, после чего сеанс отладки прерывается.
>>52311
Значит, рекурсивно генерировать сцену всё-таки не получится(
Ну и ладно, всё равно собирался что-то другое придумать...
Значит, рекурсивно генерировать сцену всё-таки не получится(
Ну и ладно, всё равно собирался что-то другое придумать...
>>52319
Чо сразу сдаёшься? Вполне получится. Главное правильно рекурсию организовать.
Чо сразу сдаёшься? Вполне получится. Главное правильно рекурсию организовать.
Наканец-та!
https://www.youtube.com/watch?v=oXQOaO8qoLo
https://www.youtube.com/watch?v=oXQOaO8qoLo
Пытаюсь отрисовать 2д скелет (с целью создания процедурно-векторной графики без текстур). Он получается в масштабе 2х. ЧЯДНТ?
>>52797
Глянь в настройках проекта, Display, Window, и там где то в конце Stretch, Shrink чтобы стояло 1
Глянь в настройках проекта, Display, Window, и там где то в конце Stretch, Shrink чтобы стояло 1
5 Кб, 437x119>>52800
Всё по дефолту же!
Всё по дефолту же!
2 Кб, 444x566>>52800
Главное, чего я не могу понять, в редакторе у кости одна позиция - её начало. В рантайме, как видно из скрипта, позиция кости - это середина. Мне приходится отрисовывать две линии, от кости к предку, от кости к потомкам. Иначе получается вот такое:
Главное, чего я не могу понять, в редакторе у кости одна позиция - её начало. В рантайме, как видно из скрипта, позиция кости - это середина. Мне приходится отрисовывать две линии, от кости к предку, от кости к потомкам. Иначе получается вот такое:
11 Кб, 654x695>>52815
Вот в режиме тулскрипта. Никакого масштабирования нигде не ставил, все значения по дефолту.
Вот в режиме тулскрипта. Никакого масштабирования нигде не ставил, все значения по дефолту.
Кто-нибудь знает, как правильно настраивать физику?
Проблемы:
- кинетикбоди пинает ригидбоди
- если отключить бесконечную инерцию, всё равно пинает, но только уже сдвинутые
- круглые ригидбоди катятся и не останавливаются
- сила трения непонятно на что влияет
- непонятно как влияет на физику масса объекта
До того момента, как я узнал про флаг бесконечной инерции, думал, что физика здесь упорота принципиально.
Помогла вот эта статья, но только частично: https://kidscancode.org/godot_recipes/physics/kinematic_to_rigidbody/
То есть на неподвижные ригидбоди это работает, а если что-то сдвинуто/катится - опять "пинает".
Круглые ригидбоди вообще неуправляемые, что с массой, что с трением. Катятся и катятся.
Что делать(
Проблемы:
- кинетикбоди пинает ригидбоди
- если отключить бесконечную инерцию, всё равно пинает, но только уже сдвинутые
- круглые ригидбоди катятся и не останавливаются
- сила трения непонятно на что влияет
- непонятно как влияет на физику масса объекта
До того момента, как я узнал про флаг бесконечной инерции, думал, что физика здесь упорота принципиально.
Помогла вот эта статья, но только частично: https://kidscancode.org/godot_recipes/physics/kinematic_to_rigidbody/
То есть на неподвижные ригидбоди это работает, а если что-то сдвинуто/катится - опять "пинает".
Круглые ригидбоди вообще неуправляемые, что с массой, что с трением. Катятся и катятся.
Что делать(
>>52849
За это отвечает Angular Damp в размере 0.8-1
Проверил на 3д кубах - все работает, 0 трения скользит как по льду, 1 сразу останавливается или опрокидывается, 0.5 ведет себя как игральный кубик
Как и должна, передача импульса, все дела, тяжелый объект при столкновении сдвинет легкий, легкий объект отскочит от тяжелого.
>круглые ригидбоди катятся и не останавливаются
За это отвечает Angular Damp в размере 0.8-1
> сила трения непонятно на что влияет
Проверил на 3д кубах - все работает, 0 трения скользит как по льду, 1 сразу останавливается или опрокидывается, 0.5 ведет себя как игральный кубик
>непонятно как влияет на физику масса объекта
Как и должна, передача импульса, все дела, тяжелый объект при столкновении сдвинет легкий, легкий объект отскочит от тяжелого.
>>52950
Спасибо, разобрался. У меня по умолчанию в настройках проекта 0.1 стояло. Правда, неясно, чем руководствоваться для установки того или иного значения.
Да, действительно. Я просто пытался поставить 10 - у меня всё в стороны разлеталось, и я пытался увеличить силу трения. Кажется, в реале сила трения должна при определённых значениях держать объект неподвижным...
Так-то так (уже убедился), но пока что у меня даже тяжёлые объекты отскакивают от KinematicBody. Скажем, собранная мной машинка нормально взаимодействует, а игрок - нет. Я знаю, что проблема в move_and_slide(), но не понимаю, как это откалибровать, чтобы соответствовало массе объектов. Я и машинку могу толкать во все стороны, хотя она 4 тонны весит... Или вот назначил кубикам вес в 10 тонн, а толку? Машина об них останавливается - и это правильно - а вот игрок спокойно "пинает" эти кубы, будто это просто мячики.
Самое странное в этих пинках: если сцена только загрузилась, кубы стоят неподвижно, и если им не прописывать импульс от столкновения вручную (как в статье по ссылке выше), то они не будут реагировать на игрока (KinematicBody). Но если я с помощью машинки хотя бы немного толкну куб, то он как будто меняет своё состояние, и теперь я могу пинать его во все стороны, хотя для машины он по-прежнему слишком тяжёлый. Если полежит немного, снова отключается. Вроде бы это должно быть связано с состоянием sleeping, но почему он пинается, когда не спит, если infinite_inertia = false?
...короче, я уже перебрал весь свой PlayerControl, даже умудрился подогнать ускорения к реальным величинам, но всё равно не нашёл причину проблемы. Такое ощущение, что мне нужно написать для игрового персонажа вообще всю физику с нуля, и только для того, чтобы он прекратил пинать десятитонные кубы как мячики.
Хотел уже приделать какой-нибудь костыль, типа навесить RigidBody и пусть он взаимодействует вместо KinematicBody, но это бред какой-то. Почему решение такой обыденной задачи настолько нетривиально((
...а, я вспомнил, что могу придавать начальный импульс предмету, с которым столкнулся, ориентируясь на его массу. Ввёл условие, которое игнорирует объекты с массой больше массы игрока, добавил вычитание массы предмета из массы игрока при вычислении импульса (да, примитивно, но не знаю как правильнее) - теперь игрок пинает только лёгкие предметы, и чем легче предмет, тем дальше пинает, но... Но, блииин, по-прежнему сохраняется та фигня с "разбуженными" кубами. То есть если на 10-тонный куб наехать колесом машины, он не сдвинется, но в течении нескольких секунд игрок может его ПНУТЬ, и он покатится. При этом это никак не зависит от моего импульса, это явно физический движок что-то сам решает... Ну почему так((
Ещё заметил, что машинка тоже по сути игнорирует все мои попытки её не двигать. Если толкать перпендикулярно движению, она может сопротивляться, может вообще не обращать внимания. Но если толкнуть по направлению движения, она резко ускоряется и катится дальше, хотя двигатель, очевидно, выключен. Нет, я помню, что нужно на ручник ставить, но дело в том, что она так сильно ускоряется из-за этого дурацкого "пинка", от которого я никак не могу избавиться. Фиг с ними, с кубами, но если у меня машины так и будут отпрыгивать от игрока, это будет невыносимо( Есть подозрение, что машина так реагирует, потому что никогда не бывает в спящем состоянии, и всё время реагирует как "разбуженный куб". Но почему это всё именно так происходит - никак не пойму(
Да, движок Bullet, встроенная физика Годо на моей сцене крашится почему-то (без сообщений об ошибках, просто закрывается).
>За это отвечает Angular Damp в размере 0.8-1
Спасибо, разобрался. У меня по умолчанию в настройках проекта 0.1 стояло. Правда, неясно, чем руководствоваться для установки того или иного значения.
>0 трения скользит как по льду, 1 сразу останавливается или опрокидывается
Да, действительно. Я просто пытался поставить 10 - у меня всё в стороны разлеталось, и я пытался увеличить силу трения. Кажется, в реале сила трения должна при определённых значениях держать объект неподвижным...
>тяжелый объект при столкновении сдвинет легкий, легкий объект отскочит от тяжелого
Так-то так (уже убедился), но пока что у меня даже тяжёлые объекты отскакивают от KinematicBody. Скажем, собранная мной машинка нормально взаимодействует, а игрок - нет. Я знаю, что проблема в move_and_slide(), но не понимаю, как это откалибровать, чтобы соответствовало массе объектов. Я и машинку могу толкать во все стороны, хотя она 4 тонны весит... Или вот назначил кубикам вес в 10 тонн, а толку? Машина об них останавливается - и это правильно - а вот игрок спокойно "пинает" эти кубы, будто это просто мячики.
Самое странное в этих пинках: если сцена только загрузилась, кубы стоят неподвижно, и если им не прописывать импульс от столкновения вручную (как в статье по ссылке выше), то они не будут реагировать на игрока (KinematicBody). Но если я с помощью машинки хотя бы немного толкну куб, то он как будто меняет своё состояние, и теперь я могу пинать его во все стороны, хотя для машины он по-прежнему слишком тяжёлый. Если полежит немного, снова отключается. Вроде бы это должно быть связано с состоянием sleeping, но почему он пинается, когда не спит, если infinite_inertia = false?
...короче, я уже перебрал весь свой PlayerControl, даже умудрился подогнать ускорения к реальным величинам, но всё равно не нашёл причину проблемы. Такое ощущение, что мне нужно написать для игрового персонажа вообще всю физику с нуля, и только для того, чтобы он прекратил пинать десятитонные кубы как мячики.
Хотел уже приделать какой-нибудь костыль, типа навесить RigidBody и пусть он взаимодействует вместо KinematicBody, но это бред какой-то. Почему решение такой обыденной задачи настолько нетривиально((
...а, я вспомнил, что могу придавать начальный импульс предмету, с которым столкнулся, ориентируясь на его массу. Ввёл условие, которое игнорирует объекты с массой больше массы игрока, добавил вычитание массы предмета из массы игрока при вычислении импульса (да, примитивно, но не знаю как правильнее) - теперь игрок пинает только лёгкие предметы, и чем легче предмет, тем дальше пинает, но... Но, блииин, по-прежнему сохраняется та фигня с "разбуженными" кубами. То есть если на 10-тонный куб наехать колесом машины, он не сдвинется, но в течении нескольких секунд игрок может его ПНУТЬ, и он покатится. При этом это никак не зависит от моего импульса, это явно физический движок что-то сам решает... Ну почему так((
Ещё заметил, что машинка тоже по сути игнорирует все мои попытки её не двигать. Если толкать перпендикулярно движению, она может сопротивляться, может вообще не обращать внимания. Но если толкнуть по направлению движения, она резко ускоряется и катится дальше, хотя двигатель, очевидно, выключен. Нет, я помню, что нужно на ручник ставить, но дело в том, что она так сильно ускоряется из-за этого дурацкого "пинка", от которого я никак не могу избавиться. Фиг с ними, с кубами, но если у меня машины так и будут отпрыгивать от игрока, это будет невыносимо( Есть подозрение, что машина так реагирует, потому что никогда не бывает в спящем состоянии, и всё время реагирует как "разбуженный куб". Но почему это всё именно так происходит - никак не пойму(
Да, движок Bullet, встроенная физика Годо на моей сцене крашится почему-то (без сообщений об ошибках, просто закрывается).
>>52950
Спасибо, разобрался. У меня по умолчанию в настройках проекта 0.1 стояло. Правда, неясно, чем руководствоваться для установки того или иного значения.
Да, действительно. Я просто пытался поставить 10 - у меня всё в стороны разлеталось, и я пытался увеличить силу трения. Кажется, в реале сила трения должна при определённых значениях держать объект неподвижным...
Так-то так (уже убедился), но пока что у меня даже тяжёлые объекты отскакивают от KinematicBody. Скажем, собранная мной машинка нормально взаимодействует, а игрок - нет. Я знаю, что проблема в move_and_slide(), но не понимаю, как это откалибровать, чтобы соответствовало массе объектов. Я и машинку могу толкать во все стороны, хотя она 4 тонны весит... Или вот назначил кубикам вес в 10 тонн, а толку? Машина об них останавливается - и это правильно - а вот игрок спокойно "пинает" эти кубы, будто это просто мячики.
Самое странное в этих пинках: если сцена только загрузилась, кубы стоят неподвижно, и если им не прописывать импульс от столкновения вручную (как в статье по ссылке выше), то они не будут реагировать на игрока (KinematicBody). Но если я с помощью машинки хотя бы немного толкну куб, то он как будто меняет своё состояние, и теперь я могу пинать его во все стороны, хотя для машины он по-прежнему слишком тяжёлый. Если полежит немного, снова отключается. Вроде бы это должно быть связано с состоянием sleeping, но почему он пинается, когда не спит, если infinite_inertia = false?
...короче, я уже перебрал весь свой PlayerControl, даже умудрился подогнать ускорения к реальным величинам, но всё равно не нашёл причину проблемы. Такое ощущение, что мне нужно написать для игрового персонажа вообще всю физику с нуля, и только для того, чтобы он прекратил пинать десятитонные кубы как мячики.
Хотел уже приделать какой-нибудь костыль, типа навесить RigidBody и пусть он взаимодействует вместо KinematicBody, но это бред какой-то. Почему решение такой обыденной задачи настолько нетривиально((
...а, я вспомнил, что могу придавать начальный импульс предмету, с которым столкнулся, ориентируясь на его массу. Ввёл условие, которое игнорирует объекты с массой больше массы игрока, добавил вычитание массы предмета из массы игрока при вычислении импульса (да, примитивно, но не знаю как правильнее) - теперь игрок пинает только лёгкие предметы, и чем легче предмет, тем дальше пинает, но... Но, блииин, по-прежнему сохраняется та фигня с "разбуженными" кубами. То есть если на 10-тонный куб наехать колесом машины, он не сдвинется, но в течении нескольких секунд игрок может его ПНУТЬ, и он покатится. При этом это никак не зависит от моего импульса, это явно физический движок что-то сам решает... Ну почему так((
Ещё заметил, что машинка тоже по сути игнорирует все мои попытки её не двигать. Если толкать перпендикулярно движению, она может сопротивляться, может вообще не обращать внимания. Но если толкнуть по направлению движения, она резко ускоряется и катится дальше, хотя двигатель, очевидно, выключен. Нет, я помню, что нужно на ручник ставить, но дело в том, что она так сильно ускоряется из-за этого дурацкого "пинка", от которого я никак не могу избавиться. Фиг с ними, с кубами, но если у меня машины так и будут отпрыгивать от игрока, это будет невыносимо( Есть подозрение, что машина так реагирует, потому что никогда не бывает в спящем состоянии, и всё время реагирует как "разбуженный куб". Но почему это всё именно так происходит - никак не пойму(
Да, движок Bullet, встроенная физика Годо на моей сцене крашится почему-то (без сообщений об ошибках, просто закрывается).
>За это отвечает Angular Damp в размере 0.8-1
Спасибо, разобрался. У меня по умолчанию в настройках проекта 0.1 стояло. Правда, неясно, чем руководствоваться для установки того или иного значения.
>0 трения скользит как по льду, 1 сразу останавливается или опрокидывается
Да, действительно. Я просто пытался поставить 10 - у меня всё в стороны разлеталось, и я пытался увеличить силу трения. Кажется, в реале сила трения должна при определённых значениях держать объект неподвижным...
>тяжелый объект при столкновении сдвинет легкий, легкий объект отскочит от тяжелого
Так-то так (уже убедился), но пока что у меня даже тяжёлые объекты отскакивают от KinematicBody. Скажем, собранная мной машинка нормально взаимодействует, а игрок - нет. Я знаю, что проблема в move_and_slide(), но не понимаю, как это откалибровать, чтобы соответствовало массе объектов. Я и машинку могу толкать во все стороны, хотя она 4 тонны весит... Или вот назначил кубикам вес в 10 тонн, а толку? Машина об них останавливается - и это правильно - а вот игрок спокойно "пинает" эти кубы, будто это просто мячики.
Самое странное в этих пинках: если сцена только загрузилась, кубы стоят неподвижно, и если им не прописывать импульс от столкновения вручную (как в статье по ссылке выше), то они не будут реагировать на игрока (KinematicBody). Но если я с помощью машинки хотя бы немного толкну куб, то он как будто меняет своё состояние, и теперь я могу пинать его во все стороны, хотя для машины он по-прежнему слишком тяжёлый. Если полежит немного, снова отключается. Вроде бы это должно быть связано с состоянием sleeping, но почему он пинается, когда не спит, если infinite_inertia = false?
...короче, я уже перебрал весь свой PlayerControl, даже умудрился подогнать ускорения к реальным величинам, но всё равно не нашёл причину проблемы. Такое ощущение, что мне нужно написать для игрового персонажа вообще всю физику с нуля, и только для того, чтобы он прекратил пинать десятитонные кубы как мячики.
Хотел уже приделать какой-нибудь костыль, типа навесить RigidBody и пусть он взаимодействует вместо KinematicBody, но это бред какой-то. Почему решение такой обыденной задачи настолько нетривиально((
...а, я вспомнил, что могу придавать начальный импульс предмету, с которым столкнулся, ориентируясь на его массу. Ввёл условие, которое игнорирует объекты с массой больше массы игрока, добавил вычитание массы предмета из массы игрока при вычислении импульса (да, примитивно, но не знаю как правильнее) - теперь игрок пинает только лёгкие предметы, и чем легче предмет, тем дальше пинает, но... Но, блииин, по-прежнему сохраняется та фигня с "разбуженными" кубами. То есть если на 10-тонный куб наехать колесом машины, он не сдвинется, но в течении нескольких секунд игрок может его ПНУТЬ, и он покатится. При этом это никак не зависит от моего импульса, это явно физический движок что-то сам решает... Ну почему так((
Ещё заметил, что машинка тоже по сути игнорирует все мои попытки её не двигать. Если толкать перпендикулярно движению, она может сопротивляться, может вообще не обращать внимания. Но если толкнуть по направлению движения, она резко ускоряется и катится дальше, хотя двигатель, очевидно, выключен. Нет, я помню, что нужно на ручник ставить, но дело в том, что она так сильно ускоряется из-за этого дурацкого "пинка", от которого я никак не могу избавиться. Фиг с ними, с кубами, но если у меня машины так и будут отпрыгивать от игрока, это будет невыносимо( Есть подозрение, что машина так реагирует, потому что никогда не бывает в спящем состоянии, и всё время реагирует как "разбуженный куб". Но почему это всё именно так происходит - никак не пойму(
Да, движок Bullet, встроенная физика Годо на моей сцене крашится почему-то (без сообщений об ошибках, просто закрывается).
Почему годот просаживается на 4х тысячах спрайтов одновременно двигающихся? Даже казаки держали 8 тысяч активных юнитов, а там были ещё 200гц одноядерные процессоры. Это можно как-то поправить?
>>53022
Попробуй посмотреть вот эти значения:
var objs = Performance.get_monitor(Performance.OBJECT_COUNT)
var nodes = Performance.get_monitor(Performance.OBJECT_NODE_COUNT)
Там наверняка больше 4к будет.
По идее, для того, что ты хочешь, можно попробовать использовать MultiMeshInstance2D:
Скорее всего "юниты" не были отдельными сущностями, а держались в одном массиве. То есть для смещения и рендеринга игре не нужно было далеко бегать, i+1 и всё. Это называется Data-oriented Design:
В той же статье есть раздел "Motives", и там как раз про эти древние 200 Гц процессоры. Как я понял, основная проблема не в процессоре, а в том, что процессор вынужден искать данные в памяти, и тратить на это много времени. Если мы используем массивы однотипных данных, они могут загружаться в кэш процессора последовательно и поэтому процессор не будет тратить время на ожидание оперативной памяти. Кэш маленький, но он вроде заранее заполняется, если процессор может предсказать следующий блок данных (ща все оптимизации ЦП строятся на том, чтобы выполнить задачу раньше, чем программа об этой задаче попросит). А в ООП-подходе данные разбросаны по памяти рандомно, и процессор вынужден искать эти данные в оперативной памяти, что тормозит всю работу.
В документации Годо по этому поводу есть вот это: https://docs.godotengine.org/en/stable/about/faq.html#why-does-godot-not-force-users-to-implement-dod-data-oriented-design
Короче, Годо ориентирован на удобство большинства игр, а большинству игр двигать тысячи спрайтов одновременно просто не нужно, поэтому Годо в своей основе использует ООП, которое не очень дружит с большим числом объектов. А для тех, кому всё-таки нужно, совет:
>Почему годот просаживается на 4х тысячах спрайтов одновременно двигающихся?
Попробуй посмотреть вот эти значения:
var objs = Performance.get_monitor(Performance.OBJECT_COUNT)
var nodes = Performance.get_monitor(Performance.OBJECT_NODE_COUNT)
Там наверняка больше 4к будет.
По идее, для того, что ты хочешь, можно попробовать использовать MultiMeshInstance2D:
>MultiMesh provides low-level mesh instancing. Drawing thousands of MeshInstance nodes can be slow, since each object is submitted to the GPU then drawn individually.
>MultiMesh is much faster as it can draw thousands of instances with a single draw call, resulting in less API overhead.
>As a drawback, if the instances are too far away of each other, performance may be reduced as every single instance will always rendered (they are spatially indexed as one, for the whole object).
>Since instances may have any behavior, the AABB used for visibility must be provided by the user.
>казаки держали 8 тысяч активных юнитов
Скорее всего "юниты" не были отдельными сущностями, а держались в одном массиве. То есть для смещения и рендеринга игре не нужно было далеко бегать, i+1 и всё. Это называется Data-oriented Design:
>In computing, data-oriented design is a program optimization approach motivated by efficient usage of the CPU cache, used in video game development. The approach is to focus on the data layout, separating and sorting fields according to when they are needed, and to think about transformations of data. https://en.wikipedia.org/wiki/Data-oriented_design
В той же статье есть раздел "Motives", и там как раз про эти древние 200 Гц процессоры. Как я понял, основная проблема не в процессоре, а в том, что процессор вынужден искать данные в памяти, и тратить на это много времени. Если мы используем массивы однотипных данных, они могут загружаться в кэш процессора последовательно и поэтому процессор не будет тратить время на ожидание оперативной памяти. Кэш маленький, но он вроде заранее заполняется, если процессор может предсказать следующий блок данных (ща все оптимизации ЦП строятся на том, чтобы выполнить задачу раньше, чем программа об этой задаче попросит). А в ООП-подходе данные разбросаны по памяти рандомно, и процессор вынужден искать эти данные в оперативной памяти, что тормозит всю работу.
В документации Годо по этому поводу есть вот это: https://docs.godotengine.org/en/stable/about/faq.html#why-does-godot-not-force-users-to-implement-dod-data-oriented-design
Короче, Годо ориентирован на удобство большинства игр, а большинству игр двигать тысячи спрайтов одновременно просто не нужно, поэтому Годо в своей основе использует ООП, которое не очень дружит с большим числом объектов. А для тех, кому всё-таки нужно, совет:
>If a game that really needs to process such large amount of objects is needed, our recommendation is to use C++ and GDNative for the high performance parts and GDScript (or C#) for the rest of the game.
>>53022
Попробуй посмотреть вот эти значения:
var objs = Performance.get_monitor(Performance.OBJECT_COUNT)
var nodes = Performance.get_monitor(Performance.OBJECT_NODE_COUNT)
Там наверняка больше 4к будет.
По идее, для того, что ты хочешь, можно попробовать использовать MultiMeshInstance2D:
Скорее всего "юниты" не были отдельными сущностями, а держались в одном массиве. То есть для смещения и рендеринга игре не нужно было далеко бегать, i+1 и всё. Это называется Data-oriented Design:
В той же статье есть раздел "Motives", и там как раз про эти древние 200 Гц процессоры. Как я понял, основная проблема не в процессоре, а в том, что процессор вынужден искать данные в памяти, и тратить на это много времени. Если мы используем массивы однотипных данных, они могут загружаться в кэш процессора последовательно и поэтому процессор не будет тратить время на ожидание оперативной памяти. Кэш маленький, но он вроде заранее заполняется, если процессор может предсказать следующий блок данных (ща все оптимизации ЦП строятся на том, чтобы выполнить задачу раньше, чем программа об этой задаче попросит). А в ООП-подходе данные разбросаны по памяти рандомно, и процессор вынужден искать эти данные в оперативной памяти, что тормозит всю работу.
В документации Годо по этому поводу есть вот это: https://docs.godotengine.org/en/stable/about/faq.html#why-does-godot-not-force-users-to-implement-dod-data-oriented-design
Короче, Годо ориентирован на удобство большинства игр, а большинству игр двигать тысячи спрайтов одновременно просто не нужно, поэтому Годо в своей основе использует ООП, которое не очень дружит с большим числом объектов. А для тех, кому всё-таки нужно, совет:
>Почему годот просаживается на 4х тысячах спрайтов одновременно двигающихся?
Попробуй посмотреть вот эти значения:
var objs = Performance.get_monitor(Performance.OBJECT_COUNT)
var nodes = Performance.get_monitor(Performance.OBJECT_NODE_COUNT)
Там наверняка больше 4к будет.
По идее, для того, что ты хочешь, можно попробовать использовать MultiMeshInstance2D:
>MultiMesh provides low-level mesh instancing. Drawing thousands of MeshInstance nodes can be slow, since each object is submitted to the GPU then drawn individually.
>MultiMesh is much faster as it can draw thousands of instances with a single draw call, resulting in less API overhead.
>As a drawback, if the instances are too far away of each other, performance may be reduced as every single instance will always rendered (they are spatially indexed as one, for the whole object).
>Since instances may have any behavior, the AABB used for visibility must be provided by the user.
>казаки держали 8 тысяч активных юнитов
Скорее всего "юниты" не были отдельными сущностями, а держались в одном массиве. То есть для смещения и рендеринга игре не нужно было далеко бегать, i+1 и всё. Это называется Data-oriented Design:
>In computing, data-oriented design is a program optimization approach motivated by efficient usage of the CPU cache, used in video game development. The approach is to focus on the data layout, separating and sorting fields according to when they are needed, and to think about transformations of data. https://en.wikipedia.org/wiki/Data-oriented_design
В той же статье есть раздел "Motives", и там как раз про эти древние 200 Гц процессоры. Как я понял, основная проблема не в процессоре, а в том, что процессор вынужден искать данные в памяти, и тратить на это много времени. Если мы используем массивы однотипных данных, они могут загружаться в кэш процессора последовательно и поэтому процессор не будет тратить время на ожидание оперативной памяти. Кэш маленький, но он вроде заранее заполняется, если процессор может предсказать следующий блок данных (ща все оптимизации ЦП строятся на том, чтобы выполнить задачу раньше, чем программа об этой задаче попросит). А в ООП-подходе данные разбросаны по памяти рандомно, и процессор вынужден искать эти данные в оперативной памяти, что тормозит всю работу.
В документации Годо по этому поводу есть вот это: https://docs.godotengine.org/en/stable/about/faq.html#why-does-godot-not-force-users-to-implement-dod-data-oriented-design
Короче, Годо ориентирован на удобство большинства игр, а большинству игр двигать тысячи спрайтов одновременно просто не нужно, поэтому Годо в своей основе использует ООП, которое не очень дружит с большим числом объектов. А для тех, кому всё-таки нужно, совет:
>If a game that really needs to process such large amount of objects is needed, our recommendation is to use C++ and GDNative for the high performance parts and GDScript (or C#) for the rest of the game.
>>53022
Define "держали"? А то окажется, что там было разрешение 800х600, спрайты размером 16х32 и 12 фпс.
Про MultiMeshInstance2D тебе уже написали. Современные спрайты это не то же самое что спрайты в 2000.
Define "держали"? А то окажется, что там было разрешение 800х600, спрайты размером 16х32 и 12 фпс.
Про MultiMeshInstance2D тебе уже написали. Современные спрайты это не то же самое что спрайты в 2000.
>>53032
ИМХО проблема не в разрешении и размерах. Если статично расставить по 3D-сцене >15000 нод, то Годо может выдавать почти стабильные 75 фпс на 1440x900. Но если хотя бы часть этих нод подвижна, то всё сильно ухудшается. Значит, проблема именно в адресации данных, а не в их размерах. Грубо говоря процессору приходится бегать по памяти, чтобы 60 раз за секунду немножко сдвинуть каждую из тысяч сущностей - и именно здесь происходит просадка. DoD призван исправить эту проблему, но DoD через GDScript реализовать не получится, если я правильно понимаю, поэтому рекомендуется подключать внешние низкоуровневые/компилируемые ЯП.
>А то окажется, что там было разрешение 800х600, спрайты размером 16х32 и 12 фпс.
ИМХО проблема не в разрешении и размерах. Если статично расставить по 3D-сцене >15000 нод, то Годо может выдавать почти стабильные 75 фпс на 1440x900. Но если хотя бы часть этих нод подвижна, то всё сильно ухудшается. Значит, проблема именно в адресации данных, а не в их размерах. Грубо говоря процессору приходится бегать по памяти, чтобы 60 раз за секунду немножко сдвинуть каждую из тысяч сущностей - и именно здесь происходит просадка. DoD призван исправить эту проблему, но DoD через GDScript реализовать не получится, если я правильно понимаю, поэтому рекомендуется подключать внешние низкоуровневые/компилируемые ЯП.
>>53030
В Годо нет ООП.
Юнити, не смотря на свои огромные монобехейворы держит 9к спрайтов без лагов.
nodes/objects - Нахуя? Я просто взял и вкинул спрайты на сцену. У меня создано 4к спрайтов, а дальше резко идет падение по производительности. Резко - это когда почти 90 градусов после превышения значения. Почему это лагает? Это просто точка с положением от которого надо рендерить изображение и если оно закрывает другое, альфомаской стирать то, которое под ним.
MultiMeshInstance2D спасибо. Посмотрю. Надеюсь мне не придется вытворять магию, чтобы просто создать несколько сотен спрайтов.
В Годо нет ООП.
Юнити, не смотря на свои огромные монобехейворы держит 9к спрайтов без лагов.
nodes/objects - Нахуя? Я просто взял и вкинул спрайты на сцену. У меня создано 4к спрайтов, а дальше резко идет падение по производительности. Резко - это когда почти 90 градусов после превышения значения. Почему это лагает? Это просто точка с положением от которого надо рендерить изображение и если оно закрывает другое, альфомаской стирать то, которое под ним.
MultiMeshInstance2D спасибо. Посмотрю. Надеюсь мне не придется вытворять магию, чтобы просто создать несколько сотен спрайтов.
>>53101
Чиво? Скрипты на GDScript - это отдельные классы, со свойствами и методами. И всё, что ты используешь в скриптах, это тоже какие-то стандартные классы движка и их методы/свойства/константы. Можно объявить свой скрипт кастомным классом (class_name) и наследоваться от него. Потом, каждая нода имеет в себе свойства и функции, чем не ООП? Внутри движка есть какие-то оптимизации, но снаружи это явное ООП.
Ограничитель FPS снят? Если снять ограничитель, будет видно, что без нагрузки Годо выдаёт сотни кадров в секунду - "резкого падения" нет, просто ограничитель по умолчанию залочен на частоту экрана (60/75 Гц), и ты видишь просадку только когда она падает ниже ограничения.
Потому что
Ты же в каждом отдельном спрайте позицию меняешь? Вот. Где данные положения находятся в памяти - заранее неизвестно, процессору приходится запрашивать у оперативной памяти данные каждого спрайта.
https://docs.godotengine.org/en/stable/tutorials/3d/vertex_animation/animating_thousands_of_fish.html#making-a-school-of-fish
Правда,
https://docs.godotengine.org/en/stable/tutorials/3d/vertex_animation/controlling_thousands_of_fish.html
Так тебе несколько сотен, или несколько сотен + 4 тысячи? В FAQ же написано, большинству игр не нужны тысячи спрайтов одновременно движущихся, поэтому движок использует более простую модель (которая понятнее новичкам и дизайнерам), но если всё-таки нужны тысячи - можно запилить костыль оптимизированный код на C++/GDNative, но это уметь надо.
Но если тебя так привлекают 200 Гц доядерные процы, пили на C без каких-либо движков.
>В Годо нет ООП.
Чиво? Скрипты на GDScript - это отдельные классы, со свойствами и методами. И всё, что ты используешь в скриптах, это тоже какие-то стандартные классы движка и их методы/свойства/константы. Можно объявить свой скрипт кастомным классом (class_name) и наследоваться от него. Потом, каждая нода имеет в себе свойства и функции, чем не ООП? Внутри движка есть какие-то оптимизации, но снаружи это явное ООП.
>У меня создано 4к спрайтов, а дальше резко идет падение по производительности. Резко - это когда почти 90 градусов после превышения значения
Ограничитель FPS снят? Если снять ограничитель, будет видно, что без нагрузки Годо выдаёт сотни кадров в секунду - "резкого падения" нет, просто ограничитель по умолчанию залочен на частоту экрана (60/75 Гц), и ты видишь просадку только когда она падает ниже ограничения.
>Почему это лагает? Это просто точка с положением от которого надо рендерить изображение
Потому что
>спрайтов одновременно двигающихся
Ты же в каждом отдельном спрайте позицию меняешь? Вот. Где данные положения находятся в памяти - заранее неизвестно, процессору приходится запрашивать у оперативной памяти данные каждого спрайта.
>MultiMeshInstance2D спасибо. Посмотрю.
https://docs.godotengine.org/en/stable/tutorials/3d/vertex_animation/animating_thousands_of_fish.html#making-a-school-of-fish
Правда,
>The problem with MeshInstances is that it is expensive to update their transform array. It is great for placing many static objects around the scene. But it is still difficult to move the objects around the scene.
>To make each instance move in an interesting way we will use a Particles node. Particles take advantage of GPU acceleration by computing and setting the per-instance information in a Shader.
https://docs.godotengine.org/en/stable/tutorials/3d/vertex_animation/controlling_thousands_of_fish.html
>просто создать несколько сотен спрайтов
>несколько сотен
>создано 4к спрайтов
Так тебе несколько сотен, или несколько сотен + 4 тысячи? В FAQ же написано, большинству игр не нужны тысячи спрайтов одновременно движущихся, поэтому движок использует более простую модель (которая понятнее новичкам и дизайнерам), но если всё-таки нужны тысячи - можно запилить костыль оптимизированный код на C++/GDNative, но это уметь надо.
Но если тебя так привлекают 200 Гц доядерные процы, пили на C без каких-либо движков.
>>53101
Чиво? Скрипты на GDScript - это отдельные классы, со свойствами и методами. И всё, что ты используешь в скриптах, это тоже какие-то стандартные классы движка и их методы/свойства/константы. Можно объявить свой скрипт кастомным классом (class_name) и наследоваться от него. Потом, каждая нода имеет в себе свойства и функции, чем не ООП? Внутри движка есть какие-то оптимизации, но снаружи это явное ООП.
Ограничитель FPS снят? Если снять ограничитель, будет видно, что без нагрузки Годо выдаёт сотни кадров в секунду - "резкого падения" нет, просто ограничитель по умолчанию залочен на частоту экрана (60/75 Гц), и ты видишь просадку только когда она падает ниже ограничения.
Потому что
Ты же в каждом отдельном спрайте позицию меняешь? Вот. Где данные положения находятся в памяти - заранее неизвестно, процессору приходится запрашивать у оперативной памяти данные каждого спрайта.
https://docs.godotengine.org/en/stable/tutorials/3d/vertex_animation/animating_thousands_of_fish.html#making-a-school-of-fish
Правда,
https://docs.godotengine.org/en/stable/tutorials/3d/vertex_animation/controlling_thousands_of_fish.html
Так тебе несколько сотен, или несколько сотен + 4 тысячи? В FAQ же написано, большинству игр не нужны тысячи спрайтов одновременно движущихся, поэтому движок использует более простую модель (которая понятнее новичкам и дизайнерам), но если всё-таки нужны тысячи - можно запилить костыль оптимизированный код на C++/GDNative, но это уметь надо.
Но если тебя так привлекают 200 Гц доядерные процы, пили на C без каких-либо движков.
>В Годо нет ООП.
Чиво? Скрипты на GDScript - это отдельные классы, со свойствами и методами. И всё, что ты используешь в скриптах, это тоже какие-то стандартные классы движка и их методы/свойства/константы. Можно объявить свой скрипт кастомным классом (class_name) и наследоваться от него. Потом, каждая нода имеет в себе свойства и функции, чем не ООП? Внутри движка есть какие-то оптимизации, но снаружи это явное ООП.
>У меня создано 4к спрайтов, а дальше резко идет падение по производительности. Резко - это когда почти 90 градусов после превышения значения
Ограничитель FPS снят? Если снять ограничитель, будет видно, что без нагрузки Годо выдаёт сотни кадров в секунду - "резкого падения" нет, просто ограничитель по умолчанию залочен на частоту экрана (60/75 Гц), и ты видишь просадку только когда она падает ниже ограничения.
>Почему это лагает? Это просто точка с положением от которого надо рендерить изображение
Потому что
>спрайтов одновременно двигающихся
Ты же в каждом отдельном спрайте позицию меняешь? Вот. Где данные положения находятся в памяти - заранее неизвестно, процессору приходится запрашивать у оперативной памяти данные каждого спрайта.
>MultiMeshInstance2D спасибо. Посмотрю.
https://docs.godotengine.org/en/stable/tutorials/3d/vertex_animation/animating_thousands_of_fish.html#making-a-school-of-fish
Правда,
>The problem with MeshInstances is that it is expensive to update their transform array. It is great for placing many static objects around the scene. But it is still difficult to move the objects around the scene.
>To make each instance move in an interesting way we will use a Particles node. Particles take advantage of GPU acceleration by computing and setting the per-instance information in a Shader.
https://docs.godotengine.org/en/stable/tutorials/3d/vertex_animation/controlling_thousands_of_fish.html
>просто создать несколько сотен спрайтов
>несколько сотен
>создано 4к спрайтов
Так тебе несколько сотен, или несколько сотен + 4 тысячи? В FAQ же написано, большинству игр не нужны тысячи спрайтов одновременно движущихся, поэтому движок использует более простую модель (которая понятнее новичкам и дизайнерам), но если всё-таки нужны тысячи - можно запилить костыль оптимизированный код на C++/GDNative, но это уметь надо.
Но если тебя так привлекают 200 Гц доядерные процы, пили на C без каких-либо движков.
>>53101 >>53123
https://ru.wikipedia.org/wiki/Инкапсуляция_(программирование)
GDScript подобен Python, а Python - ООП, хотя в Python нет скрытия данных.
Только давайте не устраивать срач на тему труЪ-ООП.
И вот ещё - https://godotengine.org/qa/42034/oop-in-godot
https://ru.wikipedia.org/wiki/Инкапсуляция_(программирование)
>Инкапсуляция — в информатике размещение в одном компоненте данных и методов, которые с ними работают. Также может означать скрытие внутренней реализации от других компонентов.
>...некоторые языки (например, Smalltalk, Python) реализуют инкапсуляцию в полной мере, но не предусматривают возможности скрытия в принципе.
>В общем случае в разных языках программирования термин «инкапсуляция» относится к одной или обеим одновременно следующим нотациям:
>- механизм языка, позволяющий ограничить доступ одних компонентов программы к другим;
>- языковая конструкция, позволяющая связать данные с методами, предназначенными для обработки этих данных.
GDScript подобен Python, а Python - ООП, хотя в Python нет скрытия данных.
Только давайте не устраивать срач на тему труЪ-ООП.
И вот ещё - https://godotengine.org/qa/42034/oop-in-godot
>Godot is strongly OOP. Nodes and scenes are objects, as are scripts, so you can use inheritance with either of them.
>>53133
Точку в этом вопросе недавно поставил extremecode на youtube. Кроме того, твоя же паста говорит, что авторы питона как раз таки понимают суть, в отличие от "так же означающих".
Инкапсуляция - это не сокрытие. В гдскрипте нет скрытия, нет приватных членов. Однако там есть инкапсуляция, наследование, полиморфизм. Таким образом, я подтверждаю, что гдскрипт стронгООП.
> Только давайте не устраивать срач на тему труЪ-ООП.
Точку в этом вопросе недавно поставил extremecode на youtube. Кроме того, твоя же паста говорит, что авторы питона как раз таки понимают суть, в отличие от "так же означающих".
Инкапсуляция - это не сокрытие. В гдскрипте нет скрытия, нет приватных членов. Однако там есть инкапсуляция, наследование, полиморфизм. Таким образом, я подтверждаю, что гдскрипт стронгООП.
4,1 Мб, 1920x1031>>53101
MultiMeshInstance это не то чтобы магия. Это примерно то же, что используется под капотом для частиц (particles)
Также можно смортреть в сторону вот этого пулл реквеста, в котором ведутся работы и там уже х2.5 прирост в спрайт батчинге: https://github.com/godotengine/godot/pull/37349
Несколько сотен спрайтов ты сможешь создать и сейчас, тест в шапке - 60 фпс на некропеке при ~1000 спрайтах.
>Надеюсь мне не придется вытворять магию
MultiMeshInstance это не то чтобы магия. Это примерно то же, что используется под капотом для частиц (particles)
Также можно смортреть в сторону вот этого пулл реквеста, в котором ведутся работы и там уже х2.5 прирост в спрайт батчинге: https://github.com/godotengine/godot/pull/37349
>чтобы просто создать несколько сотен спрайтов.
Несколько сотен спрайтов ты сможешь создать и сейчас, тест в шапке - 60 фпс на некропеке при ~1000 спрайтах.
>>53022
Потому что каждый спрайт рисуется одним вызовом к opengl. Сколько спрайтов - столько и draw call'ов.
Потому что каждый спрайт рисуется одним вызовом к opengl. Сколько спрайтов - столько и draw call'ов.
>>53120
Я пробовал и через одну ноду двигать 4 тысячи и через 4 тысячи НОД. Разницы нет. Чувак, годо лагает тупо сам по себе. Не держит он выше своего пула объекты. Вопрос только как пул расширить.
Я пробовал и через одну ноду двигать 4 тысячи и через 4 тысячи НОД. Разницы нет. Чувак, годо лагает тупо сам по себе. Не держит он выше своего пула объекты. Вопрос только как пул расширить.
>>53138
4300 спрайтов. Меня интересует что угодно, что достигнет хотя бы 9к. А ещё лучше 15к. Чтобы мои говноскрипты снизили это значение до 9к
4300 спрайтов. Меня интересует что угодно, что достигнет хотя бы 9к. А ещё лучше 15к. Чтобы мои говноскрипты снизили это значение до 9к
>>53372
Ебать дебил.
Ебать дебил.
![floppy-disk-data-storage-hard-disk-drive-backup-disk-storag[...].jpg](https://2ch.hk//gd/src/643188/15861572174740.jpg)
>>53372
Ну раз ты сам делаешь какую то уникальную хуйню, то и рендер напишешь сам.
Ну раз ты сам делаешь какую то уникальную хуйню, то и рендер напишешь сам.
>>53345
Способы выжать сколько угодно спрайтов есть. Только управлять ими ты не сможешь.
>>53372
Сразу об этом и не подумал. Серьёзно, зачем тебе 9к спрайтов на одном экране?
1920 x 1080 / 9000 = 230 пикселей на один спрайт = 10x23 один спрайт.
Это если располагать их сеточкой, то есть без пробелов.
Один вопрос: зачем?
Если тебе нужно расположить 9к спрайтов на одной сцене, а не на одном экране, то тут уже другие способы оптимизации нужны, потому что 9к спрайтов на одном экране у тебя никогда не выйдет (точнее отдалить-то камеру можно, но спрайты сожмутся в точки, кому это нужно?).
Короче, опиши вкратце, что хочешь реализовать, а мы подумаем, чем тебе можно помочь.
>>53385
Никогда не слышал выражение "библиотека с кодом"? В ней содержится всё то, благодаря чему ты можешь делать игры без головной боли, просто тыкая мышой по кнопочкам и не задумываясь о низкоуровневых проблемах конкретной ОС и/или низкоуровневых игровых алгоритмах. Хочешь пустой APK - пили на Java с нуля, только тебе придётся самому возиться с тем, с чем возятся эти 20 МБ вместо тебя.
>4300 спрайтов. Меня интересует что угодно, что достигнет хотя бы 9к. А ещё лучше 15к.
Способы выжать сколько угодно спрайтов есть. Только управлять ими ты не сможешь.
>>53372
>Я сам решу, нужны мне 9к спрайтов или нет. Спасибо.
Сразу об этом и не подумал. Серьёзно, зачем тебе 9к спрайтов на одном экране?
1920 x 1080 / 9000 = 230 пикселей на один спрайт = 10x23 один спрайт.
Это если располагать их сеточкой, то есть без пробелов.
Один вопрос: зачем?
Если тебе нужно расположить 9к спрайтов на одной сцене, а не на одном экране, то тут уже другие способы оптимизации нужны, потому что 9к спрайтов на одном экране у тебя никогда не выйдет (точнее отдалить-то камеру можно, но спрайты сожмутся в точки, кому это нужно?).
Короче, опиши вкратце, что хочешь реализовать, а мы подумаем, чем тебе можно помочь.
>>53385
>Почему apk с пустой сценой весит ДВАДЦАТЬ СРАНЫХ МЕГАБАЙТ?
Никогда не слышал выражение "библиотека с кодом"? В ней содержится всё то, благодаря чему ты можешь делать игры без головной боли, просто тыкая мышой по кнопочкам и не задумываясь о низкоуровневых проблемах конкретной ОС и/или низкоуровневых игровых алгоритмах. Хочешь пустой APK - пили на Java с нуля, только тебе придётся самому возиться с тем, с чем возятся эти 20 МБ вместо тебя.
>>53499
Имхо, визуально блоки добавлять и редактировать в несколько раз дольше и сложнее, чем код писать.
Если уже умеешь писать код и не имеешь с этим проблем, то лучше даже не пытаться в визуальный код.
потыкался, ниасилил, вернулся к использованию gdscript
Даже не знаю, какой дисигнер осилит визуальный скриптинг
>Какие подводные?
Имхо, визуально блоки добавлять и редактировать в несколько раз дольше и сложнее, чем код писать.
Если уже умеешь писать код и не имеешь с этим проблем, то лучше даже не пытаться в визуальный код.
потыкался, ниасилил, вернулся к использованию gdscript
Даже не знаю, какой дисигнер осилит визуальный скриптинг
>>53513
В код мы с товарищем не слишком-то хорошо умеем, разве что со словарём, а свою ЖРПГ сделать хочется. Потому, собсно, и спросил.
В код мы с товарищем не слишком-то хорошо умеем, разве что со словарём, а свою ЖРПГ сделать хочется. Потому, собсно, и спросил.
>>53523
Ну смотри, принципиальная разница между кодом и "визуальным программированием" в том, что в одном случае ты пишешь текст, который будет читать компьютер (транслятор), а во втором ты двигаешь мышу и жмёшь на виртуальные кнопки, натягиваешь виртуальные ниточки и переключаешь виртуальные переключатели, а ещё вводишь в разные поля ввода всё тот же текст, чтобы... чтобы, ВНЕЗАПНО, создать всё тот же код, который будет читать компьютер, просто у этого кода будет графическое представление (но на диск он всё равно сохраняется в виде какого-то текста).
Чтобы программировать, нужно три вещи:
- уметь составлять алгоритмы для решения задач;
- знать базовый синтаксис выбранного ЯП;
- знать содержимое используемых библиотек.
Что из этого может убрать визуальное программирование?
- алгоритмы тебе в любом случае придётся составлять;
- вместо синтаксиса тебе нужно знать GUI редактора;
- библиотеки используются те же самые, что и с кодом.
То есть визуальный кодинг всего лишь подменяет текст на ГУЙ, в который тебе нужно мышой тыкать.
Разумеется, речь о том визуальном кодинге, который есть сейчас (вообще в мире, не только в Годо), это не значит, что никогда не появится гениальное изобретение, которое отменит необходимость писать код, но пока оно не появилось, использовать визуальные инструменты банально неудобно, КПД резко снижается. Проще немного подучить ЯП, тем более GDScript достаточно прост.
Практически ни один программист не помнит наизусть содержимое библиотек. В крупных ЯП даже необязательно знать все фичи языка, чтобы успешно писать программы. Мануал - твой друг, используй его. А в том же визуальном программировании тебе всё равно потребуется помнить все эти многочисленные блоки, их назначение и способы применения...
Если речь о классических 2D jRPG, не проще ли будет использовать RPG Maker? Там вообще кодинга не нужно вроде.
Ну смотри, принципиальная разница между кодом и "визуальным программированием" в том, что в одном случае ты пишешь текст, который будет читать компьютер (транслятор), а во втором ты двигаешь мышу и жмёшь на виртуальные кнопки, натягиваешь виртуальные ниточки и переключаешь виртуальные переключатели, а ещё вводишь в разные поля ввода всё тот же текст, чтобы... чтобы, ВНЕЗАПНО, создать всё тот же код, который будет читать компьютер, просто у этого кода будет графическое представление (но на диск он всё равно сохраняется в виде какого-то текста).
Чтобы программировать, нужно три вещи:
- уметь составлять алгоритмы для решения задач;
- знать базовый синтаксис выбранного ЯП;
- знать содержимое используемых библиотек.
Что из этого может убрать визуальное программирование?
- алгоритмы тебе в любом случае придётся составлять;
- вместо синтаксиса тебе нужно знать GUI редактора;
- библиотеки используются те же самые, что и с кодом.
То есть визуальный кодинг всего лишь подменяет текст на ГУЙ, в который тебе нужно мышой тыкать.
Разумеется, речь о том визуальном кодинге, который есть сейчас (вообще в мире, не только в Годо), это не значит, что никогда не появится гениальное изобретение, которое отменит необходимость писать код, но пока оно не появилось, использовать визуальные инструменты банально неудобно, КПД резко снижается. Проще немного подучить ЯП, тем более GDScript достаточно прост.
>разве что со словарём
Практически ни один программист не помнит наизусть содержимое библиотек. В крупных ЯП даже необязательно знать все фичи языка, чтобы успешно писать программы. Мануал - твой друг, используй его. А в том же визуальном программировании тебе всё равно потребуется помнить все эти многочисленные блоки, их назначение и способы применения...
>ЖРПГ
Если речь о классических 2D jRPG, не проще ли будет использовать RPG Maker? Там вообще кодинга не нужно вроде.
>>53532
В том-то и дело, что есть задумки, которые на мейкере сделать тяжко, невозможно или ХЗВЩ как.
А по поводу подучить язык... ну, замечание верное. Попытаемся, короче.
>Если речь о классических 2D jRPG, не проще ли будет использовать RPG Maker? Там вообще кодинга не нужно вроде.
В том-то и дело, что есть задумки, которые на мейкере сделать тяжко, невозможно или ХЗВЩ как.
А по поводу подучить язык... ну, замечание верное. Попытаемся, короче.
>>53569
Я почти сразу в GDScript разобрался, встроенная справка очень помогает. Но у меня богатый опыт Pascal, конечно...
Я почти сразу в GDScript разобрался, встроенная справка очень помогает. Но у меня богатый опыт Pascal, конечно...
43 Кб, 581x324Переписал с нуля контроллер персонажа. Проблемы как были, так и остались:
- расторможенные RigidBody пинаются;
- автомобили пинаются вообще всегда;
- на наклонных плоскостях соскальзывает;
- на маленьких бордюрах подпрыгивает.
Последняя проблема недавно появилась, раньше как-то удавалось избегать.
Замена move_and_slide() на move_and_slide_with_snap() не помогает.
Я уже замучился, я хотел просто игру делать, а не вот это вот всё.
Смотрел чужие контроллеры, там всё аналогично...
- расторможенные RigidBody пинаются;
- автомобили пинаются вообще всегда;
- на наклонных плоскостях соскальзывает;
- на маленьких бордюрах подпрыгивает.
Последняя проблема недавно появилась, раньше как-то удавалось избегать.
Замена move_and_slide() на move_and_slide_with_snap() не помогает.
Я уже замучился, я хотел просто игру делать, а не вот это вот всё.
Смотрел чужие контроллеры, там всё аналогично...
9 Кб, 317x153>>53589
Оооокееей, эти две проблемы я внезапно решил, случайно обнаружив параметр safe_margin, который по сути заставляет Kinetic_Body останавливаться раньше, чем Rigid_Body детектит столкновение с ним, если я правильно понимаю.
Остаётся только понять, как исправить это -
Но это по крайней мере можно закостылить RayCast'ами, хоть я и хотел бы более простое решение...
>- расторможенные RigidBody пинаются;
>- автомобили пинаются вообще всегда;
Оооокееей, эти две проблемы я внезапно решил, случайно обнаружив параметр safe_margin, который по сути заставляет Kinetic_Body останавливаться раньше, чем Rigid_Body детектит столкновение с ним, если я правильно понимаю.
Остаётся только понять, как исправить это -
>- на наклонных плоскостях соскальзывает;
>- на маленьких бордюрах подпрыгивает.
Но это по крайней мере можно закостылить RayCast'ами, хоть я и хотел бы более простое решение...
>>53590
Погугли "godot платформер", я точно помню, как видел где-то решение соскальзывающего персонажа.
Погугли "godot платформер", я точно помню, как видел где-то решение соскальзывающего персонажа.
>>53597
В предыдущей версии контроллера у меня оно уже решалось как-то. Скорее всего потому, что я занулял скорость по Y, если был контакт с землёй, а тут я сделал так, как сделано в других контроллерах - вместо зануления вручную, сохраняю ответ move_and_slide(), она сама зануляет Y если персонаж ударился о поверхность. Так вот если занулять Y, то персонаж будет стоять на наклонной поверхности как на ровной, а если не занулять, то move_and_slide() будет делать микроскопические скачки, которые выглядят как скольжение. Один из аргументов должен предотвращать скольжение, но он почему-то не работает.
Я уже смотрел несколько вариантов контроллера в сети (вроде 3), они все такие разные (и при этом не учитывают такие сложные ситуации)...
Но больше всего мне непонятно сейчас, почему персонаж начал ПОДСКАКИВАТЬ на бордюрах. Раньше он либо забирался плавно, либо вообще не мог забраться, а сейчас он взлетает в воздух и приземляется на бордюр, если хватает инерции. Вроде бы это появилось после того, как я снизил сопротивление воздуха, то есть уменьшил торможение, когда нет контакта с землёй - но проблема в том, что если я увеличу это сопротивление, будет невозможно делать длинные прыжки, только прыжки на месте. Костылировать каждый такой случай рейкастами совсем не хочется... Хотя, наверное, правильнее всего будет делать "шаг вверх" при обнаружении относительно низкого препятствия, ведь в реале люди шагают, а не скользят, лол.
В предыдущей версии контроллера у меня оно уже решалось как-то. Скорее всего потому, что я занулял скорость по Y, если был контакт с землёй, а тут я сделал так, как сделано в других контроллерах - вместо зануления вручную, сохраняю ответ move_and_slide(), она сама зануляет Y если персонаж ударился о поверхность. Так вот если занулять Y, то персонаж будет стоять на наклонной поверхности как на ровной, а если не занулять, то move_and_slide() будет делать микроскопические скачки, которые выглядят как скольжение. Один из аргументов должен предотвращать скольжение, но он почему-то не работает.
Я уже смотрел несколько вариантов контроллера в сети (вроде 3), они все такие разные (и при этом не учитывают такие сложные ситуации)...
Но больше всего мне непонятно сейчас, почему персонаж начал ПОДСКАКИВАТЬ на бордюрах. Раньше он либо забирался плавно, либо вообще не мог забраться, а сейчас он взлетает в воздух и приземляется на бордюр, если хватает инерции. Вроде бы это появилось после того, как я снизил сопротивление воздуха, то есть уменьшил торможение, когда нет контакта с землёй - но проблема в том, что если я увеличу это сопротивление, будет невозможно делать длинные прыжки, только прыжки на месте. Костылировать каждый такой случай рейкастами совсем не хочется... Хотя, наверное, правильнее всего будет делать "шаг вверх" при обнаружении относительно низкого препятствия, ведь в реале люди шагают, а не скользят, лол.
32 Кб, 719x197Не помню где, но где-то прочитал, что чтобы код и сцены были модульными, в коде нельзя обращаться к нодам-родителям, только к нодам-потомкам. Хочу следовать этому правилу, но на практике вижу, что это не всегда удобно. Для примера, я сделал сцену OrbitCamera и скрипт OrbitCamera, теперь мне достаточно накинуть эту сцену на любую ноду, чтобы у меня получилась адекватно управляемая мышью орбитальная камера с несколькими полезными настройками. Однако, мне от этой камеры нужно, чтобы она дублировала своё вращение по Y на объект, к которому прицеплена - в частности, на персонажа игрока. Да, я действительно могу корректировать вращение персонажа по положению камеры, но это будет выглядеть некрасиво и может вызвать трудности, тем более что такой код придётся писать для любого объекта, которому нужно вращаться камерой по Y. Поэтому сейчас моя камера вращает персонажа, а не наоборот, но это нарушает описанный выше принцип. Менять это или нет? Так-то конкретно эта камера никогда не будет самостоятельной, у неё всегда должен быть parent, вокруг которого она вращается...
>>53660
Ну он же у тебя технически скользит, а не ходит. Вот его, как на рампе, и подкидывает.И да, просто "шаг вверх" будет хорошим решением, ящитаю.
>Но больше всего мне непонятно сейчас, почему персонаж начал ПОДСКАКИВАТЬ на бордюрах
Ну он же у тебя технически скользит, а не ходит. Вот его, как на рампе, и подкидывает.И да, просто "шаг вверх" будет хорошим решением, ящитаю.
>>53421
В казаках было 7 тысяч юнитов на 1 экране. Хочу 9 тысяч юнитов на 1 экране. По факту выйдет меньше, но да хер с ним, процессор сожрет что-то другое.
В казаках было 7 тысяч юнитов на 1 экране. Хочу 9 тысяч юнитов на 1 экране. По факту выйдет меньше, но да хер с ним, процессор сожрет что-то другое.
>>53700
Сигналы. Сигналы решают эту проблему.
Либо ты должен описать вращение в персонаже, и передавать его на камеру.
А ещё можно сделать роутинг через синглтон. Но это легкая дичь, которую я использую только для быстрого поиска менеджеров в проекте.
Сигналы. Сигналы решают эту проблему.
Либо ты должен описать вращение в персонаже, и передавать его на камеру.
А ещё можно сделать роутинг через синглтон. Но это легкая дичь, которую я использую только для быстрого поиска менеджеров в проекте.
>>54231
Покажи. Такое чувство что это бред рекламщиков из игровых журналов
>В казаках было 7 тысяч юнитов на 1 экране.
Покажи. Такое чувство что это бред рекламщиков из игровых журналов
>>54233
Что тебе показывать? Возьми да установи. Поставь 7 тысяч юнитов и они без лагов дойдут куда угодно.
Что тебе показывать? Возьми да установи. Поставь 7 тысяч юнитов и они без лагов дойдут куда угодно.
8 Кб, 370x81>>54232
Я не разобрался, по-моему биндинг сигналов какой-то мудрёный. Да и посылать сигнал практически каждый кадр?
Изначально так и было, но я решил абстрагировать камеру, чтобы облегчить персонажа.
В общем, всё оказалось намного проще и компактнее, см. скрин. :D
Персонаж сам себя вращает по камере, когда хочет, а камера теперь не сможет никого вращать.
>>53903
Пытаюсь так сделать, но чёт не выходит. Задолбался в очередной раз...
>Сигналы. Сигналы решают эту проблему.
Я не разобрался, по-моему биндинг сигналов какой-то мудрёный. Да и посылать сигнал практически каждый кадр?
>Либо ты должен описать вращение в персонаже, и передавать его на камеру.
Изначально так и было, но я решил абстрагировать камеру, чтобы облегчить персонажа.
В общем, всё оказалось намного проще и компактнее, см. скрин. :D
Персонаж сам себя вращает по камере, когда хочет, а камера теперь не сможет никого вращать.
>>53903
>И да, просто "шаг вверх" будет хорошим решением, ящитаю.
Пытаюсь так сделать, но чёт не выходит. Задолбался в очередной раз...
346 Кб, 1280x720>>54233
Там можно устроить месиво из пикселей, как я понимаю.
>>54240
Ты это цветное месиво называешь "7 тысяч юнитов"?
Теоретически, можно соединять все эти спрайты на процессоре, видеокарте тут нечего делать вообще.
Но, конечно, это будет проще реализовать на каком-нибудь Ассемблере, чем прикручивать к Годо или другому движку.
Там можно устроить месиво из пикселей, как я понимаю.
>>54240
>Поставь 7 тысяч юнитов и они без лагов дойдут куда угодно
Ты это цветное месиво называешь "7 тысяч юнитов"?
Теоретически, можно соединять все эти спрайты на процессоре, видеокарте тут нечего делать вообще.
Но, конечно, это будет проще реализовать на каком-нибудь Ассемблере, чем прикручивать к Годо или другому движку.
113 Кб, 642x507>>54231
Движки общего назначения не подходят для создания игр не общего назначения, без жесткого допиливания напильником их недр.
Тут просто тонко настраивают отрисовку объектов, а не делают в лоб. Например, вот, на картинке 216к кубов одновременно в кадре выдают на некроноуте 30 фпс.
Так что тебе или лезть в ядро любого такого движка или накидать свое решение или прикрепить свое решение к движку в виде модуля.
Движки общего назначения не подходят для создания игр не общего назначения, без жесткого допиливания напильником их недр.
Тут просто тонко настраивают отрисовку объектов, а не делают в лоб. Например, вот, на картинке 216к кубов одновременно в кадре выдают на некроноуте 30 фпс.
Так что тебе или лезть в ядро любого такого движка или накидать свое решение или прикрепить свое решение к движку в виде модуля.
>>53700
Глупости. Допустим, тебе нужен универсальный компонент, работающий только с кинематиками, а если ты про запарке его закинул в ноду иного класса, он должен это детектить и деактивироваться. Возможно даже с ассертом. И ты просто создаёшь переменную var body : KinematicBody и в ready пишешь такой код:
if get_parent() is KinematicBody:
body = get_parent()
else:
assert(true)
print("This component function only as KB child")
set_process(false)
И всё, у тебя универсальный компонент, с которым невозможно ошибиться. Он не даст тебе нормально работать в случае неправильного размещения в дереве.
Таким образом ты можешь внести логику движения в отдельные компоненты и переключать функционал путём динамического удаления и добавления компонентов. По земле персонаж бежит когда у него компонент walk.gd, по воде плывет, когда swim.gd, а если тебе надо переключаться между персонажами, то ты вешаешь на персонажей ai.gd
А управляет переключением компонентов разумеется стейтмашина, конечный автомат.
> Не помню где, но где-то прочитал, что чтобы код и сцены были модульными, в коде нельзя обращаться к нодам-родителям, только к нодам-потомкам.
Глупости. Допустим, тебе нужен универсальный компонент, работающий только с кинематиками, а если ты про запарке его закинул в ноду иного класса, он должен это детектить и деактивироваться. Возможно даже с ассертом. И ты просто создаёшь переменную var body : KinematicBody и в ready пишешь такой код:
if get_parent() is KinematicBody:
body = get_parent()
else:
assert(true)
print("This component function only as KB child")
set_process(false)
И всё, у тебя универсальный компонент, с которым невозможно ошибиться. Он не даст тебе нормально работать в случае неправильного размещения в дереве.
Таким образом ты можешь внести логику движения в отдельные компоненты и переключать функционал путём динамического удаления и добавления компонентов. По земле персонаж бежит когда у него компонент walk.gd, по воде плывет, когда swim.gd, а если тебе надо переключаться между персонажами, то ты вешаешь на персонажей ai.gd
А управляет переключением компонентов разумеется стейтмашина, конечный автомат.
>>54270
Нет такого термина в проектировании ПО, это похоже на выдумку маркетологов. Если наше ПО что-то не умеет - это потому что оно "общего назначения".
>Движки общего назначения
Нет такого термина в проектировании ПО, это похоже на выдумку маркетологов. Если наше ПО что-то не умеет - это потому что оно "общего назначения".
>>54426
Из какой школы капчуешь?
Чем более общий алгоритм мы пишем, чем больше он предусматривает вариантов, настроек, проверок, тем больше он потребляет ресурсов. Это называется общим или обобщенным алгоритмом решения какой-либо задачи.
Из какой школы капчуешь?
Чем более общий алгоритм мы пишем, чем больше он предусматривает вариантов, настроек, проверок, тем больше он потребляет ресурсов. Это называется общим или обобщенным алгоритмом решения какой-либо задачи.
>>54426
Всё абсолютно наоборот. "Общего назначения" означает, что ПО буквально умеет "всего понемножку", из всех или большинства возможных областей применения. С одной стороны это хорошо, т.к. пользователь может изучить это ПО и не искать под каждую задачу специальное ПО, но с другой стороны "ПО общего назначения" не имеет специальных оптимизаций для конкретных ситуаций. "Специализированное ПО", напротив, умеет только что-то одно, но умеет это превосходно.
В случае Годо и 7к спрайтов: Годо оптимизирован для удобного дизайна и управления сценами, ты можешь практически одной мышкой, не притрагиваясь к клавиатуре, сделать прототип своей игры, и это применимо к большинству видов игр. Если бы Годо был оптимизирован под огромное количество однотипных данных, то вместо имеющегося удобства были бы очень неудобные инструменты, которые работают быстро, но раскрывают свой потенциал только на 5к+ одинаковых объектов.
Другими словами, Годо умеет очень многое, но тебе всё это не нужно. Ты сейчас можешь взять язык Си и написать очень примитивный игровой движок, который не будет уметь всего того, что умеет Годо, но благодаря своей специализации сможет рисовать сотни тысяч спрайтов - а тебе, как я вижу, кроме этого ничего больше и не нужно.
>>54410
Пример - KB-платформа и KB-персонаж, скрипт swim.gd случайно цепляется на платформу, платформа уплывает.
Мне кажется, или подключение/отключение компонентов в случае бега/плавания - это немного лишнее? Ведь персонаж по идее всегда умеет бегать и плавать, а не только когда находится в воде... Можно же просто добавить процедуры:
if in_water():
swim()
else:
walk()
Хотя да, так труднее будет дизайнить инвалидов))
Да и меня вот смущает, что я не могу накинуть несколько скриптов на одну ноду, мне этот swim.gd на Node-пустышку вешать что ли?
Если бы я делал компоненты, я бы сделал так:
- нода, которая ждёт компоненты, имеет в update код типа:
for component in components:
component.tick(self)
- нода, которая хочет быть компонентом, имеет метод tick(), в котором делает полезную работу;
- метод tick() принимает ноду, с которой нужно работать, получая доступ к её редактированию;
- расположение компонента и подключающей его к себе ноде не имеет значения.
Т.о. можно создать только один swim.gd, а все персонажи, которые хотят плавать, будут делать swim.tick(self).
Правда, это не решает вопроса уникальных переменных...
Вообще, в Ъ-ECS компонент swim был бы всего лишь флажком или набором переменных, означающим, что конкретную сущность нужно передать в систему плавания, которая будет плыть эту сущность так, как посчитает нужным. Но на Godot, конечно, надстраивать полноценную ECS смысла нет, я полагаю...
>Если наше ПО что-то не умеет - это потому что оно "общего назначения".
Всё абсолютно наоборот. "Общего назначения" означает, что ПО буквально умеет "всего понемножку", из всех или большинства возможных областей применения. С одной стороны это хорошо, т.к. пользователь может изучить это ПО и не искать под каждую задачу специальное ПО, но с другой стороны "ПО общего назначения" не имеет специальных оптимизаций для конкретных ситуаций. "Специализированное ПО", напротив, умеет только что-то одно, но умеет это превосходно.
В случае Годо и 7к спрайтов: Годо оптимизирован для удобного дизайна и управления сценами, ты можешь практически одной мышкой, не притрагиваясь к клавиатуре, сделать прототип своей игры, и это применимо к большинству видов игр. Если бы Годо был оптимизирован под огромное количество однотипных данных, то вместо имеющегося удобства были бы очень неудобные инструменты, которые работают быстро, но раскрывают свой потенциал только на 5к+ одинаковых объектов.
Другими словами, Годо умеет очень многое, но тебе всё это не нужно. Ты сейчас можешь взять язык Си и написать очень примитивный игровой движок, который не будет уметь всего того, что умеет Годо, но благодаря своей специализации сможет рисовать сотни тысяч спрайтов - а тебе, как я вижу, кроме этого ничего больше и не нужно.
>>54410
>Он не даст тебе нормально работать в случае неправильного размещения в дереве.
Пример - KB-платформа и KB-персонаж, скрипт swim.gd случайно цепляется на платформу, платформа уплывает.
>По земле персонаж бежит когда у него компонент walk.gd, по воде плывет, когда swim.gd
Мне кажется, или подключение/отключение компонентов в случае бега/плавания - это немного лишнее? Ведь персонаж по идее всегда умеет бегать и плавать, а не только когда находится в воде... Можно же просто добавить процедуры:
if in_water():
swim()
else:
walk()
Хотя да, так труднее будет дизайнить инвалидов))
Да и меня вот смущает, что я не могу накинуть несколько скриптов на одну ноду, мне этот swim.gd на Node-пустышку вешать что ли?
Если бы я делал компоненты, я бы сделал так:
- нода, которая ждёт компоненты, имеет в update код типа:
for component in components:
component.tick(self)
- нода, которая хочет быть компонентом, имеет метод tick(), в котором делает полезную работу;
- метод tick() принимает ноду, с которой нужно работать, получая доступ к её редактированию;
- расположение компонента и подключающей его к себе ноде не имеет значения.
Т.о. можно создать только один swim.gd, а все персонажи, которые хотят плавать, будут делать swim.tick(self).
Правда, это не решает вопроса уникальных переменных...
Вообще, в Ъ-ECS компонент swim был бы всего лишь флажком или набором переменных, означающим, что конкретную сущность нужно передать в систему плавания, которая будет плыть эту сущность так, как посчитает нужным. Но на Godot, конечно, надстраивать полноценную ECS смысла нет, я полагаю...
>>54426
Всё абсолютно наоборот. "Общего назначения" означает, что ПО буквально умеет "всего понемножку", из всех или большинства возможных областей применения. С одной стороны это хорошо, т.к. пользователь может изучить это ПО и не искать под каждую задачу специальное ПО, но с другой стороны "ПО общего назначения" не имеет специальных оптимизаций для конкретных ситуаций. "Специализированное ПО", напротив, умеет только что-то одно, но умеет это превосходно.
В случае Годо и 7к спрайтов: Годо оптимизирован для удобного дизайна и управления сценами, ты можешь практически одной мышкой, не притрагиваясь к клавиатуре, сделать прототип своей игры, и это применимо к большинству видов игр. Если бы Годо был оптимизирован под огромное количество однотипных данных, то вместо имеющегося удобства были бы очень неудобные инструменты, которые работают быстро, но раскрывают свой потенциал только на 5к+ одинаковых объектов.
Другими словами, Годо умеет очень многое, но тебе всё это не нужно. Ты сейчас можешь взять язык Си и написать очень примитивный игровой движок, который не будет уметь всего того, что умеет Годо, но благодаря своей специализации сможет рисовать сотни тысяч спрайтов - а тебе, как я вижу, кроме этого ничего больше и не нужно.
>>54410
Пример - KB-платформа и KB-персонаж, скрипт swim.gd случайно цепляется на платформу, платформа уплывает.
Мне кажется, или подключение/отключение компонентов в случае бега/плавания - это немного лишнее? Ведь персонаж по идее всегда умеет бегать и плавать, а не только когда находится в воде... Можно же просто добавить процедуры:
if in_water():
swim()
else:
walk()
Хотя да, так труднее будет дизайнить инвалидов))
Да и меня вот смущает, что я не могу накинуть несколько скриптов на одну ноду, мне этот swim.gd на Node-пустышку вешать что ли?
Если бы я делал компоненты, я бы сделал так:
- нода, которая ждёт компоненты, имеет в update код типа:
for component in components:
component.tick(self)
- нода, которая хочет быть компонентом, имеет метод tick(), в котором делает полезную работу;
- метод tick() принимает ноду, с которой нужно работать, получая доступ к её редактированию;
- расположение компонента и подключающей его к себе ноде не имеет значения.
Т.о. можно создать только один swim.gd, а все персонажи, которые хотят плавать, будут делать swim.tick(self).
Правда, это не решает вопроса уникальных переменных...
Вообще, в Ъ-ECS компонент swim был бы всего лишь флажком или набором переменных, означающим, что конкретную сущность нужно передать в систему плавания, которая будет плыть эту сущность так, как посчитает нужным. Но на Godot, конечно, надстраивать полноценную ECS смысла нет, я полагаю...
>Если наше ПО что-то не умеет - это потому что оно "общего назначения".
Всё абсолютно наоборот. "Общего назначения" означает, что ПО буквально умеет "всего понемножку", из всех или большинства возможных областей применения. С одной стороны это хорошо, т.к. пользователь может изучить это ПО и не искать под каждую задачу специальное ПО, но с другой стороны "ПО общего назначения" не имеет специальных оптимизаций для конкретных ситуаций. "Специализированное ПО", напротив, умеет только что-то одно, но умеет это превосходно.
В случае Годо и 7к спрайтов: Годо оптимизирован для удобного дизайна и управления сценами, ты можешь практически одной мышкой, не притрагиваясь к клавиатуре, сделать прототип своей игры, и это применимо к большинству видов игр. Если бы Годо был оптимизирован под огромное количество однотипных данных, то вместо имеющегося удобства были бы очень неудобные инструменты, которые работают быстро, но раскрывают свой потенциал только на 5к+ одинаковых объектов.
Другими словами, Годо умеет очень многое, но тебе всё это не нужно. Ты сейчас можешь взять язык Си и написать очень примитивный игровой движок, который не будет уметь всего того, что умеет Годо, но благодаря своей специализации сможет рисовать сотни тысяч спрайтов - а тебе, как я вижу, кроме этого ничего больше и не нужно.
>>54410
>Он не даст тебе нормально работать в случае неправильного размещения в дереве.
Пример - KB-платформа и KB-персонаж, скрипт swim.gd случайно цепляется на платформу, платформа уплывает.
>По земле персонаж бежит когда у него компонент walk.gd, по воде плывет, когда swim.gd
Мне кажется, или подключение/отключение компонентов в случае бега/плавания - это немного лишнее? Ведь персонаж по идее всегда умеет бегать и плавать, а не только когда находится в воде... Можно же просто добавить процедуры:
if in_water():
swim()
else:
walk()
Хотя да, так труднее будет дизайнить инвалидов))
Да и меня вот смущает, что я не могу накинуть несколько скриптов на одну ноду, мне этот swim.gd на Node-пустышку вешать что ли?
Если бы я делал компоненты, я бы сделал так:
- нода, которая ждёт компоненты, имеет в update код типа:
for component in components:
component.tick(self)
- нода, которая хочет быть компонентом, имеет метод tick(), в котором делает полезную работу;
- метод tick() принимает ноду, с которой нужно работать, получая доступ к её редактированию;
- расположение компонента и подключающей его к себе ноде не имеет значения.
Т.о. можно создать только один swim.gd, а все персонажи, которые хотят плавать, будут делать swim.tick(self).
Правда, это не решает вопроса уникальных переменных...
Вообще, в Ъ-ECS компонент swim был бы всего лишь флажком или набором переменных, означающим, что конкретную сущность нужно передать в систему плавания, которая будет плыть эту сущность так, как посчитает нужным. Но на Godot, конечно, надстраивать полноценную ECS смысла нет, я полагаю...
>>54498
Всегда есть смысл надстраивать полноценную ецс. Вопрос личного удобства.
Всегда есть смысл надстраивать полноценную ецс. Вопрос личного удобства.
Как у годота с многопотоком? Есть ли он из-коробки или нужно пилить самому?
Есть один сетевой 3д проект для своих нужд, успел уже сделать редактор уровней (алсо записываю все уровни в свой васянский формат), но теперь думаю как оптимизировать все это.
Есть один сетевой 3д проект для своих нужд, успел уже сделать редактор уровней (алсо записываю все уровни в свой васянский формат), но теперь думаю как оптимизировать все это.
>>54586
Многопоток есть. Ограничения типичные для многопотока. Луркай мор.
Многопоток есть. Ограничения типичные для многопотока. Луркай мор.
Короч решил попробовать ноду Navigation, туториалов в официальных доках конечно же не нашёл, решил сделать по интуиции, но что-то я не понимаю, как заставить эту ноду видеть статикбоди и вообще хоть что-то кроме её навмеша.
На первой картинке: бот запрашивает маршрут от своей позиции к нужной ему, но маршрут строится напрямую через две точки. Навмеш представляет собой коробку 10x2x10, создал из простого растянутого меша-куба. Учитывая то, что сдвиг навмеша в сторону обрывает путь на краю навмеша, я полагаю, что дырка в навмеше должна вызвать построение пути в обход дырки? Но если это так, то я должен вручную делать дырки в навмешах? Я рассчитывал, что он будет как-то сам цеплять хотя бы окружающие статикбоди, но он их не видит, даже если удочерять статикбоди от навмеша или ноды Navigation. Странно.
А вот на второй картинке натуральный баг. Если бот запрашивает путь из точки (0, 0, 0), то Navigation почему-то посылает сначала на угол своего навмеша, а только потом - на конечную точку. Я пробовал смещать бота на (0.1, 0, 0) и (0, 0, -1) - любое смещение от нулевой точки исправляет проблему, т.е. маршрут строится по прямой, но нельзя же предугадать, что бот никогда не наступит на точку (0, 0, 0) во время игры? В реальной игре это может вызвать очень неприятные последствия (у меня тут бот срывался в пропасть, пока я не расширил тестовый полигон, чтобы убедиться, что он потом вернётся)...
Собсна баг смутил даже больше, чем то, что навмеш почему-то не видит статикбоди. Кстати, для чего кнопка "запечь навмеш"? Я её нажал - навмеш просто пропал (лол), пришлось создавать его заново из той коробки.
Вообще, пробую эти навмеши чисто из любопытства, т.к. скорее всего навигацию придётся самому велосипедить. Просто думалось, что навмеш реально может помочь обходить препятствия, но тут чёт проблем ещё больше(
Планирую сделать как-то так:
- есть карта, она по большому счёту никак не меняется (кроме машинок и прочих ригидбоди);
- по карте расставлены т.н. "зоны интереса" и "вейпойнты" - точки, по которым боты ходят;
- когда боту нужно в какую-то зону интереса, скрипт строит маршрут по набору вейпойнтов;
- если бот на пути к вейпойнту видит препятствие, он пытается сам обойти его по кругу;
- боты, находящиеся далеко от игрока, телепортируются от вейпойнта к вейпойнту.
Ну, не телепортируются, а скорее симулируются отдельным фоновым кодом, который планирую прицепить к Godot через GDNative, а уже игровые скрипты запрашивают актуальную позицию ботов у этого кода, когда приходит пора отобразить ближайших к игроку ботов. Следовательно, навмеш мог бы пригодиться только в момент обхода ботом препятствия между двумя вейпойнтами, и то - только когда этот конкретный бот находится поблизости от игрока. Поэтому сильно сомневаюсь, а нужно ли мне вообще возиться с системой навигации Годо, или так обойдусь? Разве что с обходом сложных препятствий проблемы могут возникнуть, но с этими сложными препятствиями ещё нужно столкнуться...
На первой картинке: бот запрашивает маршрут от своей позиции к нужной ему, но маршрут строится напрямую через две точки. Навмеш представляет собой коробку 10x2x10, создал из простого растянутого меша-куба. Учитывая то, что сдвиг навмеша в сторону обрывает путь на краю навмеша, я полагаю, что дырка в навмеше должна вызвать построение пути в обход дырки? Но если это так, то я должен вручную делать дырки в навмешах? Я рассчитывал, что он будет как-то сам цеплять хотя бы окружающие статикбоди, но он их не видит, даже если удочерять статикбоди от навмеша или ноды Navigation. Странно.
А вот на второй картинке натуральный баг. Если бот запрашивает путь из точки (0, 0, 0), то Navigation почему-то посылает сначала на угол своего навмеша, а только потом - на конечную точку. Я пробовал смещать бота на (0.1, 0, 0) и (0, 0, -1) - любое смещение от нулевой точки исправляет проблему, т.е. маршрут строится по прямой, но нельзя же предугадать, что бот никогда не наступит на точку (0, 0, 0) во время игры? В реальной игре это может вызвать очень неприятные последствия (у меня тут бот срывался в пропасть, пока я не расширил тестовый полигон, чтобы убедиться, что он потом вернётся)...
Собсна баг смутил даже больше, чем то, что навмеш почему-то не видит статикбоди. Кстати, для чего кнопка "запечь навмеш"? Я её нажал - навмеш просто пропал (лол), пришлось создавать его заново из той коробки.
Вообще, пробую эти навмеши чисто из любопытства, т.к. скорее всего навигацию придётся самому велосипедить. Просто думалось, что навмеш реально может помочь обходить препятствия, но тут чёт проблем ещё больше(
Планирую сделать как-то так:
- есть карта, она по большому счёту никак не меняется (кроме машинок и прочих ригидбоди);
- по карте расставлены т.н. "зоны интереса" и "вейпойнты" - точки, по которым боты ходят;
- когда боту нужно в какую-то зону интереса, скрипт строит маршрут по набору вейпойнтов;
- если бот на пути к вейпойнту видит препятствие, он пытается сам обойти его по кругу;
- боты, находящиеся далеко от игрока, телепортируются от вейпойнта к вейпойнту.
Ну, не телепортируются, а скорее симулируются отдельным фоновым кодом, который планирую прицепить к Godot через GDNative, а уже игровые скрипты запрашивают актуальную позицию ботов у этого кода, когда приходит пора отобразить ближайших к игроку ботов. Следовательно, навмеш мог бы пригодиться только в момент обхода ботом препятствия между двумя вейпойнтами, и то - только когда этот конкретный бот находится поблизости от игрока. Поэтому сильно сомневаюсь, а нужно ли мне вообще возиться с системой навигации Годо, или так обойдусь? Разве что с обходом сложных препятствий проблемы могут возникнуть, но с этими сложными препятствиями ещё нужно столкнуться...
Короч решил попробовать ноду Navigation, туториалов в официальных доках конечно же не нашёл, решил сделать по интуиции, но что-то я не понимаю, как заставить эту ноду видеть статикбоди и вообще хоть что-то кроме её навмеша.
На первой картинке: бот запрашивает маршрут от своей позиции к нужной ему, но маршрут строится напрямую через две точки. Навмеш представляет собой коробку 10x2x10, создал из простого растянутого меша-куба. Учитывая то, что сдвиг навмеша в сторону обрывает путь на краю навмеша, я полагаю, что дырка в навмеше должна вызвать построение пути в обход дырки? Но если это так, то я должен вручную делать дырки в навмешах? Я рассчитывал, что он будет как-то сам цеплять хотя бы окружающие статикбоди, но он их не видит, даже если удочерять статикбоди от навмеша или ноды Navigation. Странно.
А вот на второй картинке натуральный баг. Если бот запрашивает путь из точки (0, 0, 0), то Navigation почему-то посылает сначала на угол своего навмеша, а только потом - на конечную точку. Я пробовал смещать бота на (0.1, 0, 0) и (0, 0, -1) - любое смещение от нулевой точки исправляет проблему, т.е. маршрут строится по прямой, но нельзя же предугадать, что бот никогда не наступит на точку (0, 0, 0) во время игры? В реальной игре это может вызвать очень неприятные последствия (у меня тут бот срывался в пропасть, пока я не расширил тестовый полигон, чтобы убедиться, что он потом вернётся)...
Собсна баг смутил даже больше, чем то, что навмеш почему-то не видит статикбоди. Кстати, для чего кнопка "запечь навмеш"? Я её нажал - навмеш просто пропал (лол), пришлось создавать его заново из той коробки.
Вообще, пробую эти навмеши чисто из любопытства, т.к. скорее всего навигацию придётся самому велосипедить. Просто думалось, что навмеш реально может помочь обходить препятствия, но тут чёт проблем ещё больше(
Планирую сделать как-то так:
- есть карта, она по большому счёту никак не меняется (кроме машинок и прочих ригидбоди);
- по карте расставлены т.н. "зоны интереса" и "вейпойнты" - точки, по которым боты ходят;
- когда боту нужно в какую-то зону интереса, скрипт строит маршрут по набору вейпойнтов;
- если бот на пути к вейпойнту видит препятствие, он пытается сам обойти его по кругу;
- боты, находящиеся далеко от игрока, телепортируются от вейпойнта к вейпойнту.
Ну, не телепортируются, а скорее симулируются отдельным фоновым кодом, который планирую прицепить к Godot через GDNative, а уже игровые скрипты запрашивают актуальную позицию ботов у этого кода, когда приходит пора отобразить ближайших к игроку ботов. Следовательно, навмеш мог бы пригодиться только в момент обхода ботом препятствия между двумя вейпойнтами, и то - только когда этот конкретный бот находится поблизости от игрока. Поэтому сильно сомневаюсь, а нужно ли мне вообще возиться с системой навигации Годо, или так обойдусь? Разве что с обходом сложных препятствий проблемы могут возникнуть, но с этими сложными препятствиями ещё нужно столкнуться...
На первой картинке: бот запрашивает маршрут от своей позиции к нужной ему, но маршрут строится напрямую через две точки. Навмеш представляет собой коробку 10x2x10, создал из простого растянутого меша-куба. Учитывая то, что сдвиг навмеша в сторону обрывает путь на краю навмеша, я полагаю, что дырка в навмеше должна вызвать построение пути в обход дырки? Но если это так, то я должен вручную делать дырки в навмешах? Я рассчитывал, что он будет как-то сам цеплять хотя бы окружающие статикбоди, но он их не видит, даже если удочерять статикбоди от навмеша или ноды Navigation. Странно.
А вот на второй картинке натуральный баг. Если бот запрашивает путь из точки (0, 0, 0), то Navigation почему-то посылает сначала на угол своего навмеша, а только потом - на конечную точку. Я пробовал смещать бота на (0.1, 0, 0) и (0, 0, -1) - любое смещение от нулевой точки исправляет проблему, т.е. маршрут строится по прямой, но нельзя же предугадать, что бот никогда не наступит на точку (0, 0, 0) во время игры? В реальной игре это может вызвать очень неприятные последствия (у меня тут бот срывался в пропасть, пока я не расширил тестовый полигон, чтобы убедиться, что он потом вернётся)...
Собсна баг смутил даже больше, чем то, что навмеш почему-то не видит статикбоди. Кстати, для чего кнопка "запечь навмеш"? Я её нажал - навмеш просто пропал (лол), пришлось создавать его заново из той коробки.
Вообще, пробую эти навмеши чисто из любопытства, т.к. скорее всего навигацию придётся самому велосипедить. Просто думалось, что навмеш реально может помочь обходить препятствия, но тут чёт проблем ещё больше(
Планирую сделать как-то так:
- есть карта, она по большому счёту никак не меняется (кроме машинок и прочих ригидбоди);
- по карте расставлены т.н. "зоны интереса" и "вейпойнты" - точки, по которым боты ходят;
- когда боту нужно в какую-то зону интереса, скрипт строит маршрут по набору вейпойнтов;
- если бот на пути к вейпойнту видит препятствие, он пытается сам обойти его по кругу;
- боты, находящиеся далеко от игрока, телепортируются от вейпойнта к вейпойнту.
Ну, не телепортируются, а скорее симулируются отдельным фоновым кодом, который планирую прицепить к Godot через GDNative, а уже игровые скрипты запрашивают актуальную позицию ботов у этого кода, когда приходит пора отобразить ближайших к игроку ботов. Следовательно, навмеш мог бы пригодиться только в момент обхода ботом препятствия между двумя вейпойнтами, и то - только когда этот конкретный бот находится поблизости от игрока. Поэтому сильно сомневаюсь, а нужно ли мне вообще возиться с системой навигации Годо, или так обойдусь? Разве что с обходом сложных препятствий проблемы могут возникнуть, но с этими сложными препятствиями ещё нужно столкнуться...
>>54759
Самая писечка - это когда навмеш строится из блоков. Возьми гридмап для тридэ, засунь в него всего два блока: нав и ненав. В наве есть навмеш, в ненаве соответственно нетути.
Далее заполни все пространство карты блоками нав в гридмапе, а места под статики заполни блоками не_нав. И вот тебе навигация.
Главное чтобы границы навмеша в блоках гарантированно соприкасались, тогда нода навигации корректно соберёт общий навмеш из твоих блоков.
Самая писечка - это когда навмеш строится из блоков. Возьми гридмап для тридэ, засунь в него всего два блока: нав и ненав. В наве есть навмеш, в ненаве соответственно нетути.
Далее заполни все пространство карты блоками нав в гридмапе, а места под статики заполни блоками не_нав. И вот тебе навигация.
Главное чтобы границы навмеша в блоках гарантированно соприкасались, тогда нода навигации корректно соберёт общий навмеш из твоих блоков.
>>54767
Это какого ж размера должны быть ячейки гридмапа, если я не собираюсь делать кубические карты? То есть где-то препятствие будет условным "полублоком", где-то вообще один маленький столбик или деревце, где-то круглая клумба, а где-то стенка под углом к дороге. То есть с крупными ячейками будет много недочётов, а из мелких делать не вариант, их будет слишком много.
То есть в реалтайме статики вырезать нельзя? Получается в два раза больше работы - сначала расставить статики, а потом снова расставить их же, но на навмеше...
Я задумывал разрешить ботам ходить везде, где может ходить игрок, с поправкой на то, что они ориентируются на вейпойнты, которыми отмечены основные дороги (чтобы не пытались ломиться напролом, а шли по пешеходным дорожкам, по возможности возвращаясь к ним). Одна из проблем в том, что на пути ботов могут оказаться динамикбоди (куча автомобилей, к примеру), а другая - в том, что карта собирается в рантайме из заплаток-кварталов, соответственно покрывать всё это навмешем будет нерационально, мне кажется.
Пробую заюзать навмеш на случай, если он всё-таки пригодится, т.к. я мало что про него знаю. Так-то покрыть всё вейпойнтами не проблема (плюс должно быть удобно передавать их в dll-библиотеку); для обхода мелких препятствий собираюсь соорудить "зрение" ботам, будут пытаться обходить то, что попадает в конус Area, прицепленный к голове.
>Возьми гридмап для тридэ, засунь в него всего два блока: нав и ненав
Это какого ж размера должны быть ячейки гридмапа, если я не собираюсь делать кубические карты? То есть где-то препятствие будет условным "полублоком", где-то вообще один маленький столбик или деревце, где-то круглая клумба, а где-то стенка под углом к дороге. То есть с крупными ячейками будет много недочётов, а из мелких делать не вариант, их будет слишком много.
>места под статики заполни блоками не_нав
То есть в реалтайме статики вырезать нельзя? Получается в два раза больше работы - сначала расставить статики, а потом снова расставить их же, но на навмеше...
Я задумывал разрешить ботам ходить везде, где может ходить игрок, с поправкой на то, что они ориентируются на вейпойнты, которыми отмечены основные дороги (чтобы не пытались ломиться напролом, а шли по пешеходным дорожкам, по возможности возвращаясь к ним). Одна из проблем в том, что на пути ботов могут оказаться динамикбоди (куча автомобилей, к примеру), а другая - в том, что карта собирается в рантайме из заплаток-кварталов, соответственно покрывать всё это навмешем будет нерационально, мне кажется.
Пробую заюзать навмеш на случай, если он всё-таки пригодится, т.к. я мало что про него знаю. Так-то покрыть всё вейпойнтами не проблема (плюс должно быть удобно передавать их в dll-библиотеку); для обхода мелких препятствий собираюсь соорудить "зрение" ботам, будут пытаться обходить то, что попадает в конус Area, прицепленный к голове.
>>54769
Гридмап имеет все необходимые методы для динамического изменения в рантайме. Дырки в навмеше смогут себе вырезать и статики и боты.
Гридмап имеет все необходимые методы для динамического изменения в рантайме. Дырки в навмеше смогут себе вырезать и статики и боты.
13 Кб, 343x173>>54832
Навигация подразумевает ориентирование в пространстве, а зачем мне ориентироваться в пространстве, если там нет препятствий? Я думал, оно как-то само будет вычитать препятствия из путей...
В параметрах навмеша есть "Parsed Geometry Type", есть вариант "Static Colliders" - это разве не то?
Я пробовал переключать этот параметр, перемещать статик боди по дереву сцены - ноль реакции(
>>54833
Сколько это стоит по ресурсам? Как часто можно делать, чтобы всё не повесилось от 5+ объектов?
>это навигация, а не коллизии
Навигация подразумевает ориентирование в пространстве, а зачем мне ориентироваться в пространстве, если там нет препятствий? Я думал, оно как-то само будет вычитать препятствия из путей...
В параметрах навмеша есть "Parsed Geometry Type", есть вариант "Static Colliders" - это разве не то?
Я пробовал переключать этот параметр, перемещать статик боди по дереву сцены - ноль реакции(
>>54833
>Гридмап имеет все необходимые методы для динамического изменения в рантайме.
Сколько это стоит по ресурсам? Как часто можно делать, чтобы всё не повесилось от 5+ объектов?
>>54268
Нет, годо просто неоптимизирован, и посылает 7к запросов в opengl место одного.
> Годо оптимизирован для удобного дизайна и управления сценами, ты можешь практически одной мышкой, не притрагиваясь к клавиатуре
Нет, годо просто неоптимизирован, и посылает 7к запросов в opengl место одного.
>>54870
У меня температура 37, 5 и начала расти! Походу коронавирус подхватил. Не могу доползти до компа, чтобы накидать тебе проект-пример. Так что давай сам. Суть ты уловил как мне кажется. Тесты сам сделаешь.
Скажу вкратце.
Накидываешь поверх локации гридмап, заполняешь весь объем навами. Не_навы, которые я описал выше, не нужны, объекты будут просто задавать -1 для нужных ячеек, которые нужно вырезать из результирующего навмеша.
Далее. Уровнем выше должна быть нода Navigation, на всякий напоминаю.
У гридмапа есть функции, преобразующие глобальные координаты в координаты своей сетки и обратно. Это именно то, что нам нужно. Игровые объекты при своих перемещениях посылают периодически в гридмап такой запрос: по предыдущим своим координатам установить в совпадающих ячейках значение дефолт (которое ты задал при дизайне сцены) по текущим координатам задать значение -1.
Все. Имеем динамический навмеш, учитывающий как статики, так и динамики.
У меня температура 37, 5 и начала расти! Походу коронавирус подхватил. Не могу доползти до компа, чтобы накидать тебе проект-пример. Так что давай сам. Суть ты уловил как мне кажется. Тесты сам сделаешь.
Скажу вкратце.
Накидываешь поверх локации гридмап, заполняешь весь объем навами. Не_навы, которые я описал выше, не нужны, объекты будут просто задавать -1 для нужных ячеек, которые нужно вырезать из результирующего навмеша.
Далее. Уровнем выше должна быть нода Navigation, на всякий напоминаю.
У гридмапа есть функции, преобразующие глобальные координаты в координаты своей сетки и обратно. Это именно то, что нам нужно. Игровые объекты при своих перемещениях посылают периодически в гридмап такой запрос: по предыдущим своим координатам установить в совпадающих ячейках значение дефолт (которое ты задал при дизайне сцены) по текущим координатам задать значение -1.
Все. Имеем динамический навмеш, учитывающий как статики, так и динамики.
>>55185
Это-то понятно, как сделать. Я несколько дней назад уже тыкал гридмап, понимаю, о чём речь.
Проблемы использования навмеша в следующем:
- карта модульная, то есть собирается из кусочков в реалтайме;
- количество и состав модулей заранее неизвестен (я не определился пока);
- размеры карты могут быть большими (ну, допустим, карта города в GTA 3);
- часть модулей могут скрываться из дерева сцены (чанки-кварталы и комнаты в домах).
Даже если взять один гридмап с навмешами на весь город, и вырезать дырки модулями, то это всё равно будет сложно и неэффективно, как мне кажется. Кроме того, навмеш строит путь напрямик, через всё свободное пространство, а мне по идее нужно чтобы боты топали по дорожкам, возвращаясь к ним, если на что-то отвлеклись. Да и в случае "навмеша на всю карту" я не смогу перенести ИИ ботов во внешнюю библиотеку, буду привязан к навмешу Годо.
Я решил расставлять "вейпойнты", каждый из которых в _ready() добавляет себя в глобальное хранилище вейпойнтов (можно сделать иначе, не суть, нужен только один Vector3), а дальше бот запрашивает маршрут до интересующего его места у этого хранилища. Маршрут не предполагает динамические препятствия, он полагается на корректное расположение вейпойнтов внутри каждого модуля. Если у бота возникает на маршруте препятствие, он пытается его обойти (ориентируясь по коллизиям), если не удастся - строит новый маршрут по другим вейпойнтам. Смысл в том, что бот не знает заранее, встретит ли он препятствие на пути, тогда как навмеш заранее строит оптимальный маршрут; массив вейпойнтов - своего рода 3D карта города, где точками отмечены удобные для перемещения дороги, известные ботам, которые они "представляют в голове". Можно, например, скрывать часть вейпойнтов от отдельных ботов, чтобы они делали вид, что не знают дорогу до какого-то объекта.
Рассматривал возможность использовать навмеш на ближней дистанции, то есть на несколько метров возле бота, только чтобы обходить особо сложные препятствия... Кстати, а что будет, если нацепить Navigation на подвижную сущность? Мне даже не нужен полный путь, скорее направление на правильный путь (т.к. в любом случае полный путь может устареть)... Но я сомневаюсь, стоит ли оно того вообще. Мне хочется симуляцию поведения людей, а в жизни "навмешей" не бывает.
Да и, если честно, я уже сомневаюсь, хочу ли делать игру. Вряд ли получится нормальный ИИ даже в рамках игрового мира...
Это-то понятно, как сделать. Я несколько дней назад уже тыкал гридмап, понимаю, о чём речь.
Проблемы использования навмеша в следующем:
- карта модульная, то есть собирается из кусочков в реалтайме;
- количество и состав модулей заранее неизвестен (я не определился пока);
- размеры карты могут быть большими (ну, допустим, карта города в GTA 3);
- часть модулей могут скрываться из дерева сцены (чанки-кварталы и комнаты в домах).
Даже если взять один гридмап с навмешами на весь город, и вырезать дырки модулями, то это всё равно будет сложно и неэффективно, как мне кажется. Кроме того, навмеш строит путь напрямик, через всё свободное пространство, а мне по идее нужно чтобы боты топали по дорожкам, возвращаясь к ним, если на что-то отвлеклись. Да и в случае "навмеша на всю карту" я не смогу перенести ИИ ботов во внешнюю библиотеку, буду привязан к навмешу Годо.
Я решил расставлять "вейпойнты", каждый из которых в _ready() добавляет себя в глобальное хранилище вейпойнтов (можно сделать иначе, не суть, нужен только один Vector3), а дальше бот запрашивает маршрут до интересующего его места у этого хранилища. Маршрут не предполагает динамические препятствия, он полагается на корректное расположение вейпойнтов внутри каждого модуля. Если у бота возникает на маршруте препятствие, он пытается его обойти (ориентируясь по коллизиям), если не удастся - строит новый маршрут по другим вейпойнтам. Смысл в том, что бот не знает заранее, встретит ли он препятствие на пути, тогда как навмеш заранее строит оптимальный маршрут; массив вейпойнтов - своего рода 3D карта города, где точками отмечены удобные для перемещения дороги, известные ботам, которые они "представляют в голове". Можно, например, скрывать часть вейпойнтов от отдельных ботов, чтобы они делали вид, что не знают дорогу до какого-то объекта.
Рассматривал возможность использовать навмеш на ближней дистанции, то есть на несколько метров возле бота, только чтобы обходить особо сложные препятствия... Кстати, а что будет, если нацепить Navigation на подвижную сущность? Мне даже не нужен полный путь, скорее направление на правильный путь (т.к. в любом случае полный путь может устареть)... Но я сомневаюсь, стоит ли оно того вообще. Мне хочется симуляцию поведения людей, а в жизни "навмешей" не бывает.
Да и, если честно, я уже сомневаюсь, хочу ли делать игру. Вряд ли получится нормальный ИИ даже в рамках игрового мира...
>>55185
Это-то понятно, как сделать. Я несколько дней назад уже тыкал гридмап, понимаю, о чём речь.
Проблемы использования навмеша в следующем:
- карта модульная, то есть собирается из кусочков в реалтайме;
- количество и состав модулей заранее неизвестен (я не определился пока);
- размеры карты могут быть большими (ну, допустим, карта города в GTA 3);
- часть модулей могут скрываться из дерева сцены (чанки-кварталы и комнаты в домах).
Даже если взять один гридмап с навмешами на весь город, и вырезать дырки модулями, то это всё равно будет сложно и неэффективно, как мне кажется. Кроме того, навмеш строит путь напрямик, через всё свободное пространство, а мне по идее нужно чтобы боты топали по дорожкам, возвращаясь к ним, если на что-то отвлеклись. Да и в случае "навмеша на всю карту" я не смогу перенести ИИ ботов во внешнюю библиотеку, буду привязан к навмешу Годо.
Я решил расставлять "вейпойнты", каждый из которых в _ready() добавляет себя в глобальное хранилище вейпойнтов (можно сделать иначе, не суть, нужен только один Vector3), а дальше бот запрашивает маршрут до интересующего его места у этого хранилища. Маршрут не предполагает динамические препятствия, он полагается на корректное расположение вейпойнтов внутри каждого модуля. Если у бота возникает на маршруте препятствие, он пытается его обойти (ориентируясь по коллизиям), если не удастся - строит новый маршрут по другим вейпойнтам. Смысл в том, что бот не знает заранее, встретит ли он препятствие на пути, тогда как навмеш заранее строит оптимальный маршрут; массив вейпойнтов - своего рода 3D карта города, где точками отмечены удобные для перемещения дороги, известные ботам, которые они "представляют в голове". Можно, например, скрывать часть вейпойнтов от отдельных ботов, чтобы они делали вид, что не знают дорогу до какого-то объекта.
Рассматривал возможность использовать навмеш на ближней дистанции, то есть на несколько метров возле бота, только чтобы обходить особо сложные препятствия... Кстати, а что будет, если нацепить Navigation на подвижную сущность? Мне даже не нужен полный путь, скорее направление на правильный путь (т.к. в любом случае полный путь может устареть)... Но я сомневаюсь, стоит ли оно того вообще. Мне хочется симуляцию поведения людей, а в жизни "навмешей" не бывает.
Да и, если честно, я уже сомневаюсь, хочу ли делать игру. Вряд ли получится нормальный ИИ даже в рамках игрового мира...
Это-то понятно, как сделать. Я несколько дней назад уже тыкал гридмап, понимаю, о чём речь.
Проблемы использования навмеша в следующем:
- карта модульная, то есть собирается из кусочков в реалтайме;
- количество и состав модулей заранее неизвестен (я не определился пока);
- размеры карты могут быть большими (ну, допустим, карта города в GTA 3);
- часть модулей могут скрываться из дерева сцены (чанки-кварталы и комнаты в домах).
Даже если взять один гридмап с навмешами на весь город, и вырезать дырки модулями, то это всё равно будет сложно и неэффективно, как мне кажется. Кроме того, навмеш строит путь напрямик, через всё свободное пространство, а мне по идее нужно чтобы боты топали по дорожкам, возвращаясь к ним, если на что-то отвлеклись. Да и в случае "навмеша на всю карту" я не смогу перенести ИИ ботов во внешнюю библиотеку, буду привязан к навмешу Годо.
Я решил расставлять "вейпойнты", каждый из которых в _ready() добавляет себя в глобальное хранилище вейпойнтов (можно сделать иначе, не суть, нужен только один Vector3), а дальше бот запрашивает маршрут до интересующего его места у этого хранилища. Маршрут не предполагает динамические препятствия, он полагается на корректное расположение вейпойнтов внутри каждого модуля. Если у бота возникает на маршруте препятствие, он пытается его обойти (ориентируясь по коллизиям), если не удастся - строит новый маршрут по другим вейпойнтам. Смысл в том, что бот не знает заранее, встретит ли он препятствие на пути, тогда как навмеш заранее строит оптимальный маршрут; массив вейпойнтов - своего рода 3D карта города, где точками отмечены удобные для перемещения дороги, известные ботам, которые они "представляют в голове". Можно, например, скрывать часть вейпойнтов от отдельных ботов, чтобы они делали вид, что не знают дорогу до какого-то объекта.
Рассматривал возможность использовать навмеш на ближней дистанции, то есть на несколько метров возле бота, только чтобы обходить особо сложные препятствия... Кстати, а что будет, если нацепить Navigation на подвижную сущность? Мне даже не нужен полный путь, скорее направление на правильный путь (т.к. в любом случае полный путь может устареть)... Но я сомневаюсь, стоит ли оно того вообще. Мне хочется симуляцию поведения людей, а в жизни "навмешей" не бывает.
Да и, если честно, я уже сомневаюсь, хочу ли делать игру. Вряд ли получится нормальный ИИ даже в рамках игрового мира...
>>55232
Не вижу проблемы обновлять количество кубов навмешгрида. Просто бери и делай. Решай проблемы по мере поступления. У тебя игры ещё нет, а ты уже думаешь о том, как столкнешься с проблемами. Синдром умной Эльзы, не иначе.
Насчёт ИИ гугли GOAP все современные игры основаны на нем. Реалистичность поведения ботов опирается только на то, несколько грамотно и разнообразно ты создашь goals и actions для системы этой.
Всё, пока, убегаю, меня реанимация ждёт!
Не вижу проблемы обновлять количество кубов навмешгрида. Просто бери и делай. Решай проблемы по мере поступления. У тебя игры ещё нет, а ты уже думаешь о том, как столкнешься с проблемами. Синдром умной Эльзы, не иначе.
Насчёт ИИ гугли GOAP все современные игры основаны на нем. Реалистичность поведения ботов опирается только на то, несколько грамотно и разнообразно ты создашь goals и actions для системы этой.
Всё, пока, убегаю, меня реанимация ждёт!
Пытаюсь вкатиться в этот ваш Годо(т) с двадэ. Вопрос довольно специфичный, не нашёл на него ответа в интернетиках.
Итак, имеем тайлсет - картинку, нарисованную от руки, отсканированную, выровненную по горизонтали-вертикали и скормленную ноде TileMap. Если просто нарезать её на квадратики и расставлять какой-то один квадратик, получится некрасиво. Расставлять тайлы последовательно - долго и нудно, сетка довольно большая. Есть ли способ сделать так, чтобы тайлы из тайлсета расставлять в определённом порядке? Я нашёл только чтобы на границе тайлового скопления всегда появлялись определённые тайлы и чтобы тайлы чередовались с некоторой вероятностью.
И да, я ещё не искал, но всё же спрошу, раз уж пошла такая пьянка. С отдельными тайлами же можно как-то работать скриптами? Например, чтобы при попадании пули тайл "brick" превращался в "Brick damaged", а при попадании второй пули - в "brick broken", у которого уже нет коллизии и другой z-index.
Итак, имеем тайлсет - картинку, нарисованную от руки, отсканированную, выровненную по горизонтали-вертикали и скормленную ноде TileMap. Если просто нарезать её на квадратики и расставлять какой-то один квадратик, получится некрасиво. Расставлять тайлы последовательно - долго и нудно, сетка довольно большая. Есть ли способ сделать так, чтобы тайлы из тайлсета расставлять в определённом порядке? Я нашёл только чтобы на границе тайлового скопления всегда появлялись определённые тайлы и чтобы тайлы чередовались с некоторой вероятностью.
И да, я ещё не искал, но всё же спрошу, раз уж пошла такая пьянка. С отдельными тайлами же можно как-то работать скриптами? Например, чтобы при попадании пули тайл "brick" превращался в "Brick damaged", а при попадании второй пули - в "brick broken", у которого уже нет коллизии и другой z-index.
>>55288
По первому пункту гугли автотайл. Если я правильно понял. Будет тебе рисоваться автоматически поле из центральных тайлов, обрамлённое краевыми тайлами.
По второму пункту гугли map_to_world, world_to_map о чем говорилось выше но для тайлмапов все аналогично гридмапам. При коллизии физических тел движок даёт тебе координаты этой коллизии. Далее находишь координаты тайла и выставляешь желаемый индекс (индекс тайла с разбитым кирпичом) по известным тебе на этом этапе координатам можешь спавнить эффект разрушения с летящими в стороны осколками.
По первому пункту гугли автотайл. Если я правильно понял. Будет тебе рисоваться автоматически поле из центральных тайлов, обрамлённое краевыми тайлами.
По второму пункту гугли map_to_world, world_to_map о чем говорилось выше но для тайлмапов все аналогично гридмапам. При коллизии физических тел движок даёт тебе координаты этой коллизии. Далее находишь координаты тайла и выставляешь желаемый индекс (индекс тайла с разбитым кирпичом) по известным тебе на этом этапе координатам можешь спавнить эффект разрушения с летящими в стороны осколками.
>>55292
Я не он, но вижу, ты неправильно понял. У него тайлы нарисованы от руки, и поэтому если один и тот же квадратик повторять по сетке, видно сетку, а это некрасиво. Забыл, как называется этот эффект... И вот он хочет вместо одиночных тайлов лепить сразу группами типа 2x1 или 2x2, я так думаю. Хотя по-хорошему нужно просто тайлы заново перерисовать...
>>55288
Не знаю, как в Годо, не пользовался, но в Tiled и других тайловых редакторах для этого вроде можно выделить сразу несколько ближайших тайлов, чтобы лепить сразу группами типа 2x1, 2x2, 2x3, 3x3, 3x1 и т.п. Но всё-таки рекомендую перерисовать тайлы, если ты видишь чёткую сетку - значит, плохо нарисовал тайлы.
>Если я правильно понял. Будет тебе рисоваться автоматически поле из центральных тайлов, обрамлённое краевыми тайлами.
Я не он, но вижу, ты неправильно понял. У него тайлы нарисованы от руки, и поэтому если один и тот же квадратик повторять по сетке, видно сетку, а это некрасиво. Забыл, как называется этот эффект... И вот он хочет вместо одиночных тайлов лепить сразу группами типа 2x1 или 2x2, я так думаю. Хотя по-хорошему нужно просто тайлы заново перерисовать...
>>55288
>Есть ли способ сделать так, чтобы тайлы из тайлсета расставлять в определённом порядке?
Не знаю, как в Годо, не пользовался, но в Tiled и других тайловых редакторах для этого вроде можно выделить сразу несколько ближайших тайлов, чтобы лепить сразу группами типа 2x1, 2x2, 2x3, 3x3, 3x1 и т.п. Но всё-таки рекомендую перерисовать тайлы, если ты видишь чёткую сетку - значит, плохо нарисовал тайлы.
>>55293
Y-sort это не то. К тому же никакого вопроса про z-порядок я не задавал, там всё просто и понятно.
>>55300
Сенкс, няш, ты всё правильно понял. Вот только про перерисовку никакой речи быть не может: неровные линии создают неповторимый шарм, графика прям живая и дышащая становится. Попробую Tiled; если и там не получится, тогда ручками придётся каждый тайл ставить.
Y-sort это не то. К тому же никакого вопроса про z-порядок я не задавал, там всё просто и понятно.
>>55300
Сенкс, няш, ты всё правильно понял. Вот только про перерисовку никакой речи быть не может: неровные линии создают неповторимый шарм, графика прям живая и дышащая становится. Попробую Tiled; если и там не получится, тогда ручками придётся каждый тайл ставить.
>>54870
И раз
https://www.youtube.com/watch?v=_urHlep2P84
И два
https://www.youtube.com/watch?v=A1xjUuRZmWQ
> Я думал, оно как-то само будет вычитать препятствия из путей…
И раз
https://www.youtube.com/watch?v=_urHlep2P84
И два
https://www.youtube.com/watch?v=A1xjUuRZmWQ
31 Кб, 640x377>>55320
Это понятно, но тебе всё равно ведь придётся замыкать тайлы. Не 1x1, так 2x2, не 2x2, так 3x3...
Там-то точно получится, но для импорта понадобится инструмент: https://godotengine.org/asset-library/asset/158
>>55497
Спасибо, посмотрю.
>неровные линии создают неповторимый шарм, графика прям живая и дышащая становится
Это понятно, но тебе всё равно ведь придётся замыкать тайлы. Не 1x1, так 2x2, не 2x2, так 3x3...
>Попробую Tiled; если и там не получится
Там-то точно получится, но для импорта понадобится инструмент: https://godotengine.org/asset-library/asset/158
>>55497
Спасибо, посмотрю.
Перезагружаю сцену таким кодом:
if Input.is_action_just_released("reset_scene"):
var error = get_tree().reload_current_scene()
С помощью print()-ов выяснил, что во время перезагрузки ноды-синглтоны не сбрасывают состояние.
Т.е. если у меня в синглтоне хранится какой-то массив, перезагрузка сцены не сбрасывает его в ноль.
Мне что, отдельный метод для сброса писать? Нет способа определить момент сброса сцены?
Алсо, что если сделать синглтоном HUD игрока? Вроде логично, он ведь только один должен быть...
if Input.is_action_just_released("reset_scene"):
var error = get_tree().reload_current_scene()
С помощью print()-ов выяснил, что во время перезагрузки ноды-синглтоны не сбрасывают состояние.
Т.е. если у меня в синглтоне хранится какой-то массив, перезагрузка сцены не сбрасывает его в ноль.
Мне что, отдельный метод для сброса писать? Нет способа определить момент сброса сцены?
Алсо, что если сделать синглтоном HUD игрока? Вроде логично, он ведь только один должен быть...
>>55625
Само собой. Ты бы remote сцену глянул бы хоть раз, что она из себя представляет:
\SceneTree
-\root
--\singleton1
--\singleton2
--\your_current_scene
Из вышеприведённого примера видно, что синглтоны не что иное, как отдельные от сцены ветки общего дерева. Просто они регистрируют свои имена в пространстве имён дерева сцены так, что ты видишь их по именам в любом скрипте. Соответственно, за эту регистрацию и отвечает галочка "синглтон" в автозагрузке. При перезагрузке куррент-сцены, это очевидно не затрагивает соседние ветви дерева. Удаляется зарегистрированный в дереве чайлд, который олицетворяет куррент-сцену, затем загружается его новый инстанс.
Я всегда так и делаю, а ещё главное меню. Да и весь интерфейс. И ещё кучу сопутствующих мелочей, которые нужны всегда, на всех этапах рантайма игоры. Например, фоновую музыку. Только галочки синглтона с них снимаю, чтобы не возникало соблазна обращаться к ним напрямую, портя стройность игровой логики. Сценовые ноды не видят автозагруженные ноды. Однако есть несколько способов обратиться к ним:
1. Get_tree().get_root().get_node("your_autoloaded_node")
2. Get_node("/root/your_autoloaded_node")
3. Мой любимый способ. Создаёшь специальную ноду-маршрутизатор или менеджер сообщений или, как некоторые называют, диспетчер событий. Эту ноду пихаешь в автозагрузку с галкой синглтона. В скрипте этой ноды объявляешь кучу кастомных сигналов, например load_game, update_UI, set_state и прочее нужное тебе. Далее, ноды, которые должны получать данные коннектятся к этим глобальным сигналам у себя в ready(), event_manager.connect("signal_name", self, "function_name") дисконнектить не нужно, об этом движок заботится автоматически. Лично у меня крошей не возникало. Кстати, коннектить можно не только свои функции, но и другого синглтона, например, кидаешь в автозагрузку game.gd в котором описываешь глобальные функции и константы. Тогда будет так: event_manager.connect("signal_name", game, "function_name_in_global_game") Ноды, которые должны передавать данные, делают, когда требуется event_manager.emit_signal(custom_data) и подписанные на этот сигнал объекты получают содержимое custom_data и делают с этим содержимым свои дела. Если содержимым будет Dictionary, то нода-эмиттер может так же получать ответ, так как словари передаются по ссылке. Только ответ надо разделять по ключам, если ресиверов сигнала больше одного. Очень крутая система, уважающая инкапсуляцию (которая не сокрытие, напоминаю, а концентрация логики в "капсуле" внутри конкретного модуля) то есть скрипты нод независимы максимально. Им требуется только наличие как минимум одного синглтона, о чем они сообщат на этапе компиляции и ты этого не пропустишь. При желании этот момент можно тоже защитить от дурака, ища в ready() синглтон по его ожидаемому имени из п.2. (т.к. он будет потомком root) и если не найден, не подписываться на сигналы и не излучать их. Но я до такой степени не заморачиваюсь, т.к. работаю сам и принимать дураков в команду вроде как не планирую))
> во время перезагрузки ноды-синглтоны не сбрасывают состояние
Само собой. Ты бы remote сцену глянул бы хоть раз, что она из себя представляет:
\SceneTree
-\root
--\singleton1
--\singleton2
--\your_current_scene
Из вышеприведённого примера видно, что синглтоны не что иное, как отдельные от сцены ветки общего дерева. Просто они регистрируют свои имена в пространстве имён дерева сцены так, что ты видишь их по именам в любом скрипте. Соответственно, за эту регистрацию и отвечает галочка "синглтон" в автозагрузке. При перезагрузке куррент-сцены, это очевидно не затрагивает соседние ветви дерева. Удаляется зарегистрированный в дереве чайлд, который олицетворяет куррент-сцену, затем загружается его новый инстанс.
> что если сделать синглтоном HUD игрока?
Я всегда так и делаю, а ещё главное меню. Да и весь интерфейс. И ещё кучу сопутствующих мелочей, которые нужны всегда, на всех этапах рантайма игоры. Например, фоновую музыку. Только галочки синглтона с них снимаю, чтобы не возникало соблазна обращаться к ним напрямую, портя стройность игровой логики. Сценовые ноды не видят автозагруженные ноды. Однако есть несколько способов обратиться к ним:
1. Get_tree().get_root().get_node("your_autoloaded_node")
2. Get_node("/root/your_autoloaded_node")
3. Мой любимый способ. Создаёшь специальную ноду-маршрутизатор или менеджер сообщений или, как некоторые называют, диспетчер событий. Эту ноду пихаешь в автозагрузку с галкой синглтона. В скрипте этой ноды объявляешь кучу кастомных сигналов, например load_game, update_UI, set_state и прочее нужное тебе. Далее, ноды, которые должны получать данные коннектятся к этим глобальным сигналам у себя в ready(), event_manager.connect("signal_name", self, "function_name") дисконнектить не нужно, об этом движок заботится автоматически. Лично у меня крошей не возникало. Кстати, коннектить можно не только свои функции, но и другого синглтона, например, кидаешь в автозагрузку game.gd в котором описываешь глобальные функции и константы. Тогда будет так: event_manager.connect("signal_name", game, "function_name_in_global_game") Ноды, которые должны передавать данные, делают, когда требуется event_manager.emit_signal(custom_data) и подписанные на этот сигнал объекты получают содержимое custom_data и делают с этим содержимым свои дела. Если содержимым будет Dictionary, то нода-эмиттер может так же получать ответ, так как словари передаются по ссылке. Только ответ надо разделять по ключам, если ресиверов сигнала больше одного. Очень крутая система, уважающая инкапсуляцию (которая не сокрытие, напоминаю, а концентрация логики в "капсуле" внутри конкретного модуля) то есть скрипты нод независимы максимально. Им требуется только наличие как минимум одного синглтона, о чем они сообщат на этапе компиляции и ты этого не пропустишь. При желании этот момент можно тоже защитить от дурака, ища в ready() синглтон по его ожидаемому имени из п.2. (т.к. он будет потомком root) и если не найден, не подписываться на сигналы и не излучать их. Но я до такой степени не заморачиваюсь, т.к. работаю сам и принимать дураков в команду вроде как не планирую))
>>55625
Само собой. Ты бы remote сцену глянул бы хоть раз, что она из себя представляет:
\SceneTree
-\root
--\singleton1
--\singleton2
--\your_current_scene
Из вышеприведённого примера видно, что синглтоны не что иное, как отдельные от сцены ветки общего дерева. Просто они регистрируют свои имена в пространстве имён дерева сцены так, что ты видишь их по именам в любом скрипте. Соответственно, за эту регистрацию и отвечает галочка "синглтон" в автозагрузке. При перезагрузке куррент-сцены, это очевидно не затрагивает соседние ветви дерева. Удаляется зарегистрированный в дереве чайлд, который олицетворяет куррент-сцену, затем загружается его новый инстанс.
Я всегда так и делаю, а ещё главное меню. Да и весь интерфейс. И ещё кучу сопутствующих мелочей, которые нужны всегда, на всех этапах рантайма игоры. Например, фоновую музыку. Только галочки синглтона с них снимаю, чтобы не возникало соблазна обращаться к ним напрямую, портя стройность игровой логики. Сценовые ноды не видят автозагруженные ноды. Однако есть несколько способов обратиться к ним:
1. Get_tree().get_root().get_node("your_autoloaded_node")
2. Get_node("/root/your_autoloaded_node")
3. Мой любимый способ. Создаёшь специальную ноду-маршрутизатор или менеджер сообщений или, как некоторые называют, диспетчер событий. Эту ноду пихаешь в автозагрузку с галкой синглтона. В скрипте этой ноды объявляешь кучу кастомных сигналов, например load_game, update_UI, set_state и прочее нужное тебе. Далее, ноды, которые должны получать данные коннектятся к этим глобальным сигналам у себя в ready(), event_manager.connect("signal_name", self, "function_name") дисконнектить не нужно, об этом движок заботится автоматически. Лично у меня крошей не возникало. Кстати, коннектить можно не только свои функции, но и другого синглтона, например, кидаешь в автозагрузку game.gd в котором описываешь глобальные функции и константы. Тогда будет так: event_manager.connect("signal_name", game, "function_name_in_global_game") Ноды, которые должны передавать данные, делают, когда требуется event_manager.emit_signal(custom_data) и подписанные на этот сигнал объекты получают содержимое custom_data и делают с этим содержимым свои дела. Если содержимым будет Dictionary, то нода-эмиттер может так же получать ответ, так как словари передаются по ссылке. Только ответ надо разделять по ключам, если ресиверов сигнала больше одного. Очень крутая система, уважающая инкапсуляцию (которая не сокрытие, напоминаю, а концентрация логики в "капсуле" внутри конкретного модуля) то есть скрипты нод независимы максимально. Им требуется только наличие как минимум одного синглтона, о чем они сообщат на этапе компиляции и ты этого не пропустишь. При желании этот момент можно тоже защитить от дурака, ища в ready() синглтон по его ожидаемому имени из п.2. (т.к. он будет потомком root) и если не найден, не подписываться на сигналы и не излучать их. Но я до такой степени не заморачиваюсь, т.к. работаю сам и принимать дураков в команду вроде как не планирую))
> во время перезагрузки ноды-синглтоны не сбрасывают состояние
Само собой. Ты бы remote сцену глянул бы хоть раз, что она из себя представляет:
\SceneTree
-\root
--\singleton1
--\singleton2
--\your_current_scene
Из вышеприведённого примера видно, что синглтоны не что иное, как отдельные от сцены ветки общего дерева. Просто они регистрируют свои имена в пространстве имён дерева сцены так, что ты видишь их по именам в любом скрипте. Соответственно, за эту регистрацию и отвечает галочка "синглтон" в автозагрузке. При перезагрузке куррент-сцены, это очевидно не затрагивает соседние ветви дерева. Удаляется зарегистрированный в дереве чайлд, который олицетворяет куррент-сцену, затем загружается его новый инстанс.
> что если сделать синглтоном HUD игрока?
Я всегда так и делаю, а ещё главное меню. Да и весь интерфейс. И ещё кучу сопутствующих мелочей, которые нужны всегда, на всех этапах рантайма игоры. Например, фоновую музыку. Только галочки синглтона с них снимаю, чтобы не возникало соблазна обращаться к ним напрямую, портя стройность игровой логики. Сценовые ноды не видят автозагруженные ноды. Однако есть несколько способов обратиться к ним:
1. Get_tree().get_root().get_node("your_autoloaded_node")
2. Get_node("/root/your_autoloaded_node")
3. Мой любимый способ. Создаёшь специальную ноду-маршрутизатор или менеджер сообщений или, как некоторые называют, диспетчер событий. Эту ноду пихаешь в автозагрузку с галкой синглтона. В скрипте этой ноды объявляешь кучу кастомных сигналов, например load_game, update_UI, set_state и прочее нужное тебе. Далее, ноды, которые должны получать данные коннектятся к этим глобальным сигналам у себя в ready(), event_manager.connect("signal_name", self, "function_name") дисконнектить не нужно, об этом движок заботится автоматически. Лично у меня крошей не возникало. Кстати, коннектить можно не только свои функции, но и другого синглтона, например, кидаешь в автозагрузку game.gd в котором описываешь глобальные функции и константы. Тогда будет так: event_manager.connect("signal_name", game, "function_name_in_global_game") Ноды, которые должны передавать данные, делают, когда требуется event_manager.emit_signal(custom_data) и подписанные на этот сигнал объекты получают содержимое custom_data и делают с этим содержимым свои дела. Если содержимым будет Dictionary, то нода-эмиттер может так же получать ответ, так как словари передаются по ссылке. Только ответ надо разделять по ключам, если ресиверов сигнала больше одного. Очень крутая система, уважающая инкапсуляцию (которая не сокрытие, напоминаю, а концентрация логики в "капсуле" внутри конкретного модуля) то есть скрипты нод независимы максимально. Им требуется только наличие как минимум одного синглтона, о чем они сообщат на этапе компиляции и ты этого не пропустишь. При желании этот момент можно тоже защитить от дурака, ища в ready() синглтон по его ожидаемому имени из п.2. (т.к. он будет потомком root) и если не найден, не подписываться на сигналы и не излучать их. Но я до такой степени не заморачиваюсь, т.к. работаю сам и принимать дураков в команду вроде как не планирую))
>>55674
Это я знаю. Но каждая ветка - это сцена, так? Почему тогда reload_current_scene() удаляет только
Вместо того, чтобы удалять вообще всех детей root-ноды?
Нет, я, конечно, понимаю, что так сделано для того, чтобы можно было через синглтон переносить данные между разными сценами, например, текущий прогресс игрока между уровнями, или глобальные настройки игры какие-то, но мне почему-то казалось, что "перезагрузка сцены" по идее должна сбрасывать вообще всё. Дело в том, что у меня на загрузке сцены некоторые ноды в _ready регистрируют себя в одном синглтоне, и поэтому если просто сбрасывать сцену, будет утечка памяти и обращение к nil; получается, мне необходимо перед/после обращения к reload_current_scene() дополнительно делать запрос к синглтону, чтобы он сбросил своё состояние... Мне нетрудно, но выглядит не совсем логично.
Уже сделал так, действительно, намного удобнее получилось. Просто думал, что синглтоном не может быть что-то визуальное, да и тот же интерфейс придётся периодически скрывать/показывать, он ведь не всегда нужен...
В чём проблема писать HUD.show_help(true)? Если вдруг дисплей отвалится, то и стартовать игра не должна.
Или вот у меня CityNavigator.find_closest(point), бот ведь не будет использоваться где-то помимо города...
Вот с этими сигналами так много проблем. Коннектить нужно, излучать... А когда они вообще доходят? Это ведь не прямой вызов процедуры, неизвестно, дойдёт ли вообще. Про систему сообщений я знаю после изучения ECS, но так руки и не дошли сделать своими руками, с трудом понимаю, как это может работать. Раньше делал что-то похожее, но там рассылалось от каждого всем, а уже получатель определял, нужно ли ему то, что он получил...
Кстати, если использовать сигналы вместо прямых вызовов процедур, нагрузка на кадр будет меньше? А то вот подумываю о том, чтобы запускать субгенераторы через сигналы - по моему опыту, если каждая сцена определяется со своим состоянием в своём ready(), то сцена начинает грузиться несколько секунд (пока все субсцены не определятся), а при чуть более сложной генерации переполняется стек (о_О), это нехорошо. Вообще не знаю, чё делать, если б на Паскале писал, я бы просто загнал генерацию в отдельный поток и/или делал её предварительно, а тут приходится как-то мудрить с отдельными скриптами, не настраивать же все сцены из одного скрипта...
>синглтоны не что иное, как отдельные от сцены ветки общего дерева
Это я знаю. Но каждая ветка - это сцена, так? Почему тогда reload_current_scene() удаляет только
>зарегистрированный в дереве чайлд, который олицетворяет куррент-сцену
Вместо того, чтобы удалять вообще всех детей root-ноды?
Нет, я, конечно, понимаю, что так сделано для того, чтобы можно было через синглтон переносить данные между разными сценами, например, текущий прогресс игрока между уровнями, или глобальные настройки игры какие-то, но мне почему-то казалось, что "перезагрузка сцены" по идее должна сбрасывать вообще всё. Дело в том, что у меня на загрузке сцены некоторые ноды в _ready регистрируют себя в одном синглтоне, и поэтому если просто сбрасывать сцену, будет утечка памяти и обращение к nil; получается, мне необходимо перед/после обращения к reload_current_scene() дополнительно делать запрос к синглтону, чтобы он сбросил своё состояние... Мне нетрудно, но выглядит не совсем логично.
>что если сделать синглтоном HUD игрока?
Уже сделал так, действительно, намного удобнее получилось. Просто думал, что синглтоном не может быть что-то визуальное, да и тот же интерфейс придётся периодически скрывать/показывать, он ведь не всегда нужен...
>чтобы не возникало соблазна обращаться к ним напрямую
В чём проблема писать HUD.show_help(true)? Если вдруг дисплей отвалится, то и стартовать игра не должна.
Или вот у меня CityNavigator.find_closest(point), бот ведь не будет использоваться где-то помимо города...
>коннектятся к этим глобальным сигналам у себя в ready
Вот с этими сигналами так много проблем. Коннектить нужно, излучать... А когда они вообще доходят? Это ведь не прямой вызов процедуры, неизвестно, дойдёт ли вообще. Про систему сообщений я знаю после изучения ECS, но так руки и не дошли сделать своими руками, с трудом понимаю, как это может работать. Раньше делал что-то похожее, но там рассылалось от каждого всем, а уже получатель определял, нужно ли ему то, что он получил...
Кстати, если использовать сигналы вместо прямых вызовов процедур, нагрузка на кадр будет меньше? А то вот подумываю о том, чтобы запускать субгенераторы через сигналы - по моему опыту, если каждая сцена определяется со своим состоянием в своём ready(), то сцена начинает грузиться несколько секунд (пока все субсцены не определятся), а при чуть более сложной генерации переполняется стек (о_О), это нехорошо. Вообще не знаю, чё делать, если б на Паскале писал, я бы просто загнал генерацию в отдельный поток и/или делал её предварительно, а тут приходится как-то мудрить с отдельными скриптами, не настраивать же все сцены из одного скрипта...
>>55674
Это я знаю. Но каждая ветка - это сцена, так? Почему тогда reload_current_scene() удаляет только
Вместо того, чтобы удалять вообще всех детей root-ноды?
Нет, я, конечно, понимаю, что так сделано для того, чтобы можно было через синглтон переносить данные между разными сценами, например, текущий прогресс игрока между уровнями, или глобальные настройки игры какие-то, но мне почему-то казалось, что "перезагрузка сцены" по идее должна сбрасывать вообще всё. Дело в том, что у меня на загрузке сцены некоторые ноды в _ready регистрируют себя в одном синглтоне, и поэтому если просто сбрасывать сцену, будет утечка памяти и обращение к nil; получается, мне необходимо перед/после обращения к reload_current_scene() дополнительно делать запрос к синглтону, чтобы он сбросил своё состояние... Мне нетрудно, но выглядит не совсем логично.
Уже сделал так, действительно, намного удобнее получилось. Просто думал, что синглтоном не может быть что-то визуальное, да и тот же интерфейс придётся периодически скрывать/показывать, он ведь не всегда нужен...
В чём проблема писать HUD.show_help(true)? Если вдруг дисплей отвалится, то и стартовать игра не должна.
Или вот у меня CityNavigator.find_closest(point), бот ведь не будет использоваться где-то помимо города...
Вот с этими сигналами так много проблем. Коннектить нужно, излучать... А когда они вообще доходят? Это ведь не прямой вызов процедуры, неизвестно, дойдёт ли вообще. Про систему сообщений я знаю после изучения ECS, но так руки и не дошли сделать своими руками, с трудом понимаю, как это может работать. Раньше делал что-то похожее, но там рассылалось от каждого всем, а уже получатель определял, нужно ли ему то, что он получил...
Кстати, если использовать сигналы вместо прямых вызовов процедур, нагрузка на кадр будет меньше? А то вот подумываю о том, чтобы запускать субгенераторы через сигналы - по моему опыту, если каждая сцена определяется со своим состоянием в своём ready(), то сцена начинает грузиться несколько секунд (пока все субсцены не определятся), а при чуть более сложной генерации переполняется стек (о_О), это нехорошо. Вообще не знаю, чё делать, если б на Паскале писал, я бы просто загнал генерацию в отдельный поток и/или делал её предварительно, а тут приходится как-то мудрить с отдельными скриптами, не настраивать же все сцены из одного скрипта...
>синглтоны не что иное, как отдельные от сцены ветки общего дерева
Это я знаю. Но каждая ветка - это сцена, так? Почему тогда reload_current_scene() удаляет только
>зарегистрированный в дереве чайлд, который олицетворяет куррент-сцену
Вместо того, чтобы удалять вообще всех детей root-ноды?
Нет, я, конечно, понимаю, что так сделано для того, чтобы можно было через синглтон переносить данные между разными сценами, например, текущий прогресс игрока между уровнями, или глобальные настройки игры какие-то, но мне почему-то казалось, что "перезагрузка сцены" по идее должна сбрасывать вообще всё. Дело в том, что у меня на загрузке сцены некоторые ноды в _ready регистрируют себя в одном синглтоне, и поэтому если просто сбрасывать сцену, будет утечка памяти и обращение к nil; получается, мне необходимо перед/после обращения к reload_current_scene() дополнительно делать запрос к синглтону, чтобы он сбросил своё состояние... Мне нетрудно, но выглядит не совсем логично.
>что если сделать синглтоном HUD игрока?
Уже сделал так, действительно, намного удобнее получилось. Просто думал, что синглтоном не может быть что-то визуальное, да и тот же интерфейс придётся периодически скрывать/показывать, он ведь не всегда нужен...
>чтобы не возникало соблазна обращаться к ним напрямую
В чём проблема писать HUD.show_help(true)? Если вдруг дисплей отвалится, то и стартовать игра не должна.
Или вот у меня CityNavigator.find_closest(point), бот ведь не будет использоваться где-то помимо города...
>коннектятся к этим глобальным сигналам у себя в ready
Вот с этими сигналами так много проблем. Коннектить нужно, излучать... А когда они вообще доходят? Это ведь не прямой вызов процедуры, неизвестно, дойдёт ли вообще. Про систему сообщений я знаю после изучения ECS, но так руки и не дошли сделать своими руками, с трудом понимаю, как это может работать. Раньше делал что-то похожее, но там рассылалось от каждого всем, а уже получатель определял, нужно ли ему то, что он получил...
Кстати, если использовать сигналы вместо прямых вызовов процедур, нагрузка на кадр будет меньше? А то вот подумываю о том, чтобы запускать субгенераторы через сигналы - по моему опыту, если каждая сцена определяется со своим состоянием в своём ready(), то сцена начинает грузиться несколько секунд (пока все субсцены не определятся), а при чуть более сложной генерации переполняется стек (о_О), это нехорошо. Вообще не знаю, чё делать, если б на Паскале писал, я бы просто загнал генерацию в отдельный поток и/или делал её предварительно, а тут приходится как-то мудрить с отдельными скриптами, не настраивать же все сцены из одного скрипта...
26 Кб, 251x626>>55699
Не совсем.
Есть сцена как файл, который ты сохраняешь в формате (t)scn. Это полноценная сцена со своим единственным корнем-родителем и кучей детей. Однако, эта сцена входит в существующую на этапе исполнения твоего конечного приложения сцены как один из детей. Здесь конечно есть повод поругать Хуана в срачетреде за путаницу в терминах. Следует различать сцены-ресурсы, которые десериализуются игрой и их инстансы включаются в общее дерево, и различать собственно само дерево сцены (SceneTree) олицетворяющее главный цикл приложения и являющееся создателем всего дерева сцены. Вроде как всё есть сцены, но я предлагаю держать в уме, что те сцены, которые ты создаёшь в редакторе, это таки префабы, а не сцены. И сценами они не становятся. Они становятся ветвями в дереве одной единственной сцены. Как и куррент_сцене, так и аутолоадед_синглетонц. Ещё раз рекомендую ознакомиться с remote (удалённой) сценой, при запуске игры в редакторе.
> каждая ветка - это сцена, так?
Не совсем.
Есть сцена как файл, который ты сохраняешь в формате (t)scn. Это полноценная сцена со своим единственным корнем-родителем и кучей детей. Однако, эта сцена входит в существующую на этапе исполнения твоего конечного приложения сцены как один из детей. Здесь конечно есть повод поругать Хуана в срачетреде за путаницу в терминах. Следует различать сцены-ресурсы, которые десериализуются игрой и их инстансы включаются в общее дерево, и различать собственно само дерево сцены (SceneTree) олицетворяющее главный цикл приложения и являющееся создателем всего дерева сцены. Вроде как всё есть сцены, но я предлагаю держать в уме, что те сцены, которые ты создаёшь в редакторе, это таки префабы, а не сцены. И сценами они не становятся. Они становятся ветвями в дереве одной единственной сцены. Как и куррент_сцене, так и аутолоадед_синглетонц. Ещё раз рекомендую ознакомиться с remote (удалённой) сценой, при запуске игры в редакторе.
>>55709
Забыл дать пояснения к скрину. В данном скрине куррент сцена - это menu_location, фон для главного меню с простенькой анимацией. Всё остальное - автолоады, из которых с галкой синглтона только evman, config и game. Когда я делаю загрузки или перезагрузки куррент сцены (то есть, когда загружаю собственно игру), автозагруженные модули получают необходимые сигналы, чтобы изменить их состояние. Например, задать фоновую музыку, скрыть меню, показать HUD. Наборы этих действий стандартно входят в такие процедуры как загрузка сохранённой игры, старт новой игры. При включении режима паузы часть из них автоматически переходит в режим паузы, а некоторые принудительно выставлены в режим process и получают свои сигналы, например, фоновый плеер немного приглушает громкость.
Забыл дать пояснения к скрину. В данном скрине куррент сцена - это menu_location, фон для главного меню с простенькой анимацией. Всё остальное - автолоады, из которых с галкой синглтона только evman, config и game. Когда я делаю загрузки или перезагрузки куррент сцены (то есть, когда загружаю собственно игру), автозагруженные модули получают необходимые сигналы, чтобы изменить их состояние. Например, задать фоновую музыку, скрыть меню, показать HUD. Наборы этих действий стандартно входят в такие процедуры как загрузка сохранённой игры, старт новой игры. При включении режима паузы часть из них автоматически переходит в режим паузы, а некоторые принудительно выставлены в режим process и получают свои сигналы, например, фоновый плеер немного приглушает громкость.
В годо есть вообще управляющие сиволы типа \n ? Нашел только обоссаный newline(), который для моих целей не совсем подходит (с ним будет ебля на пустом месте, которой можно было бы избежать при помощи \n)
>>55699
Я тоже старый паскалист. Правда с потоками особо не работал, хоть и понимаю их суть. Удивляюсь, почему ты, обладая знаниями паскаля, не понял как это всё устроено. Там вообще ничего сложного нет.
Как паскалист паскалисту хочу подсказать (а может напомнить, если уже сам знаешь), что аналогами функций и процедур модуля в гдскрипте (равно как и в шарпе) являются static func. Это полный аналог. Статическая функция уже не является методом объекта, описываемого скриптом. У неё нет доступа к методам и полям-переменным. Это те самые функции, которые в модулях паскаля писались без префикса в виде имени класса. Сам понимаешь теперь, для чего их можно применять. Например, чтобы выполнить некий расчёт одной строкой, вызвав статическую функцию, в которой создастся экземпляр класса, вернёт какие-то данные и уничтожится.
Сигналы это полный аналог ивентов в том же дельфи. Полнейший. Доходят так же. В рамках фрейма, в котором излучены.
Сообщения - есть фундаментальное понятие программирования, есть в большинстве парадигм, методик, архитектур, паттернов. Есть сообщения и в годо. Однако, это совершенно иная подсистема и её не желательно путать с сигналами-ивентами. С помощью сообщений (оконных, NOTIFICATION_WM_QUIT_REQUEST), я например, отслеживаю закрытие приложения и выполняю необходимые действия, вплоть до отмены закрытия, если игрок передумал в диалоге ДА/НЕТ.
> Вообще не знаю, чё делать, если б на Паскале писал, я бы просто загнал генерацию в отдельный поток и/или делал её предварительно, а тут приходится как-то мудрить с отдельными скриптами, не настраивать же все сцены из одного скрипта…
Я тоже старый паскалист. Правда с потоками особо не работал, хоть и понимаю их суть. Удивляюсь, почему ты, обладая знаниями паскаля, не понял как это всё устроено. Там вообще ничего сложного нет.
Как паскалист паскалисту хочу подсказать (а может напомнить, если уже сам знаешь), что аналогами функций и процедур модуля в гдскрипте (равно как и в шарпе) являются static func. Это полный аналог. Статическая функция уже не является методом объекта, описываемого скриптом. У неё нет доступа к методам и полям-переменным. Это те самые функции, которые в модулях паскаля писались без префикса в виде имени класса. Сам понимаешь теперь, для чего их можно применять. Например, чтобы выполнить некий расчёт одной строкой, вызвав статическую функцию, в которой создастся экземпляр класса, вернёт какие-то данные и уничтожится.
> Вот с этими сигналами так много проблем. Коннектить нужно, излучать… А когда они вообще доходят? Это ведь не прямой вызов процедуры, неизвестно, дойдёт ли вообще.
Сигналы это полный аналог ивентов в том же дельфи. Полнейший. Доходят так же. В рамках фрейма, в котором излучены.
> систему сообщений
Сообщения - есть фундаментальное понятие программирования, есть в большинстве парадигм, методик, архитектур, паттернов. Есть сообщения и в годо. Однако, это совершенно иная подсистема и её не желательно путать с сигналами-ивентами. С помощью сообщений (оконных, NOTIFICATION_WM_QUIT_REQUEST), я например, отслеживаю закрытие приложения и выполняю необходимые действия, вплоть до отмены закрытия, если игрок передумал в диалоге ДА/НЕТ.
>>55743
Ок. Просто я шерстил документацию, и че-то прям совсем безрезультатно...
Ок. Просто я шерстил документацию, и че-то прям совсем безрезультатно...
>>55739
Ты хотя бы попробовал использовать \n, прежде чем задавать вопрос здесь? -_\\
>В годо есть вообще управляющие сиволы типа \n ? Нашел только обоссаный newline()
Ты хотя бы попробовал использовать \n, прежде чем задавать вопрос здесь? -_\\
>>55746
Нет, извини.
Нет, извини.
>>55746
Освой форматирование строк. Такая крутая тема! Всем рикаминдую.
text = "FPS: %s\nObjects: %s\nNodes: %s\nOrphans: %s\nVertices: %s" % [fps, objs, nodes, orphans, vertices]
Ну ты понел. И есть ещё варик со словарём, чуть длиннее и более подходит для крупных текстов.
Освой форматирование строк. Такая крутая тема! Всем рикаминдую.
text = "FPS: %s\nObjects: %s\nNodes: %s\nOrphans: %s\nVertices: %s" % [fps, objs, nodes, orphans, vertices]
Ну ты понел. И есть ещё варик со словарём, чуть длиннее и более подходит для крупных текстов.
>>55759
Ненавижу этот тупой термин. С какого хуя интерполяцией назвали строковое форматирование? Зумеры совсем ебанулись.
Ненавижу этот тупой термин. С какого хуя интерполяцией назвали строковое форматирование? Зумеры совсем ебанулись.
>>55764
Именно перл и является очередным зумерским высером, внучок.
Интерполяция чаще всего подразумевается линейная, когда lerp(from, to, delta) а что вы, зумеры подразумеваете под интерполяцей строк? Ты дяже объяснить этого не сможешь, потому что нет в стрововом форматировании никакой интерполяции. А тот дегенерат, что придумал использовать этот термин, будет гореть в аду.
Именно перл и является очередным зумерским высером, внучок.
Интерполяция чаще всего подразумевается линейная, когда lerp(from, to, delta) а что вы, зумеры подразумеваете под интерполяцей строк? Ты дяже объяснить этого не сможешь, потому что нет в стрововом форматировании никакой интерполяции. А тот дегенерат, что придумал использовать этот термин, будет гореть в аду.
>>55767
Учи латинский, технарик. Тогда не будет бомбить от знакомых терминов, которые используются в незнакомом контексте.
>ты дяже объяснить этого не сможешь
Учи латинский, технарик. Тогда не будет бомбить от знакомых терминов, которые используются в незнакомом контексте.
10 Кб, 243x252>>55709
Я не понимаю, что и зачем ты пытаешься объяснить. Я говорил, что меня смутило, что перезагружается не "root", а только одна из его веток, которая помечена как "текущая сцена". Изначально я начал использовать reload_current_scene() в качестве замены нажатия F5 в редакторе, чтобы не перезагружать всю игру целиком, если мне нужно сбросить сцену для теста. Выглядит нелогичным, что нода-синглтон (UI) имеет особые привилегии перед обычной нодой (menu_location).
Да знаю я про remote, ещё несколько лет назад в туториале к Godot 2 про неё узнал (а потом забил на Godot и вообще любые готовые движки и сам геймдев). Толку-то от неё, если у меня в тестовой сцене сотни нод. Она может помочь только в отладке мелких сцен, и то если какая-то ошибка возникнет...
>>55742
В данном конкретном случае суть в том, чтобы не тормозить главный поток. В обычном приложении главный поток может общаться с пользователем через нажатия кнопок и всякие анимации, тогда как в фоне крутится несколько потоков, занятых долгими или тяжёлыми процессами. Конкретно в игре я бы хотел (попробовать) выделить генерацию в отдельный поток, чтобы игрок мог сразу бегать по карте, пока она ещё не до конца прогрузилась. Да и систему ИИ было бы неплохо выделить в отдельный поток, но это я планирую сделать с помощью GDNative и всё того же Паскаля; можно и генерацию так же сделать, но я хотел поэкспериментировать на GDScript для начала. Знаю, что многопоточность можно симулировать на уровне приложения, но париться с этим желания нет, раз уж мы сидим на многопоточной ОС.
Тогда какой в ней смысл? Память она всё равно занимает, выделить в отдельный файл-модуль всё равно нельзя, выполнение вызывающего кода всё равно блокирует. Я когда в ООП-стиле на паскале пишу, практически не создаю простые функции и процедуры, а static методы вообще никогда не создавал...
Эммм, я не создавал свои собственные ивенты в Delphi/Lazarus, но насколько мне известно, TApplication работает в единственном потоке, и событие мгновенно вызывает связанный с ним обработчик, ничего никуда не "доходит". Это значит, что если обработчик содержит тяжёлый код, срабатывание события вызовет зависание основного потока... Нехорошо.
Ну "система сообщений" в моём представлении хранит в себе "сообщения" и периодически пытается доставить эти сообщения подключённым к ней сущностям, когда те будут готовы к приёму. То есть она должна работать в отдельном потоке, и раздавать сообщения не мгновенно, а по мере возможности. Про сообщения из WinAPI прекрасно знаю и много раз работал с ними, они примерно то, о чём я говорю, наверное, т.к. они доставляются по мере возможности - если приложение зависло, очередь сообщений забивается, например.
Главным образом я не могу понять концепцию "скриптов". Потому что когда я пишу код на Паскале или любом другом компилируемом ЯП, я чётко вижу единственную точку входа в программу, хотя бы примерно понимаю, что происходит под капотом того же TApplication, когда и при каких обстоятельствах вызываются все процедуры. А при написании скрипта для игрового объекта в любом игровом движке у меня ощущение, будто скрипт "авось выполнится, а может и нет", и вообще не имеет никакой связи с другими скриптами. Очень трудно писать код, когда он не является цельной программой.
Я вот вижу, что .gd-файл - это класс, и от него можно наследоваться, что примерно похоже на подключение модуля, но собственно подключения модулей так и не нашёл. То есть, например, для каких-то утилит мне нужно создавать отдельный класс, добавлять его в автозагрузку, и обращаться по имени класса, вместо того, чтобы явным образом подключить необходимый модуль к нуждающемуся в нём скрипту...
Эх, если б я мог осилить математику и не ленился/боялся, я бы давно на своём движке кодил. Может быть, даже сделал бы свой собственный ЯП, кто знает, заготовки валяются без дела...
А, ну да, я так-то планировал собственную скриптовую систему, и поэтому понимаю, что каждый скрипт обрабатывается независимо интерпретатором, но вместе их связывает общее хранилище каких-то данных и общая библиотека базовых функций интерпретатора. Вот только не зная подкапотной работы интерпретатора, трудно представить и удерживать в голове то, как будут вести себя твои скрипты, и это раздражает.
Вот, кстати, второй раз забываю спросить - почему в GDScript не предусмотрен деструктор класса? Роль конструктора по идее выполняет ready, хоть он и вызывается позже enter_tree, но деструктора нет. Пробовал использовать какой-то костыль, но он то ли не работает, то ли работает не так, как я думал, а тот же exit_tree в качестве деструктора нельзя использовать, т.к. нода может покидать дерево и возвращаться в него много раз за время своей жизни. Странно и неудобно.
Я не понимаю, что и зачем ты пытаешься объяснить. Я говорил, что меня смутило, что перезагружается не "root", а только одна из его веток, которая помечена как "текущая сцена". Изначально я начал использовать reload_current_scene() в качестве замены нажатия F5 в редакторе, чтобы не перезагружать всю игру целиком, если мне нужно сбросить сцену для теста. Выглядит нелогичным, что нода-синглтон (UI) имеет особые привилегии перед обычной нодой (menu_location).
>рекомендую ознакомиться с remote
Да знаю я про remote, ещё несколько лет назад в туториале к Godot 2 про неё узнал (а потом забил на Godot и вообще любые готовые движки и сам геймдев). Толку-то от неё, если у меня в тестовой сцене сотни нод. Она может помочь только в отладке мелких сцен, и то если какая-то ошибка возникнет...
>>55742
>Правда с потоками особо не работал, хоть и понимаю их суть.
В данном конкретном случае суть в том, чтобы не тормозить главный поток. В обычном приложении главный поток может общаться с пользователем через нажатия кнопок и всякие анимации, тогда как в фоне крутится несколько потоков, занятых долгими или тяжёлыми процессами. Конкретно в игре я бы хотел (попробовать) выделить генерацию в отдельный поток, чтобы игрок мог сразу бегать по карте, пока она ещё не до конца прогрузилась. Да и систему ИИ было бы неплохо выделить в отдельный поток, но это я планирую сделать с помощью GDNative и всё того же Паскаля; можно и генерацию так же сделать, но я хотел поэкспериментировать на GDScript для начала. Знаю, что многопоточность можно симулировать на уровне приложения, но париться с этим желания нет, раз уж мы сидим на многопоточной ОС.
>Статическая функция уже не является методом объекта, описываемого скриптом. У неё нет доступа к методам и полям-переменным
Тогда какой в ней смысл? Память она всё равно занимает, выделить в отдельный файл-модуль всё равно нельзя, выполнение вызывающего кода всё равно блокирует. Я когда в ООП-стиле на паскале пишу, практически не создаю простые функции и процедуры, а static методы вообще никогда не создавал...
>Сигналы это полный аналог ивентов в том же дельфи. Полнейший. Доходят так же.
Эммм, я не создавал свои собственные ивенты в Delphi/Lazarus, но насколько мне известно, TApplication работает в единственном потоке, и событие мгновенно вызывает связанный с ним обработчик, ничего никуда не "доходит". Это значит, что если обработчик содержит тяжёлый код, срабатывание события вызовет зависание основного потока... Нехорошо.
>Однако, это совершенно иная подсистема и её не желательно путать с сигналами-ивентами
Ну "система сообщений" в моём представлении хранит в себе "сообщения" и периодически пытается доставить эти сообщения подключённым к ней сущностям, когда те будут готовы к приёму. То есть она должна работать в отдельном потоке, и раздавать сообщения не мгновенно, а по мере возможности. Про сообщения из WinAPI прекрасно знаю и много раз работал с ними, они примерно то, о чём я говорю, наверное, т.к. они доставляются по мере возможности - если приложение зависло, очередь сообщений забивается, например.
>Удивляюсь, почему ты, обладая знаниями паскаля, не понял как это всё устроено. Там вообще ничего сложного нет.
Главным образом я не могу понять концепцию "скриптов". Потому что когда я пишу код на Паскале или любом другом компилируемом ЯП, я чётко вижу единственную точку входа в программу, хотя бы примерно понимаю, что происходит под капотом того же TApplication, когда и при каких обстоятельствах вызываются все процедуры. А при написании скрипта для игрового объекта в любом игровом движке у меня ощущение, будто скрипт "авось выполнится, а может и нет", и вообще не имеет никакой связи с другими скриптами. Очень трудно писать код, когда он не является цельной программой.
Я вот вижу, что .gd-файл - это класс, и от него можно наследоваться, что примерно похоже на подключение модуля, но собственно подключения модулей так и не нашёл. То есть, например, для каких-то утилит мне нужно создавать отдельный класс, добавлять его в автозагрузку, и обращаться по имени класса, вместо того, чтобы явным образом подключить необходимый модуль к нуждающемуся в нём скрипту...
Эх, если б я мог осилить математику и не ленился/боялся, я бы давно на своём движке кодил. Может быть, даже сделал бы свой собственный ЯП, кто знает, заготовки валяются без дела...
А, ну да, я так-то планировал собственную скриптовую систему, и поэтому понимаю, что каждый скрипт обрабатывается независимо интерпретатором, но вместе их связывает общее хранилище каких-то данных и общая библиотека базовых функций интерпретатора. Вот только не зная подкапотной работы интерпретатора, трудно представить и удерживать в голове то, как будут вести себя твои скрипты, и это раздражает.
Вот, кстати, второй раз забываю спросить - почему в GDScript не предусмотрен деструктор класса? Роль конструктора по идее выполняет ready, хоть он и вызывается позже enter_tree, но деструктора нет. Пробовал использовать какой-то костыль, но он то ли не работает, то ли работает не так, как я думал, а тот же exit_tree в качестве деструктора нельзя использовать, т.к. нода может покидать дерево и возвращаться в него много раз за время своей жизни. Странно и неудобно.
10 Кб, 243x252>>55709
Я не понимаю, что и зачем ты пытаешься объяснить. Я говорил, что меня смутило, что перезагружается не "root", а только одна из его веток, которая помечена как "текущая сцена". Изначально я начал использовать reload_current_scene() в качестве замены нажатия F5 в редакторе, чтобы не перезагружать всю игру целиком, если мне нужно сбросить сцену для теста. Выглядит нелогичным, что нода-синглтон (UI) имеет особые привилегии перед обычной нодой (menu_location).
Да знаю я про remote, ещё несколько лет назад в туториале к Godot 2 про неё узнал (а потом забил на Godot и вообще любые готовые движки и сам геймдев). Толку-то от неё, если у меня в тестовой сцене сотни нод. Она может помочь только в отладке мелких сцен, и то если какая-то ошибка возникнет...
>>55742
В данном конкретном случае суть в том, чтобы не тормозить главный поток. В обычном приложении главный поток может общаться с пользователем через нажатия кнопок и всякие анимации, тогда как в фоне крутится несколько потоков, занятых долгими или тяжёлыми процессами. Конкретно в игре я бы хотел (попробовать) выделить генерацию в отдельный поток, чтобы игрок мог сразу бегать по карте, пока она ещё не до конца прогрузилась. Да и систему ИИ было бы неплохо выделить в отдельный поток, но это я планирую сделать с помощью GDNative и всё того же Паскаля; можно и генерацию так же сделать, но я хотел поэкспериментировать на GDScript для начала. Знаю, что многопоточность можно симулировать на уровне приложения, но париться с этим желания нет, раз уж мы сидим на многопоточной ОС.
Тогда какой в ней смысл? Память она всё равно занимает, выделить в отдельный файл-модуль всё равно нельзя, выполнение вызывающего кода всё равно блокирует. Я когда в ООП-стиле на паскале пишу, практически не создаю простые функции и процедуры, а static методы вообще никогда не создавал...
Эммм, я не создавал свои собственные ивенты в Delphi/Lazarus, но насколько мне известно, TApplication работает в единственном потоке, и событие мгновенно вызывает связанный с ним обработчик, ничего никуда не "доходит". Это значит, что если обработчик содержит тяжёлый код, срабатывание события вызовет зависание основного потока... Нехорошо.
Ну "система сообщений" в моём представлении хранит в себе "сообщения" и периодически пытается доставить эти сообщения подключённым к ней сущностям, когда те будут готовы к приёму. То есть она должна работать в отдельном потоке, и раздавать сообщения не мгновенно, а по мере возможности. Про сообщения из WinAPI прекрасно знаю и много раз работал с ними, они примерно то, о чём я говорю, наверное, т.к. они доставляются по мере возможности - если приложение зависло, очередь сообщений забивается, например.
Главным образом я не могу понять концепцию "скриптов". Потому что когда я пишу код на Паскале или любом другом компилируемом ЯП, я чётко вижу единственную точку входа в программу, хотя бы примерно понимаю, что происходит под капотом того же TApplication, когда и при каких обстоятельствах вызываются все процедуры. А при написании скрипта для игрового объекта в любом игровом движке у меня ощущение, будто скрипт "авось выполнится, а может и нет", и вообще не имеет никакой связи с другими скриптами. Очень трудно писать код, когда он не является цельной программой.
Я вот вижу, что .gd-файл - это класс, и от него можно наследоваться, что примерно похоже на подключение модуля, но собственно подключения модулей так и не нашёл. То есть, например, для каких-то утилит мне нужно создавать отдельный класс, добавлять его в автозагрузку, и обращаться по имени класса, вместо того, чтобы явным образом подключить необходимый модуль к нуждающемуся в нём скрипту...
Эх, если б я мог осилить математику и не ленился/боялся, я бы давно на своём движке кодил. Может быть, даже сделал бы свой собственный ЯП, кто знает, заготовки валяются без дела...
А, ну да, я так-то планировал собственную скриптовую систему, и поэтому понимаю, что каждый скрипт обрабатывается независимо интерпретатором, но вместе их связывает общее хранилище каких-то данных и общая библиотека базовых функций интерпретатора. Вот только не зная подкапотной работы интерпретатора, трудно представить и удерживать в голове то, как будут вести себя твои скрипты, и это раздражает.
Вот, кстати, второй раз забываю спросить - почему в GDScript не предусмотрен деструктор класса? Роль конструктора по идее выполняет ready, хоть он и вызывается позже enter_tree, но деструктора нет. Пробовал использовать какой-то костыль, но он то ли не работает, то ли работает не так, как я думал, а тот же exit_tree в качестве деструктора нельзя использовать, т.к. нода может покидать дерево и возвращаться в него много раз за время своей жизни. Странно и неудобно.
Я не понимаю, что и зачем ты пытаешься объяснить. Я говорил, что меня смутило, что перезагружается не "root", а только одна из его веток, которая помечена как "текущая сцена". Изначально я начал использовать reload_current_scene() в качестве замены нажатия F5 в редакторе, чтобы не перезагружать всю игру целиком, если мне нужно сбросить сцену для теста. Выглядит нелогичным, что нода-синглтон (UI) имеет особые привилегии перед обычной нодой (menu_location).
>рекомендую ознакомиться с remote
Да знаю я про remote, ещё несколько лет назад в туториале к Godot 2 про неё узнал (а потом забил на Godot и вообще любые готовые движки и сам геймдев). Толку-то от неё, если у меня в тестовой сцене сотни нод. Она может помочь только в отладке мелких сцен, и то если какая-то ошибка возникнет...
>>55742
>Правда с потоками особо не работал, хоть и понимаю их суть.
В данном конкретном случае суть в том, чтобы не тормозить главный поток. В обычном приложении главный поток может общаться с пользователем через нажатия кнопок и всякие анимации, тогда как в фоне крутится несколько потоков, занятых долгими или тяжёлыми процессами. Конкретно в игре я бы хотел (попробовать) выделить генерацию в отдельный поток, чтобы игрок мог сразу бегать по карте, пока она ещё не до конца прогрузилась. Да и систему ИИ было бы неплохо выделить в отдельный поток, но это я планирую сделать с помощью GDNative и всё того же Паскаля; можно и генерацию так же сделать, но я хотел поэкспериментировать на GDScript для начала. Знаю, что многопоточность можно симулировать на уровне приложения, но париться с этим желания нет, раз уж мы сидим на многопоточной ОС.
>Статическая функция уже не является методом объекта, описываемого скриптом. У неё нет доступа к методам и полям-переменным
Тогда какой в ней смысл? Память она всё равно занимает, выделить в отдельный файл-модуль всё равно нельзя, выполнение вызывающего кода всё равно блокирует. Я когда в ООП-стиле на паскале пишу, практически не создаю простые функции и процедуры, а static методы вообще никогда не создавал...
>Сигналы это полный аналог ивентов в том же дельфи. Полнейший. Доходят так же.
Эммм, я не создавал свои собственные ивенты в Delphi/Lazarus, но насколько мне известно, TApplication работает в единственном потоке, и событие мгновенно вызывает связанный с ним обработчик, ничего никуда не "доходит". Это значит, что если обработчик содержит тяжёлый код, срабатывание события вызовет зависание основного потока... Нехорошо.
>Однако, это совершенно иная подсистема и её не желательно путать с сигналами-ивентами
Ну "система сообщений" в моём представлении хранит в себе "сообщения" и периодически пытается доставить эти сообщения подключённым к ней сущностям, когда те будут готовы к приёму. То есть она должна работать в отдельном потоке, и раздавать сообщения не мгновенно, а по мере возможности. Про сообщения из WinAPI прекрасно знаю и много раз работал с ними, они примерно то, о чём я говорю, наверное, т.к. они доставляются по мере возможности - если приложение зависло, очередь сообщений забивается, например.
>Удивляюсь, почему ты, обладая знаниями паскаля, не понял как это всё устроено. Там вообще ничего сложного нет.
Главным образом я не могу понять концепцию "скриптов". Потому что когда я пишу код на Паскале или любом другом компилируемом ЯП, я чётко вижу единственную точку входа в программу, хотя бы примерно понимаю, что происходит под капотом того же TApplication, когда и при каких обстоятельствах вызываются все процедуры. А при написании скрипта для игрового объекта в любом игровом движке у меня ощущение, будто скрипт "авось выполнится, а может и нет", и вообще не имеет никакой связи с другими скриптами. Очень трудно писать код, когда он не является цельной программой.
Я вот вижу, что .gd-файл - это класс, и от него можно наследоваться, что примерно похоже на подключение модуля, но собственно подключения модулей так и не нашёл. То есть, например, для каких-то утилит мне нужно создавать отдельный класс, добавлять его в автозагрузку, и обращаться по имени класса, вместо того, чтобы явным образом подключить необходимый модуль к нуждающемуся в нём скрипту...
Эх, если б я мог осилить математику и не ленился/боялся, я бы давно на своём движке кодил. Может быть, даже сделал бы свой собственный ЯП, кто знает, заготовки валяются без дела...
А, ну да, я так-то планировал собственную скриптовую систему, и поэтому понимаю, что каждый скрипт обрабатывается независимо интерпретатором, но вместе их связывает общее хранилище каких-то данных и общая библиотека базовых функций интерпретатора. Вот только не зная подкапотной работы интерпретатора, трудно представить и удерживать в голове то, как будут вести себя твои скрипты, и это раздражает.
Вот, кстати, второй раз забываю спросить - почему в GDScript не предусмотрен деструктор класса? Роль конструктора по идее выполняет ready, хоть он и вызывается позже enter_tree, но деструктора нет. Пробовал использовать какой-то костыль, но он то ли не работает, то ли работает не так, как я думал, а тот же exit_tree в качестве деструктора нельзя использовать, т.к. нода может покидать дерево и возвращаться в него много раз за время своей жизни. Странно и неудобно.
>>55767
Кстати, он прав, интерполировать строки действительно возможно.
И таки интерполяция строк была раньше интерполяции чисел, лол)
>что вы, зумеры подразумеваете под интерполяцей строк?
Кстати, он прав, интерполировать строки действительно возможно.
И таки интерполяция строк была раньше интерполяции чисел, лол)
>>55774
Какой латински, уёбок, блять? Interpolation = intercourse between two poles (nord, south, ord). Уёбина, блядь. Засунься в село из которого ты выполз, колхозан обосранный.
> Учи латинский, технарик.
Какой латински, уёбок, блять? Interpolation = intercourse between two poles (nord, south, ord). Уёбина, блядь. Засунься в село из которого ты выполз, колхозан обосранный.
>>55775
Утро вечера мудренее. Может завтра перечитаешь и поймёшь, может за ночь анон поумнее меня обеснит. Если вкратце: root не то, что перезагружается. Это вообще-то Viewport. Он как бы должен всегда существовать, это олицетворение контекста, в который выводится игра.
UI - загружен через автолоад.
menu_scene - загружена через change_scene() и является current_scene. После того, как игра стартует, на её место встаёт другой инстанс из файла tscn. Другая "сцена", которая, как я коряво пытался объяснить, не вся сцена, а подсцена сцены.
https://docs.godotengine.org/ru/latest/tutorials/threads/thread_safe_apis.html
> Я не понимаю, что и зачем ты пытаешься объяснить. Я говорил, что меня смутило, что перезагружается не "root", а только одна из его веток, которая помечена как "текущая сцена". Изначально я начал использовать reload_current_scene() в качестве замены нажатия F5 в редакторе, чтобы не перезагружать всю игру целиком, если мне нужно сбросить сцену для теста. Выглядит нелогичным, что нода-синглтон (UI) имеет особые привилегии перед обычной нодой (menu_location).
Утро вечера мудренее. Может завтра перечитаешь и поймёшь, может за ночь анон поумнее меня обеснит. Если вкратце: root не то, что перезагружается. Это вообще-то Viewport. Он как бы должен всегда существовать, это олицетворение контекста, в который выводится игра.
> В чём между ними разница?
UI - загружен через автолоад.
menu_scene - загружена через change_scene() и является current_scene. После того, как игра стартует, на её место встаёт другой инстанс из файла tscn. Другая "сцена", которая, как я коряво пытался объяснить, не вся сцена, а подсцена сцены.
> В обычном приложении главный поток может общаться с пользователем через нажатия кнопок и всякие анимации, тогда как в фоне крутится несколько потоков, занятых долгими или тяжёлыми процессами.
https://docs.godotengine.org/ru/latest/tutorials/threads/thread_safe_apis.html
>>55780
Нет ты.
Нет ты.
>>55784
Лол. Я ж и грю - зумеры в конец охуели.
Лол. Я ж и грю - зумеры в конец охуели.
>>55543
Я нарисовал два почти одинаковых квадрата (набора) 8х8 (с учётом неровных границ они превратились в 10х10), получилось достаточно разнообразно, чтобы в любой конфигурации найти более-менее незаметный стык.
Аригато, я уже всё нагуглил и опробовал.
>тебе всё равно ведь придётся замыкать тайлы
Я нарисовал два почти одинаковых квадрата (набора) 8х8 (с учётом неровных границ они превратились в 10х10), получилось достаточно разнообразно, чтобы в любой конфигурации найти более-менее незаметный стык.
>Там-то точно получится, но для импорта понадобится инструмент:
Аригато, я уже всё нагуглил и опробовал.
А правда, что порядок элементов одного уровня в древе сцены соответствует порядку загрузки? Если да, то можно на это рассчитывать, или все же лучше на это не надеяться и писать костыли, чтобы действия в принципе не могли выполниться в неверном порядке?
>>55818
Вообще, выглядит как правда. И ты можешь сам это проверить. Можешь обезопасить себя, конечно, но это лишнее, ИМХО. Порядок загрузки, порядок чтения файлов это все вещи фундаментальные и их менять не предполагается. Когда меняют такие фундаментальные вещи, то заявляют вслух о несовместимости новых версий со старыми.
Вообще, выглядит как правда. И ты можешь сам это проверить. Можешь обезопасить себя, конечно, но это лишнее, ИМХО. Порядок загрузки, порядок чтения файлов это все вещи фундаментальные и их менять не предполагается. Когда меняют такие фундаментальные вещи, то заявляют вслух о несовместимости новых версий со старыми.
>>55818
Да, это так. Попробуй набросать несколько нод с кодом:
func _enter_tree():
print(name, " enters tree")
func _ready():
print(name, " are ready")
func _exit_tree():
print(name, " leaves tree")
Когда запустишь, увидишь, что ноды входят в дерево и готовятся к работе в прямом порядке, а выходят в обратном порядке. Иногда это может быть важно, да. Например, если у тебя две камеры, то первой перехватит управление та, что войдёт дерево раньше, и через неё будет идти рендеринг - поэтому если камер несколько, Player со своей камерой должен находиться выше остальных камер.
>порядок элементов одного уровня в древе сцены соответствует порядку загрузки
Да, это так. Попробуй набросать несколько нод с кодом:
func _enter_tree():
print(name, " enters tree")
func _ready():
print(name, " are ready")
func _exit_tree():
print(name, " leaves tree")
Когда запустишь, увидишь, что ноды входят в дерево и готовятся к работе в прямом порядке, а выходят в обратном порядке. Иногда это может быть важно, да. Например, если у тебя две камеры, то первой перехватит управление та, что войдёт дерево раньше, и через неё будет идти рендеринг - поэтому если камер несколько, Player со своей камерой должен находиться выше остальных камер.
>>55919
Порядок входа в сцену\инициализации\прочего говна.
Порядок входа в сцену\инициализации\прочего говна.
>>55934
Я имел ввиду что она это делает тоже при инициализации
>одна из которых загружает переменные другой
Я имел ввиду что она это делает тоже при инициализации
>>55232
Напиши свой алгоритм поиска пути, например "Первый лучший" и вставь местам, где "дорожка" ниже коэффициент маршрута.
Напиши свой алгоритм поиска пути, например "Первый лучший" и вставь местам, где "дорожка" ниже коэффициент маршрута.
>>55934
Полетит или не полетит - попробуй и узнаешь сам. Но скорее всего полетит, потому что соседняя сущность ещё не существует и будет обращение к null (точнее get_node() не сможет найти и вернёт null, к которому ты обратишься). Лучше переделай код, тут вот выше уже обсуждалось, что лучше иметь обращения только к потомкам (ready() предка вызывается после всех ready() потомков).
>все полетит к херам собачьим?
Полетит или не полетит - попробуй и узнаешь сам. Но скорее всего полетит, потому что соседняя сущность ещё не существует и будет обращение к null (точнее get_node() не сможет найти и вернёт null, к которому ты обратишься). Лучше переделай код, тут вот выше уже обсуждалось, что лучше иметь обращения только к потомкам (ready() предка вызывается после всех ready() потомков).
>>55990
Да это даже обсуждать не надо. Я нюфаня в годо, но и я понимаю, что не стоит.
>тут вот выше уже обсуждалось, что лучше иметь обращения только к потомкам
Да это даже обсуждать не надо. Я нюфаня в годо, но и я понимаю, что не стоит.
>>55989
Да мне нужно было тупо сразу Википедию почитать:
Короче Navigation Godot'а нужен по большому счёту для стратегий, где не бывает сложной геометрии уровня.
Да мне нужно было тупо сразу Википедию почитать:
>В жанре 3D-шутеров используются намного более ограниченные пространства, которые не так легко разделить на узлы. Здесь взамен узлов используются так называемые waypoints (дословно с англ. — «точки пути»). Waypoints — это нерегулярные и вручную установленные узлы, которые содержат информацию о том, к каким другим узлам возможно добраться от данного.
Короче Navigation Godot'а нужен по большому счёту для стратегий, где не бывает сложной геометрии уровня.
>>56021
Всё, нашёл.
Всё, нашёл.
>>56160
Ну я и говорю, что полноценный астар - оверкилл для всего шутаноподобного. Вроде бы.
Ну я и говорю, что полноценный астар - оверкилл для всего шутаноподобного. Вроде бы.
Чёт я немного подзадолбался.
Делаю двадэ-анимацию по принципу "одна кость - одна картинка". Чтобы никаких артефактов на сгибах. Делаю по инструкции как у этого чувака https://www.youtube.com/watch?v=QL57J3anDTU - и стопорюсь на этапе IK. Правая рука ведёт себя правильно, причём не по старому методу, описанному в видео, а по новому, про который он сказал, мол, пока ещё не работает (у него версия 3.1). А с левой рукой не срабатывает. Как будто никакой привязки графики к костям нету, картинка не двигается вместе с костью, к тому же кость растягивается, будто никакого IK нету. Хотя я абсолютно одинаково всё сделал с левой и с правой стороной.
То есть, я двигаю кость предплечья, само предплечье с ней вместе двигается, плечо стоит на месте, кость плеча растягивается. Двигаю кость плеча - двигается плечо и предплечье вместе с костью. Попробовал отсоединить скелет, всё заново просинхронизировать. Смог заставить правильно работать одну ногу, вторая не хочет. Куда копать? Что курить? Где гуглить?
Делаю двадэ-анимацию по принципу "одна кость - одна картинка". Чтобы никаких артефактов на сгибах. Делаю по инструкции как у этого чувака https://www.youtube.com/watch?v=QL57J3anDTU - и стопорюсь на этапе IK. Правая рука ведёт себя правильно, причём не по старому методу, описанному в видео, а по новому, про который он сказал, мол, пока ещё не работает (у него версия 3.1). А с левой рукой не срабатывает. Как будто никакой привязки графики к костям нету, картинка не двигается вместе с костью, к тому же кость растягивается, будто никакого IK нету. Хотя я абсолютно одинаково всё сделал с левой и с правой стороной.
То есть, я двигаю кость предплечья, само предплечье с ней вместе двигается, плечо стоит на месте, кость плеча растягивается. Двигаю кость плеча - двигается плечо и предплечье вместе с костью. Попробовал отсоединить скелет, всё заново просинхронизировать. Смог заставить правильно работать одну ногу, вторая не хочет. Куда копать? Что курить? Где гуглить?
22 Кб, 391x373>>56332
Мы тут экстрасенсы что ли? Не проще найти готовый шаблон/демо? Пикрил, например, хоть это и 3D, но прицип скорее всего тот же.
Мы тут экстрасенсы что ли? Не проще найти готовый шаблон/демо? Пикрил, например, хоть это и 3D, но прицип скорее всего тот же.
>>56346
Нет, не проще. Терпеть не могу в чужом коде ковыряться.
Впрочем, я уже нашёл более простое решение для себя: https://docs.godotengine.org/ru/latest/tutorials/animation/cutout_animation.html#doc-cutout-animation - гораздо меньше возни, никаких искажений и всё работает.
>Не проще найти готовый шаблон/демо?
Нет, не проще. Терпеть не могу в чужом коде ковыряться.
Впрочем, я уже нашёл более простое решение для себя: https://docs.godotengine.org/ru/latest/tutorials/animation/cutout_animation.html#doc-cutout-animation - гораздо меньше возни, никаких искажений и всё работает.
>>56347
а другим предлагаешь ковыряться в твоем, причем еще и на словах
> Нет, не проще. Терпеть не могу в чужом коде ковыряться.
а другим предлагаешь ковыряться в твоем, причем еще и на словах
>>56366
Ему все равно придется генерировать сетку way-point-ов, т.к. a-star в шутане определит путь в комнате и нескольких прилежащих, но на чуть дальние расстояния он уже не осилит, тем более в шутане. Так что тут надо комбинированный подход нави-сеток делать.
Ему все равно придется генерировать сетку way-point-ов, т.к. a-star в шутане определит путь в комнате и нескольких прилежащих, но на чуть дальние расстояния он уже не осилит, тем более в шутане. Так что тут надо комбинированный подход нави-сеток делать.
>>56373
В видосе выше показан простой и удобный метод генерации вейпоинтов, который работает как в дизайнтайме, так и в рантайме. Не вижу проблемы. Если анон и ниасилит, то только из-за своей лени.
В видосе выше показан простой и удобный метод генерации вейпоинтов, который работает как в дизайнтайме, так и в рантайме. Не вижу проблемы. Если анон и ниасилит, то только из-за своей лени.
4 Кб, 680x44Привет, народ. Возник такой вопрос: как сохранять игру из паузы? Для паузы использую функцию get_tree().paused. Но во время вызова функции сохранения получаю ошибку с пикрила. Может кто подскажет: как исправить это?
21 Кб, 395x200>>56365
А когда она будет-то, четвёрка эта? Надеюсь, обратную совместимость не сломают...
А когда она будет-то, четвёрка эта? Надеюсь, обратную совместимость не сломают...
>>56550
Такое сообщение выбрасывается, когда ты где-то теряешь ссылку на сущность. Снабди код проверками на null, где возможно, и выводи собственные ошибки в консоль, чтобы знать, где ссылка теряется. Ну или просто тщательно код пересмотри, где вероятнее всего могут возникать null-ы?
Функцию сам писал же? Вот в ней и нужно разбираться, где там у тебя ссылки на null.
Сам я пока не разбирался в функционале паузы и сохранения, но по идее paused просто меняет внутреннее состояние нод, и не должно ломать ссылки. Поэтому скорее всего ты сам где-то ссылки теряешь, или небезопасно уничтожаешь какие-то объекты. Может, какой-то код написал и забыл про него, а он сейчас реагирует неправильно.
Такое сообщение выбрасывается, когда ты где-то теряешь ссылку на сущность. Снабди код проверками на null, где возможно, и выводи собственные ошибки в консоль, чтобы знать, где ссылка теряется. Ну или просто тщательно код пересмотри, где вероятнее всего могут возникать null-ы?
>во время вызова функции сохранения
Функцию сам писал же? Вот в ней и нужно разбираться, где там у тебя ссылки на null.
Сам я пока не разбирался в функционале паузы и сохранения, но по идее paused просто меняет внутреннее состояние нод, и не должно ломать ссылки. Поэтому скорее всего ты сам где-то ссылки теряешь, или небезопасно уничтожаешь какие-то объекты. Может, какой-то код написал и забыл про него, а он сейчас реагирует неправильно.
>>56555
Не будет обратной совместимости.
Не будет обратной совместимости.
Сделал 2д-рэгдолл, у которого при этом имеется удобно анимируемый скелет. Красиво складывается при падении на твёрдую поверхность. Теперь надо как-то к нему прикрутить сами анимации, чтобы при этом физика не мешала. Ещё не гуглил, как это делается, просто отписываюсь о достигнутом успехе. Ща займусь.
>>56550
Привет!
Добро пожаловать в Годо-15! Лучший тред из оставшихся.
Я сегодня как раз размышлял над удобной системой схоронения. И придумал следующие положения:
1. Данные сохранения подготавливаются как словарь (Dictionary) в глобальной области (автозагруженном скрипте).
2. Сущности, которые должны сохранять данные обладают компонентом сохранения, который гибко настраивается.
3. Развешиваем компонент на нужные ноды.
4. Подписываем компонент на сигналы сохранения и загрузки.
Вот накидал примерчик. Я разделяю свойства полученные через геттер, чтобы в дальнейшем выставлять их через сеттер, а остальные напрямую. Ну и save_example это разумеется не настоящие данные сохранения, а показанные для примера.
Логика токова: когда игрок нажимает эфпяточку, генерируется сигнал collect_save_data после чего все подписанные на него сэйверы наполняют словарь данными, разбитыми, как видно из кода по овнерам (рутам субсцен), парентам и могут сами содержать подразделы-словари. Затем нужно подождать, пока все данные соберутся. Я пока ещё не придумал, как. После того, как данные соберутся, генерируется сигнал save_game который собственно записывает содержимое в файл.
Загрузка работает в обратном порядке. Но надо дополнительно смотреть, существуют ли указанные в файле объекты и если нет - сначала создавать, а потом разсериализовывать им свойства.
Привет!
Добро пожаловать в Годо-15! Лучший тред из оставшихся.
Я сегодня как раз размышлял над удобной системой схоронения. И придумал следующие положения:
1. Данные сохранения подготавливаются как словарь (Dictionary) в глобальной области (автозагруженном скрипте).
2. Сущности, которые должны сохранять данные обладают компонентом сохранения, который гибко настраивается.
3. Развешиваем компонент на нужные ноды.
4. Подписываем компонент на сигналы сохранения и загрузки.
Вот накидал примерчик. Я разделяю свойства полученные через геттер, чтобы в дальнейшем выставлять их через сеттер, а остальные напрямую. Ну и save_example это разумеется не настоящие данные сохранения, а показанные для примера.
Логика токова: когда игрок нажимает эфпяточку, генерируется сигнал collect_save_data после чего все подписанные на него сэйверы наполняют словарь данными, разбитыми, как видно из кода по овнерам (рутам субсцен), парентам и могут сами содержать подразделы-словари. Затем нужно подождать, пока все данные соберутся. Я пока ещё не придумал, как. После того, как данные соберутся, генерируется сигнал save_game который собственно записывает содержимое в файл.
Загрузка работает в обратном порядке. Но надо дополнительно смотреть, существуют ли указанные в файле объекты и если нет - сначала создавать, а потом разсериализовывать им свойства.
>>56600
И да. Разумеется, это работает с пользовательскими свойствами, созданными в скриптах. Вот я создал свойство, указал его в инспекторе и вуаля!
Кому-то может показаться неудобным выставление свойств строками в массиве - нет защиты от опечаток. Штош. Пишите аддон. Чтобы как у аниматора ключики - у сэйвера стояли значки для отбора сохраняемых свойств.
И да. Разумеется, это работает с пользовательскими свойствами, созданными в скриптах. Вот я создал свойство, указал его в инспекторе и вуаля!
Кому-то может показаться неудобным выставление свойств строками в массиве - нет защиты от опечаток. Штош. Пишите аддон. Чтобы как у аниматора ключики - у сэйвера стояли значки для отбора сохраняемых свойств.
>>56600
По-моему твой способ мудрёный и не для всякой игры подойдёт.
Я вот собираюсь попробовать это - https://godotengine.org/qa/903/how-to-save-a-scene-at-run-time
Т.к. мне вся сцена целиком нужна, а не только отдельные свойства отдельных объектов...
И почему добавление random() так сильно замедляет загрузку сцен?..
По-моему твой способ мудрёный и не для всякой игры подойдёт.
Я вот собираюсь попробовать это - https://godotengine.org/qa/903/how-to-save-a-scene-at-run-time
Т.к. мне вся сцена целиком нужна, а не только отдельные свойства отдельных объектов...
И почему добавление random() так сильно замедляет загрузку сцен?..
Годаны, подскажите. Не понимаю, как гуглить.
Задача: найти всех потомков ноды, имеющих определённый тип (например, RigidBody2D), и со всеми проделать одну и ту же операцию (отключить обработку физики; я видел пару дней назад, как это делается, но уже тот видос потерял, придётся снова искать). Вот. Как найти всех потомков, соответствующих заданному типу? Ясно, что циклом for. А дальше? Анончик, может, какой-нибудь тутор по теме подкинешь?
Задача: найти всех потомков ноды, имеющих определённый тип (например, RigidBody2D), и со всеми проделать одну и ту же операцию (отключить обработку физики; я видел пару дней назад, как это делается, но уже тот видос потерял, придётся снова искать). Вот. Как найти всех потомков, соответствующих заданному типу? Ясно, что циклом for. А дальше? Анончик, может, какой-нибудь тутор по теме подкинешь?
>>56704
Буквально вчера писал
for b in $Container.get_children():
var body = b as RigidBody
if body: ...
Буквально вчера писал
for b in $Container.get_children():
var body = b as RigidBody
if body: ...
>>56704
Это очень просто:
for child in get_children():
if child is RigidBody2D:
(child as RigidBody2D).add_collision_exception_with(self)
Оператор is проверяет соответствие типу или классу.
Не уверен, нужно ли после проверки приведение типа (as), но без него подсказка в редакторе не работает.
...Блин, опоздал)
>>56718
1. Зачем отдельную переменную заводить?
2. Если оператор as ниасилит приведение типа, игра должна упасть с ошибкой.
Это очень просто:
for child in get_children():
if child is RigidBody2D:
(child as RigidBody2D).add_collision_exception_with(self)
Оператор is проверяет соответствие типу или классу.
Не уверен, нужно ли после проверки приведение типа (as), но без него подсказка в редакторе не работает.
...Блин, опоздал)
>>56718
1. Зачем отдельную переменную заводить?
2. Если оператор as ниасилит приведение типа, игра должна упасть с ошибкой.
>>56720
Там просто null будет, т.е. false, лол.
Переменная там чтобы не писать все по два раза как у тебя
Там просто null будет, т.е. false, лол.
Переменная там чтобы не писать все по два раза как у тебя
>>56720
>>56722
Я тут подумал, похоже не нужно делать лишнее приведение:
for child in get_children():
if child is RigidBody2D:
child.add_collision_exception_with(self)
Да, подсказки в редакторе кода не будет (т.к. подсказка не знает, какого типа child), но и ошибки тоже не будет.
Попытаться вызвать метод можно на любой объект, но сработает он только там, где действительно есть.
Поскольку мы уже проверили, что child нам подходит, мы можем вызывать из него что нам нужно.
>Не уверен, нужно ли после проверки приведение типа (as)
>>56722
>Переменная там чтобы не писать все по два раза как у тебя
Я тут подумал, похоже не нужно делать лишнее приведение:
for child in get_children():
if child is RigidBody2D:
child.add_collision_exception_with(self)
Да, подсказки в редакторе кода не будет (т.к. подсказка не знает, какого типа child), но и ошибки тоже не будет.
Попытаться вызвать метод можно на любой объект, но сработает он только там, где действительно есть.
Поскольку мы уже проверили, что child нам подходит, мы можем вызывать из него что нам нужно.
>>56729
Зачем множить сущности без необходимости? Подсказки тебе нужны будут только один раз при написании кода, а память под переменную будет выделяться каждый раз, когда этот код будет выполняться (возможно, 60 раз в секунду, лол). Может мы и пишем на скриптовом ЯП, которой по определению неполноценен в сравнении с компилируемыми ЯП, но всё-таки должны думать о производительности нашего кода.
Зачем множить сущности без необходимости? Подсказки тебе нужны будут только один раз при написании кода, а память под переменную будет выделяться каждый раз, когда этот код будет выполняться (возможно, 60 раз в секунду, лол). Может мы и пишем на скриптовом ЯП, которой по определению неполноценен в сравнении с компилируемыми ЯП, но всё-таки должны думать о производительности нашего кода.
>>56784
Не знаю на счёт "всех", но конкретно доступ к экземплярам классов идёт по ссылкам, как и в любом другом ЯП - то есть a = b не создаёт копию, а копирует ссылку (было бы глупо делать так с обычными типами). Вопрос в том, куда копирует, сколько весит ссылка, насколько дорогая эта операция и оптимизируется ли она интерпретатором?
В FreePascal, например, указатель занимает 4 байта для x86 и 8 байт для x64 (в C++ наверняка так же). В GDScript вес может быть меньше (т.к. адресация не в реальной RAM, а в интерпретаторе), но при этом неизвестно, какую информацию он несёт в себе помимо ссылки (может нести сведения о типе, как Variant).
Впрочем, да, это экономия на спичках, если только не делается много раз каждый кадр. То есть даже такая маленькая экономия в каком-то цикле, вызываемом каждый кадр, может оказаться существенной, но в остальных случаях заметных отличий не будет. Но речь как раз шла о for, в котором на каждой итерации создаётся (var...) переменная. Возможно, если создать переменную перед циклом, а в цикле только менять ссылку внутри неё, будет немного оптимальнее, но я предпочёл бы вообще не создавать лишнего. Переменная-итератор цикла уже хранит нужную нам ссылку, так зачем создавать её копию?
...я подумал - скорее всего все переменные тут - это Variant. Отличие Variant от Pointer в том, что Pointer хранит ссылку на какую-то область памяти, а Variant хранит любые данные и тип этих данных, в т.ч. может хранить Pointer. Pointer может указывать на любые данные в памяти, но он ничего не говорит ни об их типе, ни об их размере. Variant сам по себе может содержать любые данные, но тратится лишнее время на определение типа данных перед каждой операцией с ним. Но поскольку ссылка на экземпляр класса хранится в обычной переменной (в которой может храниться что угодно), то мы получаем Pointer, упакованный в Variant, а это всё значительно усложняет.
Кстати, когда искал про массивы в GDScript, обнаружил, что обычный массив[] - это массив Variant, из-за чего работа с массивами в GDScript медленная. Разработчик обещал когда-нибудь ввести типизированные массивы для увеличения производительности, но пока есть только Pool-ы... Значит, операции с переменными не такие уж и дешёвые.
>Разве? Мне где-то попадалось, что в Годоте все переменные это ссылки.
Не знаю на счёт "всех", но конкретно доступ к экземплярам классов идёт по ссылкам, как и в любом другом ЯП - то есть a = b не создаёт копию, а копирует ссылку (было бы глупо делать так с обычными типами). Вопрос в том, куда копирует, сколько весит ссылка, насколько дорогая эта операция и оптимизируется ли она интерпретатором?
В FreePascal, например, указатель занимает 4 байта для x86 и 8 байт для x64 (в C++ наверняка так же). В GDScript вес может быть меньше (т.к. адресация не в реальной RAM, а в интерпретаторе), но при этом неизвестно, какую информацию он несёт в себе помимо ссылки (может нести сведения о типе, как Variant).
Впрочем, да, это экономия на спичках, если только не делается много раз каждый кадр. То есть даже такая маленькая экономия в каком-то цикле, вызываемом каждый кадр, может оказаться существенной, но в остальных случаях заметных отличий не будет. Но речь как раз шла о for, в котором на каждой итерации создаётся (var...) переменная. Возможно, если создать переменную перед циклом, а в цикле только менять ссылку внутри неё, будет немного оптимальнее, но я предпочёл бы вообще не создавать лишнего. Переменная-итератор цикла уже хранит нужную нам ссылку, так зачем создавать её копию?
...я подумал - скорее всего все переменные тут - это Variant. Отличие Variant от Pointer в том, что Pointer хранит ссылку на какую-то область памяти, а Variant хранит любые данные и тип этих данных, в т.ч. может хранить Pointer. Pointer может указывать на любые данные в памяти, но он ничего не говорит ни об их типе, ни об их размере. Variant сам по себе может содержать любые данные, но тратится лишнее время на определение типа данных перед каждой операцией с ним. Но поскольку ссылка на экземпляр класса хранится в обычной переменной (в которой может храниться что угодно), то мы получаем Pointer, упакованный в Variant, а это всё значительно усложняет.
Кстати, когда искал про массивы в GDScript, обнаружил, что обычный массив[] - это массив Variant, из-за чего работа с массивами в GDScript медленная. Разработчик обещал когда-нибудь ввести типизированные массивы для увеличения производительности, но пока есть только Pool-ы... Значит, операции с переменными не такие уж и дешёвые.
>>56784
Не знаю на счёт "всех", но конкретно доступ к экземплярам классов идёт по ссылкам, как и в любом другом ЯП - то есть a = b не создаёт копию, а копирует ссылку (было бы глупо делать так с обычными типами). Вопрос в том, куда копирует, сколько весит ссылка, насколько дорогая эта операция и оптимизируется ли она интерпретатором?
В FreePascal, например, указатель занимает 4 байта для x86 и 8 байт для x64 (в C++ наверняка так же). В GDScript вес может быть меньше (т.к. адресация не в реальной RAM, а в интерпретаторе), но при этом неизвестно, какую информацию он несёт в себе помимо ссылки (может нести сведения о типе, как Variant).
Впрочем, да, это экономия на спичках, если только не делается много раз каждый кадр. То есть даже такая маленькая экономия в каком-то цикле, вызываемом каждый кадр, может оказаться существенной, но в остальных случаях заметных отличий не будет. Но речь как раз шла о for, в котором на каждой итерации создаётся (var...) переменная. Возможно, если создать переменную перед циклом, а в цикле только менять ссылку внутри неё, будет немного оптимальнее, но я предпочёл бы вообще не создавать лишнего. Переменная-итератор цикла уже хранит нужную нам ссылку, так зачем создавать её копию?
...я подумал - скорее всего все переменные тут - это Variant. Отличие Variant от Pointer в том, что Pointer хранит ссылку на какую-то область памяти, а Variant хранит любые данные и тип этих данных, в т.ч. может хранить Pointer. Pointer может указывать на любые данные в памяти, но он ничего не говорит ни об их типе, ни об их размере. Variant сам по себе может содержать любые данные, но тратится лишнее время на определение типа данных перед каждой операцией с ним. Но поскольку ссылка на экземпляр класса хранится в обычной переменной (в которой может храниться что угодно), то мы получаем Pointer, упакованный в Variant, а это всё значительно усложняет.
Кстати, когда искал про массивы в GDScript, обнаружил, что обычный массив[] - это массив Variant, из-за чего работа с массивами в GDScript медленная. Разработчик обещал когда-нибудь ввести типизированные массивы для увеличения производительности, но пока есть только Pool-ы... Значит, операции с переменными не такие уж и дешёвые.
>Разве? Мне где-то попадалось, что в Годоте все переменные это ссылки.
Не знаю на счёт "всех", но конкретно доступ к экземплярам классов идёт по ссылкам, как и в любом другом ЯП - то есть a = b не создаёт копию, а копирует ссылку (было бы глупо делать так с обычными типами). Вопрос в том, куда копирует, сколько весит ссылка, насколько дорогая эта операция и оптимизируется ли она интерпретатором?
В FreePascal, например, указатель занимает 4 байта для x86 и 8 байт для x64 (в C++ наверняка так же). В GDScript вес может быть меньше (т.к. адресация не в реальной RAM, а в интерпретаторе), но при этом неизвестно, какую информацию он несёт в себе помимо ссылки (может нести сведения о типе, как Variant).
Впрочем, да, это экономия на спичках, если только не делается много раз каждый кадр. То есть даже такая маленькая экономия в каком-то цикле, вызываемом каждый кадр, может оказаться существенной, но в остальных случаях заметных отличий не будет. Но речь как раз шла о for, в котором на каждой итерации создаётся (var...) переменная. Возможно, если создать переменную перед циклом, а в цикле только менять ссылку внутри неё, будет немного оптимальнее, но я предпочёл бы вообще не создавать лишнего. Переменная-итератор цикла уже хранит нужную нам ссылку, так зачем создавать её копию?
...я подумал - скорее всего все переменные тут - это Variant. Отличие Variant от Pointer в том, что Pointer хранит ссылку на какую-то область памяти, а Variant хранит любые данные и тип этих данных, в т.ч. может хранить Pointer. Pointer может указывать на любые данные в памяти, но он ничего не говорит ни об их типе, ни об их размере. Variant сам по себе может содержать любые данные, но тратится лишнее время на определение типа данных перед каждой операцией с ним. Но поскольку ссылка на экземпляр класса хранится в обычной переменной (в которой может храниться что угодно), то мы получаем Pointer, упакованный в Variant, а это всё значительно усложняет.
Кстати, когда искал про массивы в GDScript, обнаружил, что обычный массив[] - это массив Variant, из-за чего работа с массивами в GDScript медленная. Разработчик обещал когда-нибудь ввести типизированные массивы для увеличения производительности, но пока есть только Pool-ы... Значит, операции с переменными не такие уж и дешёвые.
>>56804
Речь шла о том, чтобы один раз перебрать всех детей одной ноды. То есть, сам цикл не очень большой, вызываться будет далеко не каждый кадр.
Впрочем, да, лучше иметь привычку экономить ресурсы даже в таких мелочах.
>Но речь как раз шла о for, в котором на каждой итерации создаётся (var...) переменная.
Речь шла о том, чтобы один раз перебрать всех детей одной ноды. То есть, сам цикл не очень большой, вызываться будет далеко не каждый кадр.
Впрочем, да, лучше иметь привычку экономить ресурсы даже в таких мелочах.
164 Кб, 1024x768Такая мысль возникла... Видел у одного чувака проблемы с разными раскладками клавиатур (его игра заточена под en_US), понятия не имею, какой у него движок, но, похоже, он назначает действия в игре на коды клавиш, а не на скан-коды клавиш. Теперь меня беспокоит вот что: Godot назначает коды или скан-коды клавиш?
Если кто не знал:
https://ru.wikipedia.org/wiki/Скан-код
Суть в том, что клавиши клавиатуры имеют аппаратно прошитые скан-коды, а уже драйвер клавиатуры подбирает каждому скан-коду соответствующий код клавиши текущей раскладки ОС. Приложение, по сути, получает два кода - код клавиши и скан-код, а что из них использовать - дело разработчика. При наборе текста, например, нам не важно, где расположена клавиша, нам важен только её код (буква, цифра, символ), а вот в играх важно только расположение клавиш, т.е. нужно ориентироваться на скан-коды (исключение - чат, это набор текста).
Понятное дело, что можно сделать настройку клавиш в игре, но хотелось бы иметь нормальный биндинг по умолчанию для любой раскладки.
Для примера, сравните хотя бы QWERTY и AZERTY - привычный нам WASD во Франции выглядит как ZQSD.
Если кто не знал:
https://ru.wikipedia.org/wiki/Скан-код
Суть в том, что клавиши клавиатуры имеют аппаратно прошитые скан-коды, а уже драйвер клавиатуры подбирает каждому скан-коду соответствующий код клавиши текущей раскладки ОС. Приложение, по сути, получает два кода - код клавиши и скан-код, а что из них использовать - дело разработчика. При наборе текста, например, нам не важно, где расположена клавиша, нам важен только её код (буква, цифра, символ), а вот в играх важно только расположение клавиш, т.е. нужно ориентироваться на скан-коды (исключение - чат, это набор текста).
Понятное дело, что можно сделать настройку клавиш в игре, но хотелось бы иметь нормальный биндинг по умолчанию для любой раскладки.
Для примера, сравните хотя бы QWERTY и AZERTY - привычный нам WASD во Франции выглядит как ZQSD.
>>56840
Наличие проблем в крупных играх не говорит о том, что нужно добавлять эти пробелы в свои игры)
>>56840
Как уже сказали, рекурсия. Два варианта: либо такая функция:
func do_work(obj):
for child in obj.get_children():
if child.get_child_count() > 0:
do_work(child)
# тут работаем над самим child
else:
# тут работаем над самим child
Либо, если это делается в _ready(), тогда можно просто повесить скрипт на каждую ноду: _ready() вызывается последовательно сначала у самых дальних потомков, а потом постепенно поднимается до главного предка. Т.о. сначала вызовутся циклы у потомков, потом у их предков, и т.д. до главного предка. Но тут всё зависит от того, что за работу нужно сделать...
>Я даже более того тебе скажу. В некоторых крупных играх бывает такая же проблема с раскладками. НЯП, в Doom Eternal она есть, в "Сталкере" точно была.
Наличие проблем в крупных играх не говорит о том, что нужно добавлять эти пробелы в свои игры)
>>56840
>распространяется только на детей, внуков уже не берёт. А если надо обработать более-менее разветвлённое дерево?
Как уже сказали, рекурсия. Два варианта: либо такая функция:
func do_work(obj):
for child in obj.get_children():
if child.get_child_count() > 0:
do_work(child)
# тут работаем над самим child
else:
# тут работаем над самим child
Либо, если это делается в _ready(), тогда можно просто повесить скрипт на каждую ноду: _ready() вызывается последовательно сначала у самых дальних потомков, а потом постепенно поднимается до главного предка. Т.о. сначала вызовутся циклы у потомков, потом у их предков, и т.д. до главного предка. Но тут всё зависит от того, что за работу нужно сделать...
>>56855
То есть, какого-то простого метода, чтобы в одну строчку, как get_children(), не существует, я правильно понял? Надо описывать свою функцию для такой рутинной операции? Океей. Это немножко странно для годота, я уже успел привыкнуть, что на всякую объектную рутину здесь есть готовые функции, которые надо просто знать. Ещё и этот >>56852 хитрец загадками говорит, своими намёками утвердил меня в мысли, что есть однострочное решение.
То есть, какого-то простого метода, чтобы в одну строчку, как get_children(), не существует, я правильно понял? Надо описывать свою функцию для такой рутинной операции? Океей. Это немножко странно для годота, я уже успел привыкнуть, что на всякую объектную рутину здесь есть готовые функции, которые надо просто знать. Ещё и этот >>56852 хитрец загадками говорит, своими намёками утвердил меня в мысли, что есть однострочное решение.
Всё работает, поцоны! Написал немножко иначе:
func do_work(obj):
# можно сделать что-то с объектом вот тут
for child in obj.get_children():
if child.get_child_count() > 0:
do_work(child)
# а можно и вот тут, лишь бы не в теле цикла
Спасибо за пояснения, я бы так и долбился головой об стену, пытаясь найти несуществующее однострочное решение.
хотя я всё ещё считаю странным, что у get_children() нет аналога, который бы перебирал всё потомство, а не только детей
func do_work(obj):
# можно сделать что-то с объектом вот тут
for child in obj.get_children():
if child.get_child_count() > 0:
do_work(child)
# а можно и вот тут, лишь бы не в теле цикла
Спасибо за пояснения, я бы так и долбился головой об стену, пытаясь найти несуществующее однострочное решение.
хотя я всё ещё считаю странным, что у get_children() нет аналога, который бы перебирал всё потомство, а не только детей
>>56861
У меня тоже стойкое ощущение, что где-то в доках я видел рекурсивный вариант функции. Возможно вездесущий эффект Манделы, или что-то путаю.
> я всё ещё считаю странным, что у get_children() нет аналога, который бы перебирал всё потомство, а не только детей
У меня тоже стойкое ощущение, что где-то в доках я видел рекурсивный вариант функции. Возможно вездесущий эффект Манделы, или что-то путаю.
>>56862
Всё, нашёл!
Эта функция подозреваю, медленная, ибо ищет ноды по строковому паттерну. И работа с ней немного отличается. Нужно юзать while пока функция не вернёт нулль. Начал писать код, но всё стёр. ВРЕДНО! НИЗЯ! Юзайте get_children() по индексам.
Всё, нашёл!
> Node find_node ( String mask, bool recursive=true, bool owned=true )
Эта функция подозреваю, медленная, ибо ищет ноды по строковому паттерну. И работа с ней немного отличается. Нужно юзать while пока функция не вернёт нулль. Начал писать код, но всё стёр. ВРЕДНО! НИЗЯ! Юзайте get_children() по индексам.
8 Кб, 355x130>>56856
(тут было многабукав) ...а, ну да. Если сделать так, как на скриншоте, то else не нужен. Ох уж эти питоновские отступы, без них в коде можно запутаться...
>>56857
Вряд ли. Даже если бы он существовал, под капотом там примерно такая же хрень и была бы, только вместо непосредственной работы собирался бы массив, что увеличивало бы общие затраты ресурсов. Лучше всего работать с минимальными инструментами, используя их так, как нужно, чем забивать гвозди микроскопом...
Я бы не сказал, что эту операцию приходится часто выполнять. Вот тебе зачем это понадобилось?
>>56861
Ты сейчас лишний раз вызываешь do_work() на бездетные ноды. Если у тебя таких мало (что вряд ли), то ладно, но если где-то много одноуровневых бездетных нод, то на каждую будет во-первых лишний вызов функции, во-вторых лишняя проверка их бездетности (она уже выполняется в if). Учитывая то, что функция рекурсивная, то есть забивает собой стек вызовов, от лишних её вызовов лучше избавляться.
Ничего странного. Если бы такая функция была, она должна была бы формировать длинный массив всего потомства, а потом ты бы проходил по нему циклом. То есть получалась бы двойная работа - сначала собрать массив, потом пройти по нему. Нет, мог бы быть вариант типа do_work_on_children(parent, method, recursive) - который будет вызывать метод method() на каждого потомка parent, но я не уверен, можно ли сделать такой обработчик на GDScript (для этого нужна возможность передавать указатель на метод и вызывать метод по указателю). В функциональных ЯП такие обработчики - обыденность, в императивных же таким занимаются редко (хоть и можно).
>>56863
Правильно подозреваешь, get_children() тупо возвращает уже имеющийся массив ссылок на потомков, а find_node() пытается найти в этих массивах конкретную ноду. При этом find_node() возвращает первую попавшуюся ноду, а не массив всех подходящих, что не имеет смысла, если только ты не удаляешь все ноды с определённым именем.
??? Как она вернёт нуль, если ты не удаляешь отданные ею ноды?
>Только ты с else перемудрил, ящитаю. Оно там лишнее
(тут было многабукав) ...а, ну да. Если сделать так, как на скриншоте, то else не нужен. Ох уж эти питоновские отступы, без них в коде можно запутаться...
>>56857
>простого метода, чтобы в одну строчку, как get_children(), не существует
Вряд ли. Даже если бы он существовал, под капотом там примерно такая же хрень и была бы, только вместо непосредственной работы собирался бы массив, что увеличивало бы общие затраты ресурсов. Лучше всего работать с минимальными инструментами, используя их так, как нужно, чем забивать гвозди микроскопом...
>описывать свою функцию для такой рутинной операции
Я бы не сказал, что эту операцию приходится часто выполнять. Вот тебе зачем это понадобилось?
>>56861
Ты сейчас лишний раз вызываешь do_work() на бездетные ноды. Если у тебя таких мало (что вряд ли), то ладно, но если где-то много одноуровневых бездетных нод, то на каждую будет во-первых лишний вызов функции, во-вторых лишняя проверка их бездетности (она уже выполняется в if). Учитывая то, что функция рекурсивная, то есть забивает собой стек вызовов, от лишних её вызовов лучше избавляться.
>хотя я всё ещё считаю странным, что у get_children() нет аналога, который бы перебирал всё потомство
Ничего странного. Если бы такая функция была, она должна была бы формировать длинный массив всего потомства, а потом ты бы проходил по нему циклом. То есть получалась бы двойная работа - сначала собрать массив, потом пройти по нему. Нет, мог бы быть вариант типа do_work_on_children(parent, method, recursive) - который будет вызывать метод method() на каждого потомка parent, но я не уверен, можно ли сделать такой обработчик на GDScript (для этого нужна возможность передавать указатель на метод и вызывать метод по указателю). В функциональных ЯП такие обработчики - обыденность, в императивных же таким занимаются редко (хоть и можно).
>>56863
>Эта функция подозреваю, медленная
Правильно подозреваешь, get_children() тупо возвращает уже имеющийся массив ссылок на потомков, а find_node() пытается найти в этих массивах конкретную ноду. При этом find_node() возвращает первую попавшуюся ноду, а не массив всех подходящих, что не имеет смысла, если только ты не удаляешь все ноды с определённым именем.
>Нужно юзать while пока функция не вернёт нулль
??? Как она вернёт нуль, если ты не удаляешь отданные ею ноды?
8 Кб, 355x130>>56856
(тут было многабукав) ...а, ну да. Если сделать так, как на скриншоте, то else не нужен. Ох уж эти питоновские отступы, без них в коде можно запутаться...
>>56857
Вряд ли. Даже если бы он существовал, под капотом там примерно такая же хрень и была бы, только вместо непосредственной работы собирался бы массив, что увеличивало бы общие затраты ресурсов. Лучше всего работать с минимальными инструментами, используя их так, как нужно, чем забивать гвозди микроскопом...
Я бы не сказал, что эту операцию приходится часто выполнять. Вот тебе зачем это понадобилось?
>>56861
Ты сейчас лишний раз вызываешь do_work() на бездетные ноды. Если у тебя таких мало (что вряд ли), то ладно, но если где-то много одноуровневых бездетных нод, то на каждую будет во-первых лишний вызов функции, во-вторых лишняя проверка их бездетности (она уже выполняется в if). Учитывая то, что функция рекурсивная, то есть забивает собой стек вызовов, от лишних её вызовов лучше избавляться.
Ничего странного. Если бы такая функция была, она должна была бы формировать длинный массив всего потомства, а потом ты бы проходил по нему циклом. То есть получалась бы двойная работа - сначала собрать массив, потом пройти по нему. Нет, мог бы быть вариант типа do_work_on_children(parent, method, recursive) - который будет вызывать метод method() на каждого потомка parent, но я не уверен, можно ли сделать такой обработчик на GDScript (для этого нужна возможность передавать указатель на метод и вызывать метод по указателю). В функциональных ЯП такие обработчики - обыденность, в императивных же таким занимаются редко (хоть и можно).
>>56863
Правильно подозреваешь, get_children() тупо возвращает уже имеющийся массив ссылок на потомков, а find_node() пытается найти в этих массивах конкретную ноду. При этом find_node() возвращает первую попавшуюся ноду, а не массив всех подходящих, что не имеет смысла, если только ты не удаляешь все ноды с определённым именем.
??? Как она вернёт нуль, если ты не удаляешь отданные ею ноды?
>Только ты с else перемудрил, ящитаю. Оно там лишнее
(тут было многабукав) ...а, ну да. Если сделать так, как на скриншоте, то else не нужен. Ох уж эти питоновские отступы, без них в коде можно запутаться...
>>56857
>простого метода, чтобы в одну строчку, как get_children(), не существует
Вряд ли. Даже если бы он существовал, под капотом там примерно такая же хрень и была бы, только вместо непосредственной работы собирался бы массив, что увеличивало бы общие затраты ресурсов. Лучше всего работать с минимальными инструментами, используя их так, как нужно, чем забивать гвозди микроскопом...
>описывать свою функцию для такой рутинной операции
Я бы не сказал, что эту операцию приходится часто выполнять. Вот тебе зачем это понадобилось?
>>56861
Ты сейчас лишний раз вызываешь do_work() на бездетные ноды. Если у тебя таких мало (что вряд ли), то ладно, но если где-то много одноуровневых бездетных нод, то на каждую будет во-первых лишний вызов функции, во-вторых лишняя проверка их бездетности (она уже выполняется в if). Учитывая то, что функция рекурсивная, то есть забивает собой стек вызовов, от лишних её вызовов лучше избавляться.
>хотя я всё ещё считаю странным, что у get_children() нет аналога, который бы перебирал всё потомство
Ничего странного. Если бы такая функция была, она должна была бы формировать длинный массив всего потомства, а потом ты бы проходил по нему циклом. То есть получалась бы двойная работа - сначала собрать массив, потом пройти по нему. Нет, мог бы быть вариант типа do_work_on_children(parent, method, recursive) - который будет вызывать метод method() на каждого потомка parent, но я не уверен, можно ли сделать такой обработчик на GDScript (для этого нужна возможность передавать указатель на метод и вызывать метод по указателю). В функциональных ЯП такие обработчики - обыденность, в императивных же таким занимаются редко (хоть и можно).
>>56863
>Эта функция подозреваю, медленная
Правильно подозреваешь, get_children() тупо возвращает уже имеющийся массив ссылок на потомков, а find_node() пытается найти в этих массивах конкретную ноду. При этом find_node() возвращает первую попавшуюся ноду, а не массив всех подходящих, что не имеет смысла, если только ты не удаляешь все ноды с определённым именем.
>Нужно юзать while пока функция не вернёт нулль
??? Как она вернёт нуль, если ты не удаляешь отданные ею ноды?
>>56887
Есть такое у нас.
1. call(), call_deferred() возможность вызвать метод по строковому имени.
2. FuncRef объект, который реально хранит ссылку на метод, нужно удалять/очищать вместе с объектом, иначе - крош.
>>56902
Только что проверил на линуксе. Ввод работает только в английской раскладке. Причём и в игре и в редакторе (шоткаты не работают). Как минимум в линуксе обработка идёт через коды буков, а не сканоды. Хотя в винде такой проблемы не было, ЕМНИП.
> мог бы быть вариант типа do_work_on_children(parent, method, recursive) — который будет вызывать метод method() на каждого потомка parent, но я не уверен, можно ли сделать такой обработчик на GDScript (для этого нужна возможность передавать указатель на метод и вызывать метод по указателю)
Есть такое у нас.
1. call(), call_deferred() возможность вызвать метод по строковому имени.
2. FuncRef объект, который реально хранит ссылку на метод, нужно удалять/очищать вместе с объектом, иначе - крош.
>>56902
Только что проверил на линуксе. Ввод работает только в английской раскладке. Причём и в игре и в редакторе (шоткаты не работают). Как минимум в линуксе обработка идёт через коды буков, а не сканоды. Хотя в винде такой проблемы не было, ЕМНИП.
>>56887
В каком месте? if Child.Get_Children_Count() > 0: do_work(Child) - если у ноды есть потомки, то вызываем, а если нет, то проходим мимо.
Тащемта таких вещей в Годоте полно.
Пытаюсь 2д-рэгдолл на коленке собрать. И даже уже собрал. Но для полного счастья ему нужно сначала выключить физику для каждой части тела, а потом, когда персонаж умирает, включить обратно. Части тела выстроены в иерархию с узлами из ригидбодей, потому что так удобнее анимировать.
>>56909
В линуксе такое повсеместно. Почти все хоткеи работают в зависимости от раскладки. На виндах, когда ещё пользовался ими, такого вообще не встречал; хотя у некоторых стримеров видел эту проблему.
>Ты сейчас лишний раз вызываешь do_work() на бездетные ноды.
В каком месте? if Child.Get_Children_Count() > 0: do_work(Child) - если у ноды есть потомки, то вызываем, а если нет, то проходим мимо.
>Даже если бы он существовал, под капотом там примерно такая же хрень и была бы, только вместо непосредственной работы собирался бы массив, что увеличивало бы общие затраты ресурсов.
Тащемта таких вещей в Годоте полно.
>Вот тебе зачем это понадобилось?
Пытаюсь 2д-рэгдолл на коленке собрать. И даже уже собрал. Но для полного счастья ему нужно сначала выключить физику для каждой части тела, а потом, когда персонаж умирает, включить обратно. Части тела выстроены в иерархию с узлами из ригидбодей, потому что так удобнее анимировать.
>>56909
>Только что проверил на линуксе. Ввод работает только в английской раскладке.
В линуксе такое повсеместно. Почти все хоткеи работают в зависимости от раскладки. На виндах, когда ещё пользовался ими, такого вообще не встречал; хотя у некоторых стримеров видел эту проблему.
>>56947
Открой для себя группы и не изобретай велосипед. Назначаешь всем частям группу рэгдол, потом вызываешь call_group()
> Но для полного счастья ему нужно сначала выключить физику для каждой части тела, а потом, когда персонаж умирает, включить обратно. Части тела выстроены в иерархию с узлами из ригидбодей, потому что так удобнее анимировать.
Открой для себя группы и не изобретай велосипед. Назначаешь всем частям группу рэгдол, потом вызываешь call_group()
>>56947
Ну смотри. Имеем структуру:
parent
- child
Твой код, на do_work(parent) сделает бессмысленный вложенный вызов do_work(child):
1. func do_work(obj):
2. # можно сделать что-то с объектом вот тут
3. for child in obj.get_children():
4. _ if child.get_child_count() > 0:
5. _ _ do_work(child)
6.
Чтобы попасть на строчку 2, нужно сперва попасть на точку 5 и войти в функцию. Затем будет строчка 3, которая скинет к строчке 6, т.е. выходу. Если вместо этого сделать так:
1. func do_work(obj):
2. for child in obj.get_children():
3. _ # можно сделать что-то с объектом вот тут
4. _ if child.get_child_count() > 0:
5. _ _ do_work(child)
6.
То мы сразу сделаем что-то с объектом на строчке 3, а потом строчка 4 пропустит 5, т.е. лишнего вызова не будет.
Этот код при обращении do_work(parent) просто обработает child и завершится, т.к. у child нет детей.
Ну, а должно быть поменьше)
Кстати, некоторые портированные с линукса программы на винде тоже неправильно работают с хоткеями. Скорее всего это недоработка графических компонентов (Qt/GTK), т.к. скан-коды по идее генерируются железом клавиатуры и работает с ними в первую очередь BIOS, а не ОС.
>если у ноды есть потомки, то вызываем, а если нет, то проходим мимо.
Ну смотри. Имеем структуру:
parent
- child
Твой код, на do_work(parent) сделает бессмысленный вложенный вызов do_work(child):
1. func do_work(obj):
2. # можно сделать что-то с объектом вот тут
3. for child in obj.get_children():
4. _ if child.get_child_count() > 0:
5. _ _ do_work(child)
6.
Чтобы попасть на строчку 2, нужно сперва попасть на точку 5 и войти в функцию. Затем будет строчка 3, которая скинет к строчке 6, т.е. выходу. Если вместо этого сделать так:
1. func do_work(obj):
2. for child in obj.get_children():
3. _ # можно сделать что-то с объектом вот тут
4. _ if child.get_child_count() > 0:
5. _ _ do_work(child)
6.
То мы сразу сделаем что-то с объектом на строчке 3, а потом строчка 4 пропустит 5, т.е. лишнего вызова не будет.
Этот код при обращении do_work(parent) просто обработает child и завершится, т.к. у child нет детей.
>Тащемта таких вещей в Годоте полно.
Ну, а должно быть поменьше)
>В линуксе такое повсеместно. Почти все хоткеи работают в зависимости от раскладки. На виндах,
Кстати, некоторые портированные с линукса программы на винде тоже неправильно работают с хоткеями. Скорее всего это недоработка графических компонентов (Qt/GTK), т.к. скан-коды по идее генерируются железом клавиатуры и работает с ними в первую очередь BIOS, а не ОС.
>>56947
Ну смотри. Имеем структуру:
parent
- child
Твой код, на do_work(parent) сделает бессмысленный вложенный вызов do_work(child):
1. func do_work(obj):
2. # можно сделать что-то с объектом вот тут
3. for child in obj.get_children():
4. _ if child.get_child_count() > 0:
5. _ _ do_work(child)
6.
Чтобы попасть на строчку 2, нужно сперва попасть на точку 5 и войти в функцию. Затем будет строчка 3, которая скинет к строчке 6, т.е. выходу. Если вместо этого сделать так:
1. func do_work(obj):
2. for child in obj.get_children():
3. _ # можно сделать что-то с объектом вот тут
4. _ if child.get_child_count() > 0:
5. _ _ do_work(child)
6.
То мы сразу сделаем что-то с объектом на строчке 3, а потом строчка 4 пропустит 5, т.е. лишнего вызова не будет.
Этот код при обращении do_work(parent) просто обработает child и завершится, т.к. у child нет детей.
Ну, а должно быть поменьше)
Кстати, некоторые портированные с линукса программы на винде тоже неправильно работают с хоткеями. Скорее всего это недоработка графических компонентов (Qt/GTK), т.к. скан-коды по идее генерируются железом клавиатуры и работает с ними в первую очередь BIOS, а не ОС.
>если у ноды есть потомки, то вызываем, а если нет, то проходим мимо.
Ну смотри. Имеем структуру:
parent
- child
Твой код, на do_work(parent) сделает бессмысленный вложенный вызов do_work(child):
1. func do_work(obj):
2. # можно сделать что-то с объектом вот тут
3. for child in obj.get_children():
4. _ if child.get_child_count() > 0:
5. _ _ do_work(child)
6.
Чтобы попасть на строчку 2, нужно сперва попасть на точку 5 и войти в функцию. Затем будет строчка 3, которая скинет к строчке 6, т.е. выходу. Если вместо этого сделать так:
1. func do_work(obj):
2. for child in obj.get_children():
3. _ # можно сделать что-то с объектом вот тут
4. _ if child.get_child_count() > 0:
5. _ _ do_work(child)
6.
То мы сразу сделаем что-то с объектом на строчке 3, а потом строчка 4 пропустит 5, т.е. лишнего вызова не будет.
Этот код при обращении do_work(parent) просто обработает child и завершится, т.к. у child нет детей.
>Тащемта таких вещей в Годоте полно.
Ну, а должно быть поменьше)
>В линуксе такое повсеместно. Почти все хоткеи работают в зависимости от раскладки. На виндах,
Кстати, некоторые портированные с линукса программы на винде тоже неправильно работают с хоткеями. Скорее всего это недоработка графических компонентов (Qt/GTK), т.к. скан-коды по идее генерируются железом клавиатуры и работает с ними в первую очередь BIOS, а не ОС.
>>56975
Однако же, в годоте нет этих зависимостей. Значит проблема глубже. В самой глубине линуксового подхода к работе с клавиатурой. Опять же, у виндовс-билда годота такой проблемы нет.
> скорее всего это недоработка графических компонентов (Qt/GTK),
Однако же, в годоте нет этих зависимостей. Значит проблема глубже. В самой глубине линуксового подхода к работе с клавиатурой. Опять же, у виндовс-билда годота такой проблемы нет.
>>56975
Вот смотри. Вызываем функцию в любом случае извне:
1. Теперь оказываемся в функции:
1. func do_work(obj):
2. _ rape(obj)
3. _ for child in obj.get_children():
4. _ _ if child.get_child_count() > 0:
5. _ _ _ do_work(child)
2. Обрабатываем объект
3. Для бездетного объекта всё на этом заканчивается.
4. Опрашиваем каждого потомка, есть ли у него дети. Эту строчку вообще можно было бы пропустить, но у меня в любом случае каждая ветвь заканчивается спрайтом и коллизией, так что бездетную ноду точно не нужно обрабатывать.
5. И только если есть внуки, только тогда переходим к детям.
Твой вариант чище, но есть нюанс.
1. func do_work(obj):
2. _for child in obj.get_children():
3. _ _ # что здесь должно быть: rape(obj) или rape(child)?
4. _ _ if child.get_child_count() > 0:
5. _ _ _ do_work(child)
6.
Если на третьей строчке обрабатывать obj, то он будет обработан много раз. Если же child, то $node так и останется без обработки.
Проверяется очень просто:
func rape(noda):
_ print(noda)
Я проверил, мой вариант работает как надо, без лишних вызовов.
Вот смотри. Вызываем функцию в любом случае извне:
>func _ready():
>_ do_work($node)
1. Теперь оказываемся в функции:
1. func do_work(obj):
2. _ rape(obj)
3. _ for child in obj.get_children():
4. _ _ if child.get_child_count() > 0:
5. _ _ _ do_work(child)
2. Обрабатываем объект
3. Для бездетного объекта всё на этом заканчивается.
4. Опрашиваем каждого потомка, есть ли у него дети. Эту строчку вообще можно было бы пропустить, но у меня в любом случае каждая ветвь заканчивается спрайтом и коллизией, так что бездетную ноду точно не нужно обрабатывать.
5. И только если есть внуки, только тогда переходим к детям.
Твой вариант чище, но есть нюанс.
1. func do_work(obj):
2. _for child in obj.get_children():
3. _ _ # что здесь должно быть: rape(obj) или rape(child)?
4. _ _ if child.get_child_count() > 0:
5. _ _ _ do_work(child)
6.
Если на третьей строчке обрабатывать obj, то он будет обработан много раз. Если же child, то $node так и останется без обработки.
Проверяется очень просто:
func rape(noda):
_ print(noda)
Я проверил, мой вариант работает как надо, без лишних вызовов.
>>56740
Код во время разработки правится постоянно, и автодополнение нужно. А перед релизом можно и заменить, хоть автозаменой.
Код во время разработки правится постоянно, и автодополнение нужно. А перед релизом можно и заменить, хоть автозаменой.
>>56996
А, ну, для твоего случая имеет смысл сделать так.
Я говорил о таком варианте:
func _ready():
_ freeze_rigids(self)
func freeze_rigids():
_ for child in obj.get_children():
_ _ if child.get_child_count() > 0:
_ _ _ freeze_rigids(child)
_ _ if child is RigidBody:
_ _ _ child.чё_то_там()
То есть на игроке висит этот скрипт, он при старте фризит все ригидбади, которые подвешены на игрока, но самого игрока не фризит (это не нужно/не имеет смысла).
Но как уже выше говорили, это, похоже, нужно решать группами.
А, ну, для твоего случая имеет смысл сделать так.
Я говорил о таком варианте:
func _ready():
_ freeze_rigids(self)
func freeze_rigids():
_ for child in obj.get_children():
_ _ if child.get_child_count() > 0:
_ _ _ freeze_rigids(child)
_ _ if child is RigidBody:
_ _ _ child.чё_то_там()
То есть на игроке висит этот скрипт, он при старте фризит все ригидбади, которые подвешены на игрока, но самого игрока не фризит (это не нужно/не имеет смысла).
Но как уже выше говорили, это, похоже, нужно решать группами.
129 Кб, webm,1920x1080, 0:01
>>57075
Если подумать, то да. В настройках проекта включить borderless window, и per pixel background transparency. В ready включить эту самую транспаренси. Но вот дальше будут реальные сложности, если захочешь чтобы мейты ходили по окошкам программ, то придется написать модуль на c++ и ебаться с голым winapi, скорее всего.
Если подумать, то да. В настройках проекта включить borderless window, и per pixel background transparency. В ready включить эту самую транспаренси. Но вот дальше будут реальные сложности, если захочешь чтобы мейты ходили по окошкам программ, то придется написать модуль на c++ и ебаться с голым winapi, скорее всего.
6 Кб, 255x198Почему у меня сцена начала медленно сохраняться? Зависает на 2-3 секунды на 100% полоски сохранения... Всё бы ничего, да только сцены сохраняются перед каждым запуском, и это замедляет запуск. :c
>>57105
А разве нельзя сделать окно на весь экран, чтобы каждый раз оно вырезалось по координатам спрайта? Да, игра по-прежнему не будет видеть чужие окна, но сможет перемещать спрайт по всему экрану.
>>57075
ИМХО, Годо для скринмейта - оверкилл. Скринмейту по сути нужно только выводить спрайтовую анимацию. На каком-нибудь C скринмейт можно уместить в <100 КБ, и это будет не сложнее, чем в Годо. Но да, если хочешь какое-то взаимодействие с окошками - тут только WinAPI...
>>57105
А разве нельзя сделать окно на весь экран, чтобы каждый раз оно вырезалось по координатам спрайта? Да, игра по-прежнему не будет видеть чужие окна, но сможет перемещать спрайт по всему экрану.
>>57075
ИМХО, Годо для скринмейта - оверкилл. Скринмейту по сути нужно только выводить спрайтовую анимацию. На каком-нибудь C скринмейт можно уместить в <100 КБ, и это будет не сложнее, чем в Годо. Но да, если хочешь какое-то взаимодействие с окошками - тут только WinAPI...
>>57130
Не знаю, логичнее выглядит иметь маленькое окно, и двигать уже его. Вроде прозрачность это плохо по производительности, если ты будешь двигать окна программ на фоне то больше перерасчетов делается.
Если заморочиться, можно удобно писать много сложной логики...
>А разве нельзя сделать окно на весь экран, чтобы каждый раз оно вырезалось по координатам спрайта?
Не знаю, логичнее выглядит иметь маленькое окно, и двигать уже его. Вроде прозрачность это плохо по производительности, если ты будешь двигать окна программ на фоне то больше перерасчетов делается.
>Годо для скринмейта - оверкилл.
Если заморочиться, можно удобно писать много сложной логики...
>>57164
Я имею в виду, что для скринмейта ты не используешь и сотой доли возможностей движка. Сложную логику можно писать на любом ЯП, хоть на ассемблере. Движок предоставляет тебе инструменты типа физики, всяких графических штук, интерфейсов и т.д. Тебе же, по сути, нужно только двигать картинку по экрану, меняя кадры. То есть ты будешь иметь 25 МБ кода, которыми не будешь пользоваться, потому что они тебе просто не нужны. Это неправильно.
В принципе, брать движок типа Годо для скринмейта имело бы смысл, если бы скринмейт работал на фреймворке по типу Live2D, со сложной графикой, и имел бы дополнительные части интерфейса (кнопочки, менюшки). Но и то, получается, ты не задействуешь физику и ещё кучу всего (хотя теперь это уже более оправданно).
Если в Годо обрезка окна выполнена так, как я думаю, то ресурсы жрёт создание hRgn для вызова WinAPI-функции SetWindowRgn(hWnd, hRgn, bRedraw): https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-setwindowrgn
Проблема в том, что hRgn нужно создавать заново для каждого кадра анимации, если у тебя не статичная картинка. Да, это можно оптимизировать (сохранять hRgn для каждого кадра и переиспользовать), но вряд ли Годо занимается такой оптимизацией. Поэтому вряд ли расширение окна что-то изменит...
>>57153
Да там не сложно, главное осилить концепцию указателей на окно и внимательно читать документацию)
>Если заморочиться, можно удобно писать много сложной логики...
Я имею в виду, что для скринмейта ты не используешь и сотой доли возможностей движка. Сложную логику можно писать на любом ЯП, хоть на ассемблере. Движок предоставляет тебе инструменты типа физики, всяких графических штук, интерфейсов и т.д. Тебе же, по сути, нужно только двигать картинку по экрану, меняя кадры. То есть ты будешь иметь 25 МБ кода, которыми не будешь пользоваться, потому что они тебе просто не нужны. Это неправильно.
В принципе, брать движок типа Годо для скринмейта имело бы смысл, если бы скринмейт работал на фреймворке по типу Live2D, со сложной графикой, и имел бы дополнительные части интерфейса (кнопочки, менюшки). Но и то, получается, ты не задействуешь физику и ещё кучу всего (хотя теперь это уже более оправданно).
>Вроде прозрачность это плохо по производительности, если ты будешь двигать окна программ на фоне то больше перерасчетов делается
Если в Годо обрезка окна выполнена так, как я думаю, то ресурсы жрёт создание hRgn для вызова WinAPI-функции SetWindowRgn(hWnd, hRgn, bRedraw): https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-setwindowrgn
Проблема в том, что hRgn нужно создавать заново для каждого кадра анимации, если у тебя не статичная картинка. Да, это можно оптимизировать (сохранять hRgn для каждого кадра и переиспользовать), но вряд ли Годо занимается такой оптимизацией. Поэтому вряд ли расширение окна что-то изменит...
>>57153
Да там не сложно, главное осилить концепцию указателей на окно и внимательно читать документацию)
Годаны, у меня тултипы от кнопок отвалились. Один раз свет погас, а бесперебойника у меня нету. И теперь тултипы не появляются. Не могу понять, из за этого или нет? Кнопки ничего не перекрывает, на нажатия мышки реагируют, а тултипов нет. Текст введён, удалял-добавлял - не помогает.
Не то, чтобы это принципиально, смогу и без них, но как-то неприятно.
Не то, чтобы это принципиально, смогу и без них, но как-то неприятно.
>>57428
Отбой. Как обычно, написал, а потом сразу нашёл проблему. Мои кнопки - это кнопки меню, которое ставит игру на паузу при своём появлении. По видимому, отображение тултипов тоже на паузу ставится. Пойду гуглить, можно ли отключить это.
Отбой. Как обычно, написал, а потом сразу нашёл проблему. Мои кнопки - это кнопки меню, которое ставит игру на паузу при своём появлении. По видимому, отображение тултипов тоже на паузу ставится. Пойду гуглить, можно ли отключить это.
>>57442
https://docs.godotengine.org/en/stable/tutorials/misc/pausing_games.html
Держи, пока далеко не ушёл. Пауза для отдельных объектов включается/выключается в один клик.
(просто у меня эта вкладка как раз открыта, чтобы не потерять)
https://docs.godotengine.org/en/stable/tutorials/misc/pausing_games.html
Держи, пока далеко не ушёл. Пауза для отдельных объектов включается/выключается в один клик.
(просто у меня эта вкладка как раз открыта, чтобы не потерять)
>>57233
Что мешает использовать физику для скринмейта? Он может физически точно кидаться чем то. Или навернуть анимаций, частиц, морфинга
Что мешает использовать физику для скринмейта? Он может физически точно кидаться чем то. Или навернуть анимаций, частиц, морфинга
>>57233
Тебе рассказать, сколько в операционной системе на твоём компе заложено возможностей, которыми ты не пользуешься? Универсальные инструменты вообще-то так и работают.
>ты будешь иметь 25 МБ кода, которыми не будешь пользоваться, потому что они тебе просто не нужны. Это неправильно.
Тебе рассказать, сколько в операционной системе на твоём компе заложено возможностей, которыми ты не пользуешься? Универсальные инструменты вообще-то так и работают.
>>57534
Ну тогда ок.
Если не ошибаюсь, задать полупрозрачность каждому пикселю окна в Windows невозможно, можно только обрезать окно по пикселям или задать полупрозрачность всего окна целиком (на счёт Aero-тем Windows Vista/7 не знаю). Однако, если это возможно и не требует слишком многого (представляю себе скринмейт, потребляющий 50% ЦПУ), тогда было бы круто.
>>57566
А я виноват, что вынужден использовать эту ОС и не имею возможности выкинуть эти возможности? После установки Windows приходится удалять часть сервисов и выковыривать часть файлов, которая не будет нужна, но всё лишнее всё равно убрать не получится, это верно. Но ведь нельзя же следовать плохим примерам...
Не всегда. Это Godot скидывает весь свой рантайм в игру, а мог бы скидывать только те части рантайма, которые задействованы конкретным приложением. Да он и файлы из папки проекта все в игру засовывает, даже если они не задействованы никак. Но это проблемы конкретно Godot, а не любого "универсального инструмента".
Кроме того, для некоторых задач рациональнее использовать специальные инструменты вместо универсальных. Те же скринмейты/шимеджи не должны потреблять ресурсы как полноценная игра, это вообще не игра даже. Аналогично, нельзя делать скринсейвер размером с обычную игру - он должен мгновенно запускаться и мгновенно закрываться, иначе у юзера будут проблемы даже на мощном ПК (чем мощнее становится железо, тем медленнее и толще становятся приложения - как раз из-за тех, кто использует "универсальные инструменты" на любой чих, в том числе для создания новых "универсальных инструментов").
>Что мешает использовать физику для скринмейта? Он может физически точно кидаться чем то.
Ну тогда ок.
>Или навернуть анимаций, частиц, морфинга
Если не ошибаюсь, задать полупрозрачность каждому пикселю окна в Windows невозможно, можно только обрезать окно по пикселям или задать полупрозрачность всего окна целиком (на счёт Aero-тем Windows Vista/7 не знаю). Однако, если это возможно и не требует слишком многого (представляю себе скринмейт, потребляющий 50% ЦПУ), тогда было бы круто.
>>57566
>Тебе рассказать, сколько в операционной системе на твоём компе заложено возможностей, которыми ты не пользуешься?
А я виноват, что вынужден использовать эту ОС и не имею возможности выкинуть эти возможности? После установки Windows приходится удалять часть сервисов и выковыривать часть файлов, которая не будет нужна, но всё лишнее всё равно убрать не получится, это верно. Но ведь нельзя же следовать плохим примерам...
>Универсальные инструменты вообще-то так и работают.
Не всегда. Это Godot скидывает весь свой рантайм в игру, а мог бы скидывать только те части рантайма, которые задействованы конкретным приложением. Да он и файлы из папки проекта все в игру засовывает, даже если они не задействованы никак. Но это проблемы конкретно Godot, а не любого "универсального инструмента".
Кроме того, для некоторых задач рациональнее использовать специальные инструменты вместо универсальных. Те же скринмейты/шимеджи не должны потреблять ресурсы как полноценная игра, это вообще не игра даже. Аналогично, нельзя делать скринсейвер размером с обычную игру - он должен мгновенно запускаться и мгновенно закрываться, иначе у юзера будут проблемы даже на мощном ПК (чем мощнее становится железо, тем медленнее и толще становятся приложения - как раз из-за тех, кто использует "универсальные инструменты" на любой чих, в том числе для создания новых "универсальных инструментов").
>>57494
Меню и так в режиме "процесс". Речь-то не об этом.
Меню и так в режиме "процесс". Речь-то не об этом.
>>57585
Юзай линукс.
Несомненное преимущество линукса не только в том, что всё лишнее выпиливается стандартными средствами, а ещё и в том, что не сможешь прокрастинировать, играя в игры, вместо того чтобы игры делать.
> вынужден использовать эту ОС
Юзай линукс.
Несомненное преимущество линукса не только в том, что всё лишнее выпиливается стандартными средствами, а ещё и в том, что не сможешь прокрастинировать, играя в игры, вместо того чтобы игры делать.
>>57608
Юзал, не понравилось, вернулся к виндувс. Главный недостаток линукса для меня в его неустойчивости, но это долгая история...
Угу, а потом оказывается, что это было не лиш... kernel panic! ...или оставляет после себя как-то непонятные артефакты.
На линуксе тоже игры есть, к тому же моя прокрастинация - это на 99% веб-сёрфинг. Я даже когда собираюсь в игру поиграть, вместо игры в игру прокрастинирую в интернете, в итоге так и не играю ни во что практически, только покупаю. А без интернета ломка.
К тому же вот - >>56909
То есть на линуксе есть необходимые для геймдева редакторы, но даже они обычно работают кое-как, а альтернатив нет.
>Юзай линукс.
Юзал, не понравилось, вернулся к виндувс. Главный недостаток линукса для меня в его неустойчивости, но это долгая история...
>всё лишнее выпиливается стандартными средствами
Угу, а потом оказывается, что это было не лиш... kernel panic! ...или оставляет после себя как-то непонятные артефакты.
>не сможешь прокрастинировать, играя в игры, вместо того чтобы игры делать
На линуксе тоже игры есть, к тому же моя прокрастинация - это на 99% веб-сёрфинг. Я даже когда собираюсь в игру поиграть, вместо игры в игру прокрастинирую в интернете, в итоге так и не играю ни во что практически, только покупаю. А без интернета ломка.
К тому же вот - >>56909
>Только что проверил на линуксе. Ввод работает только в английской раскладке. Причём и в игре и в редакторе (шоткаты не работают).
То есть на линуксе есть необходимые для геймдева редакторы, но даже они обычно работают кое-как, а альтернатив нет.
29 Кб, 274x232>>57612
В линуксе много проблем, но я от него не отказываюсь.
Кроме того, ты ж для виндовса делаешь игры, поэтому как минимум с вводом в готовом приложении проблем не будет. Я вчера экспортировал демку для ТВГ. В линуксе ввод работает только на английской раскладке, в вайне (и в виндовсе у игроков) ввод уже на обеих раскладках работает.
Я ж грю, линукс не даст тебе расслабиться и прокрастинировать. Это не работает, то недоступно, сё не настроено. Остаётся только писать код.
В линуксе много проблем, но я от него не отказываюсь.
Кроме того, ты ж для виндовса делаешь игры, поэтому как минимум с вводом в готовом приложении проблем не будет. Я вчера экспортировал демку для ТВГ. В линуксе ввод работает только на английской раскладке, в вайне (и в виндовсе у игроков) ввод уже на обеих раскладках работает.
Я ж грю, линукс не даст тебе расслабиться и прокрастинировать. Это не работает, то недоступно, сё не настроено. Остаётся только писать код.
>>57616
Я ж для себя делаю игры)
Да, но работать в редакторе без хоткеев или постоянно переключаться с раскладки на раскладку - лишние трудности. У меня был такой опыт, кажется, в Inkscape - в какой-то из прежних версий хоткеи настраивались для каждой раскладки индивидуально, и это было очень неудобно, прям выбешивало, особенно когда печатаешь русский текст... Потом они это пофиксили, но до сих пор alt+D вместо срабатывания привязанного к хоткею действия почему-то открывает выпадающее меню, и всё это происходит на винде. Короч для разработки нужна стабильная операционная система, и минимум багов среды разработки.
Кстати о багах... У меня в Godot такие проблемы:
1. "Магнитик" в некоторых сценах стал работать по умолчанию, хотя кнопка отжата;
2. Шаг "магнитика" в части сцен 1 метр, в других - 0.1 метра, но я ничего нигде не настраивал;
3. Один раз отвалилась прокрутка кода колёсиком мыши, вообще не понял, с чем было связано;
4. Включение тумана в окружении по умолчанию полностью закрашивает цветом тумана все модельки сцены.
5. Опять же зависание сохранения на 100% сцены с большими инстансами, вряд ли баг, но бесит, явно что-то не то;
6. Export-параметры скриптов в инстанциированных сценах почему-то теряют значение, приходится пересохранять.
Кто-нибудь сталкивался? Может, "ночные" сборки имеют меньше проблем?
Особенно удивило 6, если я задаю параметру новое значение в сцене, приходится вручную сбрасывать все её инстансы в других сценах, несмотря на то, что в них уже лежит, как мне кажется, правильное значение. При этом распространяется не на все инстансы, как будто некоторые некорректно обновляются... фиг знает, то ли я что-то не понял/сломал, то ли баг какой-то, но неудобно, когда инстансов много и по ошибке в логах трудно понять, кто именно виноват.
>ты ж для виндовса делаешь игры
Я ж для себя делаю игры)
>как минимум с вводом в готовом приложении
Да, но работать в редакторе без хоткеев или постоянно переключаться с раскладки на раскладку - лишние трудности. У меня был такой опыт, кажется, в Inkscape - в какой-то из прежних версий хоткеи настраивались для каждой раскладки индивидуально, и это было очень неудобно, прям выбешивало, особенно когда печатаешь русский текст... Потом они это пофиксили, но до сих пор alt+D вместо срабатывания привязанного к хоткею действия почему-то открывает выпадающее меню, и всё это происходит на винде. Короч для разработки нужна стабильная операционная система, и минимум багов среды разработки.
Кстати о багах... У меня в Godot такие проблемы:
1. "Магнитик" в некоторых сценах стал работать по умолчанию, хотя кнопка отжата;
2. Шаг "магнитика" в части сцен 1 метр, в других - 0.1 метра, но я ничего нигде не настраивал;
3. Один раз отвалилась прокрутка кода колёсиком мыши, вообще не понял, с чем было связано;
4. Включение тумана в окружении по умолчанию полностью закрашивает цветом тумана все модельки сцены.
5. Опять же зависание сохранения на 100% сцены с большими инстансами, вряд ли баг, но бесит, явно что-то не то;
6. Export-параметры скриптов в инстанциированных сценах почему-то теряют значение, приходится пересохранять.
Кто-нибудь сталкивался? Может, "ночные" сборки имеют меньше проблем?
Особенно удивило 6, если я задаю параметру новое значение в сцене, приходится вручную сбрасывать все её инстансы в других сценах, несмотря на то, что в них уже лежит, как мне кажется, правильное значение. При этом распространяется не на все инстансы, как будто некоторые некорректно обновляются... фиг знает, то ли я что-то не понял/сломал, то ли баг какой-то, но неудобно, когда инстансов много и по ошибке в логах трудно понять, кто именно виноват.
>>57708
Возможно ты нажал Ctrl+F и вошел в режим навигации "от первого лица" по WASD.
> 3. Один раз отвалилась прокрутка кода колёсиком мыши, вообще не понял, с чем было связано;
Возможно ты нажал Ctrl+F и вошел в режим навигации "от первого лица" по WASD.
>>57779
Ой, Shift+F то есть.
Ой, Shift+F то есть.
>>57708
В годоте нет такой сущности, есть мастер который нестабильный, потому что он уже наполовину 4.0 на вулкане. Советую пользоваться стабильным 3.2.1, в него бекпортировали часть фич, и фиксили баги, возможно будет еще 3.2.2 мейтейнс версия.
>"ночные" сборки имеют меньше проблем?
В годоте нет такой сущности, есть мастер который нестабильный, потому что он уже наполовину 4.0 на вулкане. Советую пользоваться стабильным 3.2.1, в него бекпортировали часть фич, и фиксили баги, возможно будет еще 3.2.2 мейтейнс версия.
Камрады, поясните за сигналы.
Курю доки, изучаю примеры, смотрю видеотуторы и пытаюсь понять: а собсно нахуя? У нас есть:
1. Object_A со скриптом отправки сигнала
2. Object_B со скриптом принятия сигнала
3. Динамическая сцена, где создаются разные инстансы Object_A и Object_B.
Чтобы послать сигнал, мне надо сначала соединить два инстанса между собой, а потом послать. Но постойте, а не проще ли написать так:
#где-то в Object_B.gd
func Do_Something():
...
#где-то в Object_A.gd
Instance_Of_Object_B.Do_Something()
В чём выгода от использования сигналов? Для типобезопасности можно дополнительно перед вызовом проверять if Instance_Of_Object_B is Object_B. Пока что я не сталкивался с такими задачами, где такой прямой вызов функций было бы невозможно реализовать.
Не понимаю. Вот у меня есть пули, которые сталкиваются с разрушаемым физическим окружением и персонажами, наносят повреждения, толкают. Обязательно ли тут использовать сигналы? Какие преимущества по сравнению с прямым вызовом функций?
Курю доки, изучаю примеры, смотрю видеотуторы и пытаюсь понять: а собсно нахуя? У нас есть:
1. Object_A со скриптом отправки сигнала
2. Object_B со скриптом принятия сигнала
3. Динамическая сцена, где создаются разные инстансы Object_A и Object_B.
Чтобы послать сигнал, мне надо сначала соединить два инстанса между собой, а потом послать. Но постойте, а не проще ли написать так:
#где-то в Object_B.gd
func Do_Something():
...
#где-то в Object_A.gd
Instance_Of_Object_B.Do_Something()
В чём выгода от использования сигналов? Для типобезопасности можно дополнительно перед вызовом проверять if Instance_Of_Object_B is Object_B. Пока что я не сталкивался с такими задачами, где такой прямой вызов функций было бы невозможно реализовать.
Не понимаю. Вот у меня есть пули, которые сталкиваются с разрушаемым физическим окружением и персонажами, наносят повреждения, толкают. Обязательно ли тут использовать сигналы? Какие преимущества по сравнению с прямым вызовом функций?
186 Кб, 845x755>>57442
Судя по всему, отключить нельзя. В интернетах народ просит Хуана сделать дополнительный стейт для паузы, для таких случаев. А мне помог как всегда индусский копипаст-код.
Судя по всему, отключить нельзя. В интернетах народ просит Хуана сделать дополнительный стейт для паузы, для таких случаев. А мне помог как всегда индусский копипаст-код.
>>57896
В пулях сигналы не нужны.
Сигналы удобны, когда тебе надо дать ноде задачу, подключиться к сигналу готовности этой задачи у этой ноды и пойти дальше. А когда нода сделоет, она пошлёт сигнал. Без сигнала тебе бы пришлось в цикле чекать не выпольнила ли нода задачу.
В программировании сигналы ещё называют событиями, можешь загуглить их. Events.
В пулях сигналы не нужны.
Сигналы удобны, когда тебе надо дать ноде задачу, подключиться к сигналу готовности этой задачи у этой ноды и пойти дальше. А когда нода сделоет, она пошлёт сигнал. Без сигнала тебе бы пришлось в цикле чекать не выпольнила ли нода задачу.
В программировании сигналы ещё называют событиями, можешь загуглить их. Events.
>>57896
Ну ты рассматриваешь случай когда у тебя все ноды фиксированы по иерархии. А допустим в более сложной игре у тебя может быть подсцена. И по пути уже не удобно
Ну ты рассматриваешь случай когда у тебя все ноды фиксированы по иерархии. А допустим в более сложной игре у тебя может быть подсцена. И по пути уже не удобно
В гдскрипте же всё ок с инкапсуляцией? У меня чертовщина какая-то творится.
Ставлю на сцену двух инстансов от одной и той же сцены "человечек" (игрок и враг). Игрока вкладываю в ноду Control, которая передаёт сигналы с клавиатуры как команды своему человечку-потомку. Внутри сцены "человечек" нет ни одного обращения к каким-либо нодам за пределами сцены. Тем не менее, когда я нажимаю прыжок, игрок подпрыгивает нормальным образом, а враг слегка дёргается в направлении прижка. Магия какая-то.
Ставлю на сцену двух инстансов от одной и той же сцены "человечек" (игрок и враг). Игрока вкладываю в ноду Control, которая передаёт сигналы с клавиатуры как команды своему человечку-потомку. Внутри сцены "человечек" нет ни одного обращения к каким-либо нодам за пределами сцены. Тем не менее, когда я нажимаю прыжок, игрок подпрыгивает нормальным образом, а враг слегка дёргается в направлении прижка. Магия какая-то.
>>58023
Да всё, проехали.
Проблема ушла после переименования ноды игрока. Её имя совпадало с именем класса. Через это каким-то образом пролез AnimationPlayer и попытался проанимировать тушку врага; но у того был свой AnimationPlayer, который сопротивлялся, отыгрывая idle.
Такие дела. Вывод: лучше всегда переименовывать ноды, чтобы имя не совпадало с именем класса.
Да всё, проехали.
Проблема ушла после переименования ноды игрока. Её имя совпадало с именем класса. Через это каким-то образом пролез AnimationPlayer и попытался проанимировать тушку врага; но у того был свой AnimationPlayer, который сопротивлялся, отыгрывая idle.
Такие дела. Вывод: лучше всегда переименовывать ноды, чтобы имя не совпадало с именем класса.
>>58319
Я пользовался в прошлом году. Но динамическая типизация оказалась настолько наркотической хренью, что я забил на шарп. Так что ныне только гдскрипт.
Я пользовался в прошлом году. Но динамическая типизация оказалась настолько наркотической хренью, что я забил на шарп. Так что ныне только гдскрипт.
>>58325
Хотел попробовать годот. И скачал при выборе с шарпом. Но годот сам кричит, что шарп там говно альфа, все по ишью, все по тому сему. Если действительно так плохо, то пока не поздно перейду на питоноподобный гдскрипт. Хотелось бы не переходить конечно (я по работе на питоне сижу и искренне его ненавижу уже), но если шарп и правда работает примерно нихуя, то лучше бы узнать об этом сейчас.
Хотел попробовать годот. И скачал при выборе с шарпом. Но годот сам кричит, что шарп там говно альфа, все по ишью, все по тому сему. Если действительно так плохо, то пока не поздно перейду на питоноподобный гдскрипт. Хотелось бы не переходить конечно (я по работе на питоне сижу и искренне его ненавижу уже), но если шарп и правда работает примерно нихуя, то лучше бы узнать об этом сейчас.
>>58353
И как ее решать
И как ее решать
>>58350
Шарп работает. Поддерживаются все АПИ. Просто в редакторе реализация шарпа скудная. Когда я смотрел крайний раз, не было интеллисенса. Просто открываешь проект в студии и пишешь в ней, не забывая сохраняться, перед переключением в редактор годота.
>>58353
Эта хуйня называется невнимательность.
> если шарп и правда работает примерно нихуя, то лучше бы узнать об этом сейчас
Шарп работает. Поддерживаются все АПИ. Просто в редакторе реализация шарпа скудная. Когда я смотрел крайний раз, не было интеллисенса. Просто открываешь проект в студии и пишешь в ней, не забывая сохраняться, перед переключением в редактор годота.
>>58353
Эта хуйня называется невнимательность.
>>58353
Breakpoint? Это точка остановки для отладки, видимо ты в этой строчке случайно ее жамкнул, посмотри слева красный кружочек.
Breakpoint? Это точка остановки для отладки, видимо ты в этой строчке случайно ее жамкнул, посмотри слева красный кружочек.
>>58319
Пробовал, в основном разница в том, что приходится сидеть и угадывать в какой нотации записано имя метода или проперти. Вот тут я должен был догадаться, что basis пишется с маленькой, хотя обычно все поля типа Visible пишутся с большой. Поэтому документацией пользоваться довольно неудобно. Как и примерами кода. Даже кто то сайт запилил чтобы смотреть апи https://godotsharp.net/api/3.2.0/
В текущем проекте менять уже не буду, хочу чтобы он работал со стандартным годотом с оф сайта, дальше посмотрю. Хотя меня по прежнему больше соблазняет идея писать прямо на плюсах. И никакой зависимости от моно.
>>58370
В айфонах еще только в планах добавить в стабильную ветку:
Не уверен что в WebAssembly экспорте уже доделали AOT-компилятор. Если нет, то там будет ооочень медленно.
Экспорт mono на Андроид не так давно сделали, неизвестно как там по багам.
Пробовал, в основном разница в том, что приходится сидеть и угадывать в какой нотации записано имя метода или проперти. Вот тут я должен был догадаться, что basis пишется с маленькой, хотя обычно все поля типа Visible пишутся с большой. Поэтому документацией пользоваться довольно неудобно. Как и примерами кода. Даже кто то сайт запилил чтобы смотреть апи https://godotsharp.net/api/3.2.0/
В текущем проекте менять уже не буду, хочу чтобы он работал со стандартным годотом с оф сайта, дальше посмотрю. Хотя меня по прежнему больше соблазняет идея писать прямо на плюсах. И никакой зависимости от моно.
>>58370
>Шарп работает.
В айфонах еще только в планах добавить в стабильную ветку:
>Godot 4.0 will be getting C# support for iOS. We also plan to include it in a 3.2.x release, which could be 3.2.2 if everything goes well.
Не уверен что в WebAssembly экспорте уже доделали AOT-компилятор. Если нет, то там будет ооочень медленно.
Экспорт mono на Андроид не так давно сделали, неизвестно как там по багам.
5 Кб, 545x206>>58390
Пик отлепился
>Вот тут я должен был догадаться, что basis пишется с маленькой, хотя обычно все поля типа Visible пишутся с большой.
Пик отлепился
>>58390
А я по прежнему жду от тебя успехов в этом начинании, отчётов, скринов, туториалов.
> Хотя меня по прежнему больше соблазняет идея писать прямо на плюсах.
А я по прежнему жду от тебя успехов в этом начинании, отчётов, скринов, туториалов.
>>58393
Так скрин старый был где то, думаю не сильно поменялось. Но поскольку писать так медленнее (писать на плюсах в принципе медленнее, плюс надо ждать каждый запуск линковку), то прототипировать я продолжил на гдскрипте. Как можно заметить там тоже придется угадывать апи, например вместо basis.z там basis[2].
По поводу туториала, в целом, там создается обычный cpp модуль по инструкции с оф сайта, а в объявлениях своих классов пишется что то вроде макроса GDCLASS(YourClassName, BaseClass) и обработчик _notification(int) который дергает my_ready(), my_process(delta) и my_physics_process(delta). Собственно весь мой утилитный класс на пик2. Он включает в себя дебажный вывод, проверку на работу в редакторе/в релизе, саму рыбу для класса, и пару сокращателей для поиска ноды и каста типов.
Использование примерно показано на пик3, из значимого - в объявлении класса надо написать упомянутый макрос, новые объекты с подсчетом ссылок надо создавать через memnew(ClassName), сигналы работают как обычно, только надо регистрировать обработчик через bind_method(...)
Так скрин старый был где то, думаю не сильно поменялось. Но поскольку писать так медленнее (писать на плюсах в принципе медленнее, плюс надо ждать каждый запуск линковку), то прототипировать я продолжил на гдскрипте. Как можно заметить там тоже придется угадывать апи, например вместо basis.z там basis[2].
По поводу туториала, в целом, там создается обычный cpp модуль по инструкции с оф сайта, а в объявлениях своих классов пишется что то вроде макроса GDCLASS(YourClassName, BaseClass) и обработчик _notification(int) который дергает my_ready(), my_process(delta) и my_physics_process(delta). Собственно весь мой утилитный класс на пик2. Он включает в себя дебажный вывод, проверку на работу в редакторе/в релизе, саму рыбу для класса, и пару сокращателей для поиска ноды и каста типов.
Использование примерно показано на пик3, из значимого - в объявлении класса надо написать упомянутый макрос, новые объекты с подсчетом ссылок надо создавать через memnew(ClassName), сигналы работают как обычно, только надо регистрировать обработчик через bind_method(...)
>>58415
И, кажется, надо было самому включать set_process(true) в myready()
И, кажется, надо было самому включать set_process(true) в myready()
>>58461
Все сразу знать невозможно, просто это стандартно для IDE программирования лет 30 как.
Все сразу знать невозможно, просто это стандартно для IDE программирования лет 30 как.
Тред утонул или удален.
Это копия, сохраненная 31 июля 2021 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
Это копия, сохраненная 31 июля 2021 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.