Был обновлён парсер тредов Двача, просим анонов обращать внимание и сообщать об аномалиях с содержанием сохраняемых тредов.

Godot #15

 Аноним OP 15/02/20 Суб 22:48:51 #1 №643188 
.png
С чего начать?
С изучения документации. Если не можешь в инглиш, и даже в гугл-переводчик, то начат перевод официальной документации: 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/
Loading...
Аноним 15/02/20 Суб 22:51:10 #2 №643190 
image.png
После перезагрузки проект просто вылетает. Даже ошибку не выдаёт
Аноним 15/02/20 Суб 22:51:40 #3 №643191 
image.png
>>643190
В предыдущих сериях:
Аноним 15/02/20 Суб 22:57:16 #4 №643194 
>>643190
Имею ввиду, что вылетает при срабатывании триггера
Аноним 15/02/20 Суб 22:58:05 #5 №643195 
1581796684539.png
>>643190
>>643191
Бывает такое.
Мне помогает закомментить всё и переписать заново иным образом. В процессе переписывания я в 90% случаев нахожу, где я проебался.
Аноним 15/02/20 Суб 23:00:52 #6 №643197 
1581796852323.png
>>643194
Помимо вывода есть ещё отладчик. Там тоже много интересного пишут.
Аноним 15/02/20 Суб 23:01:13 #7 №643198 
>>643197
Не в моём случае.
Аноним 16/02/20 Вск 00:19:16 #8 №643212 
1487535997336.jpg
1484409359958.webm
>>643179 →
Нашел способ воспроизвести краш с 100% вероятностью. Надо войти в режим прокладывания маршрута, и начать быстро кликать по своим зданиям, возможно, при этом немного прокручивая карту
Не знаю точно, что происходит, но в один момент вылетает ошибка. Игре кажется, что после этого с ней все в порядке, но на самом деле ей уже настал omae wa mou shindeiru.
Текст ошибки намекает на обработчик мыши и его параметры. Возможно, ты где-то не дописал аргументы?
P.s. игра не выносит ресайз окна, но это ты исправишь покурив http://docs.godotengine.org/en/3.2/tutorials/viewports/multiple_resolutions.html
Аноним 16/02/20 Вск 02:26:18 #9 №643223 
>>643212
Ввёл логирование с помощью файла. Доступ к логам в игровом меню (которое раньше было пустым). Если на сайте с созданием файлов все ок, то в скором времени отладка у пользователей будет без проблем. Спасибо за детальный разбор ошибки! В скором времени её поправлю и выложу новую версию.
Аноним 16/02/20 Вск 03:26:19 #10 №643230 
>>643212
Твой баг поправил, новую версию залил. Логирование через файл на html-5 не пашет.
Аноним 16/02/20 Вск 03:30:36 #11 №643231 
Короче сделал сигналы и привёл в порядок queue_free, теперь всё зробит
Аноним 16/02/20 Вск 13:46:56 #12 №643292 
Допустим у меня есть очень много button которые делают одно и тоже, можно как-то объединить их? Чтобы при нажатии любой они давали один сигнал, а не для каждой прописывать.
Аноним 16/02/20 Вск 13:52:49 #13 №643295 
1532111726390.png
>>643292
Ты можешь поступить так, как я показывал в прошлом треде.
Пройтись в цикле по всем кнопкам и всем им подключить один сигнал.
Аноним 16/02/20 Вск 15:06:12 #14 №643307 
>>643295
Двачую этого.
Кроме того, у сигналов есть возможность привязки к ним любых дополнительных данных, в качестве которых можно указывать ссылку на кнопку. Таким образом, все кнопки будут выполнять один обработчик сигнала, но подавать на вход ссылку на себя:

for button in buttons.get_children():
-> button.connect("pressed", self, "on_arraybtn_pressed", [button])

func on_arraybtn_pressed(sender):
-> print(sender.name)
Аноним 16/02/20 Вск 15:47:25 #15 №643312 
Пополняем библиотеку ассетов
https://godotengine.org/asset-library/asset/514
Аноним 16/02/20 Вск 17:56:51 #16 №643331 
image.png
Чому не сохраняет?
Аноним 16/02/20 Вск 18:15:20 #17 №643335 
>>643331
Тому що ты пидар
Аноним 16/02/20 Вск 18:32:07 #18 №643341 
>>643331
хтмл5? Там какие-то проблемы с схоронением. При работе в браузере сохранение в файлы должно прозрачно заменяться схоронением метаданных в локальное хранилище браузера. Однако там есть куча подводных камней, с которыми я попытался разобраться, но потом хзабил.
Аноним 16/02/20 Вск 18:40:59 #19 №643346 
Я не вкатывальщик и вкатываться не планировал. Просто так вышло что я здесь. Если кто-то хочет потешить свое самолюбие за счет моей глупости или получить плюсик в карму, пожалуйста поотвечай на мои слишком тупые вопросы.
Пока только два :
1)Как ограничить движение 2д камеры? Камера передвигается перетаскиванием мышкой и wasd со стрелочками, и если как ограничить передвижение у стрелочек я понимаю, то как с перетаскиванием неебу. Желательно чтобы при отдалении камеры колесиком я не выходил за пределы.

2) Нужно перелистывание слайдов, я примерно понимаю как это можно сделать. Нажимаешь на кнопку - выключает видимость X, включает видимость Y, еще раз выкл Y вкл Z. Но как это сделать покрасивее и удобнее? Не прописывать же вкл/выкл для 15 слайдов допустим.
Аноним 16/02/20 Вск 18:41:28 #20 №643347 
>>643341
нет, windows 10
Аноним 16/02/20 Вск 18:46:18 #21 №643352 
>>643347
В смысле UWP? Приложение шындовс-маркета штоле? Вообще не пробовал туда экспортить.
В любом случае, смотри директорию, в которую выгружаешь на наличие ожидаемых тобой файлов.

Аноним 16/02/20 Вск 18:50:21 #22 №643353 
>>643352
>В смысле UWP
win32 или как его (exe)
Оказалась какая-то проблема с правами доступа у годота.
С ноута и компа знакомого всё работает, хз.
Аноним 16/02/20 Вск 18:50:33 #23 №643354 
>>643346
1. Ограничить движение камеры точно так же, как ограничить любую переменную по диапазону: проверяешь выход за границы диапазона и отменяешь изменение.

2. Максимально абстрактный вопрос. Как сделать красиво? Нужно обладать вкусом. И сделаешь красиво. Чтобы обладать вкусом, нужно перелопатить определенное количество контента, в нашем случае игр. И тогда начнёшь понимать, что красиво, а что нет.
Аноним 16/02/20 Вск 18:52:00 #24 №643355 
>>643353
Не может этого быть. Директория user://в корректно работающей винде это директория к которой у данного юзера полные права. Значит у тебя винда зверь-сиди.
Аноним 16/02/20 Вск 18:56:47 #25 №643356 
>>643346
1. Да в общем то так же. У тебя где то выставляется координата x и y.
Насчет колесика - ну ты можешь высчитать сколько пикселей видно на экране, и на столько отступить от лимита. Наверняка и готовое решение можно нагуглить. Какую нибудь rts камеру.
2. Можно много чего сделать, во-первых массив или список. Опять же смотри пример >>643295
Эффекты можно разные сделать, затухания там.
А можно вообще просто сделать большой "уровень" и выставить твои слайды по порядку, и летать камерой.
Аноним 16/02/20 Вск 18:58:37 #26 №643358 
>>643353
Нет пробелов или русских букв в имени пользователя? Выведи в отладку как полностью путь к файлу получается.
Аноним 16/02/20 Вск 19:34:53 #27 №643359 
>>643358
У меня сохранения формата "файл1.сохранение".
Может быть в этом дело, но на других компьютерах с такими русскими буквами в названии все нормально.
Аноним 16/02/20 Вск 19:43:06 #28 №643362 
>>643359
Я ещё раз пересмотрел твой код и обратил внимание на то, что у тебя сначала открывается сейв, прочитывается, парсится в переменную, вносятся изменения и затем файл открывается на запись и записываются новые данные.
Дело твоё, конечно, но я бы не рекомендовал модифицировать сейв файлы. Только если игра предполагает. Типа, как в Андертейле, когда главный злодей игроку сейвы трёт.
В основном же, я предлагаю тебе хранить актуальные данные в том же globaldata и просто брать их оттуда для сохранения.
Аноним 16/02/20 Вск 19:45:06 #29 №643363 
>>643354
Спасибо, я имел ввиду сделать код по красивому, без лишних строчек, я уверен можно не повторять одну и ту же точку

>>643356
Спасибо, попытаюсь понять >>643295
Аноним 16/02/20 Вск 19:55:48 #30 №643366 
Кстати, насчёт сейвов, годаны. Вот как вы решаете проблему нумерации? Скажем, игра начинает сохранять сейвы по эф-пяточке. Файл1, файл2, файл3. Потом игрок зафейлил игру и загрузился с точки в несколько сейвов назад. Крайний сейв это, скажем Файл100, а игрок загрузил Файл90 и играет дальше. Теперь задача, как только игрок нажимает ф5, нужно определить, что сохраняться надо не в Файл91, а в Файл101. Как?
Если брутфорсом перебирать названия файлов на существование, не будет ли это слишком долго в случаях, когда игрок наплодил ТЫСЯЧИ ФАЙЛОВ?
Если внутри игры хранить счётчик, получится перезапись существующих файлов.
Можно ли кроссплатформенно получать от системы уникальное имя файла и юзать его как сейв?
Аноним 16/02/20 Вск 20:16:59 #31 №643372 
>>643366
Самое простое, что приходит в голову - время.
Аноним 16/02/20 Вск 20:19:36 #32 №643373 
>>643359
Я писал про имя пользователя. user:// это C:/Users/<username>/AppData/Roaming/Godot/GameName, ~/.local/share/godot/app_userdata/GameName
Аноним 16/02/20 Вск 20:34:21 #33 №643375 
>>643372
Ну да, тоже думал об этом. Только в довесок ко времени ещё имя игрока: Player1_20200216_203145.sav перезапись файлов будет только если игрок начнёт бешено спамить кнопку сохранения. Впрочем, его пыл можно ограничить таймером в пару секунд, а можно и не ограничивать.
Аноним 16/02/20 Вск 20:56:40 #34 №643379 
>>643373
> <username> = Вася Пупкин

File not found: C:/Users/Вася
Аноним 16/02/20 Вск 23:51:27 #35 №643397 
>>643379
пробел не воспринимает шоле?
Аноним 17/02/20 Пнд 01:18:10 #36 №643405 
>>643362
Тащемта я подобный трюк в одной старенькой ааа игре видел, только не помню в какой. Вроде в халве подобное
Аноним 17/02/20 Пнд 08:42:03 #37 №643439 
>>643397
Это зависит от настроек шынды. Годот, как типичное кроссплатформенное приложение, имеет модуль ОС, который в хостовой системе использует её хостовые функции, в случае с виндой - винАПИ, которые могут возвращать совершенно разные результаты в зависимости от настроек. Очевидно, что модуль спроектирован под дефолтную винду с настройками искаропки и не учитывает, что какой-то ZVER в реестре отключил длинные имена в путях файлов.
Аноним 18/02/20 Втр 22:01:13 #38 №643747 
Годнота продолжает поступать
https://youtu.be/twodQHm0gxw
Аноним 18/02/20 Втр 22:33:54 #39 №643751 
думаю начать пилить видосы по сабжу и выложить на тытрубу, есть идеи про что сделать?
sageАноним 19/02/20 Срд 00:54:26 #40 №643755 
>>643751
Обзор годных игор на годоте - вот это ещё никто не делал.
 @ 19/02/20 Срд 08:55:35 #41 №643768 
>>643751
Тоже думаю, но денег нет на хороший микрофон, а имеющиеся микрофоны в гарнитурах записывают говняно.
Из идей: Курс по скриптам для продвинутых (типизация, оптимизация, бенчмарки, обзоры и применение скриптовых ассетов и аддонов, конпеляция с дополнительными модулями самого редактора и экспортных шаблонов). Курс по архитектуре игор (как что называть, в какие папки что складывать, как организовать главное меню, как грузить локации в игровой мир, как сохранять прогресс, по чекпоинтам, по квиксейвам, как организовывать хранение файлов сохранений, как настраивать звук в игре, чтобы фон играл отдельно и плавно переключался на экшн-саундрек в схватках с врагами). Курс по тридэ (как организовать эргономичное передвижение по лестницам, чтобы игрок видел перед собой свои руки, перехватывающие перекладины лестницы и мог в случае чего остановиться, достать ствол и отстреливаться от вражин, сюда же механики падения при ранении и отстреливании врагов лёжа, реализованное в популярных шутанах, комбинированный 1/3person контроллер с плавным масштабированием камеры и переключением плеча, реализация режимов ходьбы, ползанья, полётов (левитации и на крыле), распознавание стен, ступеней, потолков рейкастами и зонами, и адекватная реакция коллиженшейпа на них, реализация пойнт и клик управления в стиле РТС, передвижение по навигационному полигону и переключение с этого режима в режим WASD и много лругое).
Курс по двадэ (подробные разборы платформенных и топдаунных механик, проектирование уровней с расстановкой по ним секретов и активностей, разбор популярных подходов к реализации оных активностей, примеры реализаций каждого в гдскрипте, создание мини-игор и интеграция их в тридэ через вьюпорт-текстуру и многое другое).

Если обладаешь поставленным голосом, студийным микрофоном, можем посотрудничать. Напишу тебе планы лекций, а ты зачитаешь и выложишь. Если ты согласен с утверждением, что авторитет создаётся годами, а рушится за секунду, если готов долго и кропотливо работать чисто по фану, без отдачи, то пиши в личку, обсудим.
Аноним 19/02/20 Срд 14:19:09 #42 №643788 
Что там с системой мультиплеера в версии 3.2? Стал ли он достаточно простым уровня другого движка, который нельзя называть?
Аноним 19/02/20 Срд 14:39:25 #43 №643790 
>>643788
Не щупал, но вроде он и был простой, как rpc.
Аноним 19/02/20 Срд 14:59:52 #44 №643795 
>>643792
В загон, срачер.
Аноним 20/02/20 Чтв 13:44:44 #45 №643959 
https://gotm.io/podotchet/space

Добавил простенькую кнопку скипа хода и пару новых подсказок во время игры с low bot.
Теперь заблоченные другими строениями пути перерасчитываются не полностью, а частично (до заблоченной клетки), сохраняя дальнейший путь выстроенный игроком. (Теперь не будет казаться, что пути не сохраняются)
Добавлен новый спрайт ангара.
Добавлены логи, которые можно смотреть в game_menu.
Правки мелких багов и недоработок.
Аноним 20/02/20 Чтв 16:08:32 #46 №643980 
>>643795
Вахтёр, ты берега попутал, хули ты тут разжигаешь? Пора жаловаться на тебя Абу.
Аноним 21/02/20 Птн 08:22:17 #47 №644042 
>>643959
Это всё замечательно, ты молодец. Я не любитель подобных игор, но желаю тебе успехов. Работай над анимациями, чтобы домики красиво строились и разрушались. Чтоб кораблики красиво разлетались на обломки. Чтобы динамичное меню свистело и пердело. И музон бодрый поставь.
Аноним 21/02/20 Птн 13:17:28 #48 №644096 
Гонки доставляет годноту:
https://www.youtube.com/watch?v=STenRTku4GY
Аноним 21/02/20 Птн 15:53:29 #49 №644114 
>>644042
Спасибо за поддержку!

У меня есть геймдиз-док где расписано уже с десяток строений, вроде как даже забаланшеных на бумаге и механизм "открывания уровней/кораблей", прилепливания любых способностей к корабликам через словари. По факту внедрение одного корабля со стандартной механикой дело 5 минут и он даже будет работать в сети.
Но вот активного рисовалы, который выдавал бы контент в виде корабликов/интерфейса включая и "за денежку" - нет (ответы вроде "не специализируюсь на космических кораблях" или проблемы с нормалмапами). Аутсорс меня отпугивает тем, что если контракт разорвется, то стиль надо будет перерисовывать заново, и я подсяду на иглу.
Так что это задерживает внедрение контента.

Чуть позже, когда на 99% отлажу/оптимизирую некоторые модули, постараюсь вкинуть сюда/гит/ассеты (network,логгер, класс для быстрой работы с хексами и т.п.).

Вчера затестил на игру с одного клиента на андроиде, против второго с компа. Все работает отлично. Только HTML-5 ругается.
Если кто-то знает, почему put_packet выдает 1 ошибку, поделитесь решением (FAILED = 1 — Generic error).
Аноним 21/02/20 Птн 16:46:11 #50 №644120 
>>644114
> Если кто-то знает, почему put_packet выдает 1 ошибку, поделитесь решением (FAILED = 1 — Generic error).
Возможно, сетевые ошибки?
Аноним 21/02/20 Птн 19:36:46 #51 №644142 
Когда в движок приходят дизайнеры:
https://www.youtube.com/watch?v=0oQ5yignti4
Аноним 21/02/20 Птн 20:04:34 #52 №644145 
>>644120
На андроид и винде в приложухе пашет даже при задержках в 10сек. Ощущение, что gotm.io блочит. Либо я чего то не шарю.
Аноним 21/02/20 Птн 20:47:05 #53 №644147 
>>644145
Ну это уже ящитаю повод им в саппорт постучаться.
Аноним 22/02/20 Суб 16:49:50 #54 №644253 
Есть у кого напримете иконки энергии (электричества) квадратного типа в центр которой можно вставить число?
Аноним 22/02/20 Суб 17:20:48 #55 №644258 
>>644253
opengameart.org
ИТТ Вкатывальщик 22/02/20 Суб 22:39:50 #56 №644324 
Идеи для вката целой минитимы 3 долбаёба, чтобы было минимум рисовашки и чтоб экшон был.
Естесна, 2Д нужны.
Ну и чтобы по максимум изучить годот.
Аноним 22/02/20 Суб 23:26:12 #57 №644340 
>>644324
Идей куча. Фейкомыльце найдешь при грамотном прочтении треда. Недавних постов. Сейчас занимаемся туториалами, но на организацию реального девелопа ресурсы тоже найдутся.
Аноним 23/02/20 Вск 03:28:05 #58 №644371 
С++ нужно знать?
Вкатывальщик 23/02/20 Вск 08:20:37 #59 №644390 
>>644371
Вообще всем. Хорошо знать нельзя, но кто что знает - тому хватает.
Аноним 23/02/20 Вск 11:50:43 #60 №644411 
Хей, анончики! Поясните по использованию .gdignore: Например, я делаю эрпогэ с корованами и много моделирую. В проекте свалены файлы blend, референсы, вспомогательное барахло (старые версии и бэкапы) все это я прячу в папочке с маркером .gdignore и годот их не видит, и все вроде нормально, но зачем мне всё это держать внутри проекта? Допустим, к разработке подключились новые люди, занимаются кодингом и им гигабайты модельного барахла качать не айс.
И тут возникает вопрос. А кто вообще придумал хранить это внутри проекта? Может лучше вынести модели блендера и документы фотошопа наверх, а внутрь только забрасывать экспорт из них, glb, png.
Получается .gdignore вообще не нужен?
Аноним 23/02/20 Вск 13:24:31 #61 №644423 
Господа, в честь Вашего теплого приема, особенно от >>644042, на 23 февраля, я запилил Вам хардкор лвл в https://gotm.io/podotchet/space и мне очень интересно, сможете ли Вы его пройти.
Если все же Вас это заинтересует, и Вы вдруг пройдете, сбрасывайте сюда тактику, скриншот победы и пожелание награды в разумных пределах: (
- Подписка на новые apk для андроид, где можно поиграть по сети?
- Рублей 300 на карту?
- Занесение Вашего ника куда-нибудь?).

Всем хорошего дня и настроения!
Аноним 23/02/20 Вск 13:35:21 #62 №644424 
>>644423
Рублей 300 скину только первым трем, потому что он чет иногда играет нормально, а иногда багает, сук. И именно когда я выложил!
Аноним 23/02/20 Вск 13:43:36 #63 №644425 
Какой последний положняк годота + ведро? Год назад когда заходил было дико неоптимизировано. Изменилось ли за год что нибудь? Если нет, продолжу ковырять свой платформер на libgdx
Аноним OP 23/02/20 Вск 14:34:15 #64 №644430 
>>644425
> Какой последний положняк годота + ведро?
ОП предлагает делать игры для пекабояр. На ведро похуй. Желает Хуану выпилить поддержку ведра и ябла. Если анонимус желает делать игры на ведро, от ОПа он не получит здесь ни поддержки, ни помощи.
Аноним 23/02/20 Вск 14:56:47 #65 №644435 
>>644430
А порицание и струи мочи?
Аноним 23/02/20 Вск 15:13:21 #66 №644448 
>>644425
Да, с версии 3.2 стало практически летать. Ведроид стал неплохой платформой для годота. Единственное, что пока сосет - html5.
Аноним 23/02/20 Вск 16:53:32 #67 №644486 
Вопрос. Допустим я хочу сделать общий класс/ноду (пока не очень понимаю, как это лучше сделать в годоте) item и наследовать от него все предметы. Стоит ли делать это с помощью "extends ..." на наследуемом объекте?
Аноним 23/02/20 Вск 18:10:16 #68 №644509 
>>644486
В документации пример как раз про твои айтемы
Аноним 23/02/20 Вск 18:23:37 #69 №644515 
>>644430
Анон же, в свою очередь, советует ОПу свернуться калачиком и сосать свой собственный стручок. Ну и не указывать анону, что и как ему делать.
Аноним 23/02/20 Вск 18:25:44 #70 №644518 
>>644425
Если будешь использовать тайлмапы, то получишь 10 fps на выходе. Остальное вроде норм.
Аноним 23/02/20 Вск 18:42:45 #71 №644522 
14866643930360.jpg
>>644515
>Анон же, в свою очередь, советует ОПу свернуться калачиком и сосать свой собственный стручок
Аноним 23/02/20 Вск 19:07:43 #72 №644529 
>>644518
При заполнении или расчете ходьбы(столкновений) по клеткам?
Аноним 23/02/20 Вск 19:33:07 #73 №644537 
>>644529
Всегда.
Аноним 23/02/20 Вск 23:40:42 #74 №644648 
>>644518
Что вместо тайлмапов юзать?
Аноним 24/02/20 Пнд 05:20:22 #75 №644662 
>>644425
>>644518
->
>>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
Аноним 24/02/20 Пнд 11:04:00 #76 №644687 
>>644648
Если прям срочно надо, прям горит, то можешь юзать ручную отрисовку на канве (холсте, канвасе, canvas) Решение было в прошлом треде, со скрином готового кода на 50 строк.
Аноним 25/02/20 Втр 12:57:47 #77 №644936 
Те кто говорит о плохой производительности - использовать многопоточность в коде пробовали?
Аноним 25/02/20 Втр 13:35:55 #78 №644947 
>>644936
Чтобы пробовать треды, нужно быть программистом, а у нас в основном геймдизайнеры-директора.
> 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
Аноним 25/02/20 Втр 14:14:06 #79 №644956 
>>644936
Там затык в выводе графики, а не в процессоре.
Аноним 25/02/20 Втр 14:24:20 #80 №644962 
>>644956
Выпустили уже 4? Тестил кто хуановулканг?
Аноним 25/02/20 Втр 20:00:12 #81 №645043 
>>644962
только 3.2.1 на подходе
Аноним 25/02/20 Втр 22:20:37 #82 №645066 
>>644962
Вроде бы там прорывов нет. Да и сколько устройств на андроиде поддерживает вулкан? Нагуглил что 10-30% максимум.
Аноним OP 25/02/20 Втр 22:22:17 #83 №645067 
>>645066
> устройств на андроиде
Честно говоря, похуй сколько их там.
Вулкан нужен для десктопной платформы, пекабоярам.
Вкатывальщик 25/02/20 Втр 22:23:51 #84 №645068 
>>645067
Но... Khronos... Всем...
Аноним 25/02/20 Втр 22:27:39 #85 №645069 
>>645068
ГЛ ЕС позиционировался как мобильная платформа, Вулкан же как полностью глобальная, иначе говоря, на пека она будет работать (и работает, что это я) без мобильных ограничений. На мобилах тоже, ибо к 2020 мобилы для мобильных игродебилов уже сравнялись по мощщи с мемными игровыми ноутбуками.
Аноним 26/02/20 Срд 08:58:54 #86 №645120 
Научите ставить декали на объекты.
Следы от пуль, от покрышек, кровь, вино, кетчуп, вода - вот это всё. Предполагаю, что принцип, как с наложением теней?
Аноним 26/02/20 Срд 19:54:15 #87 №645242 
>>643188 (OP)
Помогите разобраться с рейкастами. Как сделать, чтобы персонаж стрелял не из центра камеры, а из ствола оружия, при этом, ствол оружия должен при стрельбе быть направлен в точку пересечения вектора, направленного из центра камеры на цель, помеченную прицелом на камере в центре. Не могу разобраться, есть какая-то формула?
Вообще, при стрельбе рейкастом это как бы и не актуально. Но если делать ракетницу, то стрельба будет идти объектами-ракетами же. Или бластер, где стрельба будет производиться видимым лучом, повторяющим ранее произведённый прицельный рейкаст.
Аноним 26/02/20 Срд 20:10:30 #88 №645249 
>>645242
Ухх, лень полностью расписывать, что-то вроде такого:
Нода персонажа
-Нода оружия
--Нода кончика ствола
Таким образом они все вместе двигаются
Дальше ноде ствола делаешь look_at ( Vector3 target, Vector3 up ) или look_at_from_position ( Vector3 position, Vector3 target, Vector3 up ) - это в Spatial
Ну и рейкаст кидать от объекта кончика ствола, а не от камеры
Аноним 26/02/20 Срд 20:13:04 #89 №645252 
>>645120
Почекай тут вроде есть
https://godotengine.org/asset-library/asset/241
И вот
https://www.youtube.com/watch?v=CFFZpmbhv6A
https://github.com/Miziziziz/GodotProjectedDecals
Аноним 26/02/20 Срд 20:16:00 #90 №645253 
>>645249
> look_at
Бля, ну конечно же! Чот затупил. Ведь знал же о ней.
>>645249
>>645252
Спасибо, годаны!
Аноним 27/02/20 Чтв 12:49:31 #91 №645328 
Так, ну экспортнул я на линух dodge the creeps, 41 стыдливый мегабайт, динамическая о линковка.
Где я обосраля, неужели дефолтный шаблон настолько плох?
Аноним 27/02/20 Чтв 13:18:27 #92 №645332 
1582798706962.png
Блеать, ну как так? Откуда там циклическая ссылка? Класс это же не инстанс.
Аноним 27/02/20 Чтв 13:43:03 #93 №645338 
>>645332
is Switcher? Но тогда это неюзабельно.
Аноним 27/02/20 Чтв 13:44:37 #94 №645339 
>>645328
Под виндой сам движок с редактором примерно 30Мб.
Аноним 27/02/20 Чтв 13:48:24 #95 №645341 
>>645338
Чому неюзабельно? ЧЯДНТ? Я хочу чтобы каждый свичер мог ссылаться на такой же свичер и если в нодпач левый объект (левого класса) то чтоб игнорировался.
Аноним 27/02/20 Чтв 14:11:00 #96 №645345 
1582801859123.png
>>645338
Переопределил to_string но это такая дикость, пиздец.
Аноним 27/02/20 Чтв 14:16:34 #97 №645346 
>>645341
Да не, ты все делаешь логично, но гдскрипт пока такое не переваривает. Пишут что работают над этим, обещают в 4.0. На всякий случай попробуй переименовать Switcher во что то другое, а потом обратно, вдруг подхватит.
Аноним 27/02/20 Чтв 14:21:32 #98 №645348 
>>645339
Под линухом тоже, но столько же весит и шаблон экспорта.
Короче, соберу свой годот, тем более там очень изи.
Я только не понима, как собрать шаблоны, исходников для них отдельных не нашел, они в дереве проекта в директории platform.
Мб он мне их при сборе движка тоже соберет, было бы заебись.
Аноним 27/02/20 Чтв 14:27:28 #99 №645349 
1582802847605.png
1582802847690.png
1582802847728.png
1582802847740.png
>>645346
Да, это сработало! И код стал элегантнее. И при наличии левой ноды в параметрах она игнорируется, как я и хотел.
Аноним 27/02/20 Чтв 14:27:30 #100 №645350 
>>645348
Просто отдельная сборка с флагами tools=no
https://gist.github.com/Calinou/ceb6d24b16d85bc47f9c5de9c9ae341d
Чтобы сильно уменьшить размер надо уже конкретно фичи отключать - 3d, видеокодеки. На ведре у меня сейчас 7Mb для 2d.
Впрочем если ты пытаешься сделать что то вроде dll (.so?) И пользоааться установленным в систему движком, то тут не знаю, не пробовал.
Аноним 27/02/20 Чтв 15:32:22 #101 №645357 
>>645350
Запутался, что такое tools?
Я итак собираю с tools=no отключаю нщн всякие модули, после этого в bin только бинарник годота.
Аноним 27/02/20 Чтв 15:45:10 #102 №645361 
>>645357
tools это редактор, темплейты - годот без редактора.
Аноним 27/02/20 Чтв 15:53:32 #103 №645366 
>>645361
Блять, пиздец.
Спасибо, анон, проорал
Аноним 27/02/20 Чтв 15:56:21 #104 №645367 
>>645366
Ну это упрощенно, наверняка есть какие то тонкости. Тот же андроид там еще свои ресурсы в темплейт куда то сует.
Аноним 27/02/20 Чтв 16:00:06 #105 №645369 
>>645366
С чего проорал-то?
>>645357
> Запутался, что такое tools?
https://en.wikipedia.org/wiki/Toolset
Есть такое понятие в программистском укладе - тулсет. В него входят редакторы и средства отладки. Нынче зумеры не чтят лапти дидов и под "движком" подразумевают тулсет движка. А Хуан - олдфаг, матчасть знает. Поэтому компиляция с tools=no как раз и даёт нам чистый движок без редактора (тулсета).
Аноним 27/02/20 Чтв 16:09:37 #106 №645370 
>>645369
С зависимостей между опциями.
Я не могу собрать tools=yes с некоторыми disable*-опциями, но при в сборкогайде написано, что я всего должен пересобирать шаблоны, если пересобираю двигло.
Т.е. мутные возможности таковы, как я понял:
- собрать эдитор и шаблоны, но не вырубить некоторые опции у шаблонов.
Следствие - минимальные шаблоны.
Еще я не могу target=release сделать, тому шо для шаблонов можно debug или release_debug. Но я могу собрать tools=yes target=release_debug debug_symbols=no на деле похуй, стрипну
В
- собрать отдельно с tools=no, без 3д, отключается всё, а потом пытаться собрать эдитор с tools=yes, убирая disablы, пока не соберется. Вопрос в совместимости остается открытым, хотя это один продукт.
И еще хотелось бы хотя бы один комментарий в коде модулей увидеть, я молчу про их краткое описание.
Аноним 27/02/20 Чтв 16:11:47 #107 №645371 
>>645370
> но при этом в сборкогайде
> что я всегда должен
> Следствие - неминимальные шаблоны
Аноним 27/02/20 Чтв 16:12:13 #108 №645372 
>>645370
>Я не могу собрать tools=yes с некоторыми disable*-опциями
Да, не можешь, у него в зависимостях, вроде бы, 3d и advanced gui (rich textbox и подобное)
Аноним 27/02/20 Чтв 16:39:00 #109 №645377 
>>645370
> Вопрос в совместимости остается открытым, хотя это один продукт.
Ты собираешь минимальный шаблон, в котором есть только те классы, которые ты экстендил скриптами своего проекта. А в редакторе нет смысла отключать модули. Потом запускаешь свой проект на дебаг-шаблоне и проверяешь, если какая хуйня - он в консоль напишет, чего ему не хватило. Пересобираешь или исключаешь из проекта. Когда всё работает, запускаешь на релизном шаблоне. Если всё норм - релизишь. Если не норм - ещё раз всё перепроверяешь.
Редактор пересобирать есть смысл только если ты добавляешь модули третьей стороны. Тогда да, они должны быть и в тулзовой сборке и в сборке-шаблоне.
Аноним 27/02/20 Чтв 17:02:13 #110 №645382 
>>645377
> в консоль напишет
Кто? Только что собрал только шаблон без дебага, заменил оригинальный, godot gui при экспорте сказал, что шаблон инвалид. Подробностей не было.
Аноним 27/02/20 Чтв 17:15:00 #111 №645383 
>>645377
>>645382
Разобрался, но не совсем.
Понял, что если скормить в виде шаблонов релиз и дебаг мой собранный релиз (т.е. один и тот же), то все будет норм.
Но я не понимаю, зачем ему при экспорте пути к двум шаблонам, как он выбирает нужный, зачем он вообще их сравнивает. Т.е. как мне, допустим, попросить релизный только или только отладочный юзать?
Аноним 27/02/20 Чтв 17:25:54 #112 №645386 
>>645383
Нашел эту галочку. При экспорте. Ладно, когда игру сделаю, тогда уже подберу.
Аноним 27/02/20 Чтв 21:19:17 #113 №645421 
1582827556435.png
Так. Возникла проблем по этому вопросу >>645349 указывающие друг на друга ноды устраивают циклический вызов друг друга и весело переполняют стек. Я уже и так думал и эдак, туплю, не могу найти приемлемого решения.
Код теперь выглядит так. Я убрал все велосипеды и задействовал встроенный механизм из ветки Control. Обошлось без самодельных классов вообще. Однако о циклический вызов таки споткнулся. Мне надо как-то ограничить перебор ссылочных списков по направлениям, но перебранные мною способы не помогают этого добиться. Вводил флаги. Добавлял состояния. Ничего не помогает. Либо не работает перебор, либо при циклическом вызове флаги сами меняются и происходит опять переполнение стека.
Примерное развитие моей мысли таково:
1. Как-то отделить первый вызванный свичер от остальных.
2. В первом обработчике отдать команду во все 4 направления.
3. В остальных обработчиках отдавать направления только в противоположном направлении от триггернувшего.
Аноним 27/02/20 Чтв 22:56:53 #114 №645435 
>>645421
чего вообще хочешь добиться?
Аноним 27/02/20 Чтв 23:00:40 #115 №645439 
>>645435
Пазл из взаимосвязанных ключей, которые могут переключаться группами и по отдельности. Распространённая штука во множестве игор. Интересно решить именно так, через ссылочный список из соседних элементов. Если ничего не выйдет сделаю по старинке - массивом и набором правил.
Аноним 27/02/20 Чтв 23:39:29 #116 №645443 
>>645439
сделай два метода - просто переключение и переключение по нажатию. То что по нажатию - вызывает простое переключение как у нажатого так и у соседей. Метод простого переключения ничего не знает о соседях.. и замени pressed = !pressed на вызов метода

просто есть вероятность что при такой манипуляции годо генерит сигнал и у тебя по нажатию преключаются соседи, которые начинают переключать соседей и так до бесконечности..
sageАноним 29/02/20 Суб 18:27:05 #117 №645666 
Годот выдаёт ошибку что не находит пространство имён godot. Что не так?
Штатный телепат Аноним 29/02/20 Суб 18:29:25 #118 №645667 
>>645666
Время переустанавливать шындовс!
sageАноним 29/02/20 Суб 18:31:05 #119 №645668 
>>645667
Самое время. Но это же не исправит ошибку
Аноним 29/02/20 Суб 18:37:08 #120 №645669 
>>645666
Черт, что ты там шатаешь.
sageАноним 29/02/20 Суб 18:40:05 #121 №645671 
2323.JPG
>>645666
н-н-ничего( Я просто установил годот. Он начал выдавать ошибку что нет билдера С# какого то. Я же не глупый, зашёл на офф сайт, скачал билдер какой то. Всё заработало, но теперь выдаёт ошибку что ему не известно пространство имён godot
Аноним 29/02/20 Суб 19:07:45 #122 №645675 
>>645671
УМВР. Внимательно доустанови чего не хватает.
Также рекомендую научиться гуглить https://github.com/godotengine/godot/issues/19060
У нас тред не совсем тред техподдержки, скорее тред обмена опытом.
Аноним 29/02/20 Суб 19:11:57 #123 №645677 
>>645675
Спасибо большое. Знаю что не тред тех поддежки, просто подзаколебало гуглить
Аноним 29/02/20 Суб 19:15:29 #124 №645678 
>>645677
Просто задавая такие вопросы здесь, отдавай себе отчёт, что в треде может не быть людей, способных ответить оперативно, день или два. За это время можно горы сайтов в гугле перелопатить. Ну и инглиш. Даже не пытайся вкатываться в геймдев без минимального знания.
Аноним 29/02/20 Суб 19:33:31 #125 №645681 
>>645671
Там надо Visual Studio или VS Build Tools, + .NET Framework 4.5. Плюс Mono 5.18 который он вроде бы ставит сам.
Аноним 02/03/20 Пнд 20:45:32 #126 №646103 
Как правильно грузить опенворлд, чтоб не тормозило?
Я для себя наметил такие наметки:
1. Основой сцены является т.н. distant land - огромный низкополигональный террейн 8х8 километров (8Кх8К движковых юнитов) с мыльнейшей текстурой травы и гор, без нормалмапы. По этому террейну расставлены низкополигональные деревья, горы, камни.
2. Вся эта структура видна только издалека, при приближении к любой её части она будет заполняться автоподгружаемыми чанками с высоким левелом детализации.
3. Каждый чанк имеет фиксированный размер. Он имеет в себе скрипты и всё интерактивное наполнение. И здесь главный вопрос, как лучше построить политику компоновки:
3.1. Как в ГТА - Чанки имеют размер 1х1 юнит (метр), грузятся быстро целыми пачками по мере приближения к ним, причём, когда ты быстро летишь на машине, они пропускаются из загрузки, что экономит ресурсы пеки.
3.2. Как в Скайриме - Чанки (ячейки) это логически цельные локации разных размеров. Интерьерные локации грузятся путём предзагрузки через загрузочный экран. Экстерьерные подгружаются автоматически при приближении и внимательный игрок может поймать их на этом, когда горы поблизости резко обрастают деталями.
4. Динамические объекты живут как формулы мировой логики (логики игрового мира) и наполняются телами в виде моделей при приближении игрока. Материализовавшиеся модели получают от мировой логики инфу, что они делают в данный момент, на этапе материализации. Чтоб ранее убитые враги не падали замертво на глазах кекающего от такой хуйни игрока, а чтоб материализовывались сразу мёртвыми.

Дополняйте поправляйте. И примерчиками кода порадуйте.
Аноним 03/03/20 Втр 11:27:26 #127 №646173 
>>645443
Сделол. Было сложно, но я нагородил велосипед из байтоёбства вперемешку со строкоёбством.
Только я сделал несколько иначе. Я в упор не нашёл в документации корректно работающего поля у потомков Control отвечающего за хранение состояния "нажатости". Фокус контролы самовольно передают друг другу. Состояние графической "продавленности" тоже передают. Поэтому пришлось добавить в метаданные кнопкам велосипедное поле, хранящее всё что мне нужно - набор флагов направлений. После чего пришлось подписать все кнопки не на один сигнал, а на целых три: button_down задаёт флаг из всех направлений, button_up снимает все флаги, pressed работает исходя из флага в данный момент, если флагов нет - ничего не делает, если флаги все - обходит всех имеющихся соседей, соседям слева устанавливает флаг "влево", справа - вправо, сверху - вверх, снизу - вниз, если есть только определенный набор флагов, обходит только эти указанные направления. Таким образом я исключил циклический вызов и кодом в 90 строк делаю то же самое, что на массиве я же сделал за 30 строк. Но теперь, оперируя простановкой соседей контролам, я могу гибко менять правила обхода контролов. Что для варианта с массивом потребовало бы другого велосипеда с правилами обхода.
> и замени pressed = !pressed на вызов метода
> просто есть вероятность что при такой манипуляции годо генерит сигнал и у тебя по нажатию преключаются соседи
Не, мне того и надо, чтобы присвоением значения дёргались сигналы.
Аноним 03/03/20 Втр 11:45:33 #128 №646176 
1583225132814.png
1583225133092.png
1583225133239.png
>>646173
Код вдогонку. Может кому интересно будет.
Мелкие пояснения:
1. Учусь работать с битовыми масками. Пора бы уж. 2020 год! Число & Маска == Маска - возвратит тру, если в числе есть указанные в маске биты.
2. Очень удобно константы направлений пошли как ключи для словаря соседей (nb).
3. Принцип метаданных оказался очень удобен для расширения функционала объектов. Даже наследование не нужно. Но насколько это отличается по скорости от поиска метода в классе?
Аноним 03/03/20 Втр 12:00:20 #129 №646180 
1583226020047.png
>>646176
Хех. Запостил код и сразу же обнаружил критическую ошибку. При простом задании правил обработки соседей будет обработан только первый обнаруженный сосед. Так как иф со всеми элифами - это один оператор. Быстрофикс.
Аноним 03/03/20 Втр 13:17:24 #130 №646185 
>>646180
Что-то мне подсказывает, что первый иф вообще лишний. Но проверить пока что не смогу. От компа ушёл.
Аноним 04/03/20 Срд 11:52:02 #131 №646494 
1583311921863.png
>>646185
Таки да. Код ужался вот так:
Аноним 04/03/20 Срд 11:55:47 #132 №646496 
1583312147103.png
Просто оставлю это здесь. Вдруг кому-то понадобится.
Аноним 10/03/20 Втр 10:02:38 #133 №647765 
Правильно ли я понимаю, что галка Local to scene фактически включает мне инстансинг материала?
Аноним 11/03/20 Срд 23:47:23 #134 №648320 
>>647765
Правильно понимаешь.
Аноним 12/03/20 Чтв 11:36:16 #135 №648397 
Тут кто-нибудь пилит что-нибудь на нетив/нетив биндах?
Аноним 12/03/20 Чтв 11:41:35 #136 №648399 
>>648397
Я хотел запилить, но ниасиливаю.
Аноним 12/03/20 Чтв 11:47:42 #137 №648406 
>>648397
Я прям в движке на плюсах писал. Но в результате время линковки оказалось долгим, так что я перешел просто на гдскрипт
Аноним 12/03/20 Чтв 11:50:28 #138 №648410 
>>648406
Ну так правильно. Официально рекомендовано писать модули, линковать их один раз, и дальше работать с ними через скрипт.
Аноним 12/03/20 Чтв 11:55:08 #139 №648414 
>>648410
Вообще я хочу освоить "нейтивскрипт" - традиционные динамические библиотеки. Но ниасиливаю. Раньше, в дельфи это как-то всё намного проще было.
А так для меня этот вариант самый удобный. Движок пересобирать не надо. Пересобираешь только библиотеки свои. Распространяешь вместе с конечной игрой.
Аноним 12/03/20 Чтв 11:56:47 #140 №648416 
>>648410
То есть всю игру чисто на нетив никто не пишет?
Аноним 12/03/20 Чтв 12:01:02 #141 №648419 
>>648410
Сама игра спокойно запихивается в модуль. Плюс в том, что нейтив либу нельзя подключить к html экспорту, а модуль можно.
Аноним 12/03/20 Чтв 22:13:23 #142 №648605 
Господи, вы только поглядите, какие навигационные полигоны красивые!
Построение маршрута одной функцией!
https://www.youtube.com/watch?v=KU1PslMiZ98
Аноним 14/03/20 Суб 21:25:00 #143 №649038 
1584210299881.png
Олдовый стайл.
Аноним 14/03/20 Суб 21:30:58 #144 №649039 
Разрабы годота платят создающим игры на их движке как фалько? По сути платить не придется
(Автор этого поста был предупрежден.)
Аноним 18/03/20 Срд 00:26:29 #145 №649705 
Курс создания игор в стиле первой плойки. От одного из авторов годота, Мизизиза.
https://youtu.be/azH4LD6lMpo
Аноним 18/03/20 Срд 17:41:31 #146 №649885 
Хёртбист начал новый курс эрпогэ мечты:
https://www.youtube.com/watch?v=mAbG8Oi-SvQ
Аноним 18/03/20 Срд 22:10:01 #147 №649948 
b.jpg
>>649705
За 800р научат делать модельки в из кубов в стиле гнома. Это же уровень бесплатных туториалов для новичков.
Аноним 18/03/20 Срд 22:33:50 #148 №649957 
>>649948
Научу тому же самому бесплатно ИТТ.
Аноним 19/03/20 Чтв 07:33:55 #149 №649994 
>>649985
Хреновая (очень) производительность с тайлмапами на чем-либо отличном от PC.
Аноним 19/03/20 Чтв 08:30:00 #150 №649995 
>>649985
Чел, ну пять секунд в гугле же, ёпта!
https://www.gamedesigning.org/engines/unity-vs-godot/
Аноним 19/03/20 Чтв 12:54:14 #151 №650028 
>>649957
Да тут каждый второй так умеет делать, в чем смысол
Аноним 19/03/20 Чтв 17:39:41 #152 №650070 
ПШШШКЦТ...
...идите это сообщение/этот пост...
https://www.youtube.com/watch?v=fZ6bOERw03M
Аноним 19/03/20 Чтв 22:01:32 #153 №650108 
>>650028
> в чем смысол
В обмене опытом.
Аноним 19/03/20 Чтв 23:34:03 #154 №650117 
1584650041971.png
>>649038
Нелехко игоры кодировать!
Аноним 20/03/20 Птн 13:22:58 #155 №650167 
>>643188 (OP)
Как импортировать GLTF2/0 в MeshInstance?
Аноним 20/03/20 Птн 13:31:41 #156 №650168 
>>643188 (OP)
Бля буду, баг нашёл. При открытом микшере громкости на переднем плане фпс в редакторе отпускается до 10 кадров в секунду на 1080Ti.
Аноним 20/03/20 Птн 13:34:30 #157 №650169 
>>650168
В редакторе сниженный фпс, by design.
Аноним 20/03/20 Птн 13:43:18 #158 №650172 
>>650167
Напрямую не нашел.
Либо импортишь как obj и выбираешь во вкладке Import - OBJ as Mesh
Либо как gltf, потом открываешь ее Open Anyway, выбираешь свой меш, и делаешь ему Save as
Аноним 20/03/20 Птн 14:02:23 #159 №650174 
1584702067222.mp4
Экспериментирую с буллетхеллом.
Аноним 20/03/20 Птн 14:46:46 #160 №650188 
Кто тут писал, что он не может сделать нормальный фпс контроллер, чтобы как в халве можно было адекватно взаимодействовать с rigidbody? У скамерсофта в начале неплохой отрывок кода, который вроде как исправляет эту проблему.
https://youtu.be/vVe_DsiWNOI
Аноним 20/03/20 Птн 14:57:34 #161 №650193 
1584705394228.mp4
>>650188
> вроде как исправляет эту проблему
Эта проблема исправлена версией 3.2, заслуги мобилкодела-скамера здесь нет.
Аноним 20/03/20 Птн 15:40:45 #162 №650210 
>>650193
>>650174
Ты простые спрайты спавнишь?
Аноним 20/03/20 Птн 15:41:45 #163 №650212 
>>643188 (OP)
Как правильно настроить вес rigidbody?
У меня предмет одинаково легкий при весе 300 и 30000
Аноним 20/03/20 Птн 16:05:12 #164 №650218 
>>650210
Вообще, как сказать. Я делаю прямо на канве func _draw(): draw_circle(Vector2.ZERO, diameter, color) технически это создаёт спрайт внутри движка. На моём уровне спрайта нет, а кинематик-пулька рисует сама себя.
>>650212
Одинаково лёгкие они у тебя, когда их кинематик-персонаж толкает, да? Внимательно изучи документацию по move_and_slide. Там есть один интересный параметр по умолчанию: бесконечная инерция.
Аноним 20/03/20 Птн 18:02:59 #165 №650232 
>>650174
На спрайтах не взлетит, надо смотреть в сторону multimesh или частиц а то и шейдеров, физику тоже скорее всего надо выбрасывать и писать свою на distance squared.
Аноним 20/03/20 Птн 18:15:59 #166 №650234 
1584717266021.mp4
>>650232
Тут даже не в спрайтах дело, я упёрся в производительность на количестве объектов. Даже если у них нет визуала, они всё равно просаживают фпс.
Про мультимешь знаю. Но мне-то не только визуал нужен, а детект коллизий. Сейчас пытаюсь реализовать такую логику:
Есть спавнер пуль. Он создаёт вокруг себя Area2D, которая детектирует координаты тел, находящихся в ней. Далее частицы летят, спавнер проверяет совпадение координат детектированных тел и пулек. Таким образом пульки отрисовываются одной функцией и для них не нужны тысячи объектов. Будем посмотреть, что получится.
Аноним 20/03/20 Птн 18:28:03 #167 №650235 
>>650234
Подозреваю что любые Area будет вносить оверхед, тебе надо просто поверять по формуле, что-то типа (x-px)✱(x-px) + (y-py)✱(y-py) < radius✱radius
Аноним 20/03/20 Птн 18:43:22 #168 №650238 
1584719001996.png
>>650235
И действительно. Накладывающиеся друг на друга эреи создают пикрелейтед. Пойду изучать формулу.
Аноним 20/03/20 Птн 19:58:13 #169 №650246 
image.png
>>650218
>draw_circle(Vector2.ZERO, diameter, color)
Аж вспомнились уроки паскаля и си в моей школе, ухх какие kerbal space program уровня /б/ мы с помощью примитивов и графиков делали
Аноним 20/03/20 Птн 20:01:03 #170 №650247 
>>650218
>бесконечная инерция
Там же только выбор между отключением функции толкания вообще, не?
Аноним 20/03/20 Птн 20:02:06 #171 №650248 
1520187396951.jpg
>>650238
Расстояние между двумя точками равно диагонали треугольника на координатной сетке (одна сторона это разница координат по x, вторая по y)
Это расстояние сравнивают с радиусом (или суммой радиусов если у тебя игрок тоже круг, а не точка)
Очевидно, что если расстояние меньше радиуса, то круги пересекаются.
Формула диагонали d = sqrt(a2+b2) по теореме Пифагора
Мы проверяем d < r
Но поскольку корень дорогая операция, в движках оперируют squared значениями
d2 < r2
Таким образом в левой части просто не извлекают корень, а в правой, если возможно, используют константу. Например, если размер пули не меняется.
Аноним 20/03/20 Птн 20:07:38 #172 №650250 
>>650246
Ну дак! Яж и ностальгирую таким образом по старым добрым временам. Отыскиваю вот такие пасхалки от Хуана, который тоже их заложил, ностальгируя по старым временам.
>>650247
Ну дак! Либо стул с инерцией, либо стул с коллизиями. Любое упрощение в главном является усложнением в мелочах. Кинематик боди с его простыми функциями движения означает, что всю физику тебе придётся запиливать самому.
>>650248
Слава Хуану, скваред предусмотрительно вынесен в интерфейс и выполняется в скомпилированных потрохах движка на си++.
Аноним 21/03/20 Суб 22:38:45 #173 №650401 
1584819525050.png
Блять, я такого говна накодил прошлой осенью, пиздец!
Проще всё заново переписать.
И главное, все мы знаем знаменитую пословицу, что когда возвращаешься к коду, который написан давно, то ничего не понятно. Мне-то понятно, как там и что. Но оно так мудацки написано, что у меня фейспалм с прошлогоднего себя. Например, была задача с компоновкой графического интерфейса. Я нахуярил CanvasLayer в который положил несколько Control, пикрелейтед. Потом прилепил к нему скрипт и в нём хуярил логику для всех ветвей этой сцены. Потом я сделал ветви отдельными сценами, но скрипт переделывать мне было лень и я продолжил хуярить говнокод туда. Результат немного предсказуем - глючная каша.
Сейчас сижу, сдерживая дым из горящего пердака копипащу в отдельные скрипты подсцен фрагменты оригинального скрипта, чтобы инкапсулировать поведение каждой субсцены.
Аноним 23/03/20 Пнд 21:24:26 #174 №650779 
как парсануть джсон?
Аноним 23/03/20 Пнд 21:32:13 #175 №650781 
>>650779
Ты серьёзно такой немощный?
parse_json()
Аноним 24/03/20 Втр 01:12:03 #176 №650814 
как заставить спрайт смотреть в ту сторону, куда направлен вектор? пилю топдаун, довольно важно
Аноним 24/03/20 Втр 01:20:36 #177 №650815 
>>650814
нашёл
$имяспрайта.rotation = velocity.angle()
Аноним 24/03/20 Втр 05:41:15 #178 №650826 
изображение.png
Есть способ сделать тени короче? Маску там наложить какую-нибудь, скрипт, не?
Аноним 24/03/20 Втр 08:36:13 #179 №650833 
>>650826
Спрайт света меньше сделать, например.
Аноним 24/03/20 Втр 08:52:29 #180 №650834 
>>650833
Но это же совсем не то. Меня интересует именно уменьшение длины тени, чтоб она выглядела так, будто её сам объект отбрасывает от источника света, который находится где-то сверху, а не на уровне ног.
Аноним 24/03/20 Втр 12:14:40 #181 №650853 
>>650834
Это скорее всего тебе придется на красные ноды перейти с синих. ЕВПОЧЯ.
Аноним 24/03/20 Втр 15:36:25 #182 №650874 
1585053384279.png
Посаны, велосипед или нет?
Ткните носом в АПИ, если есть, пока я не написал ещё сотню строк кода.
Аноним 24/03/20 Втр 16:05:08 #183 №650883 
1585055106995.png
1585055107144.png
1585055107168.png
>>650874
А используется это вот так:
Аноним 24/03/20 Втр 16:29:16 #184 №650886 
>>650826
Что то типа такого?
https://www.youtube.com/watch?v=Gz6x56CN0FA
Или https://www.reddit.com/r/godot/comments/efh7hz/directional_2d_blurred_shadows_through_fragment/
Аноним 24/03/20 Втр 16:54:33 #185 №650893 
1585058072891.png
>>650883
Как будто на 20 лет назад вернулся, во времена старого доброго дельфи!
Двоеточие-равно сильно добавляет атмосферы.
Аноним 24/03/20 Втр 17:25:24 #186 №650902 
>>650886
Оба варианта вполне подходят. Придётся с шейдерами пердолиться?
Аноним 24/03/20 Втр 17:29:34 #187 №650904 
>>650902
> Придётся с шейдерами пердолиться?
Шейдеры не так страшны, как ты их себе малюешь. Стоит освоить шейдеры и всё остальное отбросишь за ненадобностью и тормознутостью.
Аноним 24/03/20 Втр 17:30:09 #188 №650905 
>>650902
Оба варианта с ссылками на исходники, я сам 2д не занимаюсь. В первом, вроде бы нет шейдера, просто полигон рисуется дублированно несколько раз разными градациями яркости. Но и выглядит похуже. Второй с шейдером.
Аноним 26/03/20 Чтв 12:24:43 #189 №651196 
Всем привет. Как Шейдеры нормально использовать на все элементы, а не только на 1? Когда делаю color-rect сверху, чтобы он что-то сделал со screen_texture выдает ошибку. 2D. Да и работать с полной screen_texture не удобно, хочу ограниченную рамку и менять все что под ней относительно этой рамки.
Аноним 26/03/20 Чтв 15:45:29 #190 №651240 
>>651196
LocalToScene
Аноним 26/03/20 Чтв 15:48:52 #191 №651244 
>>651196
Или нет, падажжи. Тебя хуй поймёшь. Может имеется ввиду, что ограничить отрисовук рамкой? Тогда ClipContent
Аноним 26/03/20 Чтв 21:52:54 #192 №651332 
50 минут и вы начинаете делать игры:
https://www.youtube.com/watch?v=QftpPI5iYrY
Аноним 26/03/20 Чтв 22:55:20 #193 №651346 
1585252517882.png
Ля какую годноту нашёл!
Пикрелейтед. Взято отсюда: https://youtu.be/4xMaq-qVQGY?t=421
Аноним 27/03/20 Птн 06:20:42 #194 №651374 
>>643188 (OP)
Есть какой-то способ, как ускорить/оптимизировать сам Godot? У меня даже на зионе с 8 гб оперативы он умудряется тормозить. Сомневаюсь, что можно делать что-то сложнее хеллоуворлда с такими лагами. Я, конечно, понимаю, что движок целиком в одном exe под 50 метров, вряд ли из него что-то можно выкинуть, но ведь исходники открытые, должен быть способ перекомпилировать в облегченном режиме...

А ещё бы интерфейс по-проще, вместо "а-ля Блендер", но это неосуществимые мечты
Аноним 27/03/20 Птн 08:31:44 #195 №651380 
>>651374
Время переустанавливать шындовс. Или что там у тебя. Потому что кроме тебя на тормоза редактора никто не жалуется.
Аноним 27/03/20 Птн 09:36:09 #196 №651383 
1585290968415.png
1585290968835.png
>>651380
Ничо не тормозит на вот таком конфиге.
Аноним 27/03/20 Птн 12:12:34 #197 №651400 
>>651374
Пиши конкретику, тут вообще не ясно что именно у тебя тормозит. У меня на двух ядрах и 4 гб не тормозит, если не использовать еба постпроцессинг. Какая у тебя видеокарта? Возможно в ней затык.
У меня была история с тормозами когда я добавил ноду с ошибкой. Не помню, в чем там была причина, то ли моделька была неправильная, то ли скрипт, в результате в лог сыпалось много ошибок, и из за этого сцена запускалась в 10 раз дольше. После удаления ноды и добавления заново все исправилось.
Аноним 27/03/20 Птн 13:24:58 #198 №651411 
>>651244
Нет. Мне надо взять кусок экрана и размазать его со всеми элементами на нем. Но мне выдает ошибку буфера. Я ставлю copybuffer снизу, но мне все равно выдает ошибку и в игре все что было с шейдером черное. Я так понял из-за вечного шейдерного цикла. Чертов SCREEN_TEXTURE;
Аноним 27/03/20 Птн 14:11:25 #199 №651417 
>>651380 >>651400
Походу проблема была в старой версии, щас скачал актуальную с сайта и вроде не лагает. Раньше прям даже главное меню сильно лагало, установить и запустить пример платформера - боль.
Аноним 27/03/20 Птн 16:12:57 #200 №651442 
>>643188 (OP)
Что ж, пришло время задавать очень глупые вопросы.
Статус: Новичок.
Что за управление в Godot ?
ПКМ - Вращение сцены. А Как двигаться ?
Аноним 27/03/20 Птн 16:22:20 #201 №651444 
>>651442
Управление в 3д редакторе:
Пр. кнопка мыши - вращать камерой
Ср. кнопка мыши - вращать вокруг выбранного объекта
Шифт + Ср. кнопка мыши - перетаскивание камеры редактора
Пр. кнопка мыши + WASD - движение как в шутере
Shift+F вкл/ввкл режим WASD
F - навести камеру на выбранный объект.
Аноним 27/03/20 Птн 19:21:43 #202 №651467 
image.png
Хочу сделать игру типа Obsurity Huper light Drifter.
Что лучше выбрать, Годот или Гейммейкер?
Точно знаю, что гейммейкер подойдёт, ведь оригинал на нём и сделан, но это вроде очень ограниченный движок, а Годот позиционируется как что-то уровня Юнити, но без тормозов.
Может ли Годот в такое 2Д и есть ли тут какие-то подводные камни?
Просо если изучать с 0, то лучше уж что-то более продвинутое и мощное.

Не срача ради. Не надо сравнивать движки, просто ответе на вопрос, будет ли для этой цели Годот таким же подходящим как гейммейкер и есть ли у него какие-то плюсы в этом плане?
Аноним 27/03/20 Птн 19:28:00 #203 №651468 
>>651467
Брать 3д движок для 2д игры и рассчитывать на то, что "будет быстрее"? Ну такое.

В любом случае результат зависит только от тебя. Движок за тебя игру не сделает.
Аноним 27/03/20 Птн 19:44:57 #204 №651469 
>>651467
>Годот позиционируется как что-то уровня Юнити, но без тормозов.
Кем? Где?
>Не срача ради. Не надо сравнивать движки, просто ответе на вопрос, будет ли для этой цели Годот таким же подходящим как гейммейкер
Да, конечно.
>Может ли Годот в такое 2Д и есть ли тут какие-то подводные камни?
Есть, кое что придется оптимизировать самому.
Аноним 27/03/20 Птн 19:47:16 #205 №651470 
>>651411
Ты прав, что-то странное, то же самое. Попробую разобраться.
Аноним 27/03/20 Птн 20:00:44 #206 №651479 
>>651469
>Годот позиционируется как что-то уровня Юнити, но без тормозов.
>Кем? Где?
У него в классе. А может старшики из 5б просветили.
Аноним 27/03/20 Птн 20:19:53 #207 №651487 
>>651469
Спасибо.
Аноним 28/03/20 Суб 20:20:13 #208 №651744 
Кто делал под андроид/ios, подскажите какой там минимальный размер apk файла с одним движком выходит.
Аноним 28/03/20 Суб 20:56:24 #209 №651761 
1431853130061.png
>>651744
Если заморачиваться то 6 MB.
Аноним 28/03/20 Суб 20:59:15 #210 №651764 
g.png
>>651761
А что примерно и где настраивается для этого? А то сейчас в apk засовывается чудо таких размеров.
Аноним 28/03/20 Суб 21:02:16 #211 №651767 
>>651764
А ты для одной архитектуры экспортишь? Armeabi-v 7a либо Arm 64-v 8a
Аноним 28/03/20 Суб 21:05:12 #212 №651768 
>>651764
Вот мой батник сборки

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 если не пользуешься.
Аноним 28/03/20 Суб 21:07:52 #213 №651770 
>>651768
Да, естественно это без 3d, и без rich texteditor ну мало ли не очевидно
Аноним 28/03/20 Суб 21:12:50 #214 №651771 
>>651767
ну конкретно это открыта для одной, а так делал дефолтную под две, хроме x86

>>651768
это надо движок пересобрать сам?
Аноним 28/03/20 Суб 21:21:48 #215 №651772 
1501980652152.png
>>651771
>так делал дефолтную под две
Это удваивает размер сходу. А в плеймаркете, вроде, можно по отдельности заливать апк под каждую архитектуру.
>это надо движок пересобрать сам?
Да.
Аноним 28/03/20 Суб 21:24:43 #216 №651773 
>>651772
да сборки под каждую понятно, что увеличивают на количество сборок в одном пакете, просто сама библиотека движка на 27 мб впечатлила
спасибо, буду разбираться
Аноним 28/03/20 Суб 21:26:54 #217 №651775 
>>651773
На всякий случай уточню, ты же не debug экспортил, а release?
Аноним 28/03/20 Суб 21:35:48 #218 №651776 
>>651775
Как было дефолтное при установке, ничего не менял.
Аноним 28/03/20 Суб 21:40:20 #219 №651777 
1502401344928.png
>>651776
Вот эта галочка, возможно если ты ее уберешь, тебе этого хватит.
Аноним 28/03/20 Суб 21:48:19 #220 №651779 
Как правильно пользоваться Area? Я правильно понимаю, что Area можно использовать как зону-триггер? Вот с RayCast было несложно разобраться (у него много параметров, функций, etc), а назначение Area не ясно.
Аноним 28/03/20 Суб 21:53:00 #221 №651781 
>>651779
>Area можно использовать как зону-триггер?
Да, можно. Она посылает сигналы, если в нее вошла/вышла другая зона, вошло/вышло Kinematic/Rigid/Static Body. Можно вручную вызывать функции, которые перечисляют с какими area или body есть пересечение. Еще там можно задавать свою гравитацию и параметры звука, но с этим я пока не знаком.
Аноним 29/03/20 Вск 00:32:41 #222 №651818 
изображение.png
Просмотрел по диагонали это: https://godotengine.org/article/optional-typing-gdscript
>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'ы? Это же противоречит самой сути массива, предназначение которого - однородные данные...
Аноним 29/03/20 Вск 00:49:36 #223 №651820 
>>651818
Сам спросил @ сам ответил:
>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, и то ладно...
Аноним 29/03/20 Вск 08:11:50 #224 №651854 
>>651851
вот уж сисярп там точно не нужен, если надо скрипты, то надо брать что-то нормальное интерпретируемое вроде Lua
Аноним 29/03/20 Вск 11:17:22 #225 №651868 
>>651820
Вроде в 4.0 что-то переделают в этом плане, и всякие Pool*Array тоже заменят на другое.
Аноним 29/03/20 Вск 11:19:42 #226 №651869 
>>651868
Ну там собственно сделать С API, дальше сами желающие будут пилить биндинги под нужные им языки.
Аноним 29/03/20 Вск 12:58:23 #227 №651875 
>>651854
> надо брать что-то нормальное интерпретируемое вроде Lua
ГДскрипт и есть потомок луа.
Аноним 29/03/20 Вск 13:10:19 #228 №651876 
>>651868
>в 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
Можно было сделать этот тип массива типом по умолчанию, но уж точно не делать его единственным. -_-
Аноним 29/03/20 Вск 13:12:53 #229 №651877 
1441481597276.jpg
>>651875
>ГДскрипт и есть потомок луа.
Аноним 29/03/20 Вск 13:41:45 #230 №651881 
изображение.png
изображение.png
Задумался тут: если мне нужно сместить точку крепления модели (origin point), я могу это только через дополнительный Spatial сделать, так ведь? Как движок относится к большому числу таких пустышек?

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

Вообще, сколько всего объектов (не полигонов, а вот этих сущностей) может держать Godot без просадок производительности?
Аноним 29/03/20 Вск 13:45:05 #231 №651884 
>>651877
Код сравни построчно, человек-мем, блеать.
Аноним 29/03/20 Вск 13:49:15 #232 №651885 
>>651881
> Как движок относится к большому числу таких пустышек?
Хуёво. Я десятком постов выше экспериментировал с буллетхеллом. Так вот там, если просто спавнить пустышки и добавлять их в дерево, то где-то на 5к штук начинает падать фпс. Экспоненциально. Я там отписался, что из-за спавна Area фпс падает, но потом заменил Area на пустышку, охуел и не стал ничего сообщать.
Аноним 29/03/20 Вск 13:51:56 #233 №651887 
>>651884
Это питон, а не луа. Луа это говноподелие без массивов, с индексами начинающимися с 1, и так далее.
Аноним 29/03/20 Вск 13:57:50 #234 №651890 
>>651887
> Луа это говноподели
Я не луашизик, срущий своим луа по всем тредам, если чо. Но, справедливости ради, луа при всех своих странностях является одним из быстрых скриптовых языков. И юзается в большом количестве игор. Примеры сам загуглишь.
Аноним 29/03/20 Вск 13:59:00 #235 №651891 
>>651890
>является одним из быстрых скриптовых языков.
Только за счет того что в нем очень мало возможностей. А LuaJIT нечестно сравнивать, потому что даже Java обгоняет его в таком случае.
>И юзается в большом количестве игор
В основном доисторических 10+ лет назад.
Аноним 29/03/20 Вск 14:25:14 #236 №651894 
>>651891
Ну таки да. Но луашизику хуй чо докажешь. Второй год уже ноет, типа "почему луа не завезли?"
Аноним 29/03/20 Вск 14:40:31 #237 №651896 
>>651875
вообще-то питона и далеко не Lua
Аноним 29/03/20 Вск 14:41:05 #238 №651897 
>>651894
Пиздец. За 2 года давно сам бы биндинги сделал.
Аноним 29/03/20 Вск 14:42:11 #239 №651898 
изображение.png
>>651885
>где-то на 5к штук начинает падать фпс
Ну, это было ожидаемо. Ладно, от части Spatial я могу избавиться (хотя всё равно не ясно, можно ли как-то иначе изменять origin без плясок с бубном). Тогда следующий вопрос: возможно ли "выключать" отдельные ноды из общего дерева, чтобы они временно не тормозили игровой цикл, пока не потребуются? Собирался грубо кодом разрывать связь между предком и потомком, сохраняя потомка в отдельной переменной, чтобы потом возвращать когда понадобится, но мне на глаза постоянно попадается вот эта вкладка "Pause", и мне любопытно. Пауза ведь именно для такой заморозки объектов, которая мне нужна? Или она для чего-то другого? Если я поставлю на паузу дерево из, скажем, сотни веток - они все будут исключены из общего цикла, или будет что-то вроде if not entity.paused then entity.process else continue? В первом случае выигрыш примерно как в моём варианте, во втором всё равно каждый кадр будут лишние операции.
Аноним 29/03/20 Вск 14:42:28 #240 №651899 
>>651897
Лоол, есть даже готовый модуль для 3.2
https://github.com/perbone/luascript
Аноним 29/03/20 Вск 14:46:34 #241 №651900 
>>651898
> возможно ли "выключать" отдельные ноды из общего дерева, чтобы они временно не тормозили игровой цикл, пока не потребуются?
Возможно. Буквально в прошлом треде и начале этого обсуждали такой трюк:
1. Делаешь ноду, не включенную в общее дерево. Она висит в памяти в спящем режиме, у неё и всех её потомков не вызываются колбэки и т.п.
2. Ноды, которые надо выключить, перекидываешь в потомки этой ноды.
3. Ноды, которые надо включить, возвращаешь на свои места в дереве.
4. С помощью этой нехитрой системы можно организовать пул для динамической подгрузки чанков локаций.
Аноним 29/03/20 Вск 14:49:09 #242 №651901 
>>651891
Java не обгоняет LuaJIT
нет, его используют и сейчас все так же активно в индустрии, т.к. замены пока не сделали сопоставимой
Аноним 29/03/20 Вск 14:58:03 #243 №651902 
>>651901
>Java не обгоняет LuaJIT
В некоторых бенчах обгоняет. Как и питон, и т.д.
> его используют и сейчас
Там где он уже есть в легаси, как например в ГТА потому что он у них там давно.
В новых играх - где?
Аноним 29/03/20 Вск 15:05:45 #244 №651907 
>>651902
в новых играх и скриптовые языки-то почти и не используют, т.к. там какой-либо моддинг не предусмотрен
roblox, factorio, don't starve.. почти везде, где есть какие-то моды и не используют свой язык, типа tes
Аноним 29/03/20 Вск 15:10:55 #245 №651908 
>>651907
Авторы факторио неоднократно писали что взяли Луа, так что.
Аноним 29/03/20 Вск 15:11:42 #246 №651909 
>>651908
Авторы факторио неоднократно писали, что пожалели о том, что взяли Луа
самофикс
Аноним 29/03/20 Вск 15:13:22 #247 №651910 
>>651909
Другие не жалели, а roblox с учетом масштаба работы еще и прорабатывали обоснованность выбора каждого из языков.
Аноним 29/03/20 Вск 15:16:08 #248 №651911 
>>651910
Ну так вперёд
>>651899
Делай игры.
Аноним 29/03/20 Вск 15:17:15 #249 №651912 
>>651911
Что вперед, ты о чем вообще?
Аноним 29/03/20 Вск 15:19:25 #250 №651914 
>>651910
Другие - это ноль, на уровне статистической погрешности. А уеблокс вообще не игра, а какое то кривляние для школьников, похуй.
Аноним 29/03/20 Вск 15:19:57 #251 №651915 
>>651912
> Что вперед
>>651911
> Делай игры.
>>651912
> ты о чем вообще?
Делай. Игры.
Аноним 29/03/20 Вск 15:21:16 #252 №651916 
>>651915
Так я делаю, к чему вообще это.
Аноним 29/03/20 Вск 15:40:41 #253 №651919 
>>651900
О, ну почти именно так я и планировал. Только хотел извлекать одну ноду в переменную целиком, а не поштучно закидывать.

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

Так а для чего режим паузы нодов? Погуглил, жалуются, что паузить можно только всё дерево целиком...
Аноним 29/03/20 Вск 15:43:56 #254 №651920 
>>651919
Помещения дома не критичны, на то, что ты их менеджерить будешь и выгружать/загружать скорее больше ресурсов и потратишь. Просто разбивай сам уровень на чанки по какому-то радиусу и сохраняй на диск ненужные, а все их ноды удаляй.
Аноним 29/03/20 Вск 15:45:31 #255 №651921 
>>651920
Критичны, окклюжн куллинга то нет.
Аноним 29/03/20 Вск 16:14:39 #256 №651927 
>>651920
>Помещения дома не критичны
Только если:
1. В помещениях мало объектов
2. Мало домов с помещениями
я жта хочу, но чтоб в домики заходить можно было

Вопщем, надо просто тесты провести и самому убедиться.
Аноним 29/03/20 Вск 16:49:50 #257 №651938 
>>651927
> Вопщем, надо просто тесты провести и самому убедиться.
Святые боги! Адекват в треде!
Аноним 29/03/20 Вск 19:15:27 #258 №651998 
изображение.png
изображение.png
изображение.png
изображение.png
Продолжение >>651881 >>651898
Короч, если кому-то интересно, я немного поэкспериментировал и пришёл к таким выводам:
- отключение нод работает именно так, как я думал;
- подключение и отключение статикбади происходит мгновенно;
- подключение и отключение динамикбади вызывает фриз игры на секунду.
Похоже, что дело не в количестве нод, а в наличии подвижных объектов. В частности, пробовал наполнять жёлтую комнату как статичными, так и динамичными объектами (те же точки, то же количество) - статичные появляются мгновенно, динамические при появлении и исчезновении вызывают очень неприятную задержку, но после появления ведут себя как обычно (не тормозят).

Ещё заметил момент, важный конкретно для моей игры - если предмет выкатывается из комнаты, он по-прежнему остаётся привязанным к "исчезающим". То есть для игрока предмет на улице, но выходя на улицу предмет исчезает, таким образом становится недосягаемым. Знаю, как это можно исправить, да. Но вот от лага при добавлении/удалении хотелось бы избавиться. Я был бы согласен, если бы объекты появлялись постепенно, если б не вызывали лаг... А, ну, можно попробовать добавлять/удалять не в цикле for, а в _(physics)_process, но сомневаюсь, что получится норм.

Пока что Godot превосходит мои ожидания :D
Аноним 29/03/20 Вск 19:41:11 #259 №652005 
>>651998
Думой над архитектурой.
Допустим по сюжету игры планируется появление и исчезновение объектов. Значит ты их все грузишь при загрузке локации, затем те, которых нет для игрока делаешь невидимыми/отключёнными в большом невидимом сундуке под землёй (привет, скайрим).
> Знаю, как это можно исправить, да.
Полагаю ты про parents и owners говоришь сейчас? Если так, то сомнительно использовать механизм овнеров для динамической передачи нод между нодами. Возможно наткнуться на трудноотлавливаемые баги.
Я бы посоветовал делать одну общую ноду для "пропсов", которая по запросу игровой логики выдаёт из своего пула заранее загруженных объектов нужные локациям. Так ты избежишь проблем с
> если предмет выкатывается из комнаты, он по-прежнему остаётся привязанным к "исчезающим"
Чтобы была возможность дизайнить расположение объектов в редакторе, делай объекты-пустышки, которые уничтожают сами себя при загрузке сцены, а на их места ставятся реальные объекты из общей ноды, описанной выше.
Как-то так.
Аноним 30/03/20 Пнд 02:23:20 #260 №652083 
изображение.png
изображение.png
изображение.png
изображение.png
>>651998
>подключение и отключение динамикбади вызывает фриз игры на секунду.
Короче, я ошибся. DynamicBody вообще не имел отношения к этим фризам.
Лень писать, опишу ситуацию кратко:
- динамические кубики CSGBox лагов не вызывали;
- сферы на скриншоте - CSGSphere с параметрами 24x12;
- снижение CSGSphere 24x12 -> 8x4 снизило нагрузку/лаги;
- 64 головы Suzanne из Blender (по 507 вершин) не тормозят.
Вывод - CSG перед появлением в дереве производит какую-то ресурсоёмкую операцию (пытается произвести слияние, даже если не с кем?), и именно она вызывает тормоза. После удаления из дерева тоже происходит какая-то операция, и снова тормоза. Всё остальное время лагов нет - меш, видимо, кэшируется. С обычными мешами такого нет.

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

>>652005
>Значит ты их все грузишь при загрузке локации
Именно так и делаю.
>отключёнными в большом невидимом сундуке под землёй
Так не пойдёт, Годо работает не так, хранить нужно отдельно от дерева сцены.
Точнее нужно хранить ссылку на вырезанную из общего дерева ветку в отдельной переменной.
>Полагаю ты про parents и owners говоришь сейчас?
Не знаю про owners, но я хотел передавать объект из одной ветки в другую.
>одну общую ноду для "пропсов", которая по запросу игровой логики выдаёт из своего пула заранее загруженных объектов нужные локациям
Несколько раз перечитывал, много думал, но ничего не понял. Грубо говоря, мне нужно передать ветку "предмет" из ноды "квартира" в ноду "улица", потому что нода "квартира" скрывает своё содержимое, когда игрок выходит за пределы квартиры (в целях оптимизации дерева сцены, разумеется). Если так не сделать, то "предмет" исчезнет прямо в руках игрока, когда он перешагнёт порог квартиры/закроет дверь в квартиру снаружи.
>дизайнить расположение объектов в редакторе, делай объекты-пустышки
Я так и сделал, но у меня эти пустышки нужны для спавна рандомных предметов (запилил универсальный скрипт).
>реальные объекты из общей ноды
Эм, а зачем их хранить в общей ноде? У меня они сразу появляются на точках спавна. Когда не нужны - скрываются во внутреннюю переменную скрывающей ноды (все сразу). Проблема в том, что делать общую ноду на всю сцену нерационально, у меня сейчас по сути каждая комната занимается скрытием/отображением предметов (генерация только при запуске сцены).

Вот, для примера, на скриншоте с мартышками 3.7К нод - это улица с многоэтажками, а 12.5К нод-сирот - это внутренности тех комнат, в которых игрока сейчас нет (поэтому они скрыты). Если выйти из комнаты с мартышками, они все будут скрыты. Комната сама принимает решение, когда скрывать (с помощью Area), и сама же хранит все свои внутренности. В данный момент всё это выглядит превосходно, проблема только в том, что предметы комнаты нельзя вынести за пределы комнаты. Хотя, я думаю, можно использовать ту же Area, что следит за игроком, чтобы "выпускать" предметы за пределы комнаты...

Вообще, мне главное придерживаться модульного дизайна, чтобы каждый элемент сцены был максимально независим от других. Иначе не получится так легко собирать рандомную сцену (хотя над алгоритмом сборки я всё ещё думаю). Поэтому, например, каждая комната, являясь отдельным модулем, сама заботится о генерации, отображении и скрытии находящихся в ней предметов. Такую систему легко масштабировать... контролировать, правда, трудно, но с этим я ещё разберусь.
Аноним 30/03/20 Пнд 16:21:01 #261 №652128 
>>652083
> Не знаю про owners, но я хотел передавать объект из одной ветки в другую.
Так узнай. https://docs.godotengine.org/en/stable/classes/class_node.html#class-node-property-owner
Это часть механизма загрузки сцен. Её нельзя игнорировать, ибо при сохранении овнера твои ноды выгрузятся со своим овнером, даже если будут у другого парента. А может и не выгрузятся. А может и не сразу, но выгрузятся. В общем - всё проверяй.
> Эм, а зачем их хранить в общей ноде?
> спавна рандомных предметов (запилил универсальный скрипт)
Скрипт наследуется от Node? Вот-вот. По факту общая нода для объектов у тебя уже есть. Только она их не хранит, а спавнит. А теоретически эффективнее делать так: Если объект стал не нужен игроку и скрывается с его глаз, он не уничтожается, а возвращается в пул, где был создан и там, в "большом невидимом сундуке" лежит до тех пор, пока снова не понадобится игроку, после чего ему скрипт-менеджер пула, который нода, назначает новое имя, задаёт новые координаты и закладывает игроку в руки.
Не происходит дорогой операции выделения памяти в куче для нового объекта.
Не происходит дорогой операции выгрузки мусора сборщиком мусора.
Происходят относительно дешёвые операции по изменению координат объектов в пространстве (физический движок) и, возможно их видимости (графический движок).
> главное придерживаться модульного дизайна
Решительно двачую!
Аноним 30/03/20 Пнд 18:58:50 #262 №652156 
изображение.png
изображение.png
изображение.png
изображение.png
>>652128
>Это часть механизма загрузки сцен
А, ну про это я уже читал: https://godotengine.org/qa/903/how-to-save-a-scene-at-run-time
Просто речь шла про передачу от родителя к родителю, а owner только к сохранению относится.

>Если объект стал не нужен игроку и скрывается с его глаз, он не уничтожается, а возвращается в пул
Ты, наверное, про что-то другое говоришь. У меня объект не уничтожается, а временно скрывается.

>относительно дешёвые операции по изменению координат объектов и их видимости
Я бы не сказал, что это дешёвые операции, я попытался расширить зону действия Area комнат на улицу, и заметил, что если игрок триггерит сразу несколько домов по два этажа, происходит небольшой лаг. Хотя, возможно, это опять из-за CSG, только теперь виноваты лестницы (каждая ступенька - CSGBox). Кстати, заодно протестировал удаление/вставку не всей ветки, а по одной ноде за тик физического движка - стало ещё хуже, но скорее всего это из-за CSGBox. Я понимаю, что по-хорошему нужно обычные меши вставить и уже на них тестировать, но т.к. это только тест - мне лень.

Чтобы было понятнее, вот скриншоты моего кода:
1 - "генератор" (заполняет точки спавна рандомными предметами);
2 - "оптимизатор интерьера" (переписывал несколько раз уже);
3 - "глобальный RNG" (хотелось упростить выбор из списка);
4 - "менеджер ресурсов" (должен ускорять генерацию, но сомневаюсь).
Есть некоторые недочёты, но это тест, а не финальная версия)
Аноним 30/03/20 Пнд 19:22:16 #263 №652159 
>>652156
> лестницы (каждая ступенька — CSGBox)
Это безумие, анон. Ты настолько ленив, что не можешь открыть блендер и за 3.5 минуты набросать простейшую модель лестницы?
Аноним 30/03/20 Пнд 19:29:54 #264 №652160 
>>652156
В конце концов, там есть простые графические примитивы мешей. Они наверняка будут пошустрее CSG.
> вот скриншоты моего кода
Я предпочитаю избавляться от сравнений строк со строками в своём коде. Впрочем, это моё, бумерское. Детская травма. Нынче я понимаю, что строки работают не медленнее числовых типов. Но, тем не менее.
Аноним 30/03/20 Пнд 19:46:52 #265 №652165 
>>652159
>Ты настолько ленив, что не можешь открыть блендер
Да.

>Это безумие
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.

Вообще всё началось с "а потянет ли Годо что-то эдакое, если потянет - можно будет думоть дальше".
Потянуть вроде потянул, теперь можно думоть. (думоет)

>>652160
>Я предпочитаю избавляться от сравнений строк со строками в своём коде
Я тоже, но:
- экспортные строки ничем не заменишь (хотя надо посмотреть, есть ли функция length(string) > 0);
- я без понятия, чем отличаются body, кроме name, чтобы понять, которая из них Player;
- загрузка ресурсов идёт по адресу, адрес ничем другим не заменишь.
Я лично сомневаюсь только на счёт name == "Player", но альтернативы пока не вижу (не создавать же отдельный метод it_is_player() и проверять его наличие через has_method()?), да и это сравнение по идее должно тормозить только если в сцене существует множество объектов, чьё имя начинается на "Play...". Если строка начинается с любой буквы кроме "P", она заведомо не равна "Player", и может быть пропущена. Но как именно сравнивает строки Godot - не знаю. Кроме того, эта проверка происходит только на входе/выходе объекта из Area, вряд ли она будет вызываться достаточно часто.

У меня в предыдущей версии "оптимизатора" была функция is_player_indoor, которая перебирала все объекты, с которыми пересекается Area, и вызывалась она в _ready, чтобы проверить, нужно ли скрывать интерьер сразу после запуска. Я понял, что это совершенно лишняя операция, когда попробовал безусловно скрывать интерьер - вокруг игрока он отображается, даже если игрок появляется в комнате при загрузке сцены. С другой стороны, хотелось бы создавать сразу выключенные интерьеры (так можно избавиться от лишнего добавления/удаления в сцену), но я пока не уверен, как лучше это сделать.
Аноним 30/03/20 Пнд 20:19:14 #266 №652170 
>>652165
> не создавать же отдельный метод it_is_player() и проверять его наличие через has_method()?
Нет, конечно. Группы же есть (if body is_in_group("string_group_name") эээ, тоже строки, отпадает). Слои коллизий есть (тут соответственно уже можно либо вообще не ловить коллизии ни с кем кроме плеера, стало быть любое боди будет плеер, либо if body.get_collision_layer_bit(N) = M:). Приглашаю в документацию.
Аноним 30/03/20 Пнд 21:53:55 #267 №652173 
Уроки продолжаются https://www.youtube.com/watch?v=0nd1zNiy0C4
Аноним 30/03/20 Пнд 22:25:48 #268 №652176 
изображение.png
>>652170
>Слои коллизий есть (тут соответственно уже можно либо вообще не ловить коллизии ни с кем кроме плеера
Аааааа, точно, точно. Я многократно натыкался на эту табличку с переключателями слоёв, но думал "ну, это мне не нужно, наверное". Было бы логично настроить детекторы только на игрока...

А вот, кстати, на счёт коллизий и лестниц. Кажется, я когда-то где-то видел, что в играх лестницы физически на самом деле не лестницы вовсе, а наклонные плоскости - в современных играх это имеет смысл или нет? А то я тут починил коллизию персонажа-игрока и вдруг появились проблемы с движением по лестницам: вверх трясёт, вниз прыгает. Если же сделать просто наклонную плоскость, то персонаж съезжает вниз. Контроллер персонажа самодельный, его нужно рефакторить, много мусора... Может, есть какие-то советы (кроме "возьми готовое")? На картинке у меня один луч определяет, находится ли игрок на земле (регулирует гравитацию и способность двигаться и прыгать), другой проверяет, не пытается ли игрок забраться на лестницу (т.к. на лестнице центральный луч зависает над землёй). Так вот движения и прыжки по плоскости и с небольшими выступами происходят нормально, но на более-менее крутой лестнице всё выглядит как-то не очень (после починки коллизии капсулы)...

А ещё я хоть и сделал камеру, которая приближается к игроку, когда с чем-то сталкивается, но она всё равно то в стены проваливается, то трясётся на углах (ну, когда луч прерывается, но не полностью). Чувствую, что ещё долго буду настраивать комфортное поведение камеры, и что делаю что-то не так( У моей камеры есть луч, растянутый между камерой и моделькой игрока, и второй луч, направленный назад. Первый луч приближает камеру, если обзор что-нибудь загораживает, второй луч предотвращает удаление камеры слишком далеко. Хотя, наверное, можно было обойтись одним лучом (надо будет попробовать отодвинуть его чуть назад)... Но вот резкие "вибрации" на углах объектов сильно напрягают. Скажем, в дверном проёме в режиме от третьего лица вообще всё начинает вибрировать, да и просто в помещениях тоже...
Аноним 30/03/20 Пнд 22:27:04 #269 №652177 
>>652176
> Если же сделать просто наклонную плоскость, то персонаж съезжает вниз.
Там, вроде, есть параметр угла наклона
Аноним 30/03/20 Пнд 22:28:34 #270 №652179 
>>652177
А конкретнее вот это
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.
Аноним 30/03/20 Пнд 23:09:34 #271 №652183 
>>652176
> в современных играх это имеет смысл или нет?
Посмотри стримы по Half-Life: Alyx и сделай выводы: Пройдёт не более полугода и классические игоры уйдут в прошлое. Вангую, к лету китайцы резко опустят ценники на виар-комплекты в ответ на возросший спрос.
А в виаре никакие жульничества не прокатят ибо игроки сразу упрутся в них и высмеют разработчика на форумах. Всё придётся делать по честному: Лестницы со ступенями. Вёдра с вогнутой коллизией. Ноги и руки с кинематикой вместо капсульной коллизии.

Будущее всегда наступает незаметно. И Габен принёс нам будущее в этом марте.
Аноним 30/03/20 Пнд 23:13:11 #272 №652186 
>>652176
>второй луч предотвращает удаление камеры слишком далеко
А, он предотвращает отдаление камеры колёсиком мыши, если позади камеры препятствие. Без этой дополнительной проверки камеру можно было задвинуть в стену, после чего она возвращалась назад, и поэтому пришлось сделать отдельный луч (сам по себе он камеру не сдвигает). Уже забывать начал))

>>652179
>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 делать дополнительную проверку, но я уже устал и не хочу об этом думать сейчас.

А, вот ещё - мне хотелось добиться возможности прыгать при движении по лестнице, так вот иногда удаётся настроить возможность прыжков, а иногда настройка сбивается. Да и прыжки на лестнице почему-то получаются выше, чем на ровной земле, лол. Надо разбираться...
Аноним 30/03/20 Пнд 23:21:16 #273 №652188 
>>652183
Чел, ты несешь хуйню, в виаре одни только жульничества и канают, а твоя хуяликс это по меркам виар вообще ничто, сделанная для габеноутят.
Аноним 30/03/20 Пнд 23:21:29 #274 №652189 
>>652186
Старайся делать как можно меньше кода. На любую задачу сначала гугли документацию. А то ты много велосипедов изобретаешь. Для контроля камеры есть нода SpringArm
Аноним 30/03/20 Пнд 23:22:08 #275 №652190 
>>652188
Хах, заскринил. Ставки сделаны.
Аноним 30/03/20 Пнд 23:27:22 #276 №652197 
>>652186
Вот что, я посмотрел как сделано в каком-то контроллере, и там move_and_slide_with_snap
Работает примерно так - если ты передаешь snap вектор который смотрит вниз, то персонаж "прилипает" к полу. Если надо прыгнуть, передаешь нулевой вектор.
Аноним 30/03/20 Пнд 23:28:54 #277 №652199 
>>652190
Скринь, хуле. Чел, я виаром уже пару лет занимаюсь. Там наоборот от реализма отходят в пользу телепортов, чтобы игроков не тошнило, к лоу поли чтобы игроков не укачивало, а та самая аликс приучает игроков что ничего не подвигать кроме того что геймдизайнер разрешил.
Аноним 30/03/20 Пнд 23:31:04 #278 №652200 
>>652183
>ибо игроки сразу упрутся в них и высмеют разработчика на форумах
Я пытаюсь сделать игру в первую очередь для себя.

>Всё придётся делать по честному: Лестницы со ступенями
Вот, кстати, уж где-где, а в современных VR-играх смысла в лестницах нет, там ведь игрок тупо телепортируется с места на место. Передвигаться в VR вообще сложно. А ещё я не представляю, как можно играть в VR, если у тебя в комнате и без него развернуться негде...

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

>>652189
>На любую задачу сначала гугли документацию
Так скучно. Я читаю встроенную справку, но остальное пытаюсь сначала сам сделать.

>Для контроля камеры есть нода SpringArm
Написано "для 3 лица". Мой контроллер может переключать между первым и третьим) Но спасибо, посмотрю.

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

>>652197
>move_and_slide_with_snap
Заметил эту функцию, когда листал справку, надо будет проверить...
Аноним 30/03/20 Пнд 23:39:25 #279 №652203 
>>652199
> а та самая аликс приучает игроков что ничего не подвигать кроме того что геймдизайнер разрешил
Теперь ты хуйню несешь, чел занимающийся виаром, виара не видавший. Не позорься, посмотри, как её стримят хоть. Ясен хуй, сам ты в неё поиграть не сможешь. Гранаты в ведре поносить не сможешь.
Аноним 30/03/20 Пнд 23:43:32 #280 №652204 
>>652203
>ведро дали потрогать
>100500 других пропсов не дали
>ТОЛЬКО ВЫИГРАЛИ! ЗАТО КАСКА ЕСТЬ!
Аноним 30/03/20 Пнд 23:51:47 #281 №652207 
>>652204
> 100500 других пропсов не дали
Что ж ты за отбитый долбоёб, а? Ясен хуй, сформулировать ты ответ на это не способен. Да и не видел ты, как в алихе можно ящики и бочки таскать руками. Что тебе на форумах написздели, то ты и ретранслируешь. А моменты, когда ты одной рукой лечишься в лечилке, а второй рукой держишь на прицеле угол из-за которого может комбайн выскочить - просто бесценны!
Аноним 31/03/20 Втр 00:03:11 #282 №652210 
>>652200
> Вот, кстати, уж где-где, а в современных VR-играх смысла в лестницах нет, там ведь игрок тупо телепортируется с места на место. Передвигаться в VR вообще сложно. А ещё я не представляю, как можно играть в VR, если у тебя в комнате и без него развернуться негде…
1. Телепорты от тошноты - мера временная, потому что гироскопы не поспевают за головой.
2. Двигаться путём прожима аналогового стика на контроллере можно уже сейчас, но из-за 1. у многих возникает морская болезнь.
3. Согласно моему вангованию, эту проблему победят уже в этом году.
4. Раз двигаться можно стиком, от тебя требуется только сидеть во вращающемся кресле.
5. Однако в этом случае ты не сможешь пригибаться и уворачиваться. Так что встал и стой, сцкнх!
6. Согласно моему вангованию, ближе к концу года, возможно в начале следующего, китайцы выкинут на рынок недорогие и функциональные беговые дорожки и в виаре можно будет вообще полноценно бегать, прыгать, перекатываться.
7. Жирные тюлени вроде нас с тобой, несомненно соснут, но рыночек порешает нас, а не зумеров.
8. Так что, да, остаётся только
> сделать игру в первую очередь для себя
Потому что корпорации, по моему вангованию, повторюсь, не позднее, чем за пару лет, ПОЛНОСТЬЮ перепрофилируются на виар.

Всё, нах, можете скринить.

Аноним 31/03/20 Втр 00:09:22 #283 №652211 
>>652207
>>652210
Иди обсуждай это в каком нибудь другом треде, годот к концу года вр тянуть все равно не будет еще, там же надо 120 фпс в 2-4К.
Аноним 31/03/20 Втр 01:05:53 #284 №652217 
>>652210
>корпорации ПОЛНОСТЬЮ перепрофилируются на виар
Туда им и дорога, у меня их игры даже на диск не помещаются, не говоря уж о запуске, так что вообще без разницы, какими эти игры будут.

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

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

>Двигаться путём прожима аналогового стика на контроллере можно уже сейчас
Тогда чем это отличается от обычной игры? Только углом обзора как в подзорной трубе.

>Телепорты от тошноты
Всегда думал, что телепорты для того, чтобы сидеть/лежать неподвижно, а не топтаться стоя.

>>652211
>там же надо 120 фпс в 2-4К
Ну 120 фпс допустим вытянуть можно с лёгкостью, а 2-4К сделать тупо апскейлом.

Мне больше волнует, почему у меня контроллер камеры при повышении фпс до 700+ начинает замедляться. :C
Аноним 31/03/20 Втр 03:39:38 #285 №652225 
>>643188 (OP)
Как видос записать и скинуть? Да, вопрос тупой, в инете 100000 ответов, но я не хочу среди них искать нормальный, куда проще если кто-то поделится проверенным
Аноним 31/03/20 Втр 03:43:29 #286 №652226 
>>650834
Добавь больше источников света, типо поставь их 3 рядом, тень не может быть "короче" или "длиннее", тень там где нет света, а заслоненный свет не может взять и появится через 2 метра
Аноним 31/03/20 Втр 04:00:09 #287 №652228 
>>652226
Вот зачем писать чушь через неделю, не разбираясь в вопросе, когда уже даже показано как сделать.
Аноним 31/03/20 Втр 04:02:08 #288 №652229 
>>652226
> заслоненный свет не может взять и появится через 2 метра
Почему бля?
Аноним 31/03/20 Втр 04:21:27 #289 №652231 
>>650826
Возьми фонарик, коробку, и поэксперементируй как надо светить чтобы свет был какой нужно
Аноним 31/03/20 Втр 04:24:31 #290 №652232 
>>652229
Потому что свет это частица если она пропала то она не появится, всё ее нет, она умерла нахуй, откуда ей заного взятся то
Аноним 31/03/20 Втр 04:25:29 #291 №652233 
>>652228
Только, я вот че-то не нашел ответа на вопрос
Аноним 31/03/20 Втр 04:39:04 #292 №652234 
>>652233
Палю ультимативную годноту: делаешь в орто3д, и настраиваешь высоту коробок и ламп как надо
Аноним 31/03/20 Втр 04:41:33 #293 №652235 
изображение.png
>>652232
>откуда ей заного взятся то
я такое говно ещё в гамаке делал или в камстракте
Аноним 31/03/20 Втр 11:30:15 #294 №652254 
изображение.png
>>652226
>тень не может быть "короче" или "длиннее",
Может, зависит от высоты источника света над отбрасывающим тень объектом.
Предлагаю вернуться в 5-й класс и повторить чё вы ты там изучали про свет и тень)))
Ну или хотя бы выходи на улицу почаще, а то ты походу тени только в детстве в играх видел.
Аноним 31/03/20 Втр 11:37:11 #295 №652255 
>>652225
Я записываю GeForce Experience-м, одной кнопкой. Если нету, можно OBS-ом. Потом нарезаю в консольке ffmpeg-ом. Иногда Webm-converter for retards.
Аноним 31/03/20 Втр 13:40:01 #296 №652272 

короче, есть один спрайт палки
палкой можно будет махать в игре
можно ли как-то сделать анимацию махания палкой чем-то типа создания ключевых кадров? нужно чтоб просто менялся её угол наклона
не делать же мне анимацию для палки, ну
Аноним 31/03/20 Втр 13:43:38 #297 №652273 
>>652272
>не делать же мне анимацию для палки, ну
в смысле, не рисовать же её вручную
Аноним 31/03/20 Втр 13:51:21 #298 №652274 
>>652272
Ну да, в годоте все свойства анимируются примерно как в блендере
1. В AnimationPlayer в анимации добавляешь новый трек, Property Track
2. В всплывшем окне выбираешь объект, а в нем свойство rotation_degrees
3. Ставишь время на 0, кликаешь правой кнопкой по таймлайну и insert keyframe
4. Ставишь время в середину, крутишь объект как тебе надо, вставляешь новый keyframe
5. Ставишь время в конец, крутишь объект в начальное положение, еще один keyframe
Аноним 31/03/20 Втр 14:00:30 #299 №652275 
Как понять, почему сцена закрывается во время загрузки, но при этом никаких ошибок не вываливается?
Аноним 31/03/20 Втр 14:05:28 #300 №652276 
>>652275
А консолька что? Которая отдельно висит.
Аноним 31/03/20 Втр 16:09:08 #301 №652303 
>>652276
Тоже молчит. Выглядит, будто сцена штатно закрывается, но на самом деле это краш.
Происходит это со сценой, в которой я сделал такую штуку (вид сверху):
__с__
__д__
сдддс
__д__
__с__
Где д - блок дороги, с - точка спавна, _ - пустота.
На точке спавна должна спавниться точно такая же сцена с некоторым шансом, которая тоже что-то спавнит.
Методом тыка выяснил, что падение происходит только в определённых условиях, но определить точно эти условия не смог, потому что у меня даже print() из кода не успевает ничего вывести, когда эти условия срабатывают. Было предположение, что это происходит тогда, когда два блока накладываются друг на друга - но смещение точек спавна выше или ниже ничего не дало. Ещё было предположение, что происходит переполнение стека возвратов, но, судя по всему, в одном направлении генерироваться такая штука может достаточно долго. Пытался приделать проверку коллизий перед спавном, но они не работают в _ready, поэтому решил не мучиться. Короче, так и не понял, почему это происходит и почему без сообщений об ошибках. Версия Годо 3.2.1 stable.

Но это уже не важно, я решил отказаться от такой генерации. Нужно генерировать сначала меш ландшафта, а потом на нём расставлять домики, так должно быть правильнее...
Аноним 31/03/20 Втр 17:27:55 #302 №652311 
>>652303
> Тоже молчит. Выглядит, будто сцена штатно закрывается, но на самом деле это краш.
Переполнение стека вызовов функций. Ищи, где у тебя бесконечная рекурсия. У меня такое бывает частенько, если с рекурсией проебусь. Ошибка возникает на долю секунды, после чего сеанс отладки прерывается.
Аноним 31/03/20 Втр 18:40:37 #303 №652319 
>>652311
Значит, рекурсивно генерировать сцену всё-таки не получится(
Ну и ладно, всё равно собирался что-то другое придумать...
Аноним 31/03/20 Втр 21:08:12 #304 №652334 
>>652319
Чо сразу сдаёшься? Вполне получится. Главное правильно рекурсию организовать.
Аноним 01/04/20 Срд 16:22:46 #305 №652561 
Наканец-та!
https://www.youtube.com/watch?v=oXQOaO8qoLo
Аноним 02/04/20 Чтв 21:59:14 #306 №652797 
1585853953799.png
1585853953887.png
Пытаюсь отрисовать 2д скелет (с целью создания процедурно-векторной графики без текстур). Он получается в масштабе 2х. ЧЯДНТ?
Аноним 02/04/20 Чтв 22:10:11 #307 №652800 
>>652797
Глянь в настройках проекта, Display, Window, и там где то в конце Stretch, Shrink чтобы стояло 1
Аноним 02/04/20 Чтв 22:37:59 #308 №652812 
1585856279031.png
>>652800
Всё по дефолту же!
Аноним 02/04/20 Чтв 23:01:25 #309 №652815 
1585857684663.png
>>652800
Главное, чего я не могу понять, в редакторе у кости одна позиция - её начало. В рантайме, как видно из скрипта, позиция кости - это середина. Мне приходится отрисовывать две линии, от кости к предку, от кости к потомкам. Иначе получается вот такое:
Аноним 02/04/20 Чтв 23:05:01 #310 №652816 
1585857901439.png
>>652815
Вот в режиме тулскрипта. Никакого масштабирования нигде не ставил, все значения по дефолту.
Аноним 03/04/20 Птн 04:10:32 #311 №652849 
Кто-нибудь знает, как правильно настраивать физику?
Проблемы:
- кинетикбоди пинает ригидбоди
- если отключить бесконечную инерцию, всё равно пинает, но только уже сдвинутые
- круглые ригидбоди катятся и не останавливаются
- сила трения непонятно на что влияет
- непонятно как влияет на физику масса объекта
До того момента, как я узнал про флаг бесконечной инерции, думал, что физика здесь упорота принципиально.
Помогла вот эта статья, но только частично: https://kidscancode.org/godot_recipes/physics/kinematic_to_rigidbody/
То есть на неподвижные ригидбоди это работает, а если что-то сдвинуто/катится - опять "пинает".
Круглые ригидбоди вообще неуправляемые, что с массой, что с трением. Катятся и катятся.
Что делать(
Аноним 03/04/20 Птн 17:49:28 #312 №652950 
>>652849
>круглые ригидбоди катятся и не останавливаются
За это отвечает Angular Damp в размере 0.8-1
> сила трения непонятно на что влияет
Проверил на 3д кубах - все работает, 0 трения скользит как по льду, 1 сразу останавливается или опрокидывается, 0.5 ведет себя как игральный кубик
>непонятно как влияет на физику масса объекта
Как и должна, передача импульса, все дела, тяжелый объект при столкновении сдвинет легкий, легкий объект отскочит от тяжелого.
Аноним 03/04/20 Птн 23:31:43 #313 №653002 
>>652950
>За это отвечает 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, встроенная физика Годо на моей сцене крашится почему-то (без сообщений об ошибках, просто закрывается).
Аноним 04/04/20 Суб 05:04:33 #314 №653022 
Почему годот просаживается на 4х тысячах спрайтов одновременно двигающихся? Даже казаки держали 8 тысяч активных юнитов, а там были ещё 200гц одноядерные процессоры. Это можно как-то поправить?
Аноним 04/04/20 Суб 09:04:07 #315 №653030 
>>653022
>Почему годот просаживается на 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.
Аноним 04/04/20 Суб 09:19:29 #316 №653032 
>>653022
Define "держали"? А то окажется, что там было разрешение 800х600, спрайты размером 16х32 и 12 фпс.
Про MultiMeshInstance2D тебе уже написали. Современные спрайты это не то же самое что спрайты в 2000.
Аноним 04/04/20 Суб 09:30:59 #317 №653033 
>>653032
>А то окажется, что там было разрешение 800х600, спрайты размером 16х32 и 12 фпс.
ИМХО проблема не в разрешении и размерах. Если статично расставить по 3D-сцене >15000 нод, то Годо может выдавать почти стабильные 75 фпс на 1440x900. Но если хотя бы часть этих нод подвижна, то всё сильно ухудшается. Значит, проблема именно в адресации данных, а не в их размерах. Грубо говоря процессору приходится бегать по памяти, чтобы 60 раз за секунду немножко сдвинуть каждую из тысяч сущностей - и именно здесь происходит просадка. DoD призван исправить эту проблему, но DoD через GDScript реализовать не получится, если я правильно понимаю, поэтому рекомендуется подключать внешние низкоуровневые/компилируемые ЯП.
Аноним 04/04/20 Суб 17:17:19 #318 №653101 
>>653030
В Годо нет ООП.
Юнити, не смотря на свои огромные монобехейворы держит 9к спрайтов без лагов.
nodes/objects - Нахуя? Я просто взял и вкинул спрайты на сцену. У меня создано 4к спрайтов, а дальше резко идет падение по производительности. Резко - это когда почти 90 градусов после превышения значения. Почему это лагает? Это просто точка с положением от которого надо рендерить изображение и если оно закрывает другое, альфомаской стирать то, которое под ним.
MultiMeshInstance2D спасибо. Посмотрю. Надеюсь мне не придется вытворять магию, чтобы просто создать несколько сотен спрайтов.
Аноним 04/04/20 Суб 18:35:25 #319 №653120 
>>653101
>В Годо нет ООП.
Чиво? Скрипты на 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 без каких-либо движков.
Аноним 04/04/20 Суб 19:04:19 #320 №653123 
>>653101
> В Годо нет ООП.
Инкапсуляция - это НЕ сокрытие.
Аноним 04/04/20 Суб 19:59:05 #321 №653133 
>>653101 >>653123
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.
Аноним 04/04/20 Суб 20:06:15 #322 №653137 
>>653133
> Только давайте не устраивать срач на тему труЪ-ООП.
Точку в этом вопросе недавно поставил extremecode на youtube. Кроме того, твоя же паста говорит, что авторы питона как раз таки понимают суть, в отличие от "так же означающих".
Инкапсуляция - это не сокрытие. В гдскрипте нет скрытия, нет приватных членов. Однако там есть инкапсуляция, наследование, полиморфизм. Таким образом, я подтверждаю, что гдскрипт стронгООП.
Аноним 04/04/20 Суб 20:14:23 #323 №653138 
1504101026933.png
>>653101
>Надеюсь мне не придется вытворять магию
MultiMeshInstance это не то чтобы магия. Это примерно то же, что используется под капотом для частиц (particles)
Также можно смортреть в сторону вот этого пулл реквеста, в котором ведутся работы и там уже х2.5 прирост в спрайт батчинге: https://github.com/godotengine/godot/pull/37349
>чтобы просто создать несколько сотен спрайтов.
Несколько сотен спрайтов ты сможешь создать и сейчас, тест в шапке - 60 фпс на некропеке при ~1000 спрайтах.
sageАноним 04/04/20 Суб 23:43:47 #324 №653179 
>>653022
Потому что каждый спрайт рисуется одним вызовом к opengl. Сколько спрайтов - столько и draw call'ов.
Аноним 06/04/20 Пнд 01:28:25 #325 №653344 
>>653120
Я пробовал и через одну ноду двигать 4 тысячи и через 4 тысячи НОД. Разницы нет. Чувак, годо лагает тупо сам по себе. Не держит он выше своего пула объекты. Вопрос только как пул расширить.
Аноним 06/04/20 Пнд 01:30:44 #326 №653345 
>>653138
4300 спрайтов. Меня интересует что угодно, что достигнет хотя бы 9к. А ещё лучше 15к. Чтобы мои говноскрипты снизили это значение до 9к
Аноним 06/04/20 Пнд 01:31:54 #327 №653346 
>>653179
Вот ты шаришь. Как мне сделать так, чтобы вызов был один? Либа МБ где есть?
Аноним 06/04/20 Пнд 01:35:55 #328 №653347 
>>653346
Ты читать не умеешь? Тебе написали и про мультимеш, и про частицы, и про пулл реквест с улучшением
>>653345
В играх не нужно 9к спрайтов. Они на экран не поместятся. Ты делаешь что то не так.
Аноним 06/04/20 Пнд 07:35:35 #329 №653372 
>>653347
Я сам решу, нужны мне 9к спрайтов или нет. Спасибо.
Аноним 06/04/20 Пнд 08:20:11 #330 №653374 
>>653372
Ебать дебил.
Аноним 06/04/20 Пнд 10:13:36 #331 №653385 
floppy-disk-data-storage-hard-disk-drive-backup-disk-storag[...].jpg
Почему apk с пустой сценой весит ДВАДЦАТЬ СРАНЫХ МЕГАБАЙТ?
Аноним 06/04/20 Пнд 11:02:07 #332 №653389 
>>653385
Не занимайся троллингом в треде. Спасибо.
>>651761
Аноним 06/04/20 Пнд 11:04:57 #333 №653390 
>>653372
Ну раз ты сам делаешь какую то уникальную хуйню, то и рендер напишешь сам.
Аноним 06/04/20 Пнд 15:20:29 #334 №653421 
>>653345
>4300 спрайтов. Меня интересует что угодно, что достигнет хотя бы 9к. А ещё лучше 15к.
Способы выжать сколько угодно спрайтов есть. Только управлять ими ты не сможешь.

>>653372
>Я сам решу, нужны мне 9к спрайтов или нет. Спасибо.
Сразу об этом и не подумал. Серьёзно, зачем тебе 9к спрайтов на одном экране?
1920 x 1080 / 9000 = 230 пикселей на один спрайт = 10x23 один спрайт.
Это если располагать их сеточкой, то есть без пробелов.
Один вопрос: зачем?

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

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

>>653385
>Почему apk с пустой сценой весит ДВАДЦАТЬ СРАНЫХ МЕГАБАЙТ?
Никогда не слышал выражение "библиотека с кодом"? В ней содержится всё то, благодаря чему ты можешь делать игры без головной боли, просто тыкая мышой по кнопочкам и не задумываясь о низкоуровневых проблемах конкретной ОС и/или низкоуровневых игровых алгоритмах. Хочешь пустой APK - пили на Java с нуля, только тебе придётся самому возиться с тем, с чем возятся эти 20 МБ вместо тебя.
Аноним 06/04/20 Пнд 20:08:06 #335 №653499 
Хочу попытаться вкатиться в ГДВижуал.
Стоит ли вообще? Какие подводные?
Аноним 06/04/20 Пнд 21:28:14 #336 №653513 
>>653499
>Какие подводные?
Имхо, визуально блоки добавлять и редактировать в несколько раз дольше и сложнее, чем код писать.
Если уже умеешь писать код и не имеешь с этим проблем, то лучше даже не пытаться в визуальный код.

потыкался, ниасилил, вернулся к использованию gdscript
Даже не знаю, какой дисигнер осилит визуальный скриптинг
Аноним 06/04/20 Пнд 22:41:17 #337 №653523 
>>653513
В код мы с товарищем не слишком-то хорошо умеем, разве что со словарём, а свою ЖРПГ сделать хочется. Потому, собсно, и спросил.
Аноним 06/04/20 Пнд 23:22:21 #338 №653532 
>>653523
Ну смотри, принципиальная разница между кодом и "визуальным программированием" в том, что в одном случае ты пишешь текст, который будет читать компьютер (транслятор), а во втором ты двигаешь мышу и жмёшь на виртуальные кнопки, натягиваешь виртуальные ниточки и переключаешь виртуальные переключатели, а ещё вводишь в разные поля ввода всё тот же текст, чтобы... чтобы, ВНЕЗАПНО, создать всё тот же код, который будет читать компьютер, просто у этого кода будет графическое представление (но на диск он всё равно сохраняется в виде какого-то текста).

Чтобы программировать, нужно три вещи:
- уметь составлять алгоритмы для решения задач;
- знать базовый синтаксис выбранного ЯП;
- знать содержимое используемых библиотек.
Что из этого может убрать визуальное программирование?
- алгоритмы тебе в любом случае придётся составлять;
- вместо синтаксиса тебе нужно знать GUI редактора;
- библиотеки используются те же самые, что и с кодом.
То есть визуальный кодинг всего лишь подменяет текст на ГУЙ, в который тебе нужно мышой тыкать.

Разумеется, речь о том визуальном кодинге, который есть сейчас (вообще в мире, не только в Годо), это не значит, что никогда не появится гениальное изобретение, которое отменит необходимость писать код, но пока оно не появилось, использовать визуальные инструменты банально неудобно, КПД резко снижается. Проще немного подучить ЯП, тем более GDScript достаточно прост.

>разве что со словарём
Практически ни один программист не помнит наизусть содержимое библиотек. В крупных ЯП даже необязательно знать все фичи языка, чтобы успешно писать программы. Мануал - твой друг, используй его. А в том же визуальном программировании тебе всё равно потребуется помнить все эти многочисленные блоки, их назначение и способы применения...

>ЖРПГ
Если речь о классических 2D jRPG, не проще ли будет использовать RPG Maker? Там вообще кодинга не нужно вроде.
Аноним 07/04/20 Втр 01:38:00 #339 №653569 
>>653532
>Если речь о классических 2D jRPG, не проще ли будет использовать RPG Maker? Там вообще кодинга не нужно вроде.
В том-то и дело, что есть задумки, которые на мейкере сделать тяжко, невозможно или ХЗВЩ как.
А по поводу подучить язык... ну, замечание верное. Попытаемся, короче.
Аноним 07/04/20 Втр 01:48:08 #340 №653575 
>>653569
Я почти сразу в GDScript разобрался, встроенная справка очень помогает. Но у меня богатый опыт Pascal, конечно...
Аноним 07/04/20 Втр 04:50:44 #341 №653589 
изображение.png
Переписал с нуля контроллер персонажа. Проблемы как были, так и остались:
- расторможенные RigidBody пинаются;
- автомобили пинаются вообще всегда;
- на наклонных плоскостях соскальзывает;
- на маленьких бордюрах подпрыгивает.
Последняя проблема недавно появилась, раньше как-то удавалось избегать.
Замена move_and_slide() на move_and_slide_with_snap() не помогает.
Я уже замучился, я хотел просто игру делать, а не вот это вот всё.
Смотрел чужие контроллеры, там всё аналогично...
Аноним 07/04/20 Втр 05:01:54 #342 №653590 
изображение.png
>>653589
>- расторможенные RigidBody пинаются;
>- автомобили пинаются вообще всегда;
Оооокееей, эти две проблемы я внезапно решил, случайно обнаружив параметр safe_margin, который по сути заставляет Kinetic_Body останавливаться раньше, чем Rigid_Body детектит столкновение с ним, если я правильно понимаю.
Остаётся только понять, как исправить это -
>- на наклонных плоскостях соскальзывает;
>- на маленьких бордюрах подпрыгивает.
Но это по крайней мере можно закостылить RayCast'ами, хоть я и хотел бы более простое решение...
Аноним 07/04/20 Втр 08:32:44 #343 №653597 
>>653590
Погугли "godot платформер", я точно помню, как видел где-то решение соскальзывающего персонажа.
Аноним 07/04/20 Втр 16:58:15 #344 №653660 
>>653597
В предыдущей версии контроллера у меня оно уже решалось как-то. Скорее всего потому, что я занулял скорость по Y, если был контакт с землёй, а тут я сделал так, как сделано в других контроллерах - вместо зануления вручную, сохраняю ответ move_and_slide(), она сама зануляет Y если персонаж ударился о поверхность. Так вот если занулять Y, то персонаж будет стоять на наклонной поверхности как на ровной, а если не занулять, то move_and_slide() будет делать микроскопические скачки, которые выглядят как скольжение. Один из аргументов должен предотвращать скольжение, но он почему-то не работает.

Я уже смотрел несколько вариантов контроллера в сети (вроде 3), они все такие разные (и при этом не учитывают такие сложные ситуации)...

Но больше всего мне непонятно сейчас, почему персонаж начал ПОДСКАКИВАТЬ на бордюрах. Раньше он либо забирался плавно, либо вообще не мог забраться, а сейчас он взлетает в воздух и приземляется на бордюр, если хватает инерции. Вроде бы это появилось после того, как я снизил сопротивление воздуха, то есть уменьшил торможение, когда нет контакта с землёй - но проблема в том, что если я увеличу это сопротивление, будет невозможно делать длинные прыжки, только прыжки на месте. Костылировать каждый такой случай рейкастами совсем не хочется... Хотя, наверное, правильнее всего будет делать "шаг вверх" при обнаружении относительно низкого препятствия, ведь в реале люди шагают, а не скользят, лол.
Аноним 07/04/20 Втр 19:40:34 #345 №653700 
изображение.png
Не помню где, но где-то прочитал, что чтобы код и сцены были модульными, в коде нельзя обращаться к нодам-родителям, только к нодам-потомкам. Хочу следовать этому правилу, но на практике вижу, что это не всегда удобно. Для примера, я сделал сцену OrbitCamera и скрипт OrbitCamera, теперь мне достаточно накинуть эту сцену на любую ноду, чтобы у меня получилась адекватно управляемая мышью орбитальная камера с несколькими полезными настройками. Однако, мне от этой камеры нужно, чтобы она дублировала своё вращение по Y на объект, к которому прицеплена - в частности, на персонажа игрока. Да, я действительно могу корректировать вращение персонажа по положению камеры, но это будет выглядеть некрасиво и может вызвать трудности, тем более что такой код придётся писать для любого объекта, которому нужно вращаться камерой по Y. Поэтому сейчас моя камера вращает персонажа, а не наоборот, но это нарушает описанный выше принцип. Менять это или нет? Так-то конкретно эта камера никогда не будет самостоятельной, у неё всегда должен быть parent, вокруг которого она вращается...
Аноним 08/04/20 Срд 12:25:10 #346 №653903 
>>653660
>Но больше всего мне непонятно сейчас, почему персонаж начал ПОДСКАКИВАТЬ на бордюрах
Ну он же у тебя технически скользит, а не ходит. Вот его, как на рампе, и подкидывает.И да, просто "шаг вверх" будет хорошим решением, ящитаю.
Аноним 09/04/20 Чтв 00:12:20 #347 №654231 
>>653421
В казаках было 7 тысяч юнитов на 1 экране. Хочу 9 тысяч юнитов на 1 экране. По факту выйдет меньше, но да хер с ним, процессор сожрет что-то другое.
Аноним 09/04/20 Чтв 00:16:25 #348 №654232 
>>653700
Сигналы. Сигналы решают эту проблему.
Либо ты должен описать вращение в персонаже, и передавать его на камеру.
А ещё можно сделать роутинг через синглтон. Но это легкая дичь, которую я использую только для быстрого поиска менеджеров в проекте.
Аноним 09/04/20 Чтв 00:17:39 #349 №654233 
>>654231
>В казаках было 7 тысяч юнитов на 1 экране.
Покажи. Такое чувство что это бред рекламщиков из игровых журналов
Аноним 09/04/20 Чтв 00:46:15 #350 №654240 
>>654233
Что тебе показывать? Возьми да установи. Поставь 7 тысяч юнитов и они без лагов дойдут куда угодно.
Аноним 09/04/20 Чтв 05:45:28 #351 №654267 
изображение.png
>>654232
>Сигналы. Сигналы решают эту проблему.
Я не разобрался, по-моему биндинг сигналов какой-то мудрёный. Да и посылать сигнал практически каждый кадр?
>Либо ты должен описать вращение в персонаже, и передавать его на камеру.
Изначально так и было, но я решил абстрагировать камеру, чтобы облегчить персонажа.

В общем, всё оказалось намного проще и компактнее, см. скрин. :D
Персонаж сам себя вращает по камере, когда хочет, а камера теперь не сможет никого вращать.

>>653903
>И да, просто "шаг вверх" будет хорошим решением, ящитаю.
Пытаюсь так сделать, но чёт не выходит. Задолбался в очередной раз...
Аноним 09/04/20 Чтв 05:56:03 #352 №654268 
maxresdefault.jpg
>>654233
Там можно устроить месиво из пикселей, как я понимаю.
>>654240
>Поставь 7 тысяч юнитов и они без лагов дойдут куда угодно
Ты это цветное месиво называешь "7 тысяч юнитов"?

Теоретически, можно соединять все эти спрайты на процессоре, видеокарте тут нечего делать вообще.
Но, конечно, это будет проще реализовать на каком-нибудь Ассемблере, чем прикручивать к Годо или другому движку.
Аноним 09/04/20 Чтв 06:22:32 #353 №654270 
c.png
>>654231
Движки общего назначения не подходят для создания игр не общего назначения, без жесткого допиливания напильником их недр.
Тут просто тонко настраивают отрисовку объектов, а не делают в лоб. Например, вот, на картинке 216к кубов одновременно в кадре выдают на некроноуте 30 фпс.
Так что тебе или лезть в ядро любого такого движка или накидать свое решение или прикрепить свое решение к движку в виде модуля.
Аноним 09/04/20 Чтв 06:43:54 #354 №654278 
>>654270
>Так что тебе или лезть в ядро любого такого движка или накидать свое решение или прикрепить свое решение к движку в виде модуля.
К сожалению, этот товарищ не владеет столь мощной магией:
>>653101
>Надеюсь мне не придется вытворять магию, чтобы просто создать несколько сотен спрайтов.
Аноним 09/04/20 Чтв 13:36:36 #355 №654410 
>>653700
> Не помню где, но где-то прочитал, что чтобы код и сцены были модульными, в коде нельзя обращаться к нодам-родителям, только к нодам-потомкам.
Глупости. Допустим, тебе нужен универсальный компонент, работающий только с кинематиками, а если ты про запарке его закинул в ноду иного класса, он должен это детектить и деактивироваться. Возможно даже с ассертом. И ты просто создаёшь переменную 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
А управляет переключением компонентов разумеется стейтмашина, конечный автомат.
Аноним 09/04/20 Чтв 14:00:55 #356 №654426 
>>654270
>Движки общего назначения
Нет такого термина в проектировании ПО, это похоже на выдумку маркетологов. Если наше ПО что-то не умеет - это потому что оно "общего назначения".
Аноним 09/04/20 Чтв 14:08:55 #357 №654436 
>>654426
Из какой школы капчуешь?
Чем более общий алгоритм мы пишем, чем больше он предусматривает вариантов, настроек, проверок, тем больше он потребляет ресурсов. Это называется общим или обобщенным алгоритмом решения какой-либо задачи.
Аноним 09/04/20 Чтв 15:52:10 #358 №654498 
>>654426
>Если наше ПО что-то не умеет - это потому что оно "общего назначения".
Всё абсолютно наоборот. "Общего назначения" означает, что ПО буквально умеет "всего понемножку", из всех или большинства возможных областей применения. С одной стороны это хорошо, т.к. пользователь может изучить это ПО и не искать под каждую задачу специальное ПО, но с другой стороны "ПО общего назначения" не имеет специальных оптимизаций для конкретных ситуаций. "Специализированное ПО", напротив, умеет только что-то одно, но умеет это превосходно.

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

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

>>654410
>Он не даст тебе нормально работать в случае неправильного размещения в дереве.
Пример - 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 смысла нет, я полагаю...
Аноним 09/04/20 Чтв 16:37:35 #359 №654514 
>>654498
Всегда есть смысл надстраивать полноценную ецс. Вопрос личного удобства.
Аноним 09/04/20 Чтв 17:59:12 #360 №654586 
Как у годота с многопотоком? Есть ли он из-коробки или нужно пилить самому?
Есть один сетевой 3д проект для своих нужд, успел уже сделать редактор уровней (алсо записываю все уровни в свой васянский формат), но теперь думаю как оптимизировать все это.
Аноним 09/04/20 Чтв 21:43:35 #361 №654736 
>>654586
Многопоток есть. Ограничения типичные для многопотока. Луркай мор.
Аноним 10/04/20 Птн 00:06:58 #362 №654759 
не видит препятствие.png
какой-то баг.png
Короч решил попробовать ноду Navigation, туториалов в официальных доках конечно же не нашёл, решил сделать по интуиции, но что-то я не понимаю, как заставить эту ноду видеть статикбоди и вообще хоть что-то кроме её навмеша.

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

А вот на второй картинке натуральный баг. Если бот запрашивает путь из точки (0, 0, 0), то Navigation почему-то посылает сначала на угол своего навмеша, а только потом - на конечную точку. Я пробовал смещать бота на (0.1, 0, 0) и (0, 0, -1) - любое смещение от нулевой точки исправляет проблему, т.е. маршрут строится по прямой, но нельзя же предугадать, что бот никогда не наступит на точку (0, 0, 0) во время игры? В реальной игре это может вызвать очень неприятные последствия (у меня тут бот срывался в пропасть, пока я не расширил тестовый полигон, чтобы убедиться, что он потом вернётся)...

Собсна баг смутил даже больше, чем то, что навмеш почему-то не видит статикбоди. Кстати, для чего кнопка "запечь навмеш"? Я её нажал - навмеш просто пропал (лол), пришлось создавать его заново из той коробки.

Вообще, пробую эти навмеши чисто из любопытства, т.к. скорее всего навигацию придётся самому велосипедить. Просто думалось, что навмеш реально может помочь обходить препятствия, но тут чёт проблем ещё больше(
Планирую сделать как-то так:
- есть карта, она по большому счёту никак не меняется (кроме машинок и прочих ригидбоди);
- по карте расставлены т.н. "зоны интереса" и "вейпойнты" - точки, по которым боты ходят;
- когда боту нужно в какую-то зону интереса, скрипт строит маршрут по набору вейпойнтов;
- если бот на пути к вейпойнту видит препятствие, он пытается сам обойти его по кругу;
- боты, находящиеся далеко от игрока, телепортируются от вейпойнта к вейпойнту.
Ну, не телепортируются, а скорее симулируются отдельным фоновым кодом, который планирую прицепить к Godot через GDNative, а уже игровые скрипты запрашивают актуальную позицию ботов у этого кода, когда приходит пора отобразить ближайших к игроку ботов. Следовательно, навмеш мог бы пригодиться только в момент обхода ботом препятствия между двумя вейпойнтами, и то - только когда этот конкретный бот находится поблизости от игрока. Поэтому сильно сомневаюсь, а нужно ли мне вообще возиться с системой навигации Годо, или так обойдусь? Разве что с обходом сложных препятствий проблемы могут возникнуть, но с этими сложными препятствиями ещё нужно столкнуться...
Аноним 10/04/20 Птн 00:18:12 #363 №654767 
>>654759
Самая писечка - это когда навмеш строится из блоков. Возьми гридмап для тридэ, засунь в него всего два блока: нав и ненав. В наве есть навмеш, в ненаве соответственно нетути.
Далее заполни все пространство карты блоками нав в гридмапе, а места под статики заполни блоками не_нав. И вот тебе навигация.
Главное чтобы границы навмеша в блоках гарантированно соприкасались, тогда нода навигации корректно соберёт общий навмеш из твоих блоков.
Аноним 10/04/20 Птн 00:52:02 #364 №654769 
>>654767
>Возьми гридмап для тридэ, засунь в него всего два блока: нав и ненав
Это какого ж размера должны быть ячейки гридмапа, если я не собираюсь делать кубические карты? То есть где-то препятствие будет условным "полублоком", где-то вообще один маленький столбик или деревце, где-то круглая клумба, а где-то стенка под углом к дороге. То есть с крупными ячейками будет много недочётов, а из мелких делать не вариант, их будет слишком много.

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

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

Пробую заюзать навмеш на случай, если он всё-таки пригодится, т.к. я мало что про него знаю. Так-то покрыть всё вейпойнтами не проблема (плюс должно быть удобно передавать их в dll-библиотеку); для обхода мелких препятствий собираюсь соорудить "зрение" ботам, будут пытаться обходить то, что попадает в конус Area, прицепленный к голове.
Аноним 10/04/20 Птн 09:27:20 #365 №654832 
>>654769
Хоспаде, это навигация, а не коллизии. Сделай куб стороной полметра и всё.
Аноним 10/04/20 Птн 09:30:01 #366 №654833 
>>654769
Гридмап имеет все необходимые методы для динамического изменения в рантайме. Дырки в навмеше смогут себе вырезать и статики и боты.
Аноним 10/04/20 Птн 12:00:49 #367 №654870 
изображение.png
>>654832
>это навигация, а не коллизии
Навигация подразумевает ориентирование в пространстве, а зачем мне ориентироваться в пространстве, если там нет препятствий? Я думал, оно как-то само будет вычитать препятствия из путей...

В параметрах навмеша есть "Parsed Geometry Type", есть вариант "Static Colliders" - это разве не то?
Я пробовал переключать этот параметр, перемещать статик боди по дереву сцены - ноль реакции(

>>654833
>Гридмап имеет все необходимые методы для динамического изменения в рантайме.
Сколько это стоит по ресурсам? Как часто можно делать, чтобы всё не повесилось от 5+ объектов?
Аноним 10/04/20 Птн 18:35:59 #368 №655091 
>>654268
> Годо оптимизирован для удобного дизайна и управления сценами, ты можешь практически одной мышкой, не притрагиваясь к клавиатуре
Нет, годо просто неоптимизирован, и посылает 7к запросов в opengl место одного.
Аноним 10/04/20 Птн 20:46:19 #369 №655185 
>>654870
У меня температура 37, 5 и начала расти! Походу коронавирус подхватил. Не могу доползти до компа, чтобы накидать тебе проект-пример. Так что давай сам. Суть ты уловил как мне кажется. Тесты сам сделаешь.
Скажу вкратце.
Накидываешь поверх локации гридмап, заполняешь весь объем навами. Не_навы, которые я описал выше, не нужны, объекты будут просто задавать -1 для нужных ячеек, которые нужно вырезать из результирующего навмеша.
Далее. Уровнем выше должна быть нода Navigation, на всякий напоминаю.
У гридмапа есть функции, преобразующие глобальные координаты в координаты своей сетки и обратно. Это именно то, что нам нужно. Игровые объекты при своих перемещениях посылают периодически в гридмап такой запрос: по предыдущим своим координатам установить в совпадающих ячейках значение дефолт (которое ты задал при дизайне сцены) по текущим координатам задать значение -1.
Все. Имеем динамический навмеш, учитывающий как статики, так и динамики.
Аноним 10/04/20 Птн 22:12:57 #370 №655232 
>>655185
Это-то понятно, как сделать. Я несколько дней назад уже тыкал гридмап, понимаю, о чём речь.
Проблемы использования навмеша в следующем:
- карта модульная, то есть собирается из кусочков в реалтайме;
- количество и состав модулей заранее неизвестен (я не определился пока);
- размеры карты могут быть большими (ну, допустим, карта города в GTA 3);
- часть модулей могут скрываться из дерева сцены (чанки-кварталы и комнаты в домах).
Даже если взять один гридмап с навмешами на весь город, и вырезать дырки модулями, то это всё равно будет сложно и неэффективно, как мне кажется. Кроме того, навмеш строит путь напрямик, через всё свободное пространство, а мне по идее нужно чтобы боты топали по дорожкам, возвращаясь к ним, если на что-то отвлеклись. Да и в случае "навмеша на всю карту" я не смогу перенести ИИ ботов во внешнюю библиотеку, буду привязан к навмешу Годо.

Я решил расставлять "вейпойнты", каждый из которых в _ready() добавляет себя в глобальное хранилище вейпойнтов (можно сделать иначе, не суть, нужен только один Vector3), а дальше бот запрашивает маршрут до интересующего его места у этого хранилища. Маршрут не предполагает динамические препятствия, он полагается на корректное расположение вейпойнтов внутри каждого модуля. Если у бота возникает на маршруте препятствие, он пытается его обойти (ориентируясь по коллизиям), если не удастся - строит новый маршрут по другим вейпойнтам. Смысл в том, что бот не знает заранее, встретит ли он препятствие на пути, тогда как навмеш заранее строит оптимальный маршрут; массив вейпойнтов - своего рода 3D карта города, где точками отмечены удобные для перемещения дороги, известные ботам, которые они "представляют в голове". Можно, например, скрывать часть вейпойнтов от отдельных ботов, чтобы они делали вид, что не знают дорогу до какого-то объекта.

Рассматривал возможность использовать навмеш на ближней дистанции, то есть на несколько метров возле бота, только чтобы обходить особо сложные препятствия... Кстати, а что будет, если нацепить Navigation на подвижную сущность? Мне даже не нужен полный путь, скорее направление на правильный путь (т.к. в любом случае полный путь может устареть)... Но я сомневаюсь, стоит ли оно того вообще. Мне хочется симуляцию поведения людей, а в жизни "навмешей" не бывает.

Да и, если честно, я уже сомневаюсь, хочу ли делать игру. Вряд ли получится нормальный ИИ даже в рамках игрового мира...
Аноним 10/04/20 Птн 23:03:47 #371 №655279 
>>655232
Не вижу проблемы обновлять количество кубов навмешгрида. Просто бери и делай. Решай проблемы по мере поступления. У тебя игры ещё нет, а ты уже думаешь о том, как столкнешься с проблемами. Синдром умной Эльзы, не иначе.
Насчёт ИИ гугли GOAP все современные игры основаны на нем. Реалистичность поведения ботов опирается только на то, несколько грамотно и разнообразно ты создашь goals и actions для системы этой.

Всё, пока, убегаю, меня реанимация ждёт!
Аноним 10/04/20 Птн 23:18:22 #372 №655288 
Пытаюсь вкатиться в этот ваш Годо(т) с двадэ. Вопрос довольно специфичный, не нашёл на него ответа в интернетиках.
Итак, имеем тайлсет - картинку, нарисованную от руки, отсканированную, выровненную по горизонтали-вертикали и скормленную ноде TileMap. Если просто нарезать её на квадратики и расставлять какой-то один квадратик, получится некрасиво. Расставлять тайлы последовательно - долго и нудно, сетка довольно большая. Есть ли способ сделать так, чтобы тайлы из тайлсета расставлять в определённом порядке? Я нашёл только чтобы на границе тайлового скопления всегда появлялись определённые тайлы и чтобы тайлы чередовались с некоторой вероятностью.
И да, я ещё не искал, но всё же спрошу, раз уж пошла такая пьянка. С отдельными тайлами же можно как-то работать скриптами? Например, чтобы при попадании пули тайл "brick" превращался в "Brick damaged", а при попадании второй пули - в "brick broken", у которого уже нет коллизии и другой z-index.
Аноним 10/04/20 Птн 23:39:43 #373 №655292 
>>655288
По первому пункту гугли автотайл. Если я правильно понял. Будет тебе рисоваться автоматически поле из центральных тайлов, обрамлённое краевыми тайлами.
По второму пункту гугли map_to_world, world_to_map о чем говорилось выше но для тайлмапов все аналогично гридмапам. При коллизии физических тел движок даёт тебе координаты этой коллизии. Далее находишь координаты тайла и выставляешь желаемый индекс (индекс тайла с разбитым кирпичом) по известным тебе на этом этапе координатам можешь спавнить эффект разрушения с летящими в стороны осколками.
Аноним 10/04/20 Птн 23:42:51 #374 №655293 
>>655288
По вопросу с z порядком гугли Y-sort.
Аноним 11/04/20 Суб 00:10:45 #375 №655300 
>>655292
>Если я правильно понял. Будет тебе рисоваться автоматически поле из центральных тайлов, обрамлённое краевыми тайлами.
Я не он, но вижу, ты неправильно понял. У него тайлы нарисованы от руки, и поэтому если один и тот же квадратик повторять по сетке, видно сетку, а это некрасиво. Забыл, как называется этот эффект... И вот он хочет вместо одиночных тайлов лепить сразу группами типа 2x1 или 2x2, я так думаю. Хотя по-хорошему нужно просто тайлы заново перерисовать...

>>655288
>Есть ли способ сделать так, чтобы тайлы из тайлсета расставлять в определённом порядке?
Не знаю, как в Годо, не пользовался, но в Tiled и других тайловых редакторах для этого вроде можно выделить сразу несколько ближайших тайлов, чтобы лепить сразу группами типа 2x1, 2x2, 2x3, 3x3, 3x1 и т.п. Но всё-таки рекомендую перерисовать тайлы, если ты видишь чёткую сетку - значит, плохо нарисовал тайлы.
Аноним 11/04/20 Суб 01:08:02 #376 №655320 
>>655293
Y-sort это не то. К тому же никакого вопроса про z-порядок я не задавал, там всё просто и понятно.

>>655300
Сенкс, няш, ты всё правильно понял. Вот только про перерисовку никакой речи быть не может: неровные линии создают неповторимый шарм, графика прям живая и дышащая становится. Попробую Tiled; если и там не получится, тогда ручками придётся каждый тайл ставить.
Аноним 11/04/20 Суб 16:40:10 #377 №655497 
>>654870
> Я думал, оно как-то само будет вычитать препятствия из путей…
И раз
https://www.youtube.com/watch?v=_urHlep2P84
И два
https://www.youtube.com/watch?v=A1xjUuRZmWQ
Аноним 11/04/20 Суб 17:56:39 #378 №655543 
изображение.png
>>655320
>неровные линии создают неповторимый шарм, графика прям живая и дышащая становится
Это понятно, но тебе всё равно ведь придётся замыкать тайлы. Не 1x1, так 2x2, не 2x2, так 3x3...

>Попробую Tiled; если и там не получится
Там-то точно получится, но для импорта понадобится инструмент: https://godotengine.org/asset-library/asset/158

>>655497
Спасибо, посмотрю.
Аноним 11/04/20 Суб 20:42:48 #379 №655625 
Перезагружаю сцену таким кодом:
if Input.is_action_just_released("reset_scene"):
var error = get_tree().reload_current_scene()

С помощью print()-ов выяснил, что во время перезагрузки ноды-синглтоны не сбрасывают состояние.
Т.е. если у меня в синглтоне хранится какой-то массив, перезагрузка сцены не сбрасывает его в ноль.
Мне что, отдельный метод для сброса писать? Нет способа определить момент сброса сцены?

Алсо, что если сделать синглтоном HUD игрока? Вроде логично, он ведь только один должен быть...
Аноним 11/04/20 Суб 22:53:55 #380 №655674 
>>655625
> во время перезагрузки ноды-синглтоны не сбрасывают состояние
Само собой. Ты бы 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) и если не найден, не подписываться на сигналы и не излучать их. Но я до такой степени не заморачиваюсь, т.к. работаю сам и принимать дураков в команду вроде как не планирую))
Аноним 11/04/20 Суб 23:40:52 #381 №655699 
>>655674
>синглтоны не что иное, как отдельные от сцены ветки общего дерева
Это я знаю. Но каждая ветка - это сцена, так? Почему тогда reload_current_scene() удаляет только
>зарегистрированный в дереве чайлд, который олицетворяет куррент-сцену
Вместо того, чтобы удалять вообще всех детей root-ноды?

Нет, я, конечно, понимаю, что так сделано для того, чтобы можно было через синглтон переносить данные между разными сценами, например, текущий прогресс игрока между уровнями, или глобальные настройки игры какие-то, но мне почему-то казалось, что "перезагрузка сцены" по идее должна сбрасывать вообще всё. Дело в том, что у меня на загрузке сцены некоторые ноды в _ready регистрируют себя в одном синглтоне, и поэтому если просто сбрасывать сцену, будет утечка памяти и обращение к nil; получается, мне необходимо перед/после обращения к reload_current_scene() дополнительно делать запрос к синглтону, чтобы он сбросил своё состояние... Мне нетрудно, но выглядит не совсем логично.

>что если сделать синглтоном HUD игрока?
Уже сделал так, действительно, намного удобнее получилось. Просто думал, что синглтоном не может быть что-то визуальное, да и тот же интерфейс придётся периодически скрывать/показывать, он ведь не всегда нужен...

>чтобы не возникало соблазна обращаться к ним напрямую
В чём проблема писать HUD.show_help(true)? Если вдруг дисплей отвалится, то и стартовать игра не должна.
Или вот у меня CityNavigator.find_closest(point), бот ведь не будет использоваться где-то помимо города...

>коннектятся к этим глобальным сигналам у себя в ready
Вот с этими сигналами так много проблем. Коннектить нужно, излучать... А когда они вообще доходят? Это ведь не прямой вызов процедуры, неизвестно, дойдёт ли вообще. Про систему сообщений я знаю после изучения ECS, но так руки и не дошли сделать своими руками, с трудом понимаю, как это может работать. Раньше делал что-то похожее, но там рассылалось от каждого всем, а уже получатель определял, нужно ли ему то, что он получил...

Кстати, если использовать сигналы вместо прямых вызовов процедур, нагрузка на кадр будет меньше? А то вот подумываю о том, чтобы запускать субгенераторы через сигналы - по моему опыту, если каждая сцена определяется со своим состоянием в своём ready(), то сцена начинает грузиться несколько секунд (пока все субсцены не определятся), а при чуть более сложной генерации переполняется стек (о_О), это нехорошо. Вообще не знаю, чё делать, если б на Паскале писал, я бы просто загнал генерацию в отдельный поток и/или делал её предварительно, а тут приходится как-то мудрить с отдельными скриптами, не настраивать же все сцены из одного скрипта...
Аноним 12/04/20 Вск 00:04:51 #382 №655709 
1586639090888.png
>>655699
> каждая ветка - это сцена, так?
Не совсем.
Есть сцена как файл, который ты сохраняешь в формате (t)scn. Это полноценная сцена со своим единственным корнем-родителем и кучей детей. Однако, эта сцена входит в существующую на этапе исполнения твоего конечного приложения сцены как один из детей. Здесь конечно есть повод поругать Хуана в срачетреде за путаницу в терминах. Следует различать сцены-ресурсы, которые десериализуются игрой и их инстансы включаются в общее дерево, и различать собственно само дерево сцены (SceneTree) олицетворяющее главный цикл приложения и являющееся создателем всего дерева сцены. Вроде как всё есть сцены, но я предлагаю держать в уме, что те сцены, которые ты создаёшь в редакторе, это таки префабы, а не сцены. И сценами они не становятся. Они становятся ветвями в дереве одной единственной сцены. Как и куррент_сцене, так и аутолоадед_синглетонц. Ещё раз рекомендую ознакомиться с remote (удалённой) сценой, при запуске игры в редакторе.
Аноним 12/04/20 Вск 00:16:16 #383 №655717 
>>655709
Забыл дать пояснения к скрину. В данном скрине куррент сцена - это menu_location, фон для главного меню с простенькой анимацией. Всё остальное - автолоады, из которых с галкой синглтона только evman, config и game. Когда я делаю загрузки или перезагрузки куррент сцены (то есть, когда загружаю собственно игру), автозагруженные модули получают необходимые сигналы, чтобы изменить их состояние. Например, задать фоновую музыку, скрыть меню, показать HUD. Наборы этих действий стандартно входят в такие процедуры как загрузка сохранённой игры, старт новой игры. При включении режима паузы часть из них автоматически переходит в режим паузы, а некоторые принудительно выставлены в режим process и получают свои сигналы, например, фоновый плеер немного приглушает громкость.
Аноним 12/04/20 Вск 00:36:19 #384 №655739 
В годо есть вообще управляющие сиволы типа \n ? Нашел только обоссаный newline(), который для моих целей не совсем подходит (с ним будет ебля на пустом месте, которой можно было бы избежать при помощи \n)
Аноним 12/04/20 Вск 00:40:13 #385 №655742 
>>655699
> Вообще не знаю, чё делать, если б на Паскале писал, я бы просто загнал генерацию в отдельный поток и/или делал её предварительно, а тут приходится как-то мудрить с отдельными скриптами, не настраивать же все сцены из одного скрипта…
Я тоже старый паскалист. Правда с потоками особо не работал, хоть и понимаю их суть. Удивляюсь, почему ты, обладая знаниями паскаля, не понял как это всё устроено. Там вообще ничего сложного нет.
Как паскалист паскалисту хочу подсказать (а может напомнить, если уже сам знаешь), что аналогами функций и процедур модуля в гдскрипте (равно как и в шарпе) являются static func. Это полный аналог. Статическая функция уже не является методом объекта, описываемого скриптом. У неё нет доступа к методам и полям-переменным. Это те самые функции, которые в модулях паскаля писались без префикса в виде имени класса. Сам понимаешь теперь, для чего их можно применять. Например, чтобы выполнить некий расчёт одной строкой, вызвав статическую функцию, в которой создастся экземпляр класса, вернёт какие-то данные и уничтожится.
> Вот с этими сигналами так много проблем. Коннектить нужно, излучать… А когда они вообще доходят? Это ведь не прямой вызов процедуры, неизвестно, дойдёт ли вообще.
Сигналы это полный аналог ивентов в том же дельфи. Полнейший. Доходят так же. В рамках фрейма, в котором излучены.
> систему сообщений
Сообщения - есть фундаментальное понятие программирования, есть в большинстве парадигм, методик, архитектур, паттернов. Есть сообщения и в годо. Однако, это совершенно иная подсистема и её не желательно путать с сигналами-ивентами. С помощью сообщений (оконных, NOTIFICATION_WM_QUIT_REQUEST), я например, отслеживаю закрытие приложения и выполняю необходимые действия, вплоть до отмены закрытия, если игрок передумал в диалоге ДА/НЕТ.

Аноним 12/04/20 Вск 00:40:50 #386 №655743 
>>655739
Вообще есть. Прямо так и пиши "Foo\nBar"
Аноним 12/04/20 Вск 00:43:10 #387 №655745 
>>655743
Ок. Просто я шерстил документацию, и че-то прям совсем безрезультатно...
Аноним 12/04/20 Вск 00:43:23 #388 №655746 
изображение.png
изображение.png
>>655739
>В годо есть вообще управляющие сиволы типа \n ? Нашел только обоссаный newline()
Ты хотя бы попробовал использовать \n, прежде чем задавать вопрос здесь? -_\\
Аноним 12/04/20 Вск 00:45:04 #389 №655747 
>>655746
Нет, извини.
Аноним 12/04/20 Вск 00:49:30 #390 №655751 
>>655746
Освой форматирование строк. Такая крутая тема! Всем рикаминдую.
text = "FPS: %s\nObjects: %s\nNodes: %s\nOrphans: %s\nVertices: %s" % [fps, objs, nodes, orphans, vertices]
Ну ты понел. И есть ещё варик со словарём, чуть длиннее и более подходит для крупных текстов.
Аноним 12/04/20 Вск 01:00:12 #391 №655759 
>>655751
А интерполяция строк есть?
Аноним 12/04/20 Вск 01:03:41 #392 №655762 
>>655759
Ненавижу этот тупой термин. С какого хуя интерполяцией назвали строковое форматирование? Зумеры совсем ебанулись.
Аноним 12/04/20 Вск 01:09:52 #393 №655764 
>>655762
Этот термин ещё в перле был, пиздючелло.
Аноним 12/04/20 Вск 01:17:40 #394 №655767 
>>655764
Именно перл и является очередным зумерским высером, внучок.
Интерполяция чаще всего подразумевается линейная, когда lerp(from, to, delta) а что вы, зумеры подразумеваете под интерполяцей строк? Ты дяже объяснить этого не сможешь, потому что нет в стрововом форматировании никакой интерполяции. А тот дегенерат, что придумал использовать этот термин, будет гореть в аду.
Аноним 12/04/20 Вск 01:28:38 #395 №655770 
>>655767
>перл и является очередным зумерским высером
Зумеры - это рожденные после 2000
Аноним 12/04/20 Вск 01:46:19 #396 №655774 
>>655767
>ты дяже объяснить этого не сможешь
Учи латинский, технарик. Тогда не будет бомбить от знакомых терминов, которые используются в незнакомом контексте.
Аноним 12/04/20 Вск 01:49:32 #397 №655775 
изображение.png
>>655709
Я не понимаю, что и зачем ты пытаешься объяснить. Я говорил, что меня смутило, что перезагружается не "root", а только одна из его веток, которая помечена как "текущая сцена". Изначально я начал использовать reload_current_scene() в качестве замены нажатия F5 в редакторе, чтобы не перезагружать всю игру целиком, если мне нужно сбросить сцену для теста. Выглядит нелогичным, что нода-синглтон (UI) имеет особые привилегии перед обычной нодой (menu_location).

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

>>655742
>Правда с потоками особо не работал, хоть и понимаю их суть.
В данном конкретном случае суть в том, чтобы не тормозить главный поток. В обычном приложении главный поток может общаться с пользователем через нажатия кнопок и всякие анимации, тогда как в фоне крутится несколько потоков, занятых долгими или тяжёлыми процессами. Конкретно в игре я бы хотел (попробовать) выделить генерацию в отдельный поток, чтобы игрок мог сразу бегать по карте, пока она ещё не до конца прогрузилась. Да и систему ИИ было бы неплохо выделить в отдельный поток, но это я планирую сделать с помощью GDNative и всё того же Паскаля; можно и генерацию так же сделать, но я хотел поэкспериментировать на GDScript для начала. Знаю, что многопоточность можно симулировать на уровне приложения, но париться с этим желания нет, раз уж мы сидим на многопоточной ОС.

>Статическая функция уже не является методом объекта, описываемого скриптом. У неё нет доступа к методам и полям-переменным
Тогда какой в ней смысл? Память она всё равно занимает, выделить в отдельный файл-модуль всё равно нельзя, выполнение вызывающего кода всё равно блокирует. Я когда в ООП-стиле на паскале пишу, практически не создаю простые функции и процедуры, а static методы вообще никогда не создавал...

>Сигналы это полный аналог ивентов в том же дельфи. Полнейший. Доходят так же.
Эммм, я не создавал свои собственные ивенты в Delphi/Lazarus, но насколько мне известно, TApplication работает в единственном потоке, и событие мгновенно вызывает связанный с ним обработчик, ничего никуда не "доходит". Это значит, что если обработчик содержит тяжёлый код, срабатывание события вызовет зависание основного потока... Нехорошо.

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

>Удивляюсь, почему ты, обладая знаниями паскаля, не понял как это всё устроено. Там вообще ничего сложного нет.
Главным образом я не могу понять концепцию "скриптов". Потому что когда я пишу код на Паскале или любом другом компилируемом ЯП, я чётко вижу единственную точку входа в программу, хотя бы примерно понимаю, что происходит под капотом того же TApplication, когда и при каких обстоятельствах вызываются все процедуры. А при написании скрипта для игрового объекта в любом игровом движке у меня ощущение, будто скрипт "авось выполнится, а может и нет", и вообще не имеет никакой связи с другими скриптами. Очень трудно писать код, когда он не является цельной программой.

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

Эх, если б я мог осилить математику и не ленился/боялся, я бы давно на своём движке кодил. Может быть, даже сделал бы свой собственный ЯП, кто знает, заготовки валяются без дела...

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

Вот, кстати, второй раз забываю спросить - почему в GDScript не предусмотрен деструктор класса? Роль конструктора по идее выполняет ready, хоть он и вызывается позже enter_tree, но деструктора нет. Пробовал использовать какой-то костыль, но он то ли не работает, то ли работает не так, как я думал, а тот же exit_tree в качестве деструктора нельзя использовать, т.к. нода может покидать дерево и возвращаться в него много раз за время своей жизни. Странно и неудобно.
Аноним 12/04/20 Вск 01:54:51 #398 №655777 
изображение.png
изображение.png
>>655767
>что вы, зумеры подразумеваете под интерполяцей строк?
Кстати, он прав, интерполировать строки действительно возможно.
И таки интерполяция строк была раньше интерполяции чисел, лол)
Аноним 12/04/20 Вск 02:15:58 #399 №655779 
>>655774
> Учи латинский, технарик.
Какой латински, уёбок, блять? Interpolation = intercourse between two poles (nord, south, ord). Уёбина, блядь. Засунься в село из которого ты выполз, колхозан обосранный.
Аноним 12/04/20 Вск 02:17:53 #400 №655780 
>>655779
Не надо посреди ночи показывать свою убогость, ты обгадился ещё два поста назад.
Аноним 12/04/20 Вск 02:23:31 #401 №655782 
>>655775
> Я не понимаю, что и зачем ты пытаешься объяснить. Я говорил, что меня смутило, что перезагружается не "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
Аноним 12/04/20 Вск 02:24:00 #402 №655783 
>>655780
Нет ты.
Аноним 12/04/20 Вск 02:25:05 #403 №655784 
>>655762
Хаха, дивись, это они так шаблонизирование нащвали
Аноним 12/04/20 Вск 02:29:38 #404 №655785 
>>655784
Лол. Я ж и грю - зумеры в конец охуели.
Аноним 12/04/20 Вск 03:08:01 #405 №655793 
>>655543
>тебе всё равно ведь придётся замыкать тайлы
Я нарисовал два почти одинаковых квадрата (набора) 8х8 (с учётом неровных границ они превратились в 10х10), получилось достаточно разнообразно, чтобы в любой конфигурации найти более-менее незаметный стык.

>Там-то точно получится, но для импорта понадобится инструмент:
Аригато, я уже всё нагуглил и опробовал.
Аноним 12/04/20 Вск 08:18:25 #406 №655818 
А правда, что порядок элементов одного уровня в древе сцены соответствует порядку загрузки? Если да, то можно на это рассчитывать, или все же лучше на это не надеяться и писать костыли, чтобы действия в принципе не могли выполниться в неверном порядке?
Аноним 12/04/20 Вск 11:29:28 #407 №655851 
>>655818
Вообще, выглядит как правда. И ты можешь сам это проверить. Можешь обезопасить себя, конечно, но это лишнее, ИМХО. Порядок загрузки, порядок чтения файлов это все вещи фундаментальные и их менять не предполагается. Когда меняют такие фундаментальные вещи, то заявляют вслух о несовместимости новых версий со старыми.
Аноним 12/04/20 Вск 12:53:45 #408 №655915 
>>655818
>порядок элементов одного уровня в древе сцены соответствует порядку загрузки
Да, это так. Попробуй набросать несколько нод с кодом:

func _enter_tree():
print(name, " enters tree")

func _ready():
print(name, " are ready")

func _exit_tree():
print(name, " leaves tree")

Когда запустишь, увидишь, что ноды входят в дерево и готовятся к работе в прямом порядке, а выходят в обратном порядке. Иногда это может быть важно, да. Например, если у тебя две камеры, то первой перехватит управление та, что войдёт дерево раньше, и через неё будет идти рендеринг - поэтому если камер несколько, Player со своей камерой должен находиться выше остальных камер.
Аноним 12/04/20 Вск 13:06:59 #409 №655919 
>>655818
Что такое "порядок загрузки"?
Аноним 12/04/20 Вск 14:13:45 #410 №655934 
>>655915
>>655851
То есть, если у меня есть две ноды на одном уровне, одна из которых загружает переменные другой, заданные при ее инициализациия в курсе, что так не стоит делать, и я поменяю в какой-то момент их местами, то все полетит к херам собачьим?
Аноним 12/04/20 Вск 14:15:16 #411 №655936 
>>655919
Порядок входа в сцену\инициализации\прочего говна.
Аноним 12/04/20 Вск 14:16:32 #412 №655939 
>>655934
>одна из которых загружает переменные другой
Я имел ввиду что она это делает тоже при инициализации
Аноним 12/04/20 Вск 16:34:52 #413 №655989 
>>655232
Напиши свой алгоритм поиска пути, например "Первый лучший" и вставь местам, где "дорожка" ниже коэффициент маршрута.
Аноним 12/04/20 Вск 16:36:41 #414 №655990 
>>655934
>все полетит к херам собачьим?
Полетит или не полетит - попробуй и узнаешь сам. Но скорее всего полетит, потому что соседняя сущность ещё не существует и будет обращение к null (точнее get_node() не сможет найти и вернёт null, к которому ты обратишься). Лучше переделай код, тут вот выше уже обсуждалось, что лучше иметь обращения только к потомкам (ready() предка вызывается после всех ready() потомков).
Аноним 12/04/20 Вск 16:38:01 #415 №655991 
>>655990
>тут вот выше уже обсуждалось, что лучше иметь обращения только к потомкам
Да это даже обсуждать не надо. Я нюфаня в годо, но и я понимаю, что не стоит.
Аноним 12/04/20 Вск 16:47:09 #416 №655994 
>>655989
Да мне нужно было тупо сразу Википедию почитать:
>В жанре 3D-шутеров используются намного более ограниченные пространства, которые не так легко разделить на узлы. Здесь взамен узлов используются так называемые waypoints (дословно с англ. — «точки пути»). Waypoints — это нерегулярные и вручную установленные узлы, которые содержат информацию о том, к каким другим узлам возможно добраться от данного.
Короче Navigation Godot'а нужен по большому счёту для стратегий, где не бывает сложной геометрии уровня.
Аноним 12/04/20 Вск 17:21:47 #417 №656021 
Скачал годот, и первый вопрос - как убрать этот скайбокс???
Аноним 12/04/20 Вск 17:36:56 #418 №656040 
>>656021
Всё, нашёл.
Аноним 12/04/20 Вск 20:27:45 #419 №656160 
>>655994
> Короче Navigation Godot'а
Там полноценный астар искаропки завезён.
Второй видос >>655497
Аноним 12/04/20 Вск 23:47:43 #420 №656283 
>>656160
Ну я и говорю, что полноценный астар - оверкилл для всего шутаноподобного. Вроде бы.
Аноним 13/04/20 Пнд 02:44:29 #421 №656332 
Чёт я немного подзадолбался.
Делаю двадэ-анимацию по принципу "одна кость - одна картинка". Чтобы никаких артефактов на сгибах. Делаю по инструкции как у этого чувака https://www.youtube.com/watch?v=QL57J3anDTU - и стопорюсь на этапе IK. Правая рука ведёт себя правильно, причём не по старому методу, описанному в видео, а по новому, про который он сказал, мол, пока ещё не работает (у него версия 3.1). А с левой рукой не срабатывает. Как будто никакой привязки графики к костям нету, картинка не двигается вместе с костью, к тому же кость растягивается, будто никакого IK нету. Хотя я абсолютно одинаково всё сделал с левой и с правой стороной.
То есть, я двигаю кость предплечья, само предплечье с ней вместе двигается, плечо стоит на месте, кость плеча растягивается. Двигаю кость плеча - двигается плечо и предплечье вместе с костью. Попробовал отсоединить скелет, всё заново просинхронизировать. Смог заставить правильно работать одну ногу, вторая не хочет. Куда копать? Что курить? Где гуглить?
Аноним 13/04/20 Пнд 04:26:22 #422 №656346 
изображение.png
>>656332
Мы тут экстрасенсы что ли? Не проще найти готовый шаблон/демо? Пикрил, например, хоть это и 3D, но прицип скорее всего тот же.
Аноним 13/04/20 Пнд 04:33:19 #423 №656347 
>>656346
>Не проще найти готовый шаблон/демо?
Нет, не проще. Терпеть не могу в чужом коде ковыряться.
Впрочем, я уже нашёл более простое решение для себя: https://docs.godotengine.org/ru/latest/tutorials/animation/cutout_animation.html#doc-cutout-animation - гораздо меньше возни, никаких искажений и всё работает.
Аноним 13/04/20 Пнд 08:42:03 #424 №656364 
>>656347
> Нет, не проще. Терпеть не могу в чужом коде ковыряться.
а другим предлагаешь ковыряться в твоем, причем еще и на словах
Аноним 13/04/20 Пнд 09:04:51 #425 №656365 
https://twitter.com/reduzio/status/1249413703973457921
Аноним 13/04/20 Пнд 09:06:52 #426 №656366 
>>656283
Никакого оверкила. Просто юзаешь А* без задней мысли и имеешь ПРОФИТ.
Аноним 13/04/20 Пнд 09:32:43 #427 №656373 
>>656366
Ему все равно придется генерировать сетку way-point-ов, т.к. a-star в шутане определит путь в комнате и нескольких прилежащих, но на чуть дальние расстояния он уже не осилит, тем более в шутане. Так что тут надо комбинированный подход нави-сеток делать.
Аноним 13/04/20 Пнд 10:18:41 #428 №656383 
>>656373
В видосе выше показан простой и удобный метод генерации вейпоинтов, который работает как в дизайнтайме, так и в рантайме. Не вижу проблемы. Если анон и ниасилит, то только из-за своей лени.
Аноним 13/04/20 Пнд 17:14:58 #429 №656550 
image.png
Привет, народ. Возник такой вопрос: как сохранять игру из паузы? Для паузы использую функцию get_tree().paused. Но во время вызова функции сохранения получаю ошибку с пикрила. Может кто подскажет: как исправить это?
Аноним 13/04/20 Пнд 17:20:58 #430 №656555 
изображение.png
>>656365
А когда она будет-то, четвёрка эта? Надеюсь, обратную совместимость не сломают...
Аноним 13/04/20 Пнд 17:28:20 #431 №656558 
>>656550
Такое сообщение выбрасывается, когда ты где-то теряешь ссылку на сущность. Снабди код проверками на null, где возможно, и выводи собственные ошибки в консоль, чтобы знать, где ссылка теряется. Ну или просто тщательно код пересмотри, где вероятнее всего могут возникать null-ы?

>во время вызова функции сохранения
Функцию сам писал же? Вот в ней и нужно разбираться, где там у тебя ссылки на null.

Сам я пока не разбирался в функционале паузы и сохранения, но по идее paused просто меняет внутреннее состояние нод, и не должно ломать ссылки. Поэтому скорее всего ты сам где-то ссылки теряешь, или небезопасно уничтожаешь какие-то объекты. Может, какой-то код написал и забыл про него, а он сейчас реагирует неправильно.
Аноним 13/04/20 Пнд 18:07:04 #432 №656568 
>>656555
Не будет обратной совместимости.
Аноним 13/04/20 Пнд 18:49:34 #433 №656590 
Сделал 2д-рэгдолл, у которого при этом имеется удобно анимируемый скелет. Красиво складывается при падении на твёрдую поверхность. Теперь надо как-то к нему прикрутить сами анимации, чтобы при этом физика не мешала. Ещё не гуглил, как это делается, просто отписываюсь о достигнутом успехе. Ща займусь.
Аноним 13/04/20 Пнд 19:08:00 #434 №656600 
1586794078440.png
1586794078563.png
1586794078581.png
1586794078593.png
>>656550
Привет!
Добро пожаловать в Годо-15! Лучший тред из оставшихся.
Я сегодня как раз размышлял над удобной системой схоронения. И придумал следующие положения:
1. Данные сохранения подготавливаются как словарь (Dictionary) в глобальной области (автозагруженном скрипте).
2. Сущности, которые должны сохранять данные обладают компонентом сохранения, который гибко настраивается.
3. Развешиваем компонент на нужные ноды.
4. Подписываем компонент на сигналы сохранения и загрузки.

Вот накидал примерчик. Я разделяю свойства полученные через геттер, чтобы в дальнейшем выставлять их через сеттер, а остальные напрямую. Ну и save_example это разумеется не настоящие данные сохранения, а показанные для примера.
Логика токова: когда игрок нажимает эфпяточку, генерируется сигнал collect_save_data после чего все подписанные на него сэйверы наполняют словарь данными, разбитыми, как видно из кода по овнерам (рутам субсцен), парентам и могут сами содержать подразделы-словари. Затем нужно подождать, пока все данные соберутся. Я пока ещё не придумал, как. После того, как данные соберутся, генерируется сигнал save_game который собственно записывает содержимое в файл.
Загрузка работает в обратном порядке. Но надо дополнительно смотреть, существуют ли указанные в файле объекты и если нет - сначала создавать, а потом разсериализовывать им свойства.
Аноним 13/04/20 Пнд 19:18:33 #435 №656608 
1586794712466.png
1586794712581.png
1586794712632.png
>>656600
И да. Разумеется, это работает с пользовательскими свойствами, созданными в скриптах. Вот я создал свойство, указал его в инспекторе и вуаля!
Кому-то может показаться неудобным выставление свойств строками в массиве - нет защиты от опечаток. Штош. Пишите аддон. Чтобы как у аниматора ключики - у сэйвера стояли значки для отбора сохраняемых свойств.
Аноним 14/04/20 Втр 00:57:48 #436 №656697 
>>656600
По-моему твой способ мудрёный и не для всякой игры подойдёт.
Я вот собираюсь попробовать это - https://godotengine.org/qa/903/how-to-save-a-scene-at-run-time
Т.к. мне вся сцена целиком нужна, а не только отдельные свойства отдельных объектов...

И почему добавление random() так сильно замедляет загрузку сцен?..
Аноним 14/04/20 Втр 01:23:08 #437 №656704 
Годаны, подскажите. Не понимаю, как гуглить.
Задача: найти всех потомков ноды, имеющих определённый тип (например, RigidBody2D), и со всеми проделать одну и ту же операцию (отключить обработку физики; я видел пару дней назад, как это делается, но уже тот видос потерял, придётся снова искать). Вот. Как найти всех потомков, соответствующих заданному типу? Ясно, что циклом for. А дальше? Анончик, может, какой-нибудь тутор по теме подкинешь?
Аноним 14/04/20 Втр 03:05:13 #438 №656718 
>>656704
Буквально вчера писал
for b in $Container.get_children():
var body = b as RigidBody
if body: ...
Аноним 14/04/20 Втр 03:12:41 #439 №656720 
>>656704
Это очень просто:
for child in get_children():
if child is RigidBody2D:
(child as RigidBody2D).add_collision_exception_with(self)

Оператор is проверяет соответствие типу или классу.
Не уверен, нужно ли после проверки приведение типа (as), но без него подсказка в редакторе не работает.

...Блин, опоздал)
>>656718
1. Зачем отдельную переменную заводить?
2. Если оператор as ниасилит приведение типа, игра должна упасть с ошибкой.
Аноним 14/04/20 Втр 03:24:44 #440 №656722 
>>656720
Там просто null будет, т.е. false, лол.
Переменная там чтобы не писать все по два раза как у тебя
Аноним 14/04/20 Втр 03:42:26 #441 №656727 
>>656720
>Не уверен, нужно ли после проверки приведение типа (as)
>>656722
>Переменная там чтобы не писать все по два раза как у тебя
Я тут подумал, похоже не нужно делать лишнее приведение:
for child in get_children():
if child is RigidBody2D:
child.add_collision_exception_with(self)
Да, подсказки в редакторе кода не будет (т.к. подсказка не знает, какого типа child), но и ошибки тоже не будет.
Попытаться вызвать метод можно на любой объект, но сработает он только там, где действительно есть.
Поскольку мы уже проверили, что child нам подходит, мы можем вызывать из него что нам нужно.
Аноним 14/04/20 Втр 03:50:18 #442 №656729 
>>656727
А можно ПРОСТО написать
var c = child as RigidBody
if c...
И будут все подсказки
Аноним 14/04/20 Втр 06:03:55 #443 №656740 
>>656729
Зачем множить сущности без необходимости? Подсказки тебе нужны будут только один раз при написании кода, а память под переменную будет выделяться каждый раз, когда этот код будет выполняться (возможно, 60 раз в секунду, лол). Может мы и пишем на скриптовом ЯП, которой по определению неполноценен в сравнении с компилируемыми ЯП, но всё-таки должны думать о производительности нашего кода.
Аноним 14/04/20 Втр 12:19:33 #444 №656784 
>>656718
>>656720
Грасиас, хлопцы.

>>656740
>память под переменную будет выделяться каждый раз, когда этот код будет выполняться
Разве? Мне где-то попадалось, что в Годоте все переменные это ссылки.
Аноним 14/04/20 Втр 13:59:59 #445 №656804 
>>656784
>Разве? Мне где-то попадалось, что в Годоте все переменные это ссылки.
Не знаю на счёт "всех", но конкретно доступ к экземплярам классов идёт по ссылкам, как и в любом другом ЯП - то есть 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-ы... Значит, операции с переменными не такие уж и дешёвые.
Аноним 14/04/20 Втр 14:05:02 #446 №656807 
>>656804
>Но речь как раз шла о for, в котором на каждой итерации создаётся (var...) переменная.
Речь шла о том, чтобы один раз перебрать всех детей одной ноды. То есть, сам цикл не очень большой, вызываться будет далеко не каждый кадр.
Впрочем, да, лучше иметь привычку экономить ресурсы даже в таких мелочах.
Аноним 14/04/20 Втр 14:50:00 #447 №656825 
qwerty-azerty-769961.jpg
Такая мысль возникла... Видел у одного чувака проблемы с разными раскладками клавиатур (его игра заточена под en_US), понятия не имею, какой у него движок, но, похоже, он назначает действия в игре на коды клавиш, а не на скан-коды клавиш. Теперь меня беспокоит вот что: Godot назначает коды или скан-коды клавиш?

Если кто не знал:
https://ru.wikipedia.org/wiki/Скан-код
Суть в том, что клавиши клавиатуры имеют аппаратно прошитые скан-коды, а уже драйвер клавиатуры подбирает каждому скан-коду соответствующий код клавиши текущей раскладки ОС. Приложение, по сути, получает два кода - код клавиши и скан-код, а что из них использовать - дело разработчика. При наборе текста, например, нам не важно, где расположена клавиша, нам важен только её код (буква, цифра, символ), а вот в играх важно только расположение клавиш, т.е. нужно ориентироваться на скан-коды (исключение - чат, это набор текста).

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

Для примера, сравните хотя бы QWERTY и AZERTY - привычный нам WASD во Франции выглядит как ZQSD.
Аноним 14/04/20 Втр 15:28:22 #448 №656840 
>>656825
Я даже более того тебе скажу. В некоторых крупных играх бывает такая же проблема с раскладками. НЯП, в Doom Eternal она есть, в "Сталкере" точно была.

>>656727
>get_children():
распространяется только на детей, внуков уже не берёт. А если надо обработать более-менее разветвлённое дерево?
Аноним 14/04/20 Втр 16:02:52 #449 №656852 
>>656840
Рекурсия - матушка. Спасет детей, внуков и всех потомков.
Аноним 14/04/20 Втр 16:21:49 #450 №656855 
>>656840
>Я даже более того тебе скажу. В некоторых крупных играх бывает такая же проблема с раскладками. НЯП, в Doom Eternal она есть, в "Сталкере" точно была.
Наличие проблем в крупных играх не говорит о том, что нужно добавлять эти пробелы в свои игры)

>>656840
>распространяется только на детей, внуков уже не берёт. А если надо обработать более-менее разветвлённое дерево?
Как уже сказали, рекурсия. Два варианта: либо такая функция:
func do_work(obj):
for child in obj.get_children():
if child.get_child_count() > 0:
do_work(child)
# тут работаем над самим child
else:
# тут работаем над самим child

Либо, если это делается в _ready(), тогда можно просто повесить скрипт на каждую ноду: _ready() вызывается последовательно сначала у самых дальних потомков, а потом постепенно поднимается до главного предка. Т.о. сначала вызовутся циклы у потомков, потом у их предков, и т.д. до главного предка. Но тут всё зависит от того, что за работу нужно сделать...
Аноним 14/04/20 Втр 16:36:23 #451 №656856 
>>656855
Спасибо за код. Я с мобилы сижу, самому накладно код писать. Только ты с else перемудрил, ящитаю. Оно там лишнее. Если конечно не требуется разный код для бездетных нод )
>>656852-кун

Аноним 14/04/20 Втр 16:39:52 #452 №656857 
>>656855
То есть, какого-то простого метода, чтобы в одну строчку, как get_children(), не существует, я правильно понял? Надо описывать свою функцию для такой рутинной операции? Океей. Это немножко странно для годота, я уже успел привыкнуть, что на всякую объектную рутину здесь есть готовые функции, которые надо просто знать. Ещё и этот >>656852 хитрец загадками говорит, своими намёками утвердил меня в мысли, что есть однострочное решение.
Аноним 14/04/20 Втр 17:06:41 #453 №656861 
Всё работает, поцоны! Написал немножко иначе:
func do_work(obj):
# можно сделать что-то с объектом вот тут
for child in obj.get_children():
if child.get_child_count() > 0:
do_work(child)
# а можно и вот тут, лишь бы не в теле цикла

Спасибо за пояснения, я бы так и долбился головой об стену, пытаясь найти несуществующее однострочное решение.
хотя я всё ещё считаю странным, что у get_children() нет аналога, который бы перебирал всё потомство, а не только детей
Аноним 14/04/20 Втр 17:30:28 #454 №656862 
>>656861
> я всё ещё считаю странным, что у get_children() нет аналога, который бы перебирал всё потомство, а не только детей
У меня тоже стойкое ощущение, что где-то в доках я видел рекурсивный вариант функции. Возможно вездесущий эффект Манделы, или что-то путаю.
Аноним 14/04/20 Втр 17:51:15 #455 №656863 
>>656862
Всё, нашёл!
> Node find_node ( String mask, bool recursive=true, bool owned=true )
Эта функция подозреваю, медленная, ибо ищет ноды по строковому паттерну. И работа с ней немного отличается. Нужно юзать while пока функция не вернёт нулль. Начал писать код, но всё стёр. ВРЕДНО! НИЗЯ! Юзайте get_children() по индексам.
Аноним 14/04/20 Втр 18:57:54 #456 №656887 
изображение.png
>>656856
>Только ты с else перемудрил, ящитаю. Оно там лишнее
(тут было многабукав) ...а, ну да. Если сделать так, как на скриншоте, то else не нужен. Ох уж эти питоновские отступы, без них в коде можно запутаться...

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

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

>>656861
Ты сейчас лишний раз вызываешь do_work() на бездетные ноды. Если у тебя таких мало (что вряд ли), то ладно, но если где-то много одноуровневых бездетных нод, то на каждую будет во-первых лишний вызов функции, во-вторых лишняя проверка их бездетности (она уже выполняется в if). Учитывая то, что функция рекурсивная, то есть забивает собой стек вызовов, от лишних её вызовов лучше избавляться.

>хотя я всё ещё считаю странным, что у get_children() нет аналога, который бы перебирал всё потомство
Ничего странного. Если бы такая функция была, она должна была бы формировать длинный массив всего потомства, а потом ты бы проходил по нему циклом. То есть получалась бы двойная работа - сначала собрать массив, потом пройти по нему. Нет, мог бы быть вариант типа do_work_on_children(parent, method, recursive) - который будет вызывать метод method() на каждого потомка parent, но я не уверен, можно ли сделать такой обработчик на GDScript (для этого нужна возможность передавать указатель на метод и вызывать метод по указателю). В функциональных ЯП такие обработчики - обыденность, в императивных же таким занимаются редко (хоть и можно).

>>656863
>Эта функция подозреваю, медленная
Правильно подозреваешь, get_children() тупо возвращает уже имеющийся массив ссылок на потомков, а find_node() пытается найти в этих массивах конкретную ноду. При этом find_node() возвращает первую попавшуюся ноду, а не массив всех подходящих, что не имеет смысла, если только ты не удаляешь все ноды с определённым именем.

>Нужно юзать while пока функция не вернёт нулль
??? Как она вернёт нуль, если ты не удаляешь отданные ею ноды?
Аноним 14/04/20 Втр 19:52:03 #457 №656897 
>>656825
В коде встречал слово scan, так что скорее всего оба способа доступны.
Аноним 14/04/20 Втр 19:58:19 #458 №656902 
изображение.png
>>656897
В коде да, а в списке действий? Не хардкодить же в скриптах.
Аноним 14/04/20 Втр 20:12:17 #459 №656909 
>>656887
> мог бы быть вариант типа do_work_on_children(parent, method, recursive) — который будет вызывать метод method() на каждого потомка parent, но я не уверен, можно ли сделать такой обработчик на GDScript (для этого нужна возможность передавать указатель на метод и вызывать метод по указателю)
Есть такое у нас.
1. call(), call_deferred() возможность вызвать метод по строковому имени.
2. FuncRef объект, который реально хранит ссылку на метод, нужно удалять/очищать вместе с объектом, иначе - крош.
>>656902
Только что проверил на линуксе. Ввод работает только в английской раскладке. Причём и в игре и в редакторе (шоткаты не работают). Как минимум в линуксе обработка идёт через коды буков, а не сканоды. Хотя в винде такой проблемы не было, ЕМНИП.
Аноним 14/04/20 Втр 21:04:33 #460 №656947 
>>656887
>Ты сейчас лишний раз вызываешь do_work() на бездетные ноды.
В каком месте? if Child.Get_Children_Count() > 0: do_work(Child) - если у ноды есть потомки, то вызываем, а если нет, то проходим мимо.

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

>Вот тебе зачем это понадобилось?
Пытаюсь 2д-рэгдолл на коленке собрать. И даже уже собрал. Но для полного счастья ему нужно сначала выключить физику для каждой части тела, а потом, когда персонаж умирает, включить обратно. Части тела выстроены в иерархию с узлами из ригидбодей, потому что так удобнее анимировать.

>>656909
>Только что проверил на линуксе. Ввод работает только в английской раскладке.
В линуксе такое повсеместно. Почти все хоткеи работают в зависимости от раскладки. На виндах, когда ещё пользовался ими, такого вообще не встречал; хотя у некоторых стримеров видел эту проблему.
Аноним 14/04/20 Втр 21:21:46 #461 №656965 
>>656947
> Но для полного счастья ему нужно сначала выключить физику для каждой части тела, а потом, когда персонаж умирает, включить обратно. Части тела выстроены в иерархию с узлами из ригидбодей, потому что так удобнее анимировать.
Открой для себя группы и не изобретай велосипед. Назначаешь всем частям группу рэгдол, потом вызываешь call_group()
Аноним 14/04/20 Втр 21:57:29 #462 №656975 
>>656947
>если у ноды есть потомки, то вызываем, а если нет, то проходим мимо.
Ну смотри. Имеем структуру:
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, а не ОС.
Аноним 14/04/20 Втр 22:05:28 #463 №656977 
>>656975
> скорее всего это недоработка графических компонентов (Qt/GTK),
Однако же, в годоте нет этих зависимостей. Значит проблема глубже. В самой глубине линуксового подхода к работе с клавиатурой. Опять же, у виндовс-билда годота такой проблемы нет.
Аноним 14/04/20 Втр 22:54:11 #464 №656996 
>>656975
Вот смотри. Вызываем функцию в любом случае извне:
>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)

Я проверил, мой вариант работает как надо, без лишних вызовов.
Аноним 15/04/20 Срд 02:12:22 #465 №657026 
>>656740
Код во время разработки правится постоянно, и автодополнение нужно. А перед релизом можно и заменить, хоть автозаменой.
Аноним 15/04/20 Срд 02:58:09 #466 №657031 
>>656996
А, ну, для твоего случая имеет смысл сделать так.
Я говорил о таком варианте:

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.чё_то_там()

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

Но как уже выше говорили, это, похоже, нужно решать группами.
Аноним 15/04/20 Срд 14:28:07 #467 №657075 
Двощ, а чисто теоретически можно на годо написать скринмейт?
Аноним 15/04/20 Срд 16:14:37 #468 №657105 
1503632629057.webm
>>657075
Если подумать, то да. В настройках проекта включить borderless window, и per pixel background transparency. В ready включить эту самую транспаренси. Но вот дальше будут реальные сложности, если захочешь чтобы мейты ходили по окошкам программ, то придется написать модуль на c++ и ебаться с голым winapi, скорее всего.
Аноним 15/04/20 Срд 16:52:25 #469 №657130 
изображение.png
Почему у меня сцена начала медленно сохраняться? Зависает на 2-3 секунды на 100% полоски сохранения... Всё бы ничего, да только сцены сохраняются перед каждым запуском, и это замедляет запуск. :c


>>657105
А разве нельзя сделать окно на весь экран, чтобы каждый раз оно вырезалось по координатам спрайта? Да, игра по-прежнему не будет видеть чужие окна, но сможет перемещать спрайт по всему экрану.

>>657075
ИМХО, Годо для скринмейта - оверкилл. Скринмейту по сути нужно только выводить спрайтовую анимацию. На каком-нибудь C скринмейт можно уместить в <100 КБ, и это будет не сложнее, чем в Годо. Но да, если хочешь какое-то взаимодействие с окошками - тут только WinAPI...
Аноним 15/04/20 Срд 17:54:29 #470 №657153 
>>657130
>>657105
Ок, спасиб. WinAPI не очень охота дрочить. Уже как-то пытался, еще когда в школе учился, но не срослось.
Аноним 15/04/20 Срд 18:08:41 #471 №657164 
>>657130
>А разве нельзя сделать окно на весь экран, чтобы каждый раз оно вырезалось по координатам спрайта?
Не знаю, логичнее выглядит иметь маленькое окно, и двигать уже его. Вроде прозрачность это плохо по производительности, если ты будешь двигать окна программ на фоне то больше перерасчетов делается.
>Годо для скринмейта - оверкилл.
Если заморочиться, можно удобно писать много сложной логики...
Аноним 15/04/20 Срд 20:40:34 #472 №657233 
>>657164
>Если заморочиться, можно удобно писать много сложной логики...
Я имею в виду, что для скринмейта ты не используешь и сотой доли возможностей движка. Сложную логику можно писать на любом ЯП, хоть на ассемблере. Движок предоставляет тебе инструменты типа физики, всяких графических штук, интерфейсов и т.д. Тебе же, по сути, нужно только двигать картинку по экрану, меняя кадры. То есть ты будешь иметь 25 МБ кода, которыми не будешь пользоваться, потому что они тебе просто не нужны. Это неправильно.

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

>Вроде прозрачность это плохо по производительности, если ты будешь двигать окна программ на фоне то больше перерасчетов делается
Если в Годо обрезка окна выполнена так, как я думаю, то ресурсы жрёт создание hRgn для вызова WinAPI-функции SetWindowRgn(hWnd, hRgn, bRedraw): https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-setwindowrgn
Проблема в том, что hRgn нужно создавать заново для каждого кадра анимации, если у тебя не статичная картинка. Да, это можно оптимизировать (сохранять hRgn для каждого кадра и переиспользовать), но вряд ли Годо занимается такой оптимизацией. Поэтому вряд ли расширение окна что-то изменит...

>>657153
Да там не сложно, главное осилить концепцию указателей на окно и внимательно читать документацию)
Аноним 16/04/20 Чтв 00:51:04 #473 №657428 
Годаны, у меня тултипы от кнопок отвалились. Один раз свет погас, а бесперебойника у меня нету. И теперь тултипы не появляются. Не могу понять, из за этого или нет? Кнопки ничего не перекрывает, на нажатия мышки реагируют, а тултипов нет. Текст введён, удалял-добавлял - не помогает.
Не то, чтобы это принципиально, смогу и без них, но как-то неприятно.
Аноним 16/04/20 Чтв 00:58:33 #474 №657442 
>>657428
Отбой. Как обычно, написал, а потом сразу нашёл проблему. Мои кнопки - это кнопки меню, которое ставит игру на паузу при своём появлении. По видимому, отображение тултипов тоже на паузу ставится. Пойду гуглить, можно ли отключить это.
Аноним 16/04/20 Чтв 01:43:41 #475 №657494 
>>657442
https://docs.godotengine.org/en/stable/tutorials/misc/pausing_games.html
Держи, пока далеко не ушёл. Пауза для отдельных объектов включается/выключается в один клик.
(просто у меня эта вкладка как раз открыта, чтобы не потерять)
Аноним 16/04/20 Чтв 03:06:44 #476 №657534 
>>657233
Что мешает использовать физику для скринмейта? Он может физически точно кидаться чем то. Или навернуть анимаций, частиц, морфинга
Аноним 16/04/20 Чтв 04:16:08 #477 №657566 
>>657233
>ты будешь иметь 25 МБ кода, которыми не будешь пользоваться, потому что они тебе просто не нужны. Это неправильно.
Тебе рассказать, сколько в операционной системе на твоём компе заложено возможностей, которыми ты не пользуешься? Универсальные инструменты вообще-то так и работают.
Аноним 16/04/20 Чтв 07:38:45 #478 №657585 
>>657534
>Что мешает использовать физику для скринмейта? Он может физически точно кидаться чем то.
Ну тогда ок.
>Или навернуть анимаций, частиц, морфинга
Если не ошибаюсь, задать полупрозрачность каждому пикселю окна в Windows невозможно, можно только обрезать окно по пикселям или задать полупрозрачность всего окна целиком (на счёт Aero-тем Windows Vista/7 не знаю). Однако, если это возможно и не требует слишком многого (представляю себе скринмейт, потребляющий 50% ЦПУ), тогда было бы круто.

>>657566
>Тебе рассказать, сколько в операционной системе на твоём компе заложено возможностей, которыми ты не пользуешься?
А я виноват, что вынужден использовать эту ОС и не имею возможности выкинуть эти возможности? После установки Windows приходится удалять часть сервисов и выковыривать часть файлов, которая не будет нужна, но всё лишнее всё равно убрать не получится, это верно. Но ведь нельзя же следовать плохим примерам...

>Универсальные инструменты вообще-то так и работают.
Не всегда. Это Godot скидывает весь свой рантайм в игру, а мог бы скидывать только те части рантайма, которые задействованы конкретным приложением. Да он и файлы из папки проекта все в игру засовывает, даже если они не задействованы никак. Но это проблемы конкретно Godot, а не любого "универсального инструмента".

Кроме того, для некоторых задач рациональнее использовать специальные инструменты вместо универсальных. Те же скринмейты/шимеджи не должны потреблять ресурсы как полноценная игра, это вообще не игра даже. Аналогично, нельзя делать скринсейвер размером с обычную игру - он должен мгновенно запускаться и мгновенно закрываться, иначе у юзера будут проблемы даже на мощном ПК (чем мощнее становится железо, тем медленнее и толще становятся приложения - как раз из-за тех, кто использует "универсальные инструменты" на любой чих, в том числе для создания новых "универсальных инструментов").
Аноним 16/04/20 Чтв 11:14:22 #479 №657607 
>>657494
Меню и так в режиме "процесс". Речь-то не об этом.
Аноним 16/04/20 Чтв 11:16:37 #480 №657608 
>>657585
> вынужден использовать эту ОС
Юзай линукс.
Несомненное преимущество линукса не только в том, что всё лишнее выпиливается стандартными средствами, а ещё и в том, что не сможешь прокрастинировать, играя в игры, вместо того чтобы игры делать.
Аноним 16/04/20 Чтв 11:36:58 #481 №657612 
>>657608
>Юзай линукс.
Юзал, не понравилось, вернулся к виндувс. Главный недостаток линукса для меня в его неустойчивости, но это долгая история...
>всё лишнее выпиливается стандартными средствами
Угу, а потом оказывается, что это было не лиш... kernel panic! ...или оставляет после себя как-то непонятные артефакты.
>не сможешь прокрастинировать, играя в игры, вместо того чтобы игры делать
На линуксе тоже игры есть, к тому же моя прокрастинация - это на 99% веб-сёрфинг. Я даже когда собираюсь в игру поиграть, вместо игры в игру прокрастинирую в интернете, в итоге так и не играю ни во что практически, только покупаю. А без интернета ломка.
К тому же вот - >>656909
>Только что проверил на линуксе. Ввод работает только в английской раскладке. Причём и в игре и в редакторе (шоткаты не работают).
То есть на линуксе есть необходимые для геймдева редакторы, но даже они обычно работают кое-как, а альтернатив нет.
Аноним 16/04/20 Чтв 11:51:48 #482 №657615 
https://www.youtube.com/watch?v=STenRTku4GY

Хм...
Аноним 16/04/20 Чтв 11:53:54 #483 №657616 
1587027233668.png
>>657612
В линуксе много проблем, но я от него не отказываюсь.
Кроме того, ты ж для виндовса делаешь игры, поэтому как минимум с вводом в готовом приложении проблем не будет. Я вчера экспортировал демку для ТВГ. В линуксе ввод работает только на английской раскладке, в вайне (и в виндовсе у игроков) ввод уже на обеих раскладках работает.
Я ж грю, линукс не даст тебе расслабиться и прокрастинировать. Это не работает, то недоступно, сё не настроено. Остаётся только писать код.
Аноним 16/04/20 Чтв 14:20:55 #484 №657708 
>>657616
>ты ж для виндовса делаешь игры
Я ж для себя делаю игры)

>как минимум с вводом в готовом приложении
Да, но работать в редакторе без хоткеев или постоянно переключаться с раскладки на раскладку - лишние трудности. У меня был такой опыт, кажется, в Inkscape - в какой-то из прежних версий хоткеи настраивались для каждой раскладки индивидуально, и это было очень неудобно, прям выбешивало, особенно когда печатаешь русский текст... Потом они это пофиксили, но до сих пор alt+D вместо срабатывания привязанного к хоткею действия почему-то открывает выпадающее меню, и всё это происходит на винде. Короч для разработки нужна стабильная операционная система, и минимум багов среды разработки.

Кстати о багах... У меня в Godot такие проблемы:
1. "Магнитик" в некоторых сценах стал работать по умолчанию, хотя кнопка отжата;
2. Шаг "магнитика" в части сцен 1 метр, в других - 0.1 метра, но я ничего нигде не настраивал;
3. Один раз отвалилась прокрутка кода колёсиком мыши, вообще не понял, с чем было связано;
4. Включение тумана в окружении по умолчанию полностью закрашивает цветом тумана все модельки сцены.
5. Опять же зависание сохранения на 100% сцены с большими инстансами, вряд ли баг, но бесит, явно что-то не то;
6. Export-параметры скриптов в инстанциированных сценах почему-то теряют значение, приходится пересохранять.
Кто-нибудь сталкивался? Может, "ночные" сборки имеют меньше проблем?

Особенно удивило 6, если я задаю параметру новое значение в сцене, приходится вручную сбрасывать все её инстансы в других сценах, несмотря на то, что в них уже лежит, как мне кажется, правильное значение. При этом распространяется не на все инстансы, как будто некоторые некорректно обновляются... фиг знает, то ли я что-то не понял/сломал, то ли баг какой-то, но неудобно, когда инстансов много и по ошибке в логах трудно понять, кто именно виноват.
Аноним 16/04/20 Чтв 16:27:29 #485 №657779 
>>657708
> 3. Один раз отвалилась прокрутка кода колёсиком мыши, вообще не понял, с чем было связано;
Возможно ты нажал Ctrl+F и вошел в режим навигации "от первого лица" по WASD.
Аноним 16/04/20 Чтв 16:27:49 #486 №657780 
>>657779
Ой, Shift+F то есть.
Аноним 16/04/20 Чтв 16:30:08 #487 №657781 
>>657708
>"ночные" сборки имеют меньше проблем?
В годоте нет такой сущности, есть мастер который нестабильный, потому что он уже наполовину 4.0 на вулкане. Советую пользоваться стабильным 3.2.1, в него бекпортировали часть фич, и фиксили баги, возможно будет еще 3.2.2 мейтейнс версия.
Аноним 16/04/20 Чтв 18:58:40 #488 №657896 
Камрады, поясните за сигналы.
Курю доки, изучаю примеры, смотрю видеотуторы и пытаюсь понять: а собсно нахуя? У нас есть:
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. Пока что я не сталкивался с такими задачами, где такой прямой вызов функций было бы невозможно реализовать.

Не понимаю. Вот у меня есть пули, которые сталкиваются с разрушаемым физическим окружением и персонажами, наносят повреждения, толкают. Обязательно ли тут использовать сигналы? Какие преимущества по сравнению с прямым вызовом функций?
Аноним 16/04/20 Чтв 19:46:25 #489 №657958 
1587055583051.png
>>657442
Судя по всему, отключить нельзя. В интернетах народ просит Хуана сделать дополнительный стейт для паузы, для таких случаев. А мне помог как всегда индусский копипаст-код.
Аноним 16/04/20 Чтв 19:49:26 #490 №657961 
>>657896
В пулях сигналы не нужны.
Сигналы удобны, когда тебе надо дать ноде задачу, подключиться к сигналу готовности этой задачи у этой ноды и пойти дальше. А когда нода сделоет, она пошлёт сигнал. Без сигнала тебе бы пришлось в цикле чекать не выпольнила ли нода задачу.
В программировании сигналы ещё называют событиями, можешь загуглить их. Events.
Аноним 16/04/20 Чтв 21:03:04 #491 №658007 
>>657896
Ну ты рассматриваешь случай когда у тебя все ноды фиксированы по иерархии. А допустим в более сложной игре у тебя может быть подсцена. И по пути уже не удобно
Аноним 16/04/20 Чтв 21:27:46 #492 №658013 
В гдскрипте же всё ок с инкапсуляцией? У меня чертовщина какая-то творится.
Ставлю на сцену двух инстансов от одной и той же сцены "человечек" (игрок и враг). Игрока вкладываю в ноду Control, которая передаёт сигналы с клавиатуры как команды своему человечку-потомку. Внутри сцены "человечек" нет ни одного обращения к каким-либо нодам за пределами сцены. Тем не менее, когда я нажимаю прыжок, игрок подпрыгивает нормальным образом, а враг слегка дёргается в направлении прижка. Магия какая-то.
Аноним 16/04/20 Чтв 22:03:40 #493 №658023 
>>658013
Покаж скрин дерева нод
Аноним 16/04/20 Чтв 22:18:23 #494 №658033 
>>658023
Да всё, проехали.
Проблема ушла после переименования ноды игрока. Её имя совпадало с именем класса. Через это каким-то образом пролез AnimationPlayer и попытался проанимировать тушку врага; но у того был свой AnimationPlayer, который сопротивлялся, отыгрывая idle.
Такие дела. Вывод: лучше всегда переименовывать ноды, чтобы имя не совпадало с именем класса.
Аноним 17/04/20 Птн 15:29:01 #495 №658319 
Никто тут шарпом не пользуется чтоли?
Аноним 17/04/20 Птн 16:30:31 #496 №658325 
>>658319
Я пользовался в прошлом году. Но динамическая типизация оказалась настолько наркотической хренью, что я забил на шарп. Так что ныне только гдскрипт.
Аноним 17/04/20 Птн 17:36:33 #497 №658350 
>>658325
Хотел попробовать годот. И скачал при выборе с шарпом. Но годот сам кричит, что шарп там говно альфа, все по ишью, все по тому сему. Если действительно так плохо, то пока не поздно перейду на питоноподобный гдскрипт. Хотелось бы не переходить конечно (я по работе на питоне сижу и искренне его ненавижу уже), но если шарп и правда работает примерно нихуя, то лучше бы узнать об этом сейчас.
Аноним 17/04/20 Птн 17:44:15 #498 №658353 
image.png
Парни, может кто объяснить че это за хуйня?
Аноним 17/04/20 Птн 17:44:35 #499 №658354 
>>658353
И как ее решать
Аноним 17/04/20 Птн 18:50:55 #500 №658370 
>>658350
> если шарп и правда работает примерно нихуя, то лучше бы узнать об этом сейчас
Шарп работает. Поддерживаются все АПИ. Просто в редакторе реализация шарпа скудная. Когда я смотрел крайний раз, не было интеллисенса. Просто открываешь проект в студии и пишешь в ней, не забывая сохраняться, перед переключением в редактор годота.
>>658353
Эта хуйня называется невнимательность.
Аноним 17/04/20 Птн 18:52:22 #501 №658373 
>>658353
Breakpoint? Это точка остановки для отладки, видимо ты в этой строчке случайно ее жамкнул, посмотри слева красный кружочек.
ПЕРЕКАТ Аноним OP 17/04/20 Птн 19:03:52 #502 №658386 

>>658384 (OP)
>>658384 (OP)
>>658384 (OP)
Аноним 17/04/20 Птн 19:05:59 #503 №658390 
>>658319
Пробовал, в основном разница в том, что приходится сидеть и угадывать в какой нотации записано имя метода или проперти. Вот тут я должен был догадаться, что basis пишется с маленькой, хотя обычно все поля типа Visible пишутся с большой. Поэтому документацией пользоваться довольно неудобно. Как и примерами кода. Даже кто то сайт запилил чтобы смотреть апи https://godotsharp.net/api/3.2.0/
В текущем проекте менять уже не буду, хочу чтобы он работал со стандартным годотом с оф сайта, дальше посмотрю. Хотя меня по прежнему больше соблазняет идея писать прямо на плюсах. И никакой зависимости от моно.
>>658370
>Шарп работает.
В айфонах еще только в планах добавить в стабильную ветку:
>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 на Андроид не так давно сделали, неизвестно как там по багам.
Аноним 17/04/20 Птн 19:07:04 #504 №658392 
1507958383039.png
>>658390
>Вот тут я должен был догадаться, что basis пишется с маленькой, хотя обычно все поля типа Visible пишутся с большой.
Пик отлепился
Аноним OP 17/04/20 Птн 19:08:30 #505 №658393 
>>658390
> Хотя меня по прежнему больше соблазняет идея писать прямо на плюсах.
А я по прежнему жду от тебя успехов в этом начинании, отчётов, скринов, туториалов.
Аноним 17/04/20 Птн 19:36:15 #506 №658415 
1456234604631.png
1475343212093.png
1502082996998.png
>>658393
Так скрин старый был где то, думаю не сильно поменялось. Но поскольку писать так медленнее (писать на плюсах в принципе медленнее, плюс надо ждать каждый запуск линковку), то прототипировать я продолжил на гдскрипте. Как можно заметить там тоже придется угадывать апи, например вместо 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(...)
Аноним 17/04/20 Птн 19:39:50 #507 №658420 
>>658415
И, кажется, надо было самому включать set_process(true) в myready()
Аноним 17/04/20 Птн 20:39:02 #508 №658461 
>>658373
О, спасибо. Я про нее вообще не знал
Аноним 17/04/20 Птн 22:29:14 #509 №658558 
>>658461
Все сразу знать невозможно, просто это стандартно для IDE программирования лет 30 как.
ПЕРЕКАТ Аноним OP 17/04/20 Птн 22:35:54 #510 №658567 
1587152153544.png

>>658384 (OP) (OP)
>>658384 (OP) (OP)
>>658384 (OP) (OP)

comments powered by Disqus

Отзывы и предложения