Двач.hk не отвечает.
Вы видите копию треда, сохраненную 30 июля 2021 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
Вы видите копию треда, сохраненную 30 июля 2021 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
281 Кб, 620x349С чего начать, сидя дома на карантине?
С изучения документации. Если не можешь в инглиш, и даже в гугл-переводчик, то продолжается перевод официальной документации: https://docs.godotengine.org/ru/latest/
Но вообще, будь мужиком и изучи английский: https://docs.godotengine.org/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 и начнет грузить проект из него и из файлов, лежащих в распакованном виде в той же директории.
В версии 3.2 появилась возможность прикреплять pck к бинарнику. Бриллиант для любителей однофайлового продукта!
Редактор персонажей на основе makehuman: https://github.com/Lexpartizan/Go_MakeHuman_dot
Все языки в одном месте: https://vk.com/topic-70467171_35982467
Тест-бенчмарк:
Веб-версия - https://govdot.herokuapp.com
Вишмастер для винды - https://govdot.herokuapp.com/4Anon.rar
Предыдущий тонет там: >>643188 (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/
14 http://arhivach.ng/thread/533171/
С изучения документации. Если не можешь в инглиш, и даже в гугл-переводчик, то продолжается перевод официальной документации: https://docs.godotengine.org/ru/latest/
Но вообще, будь мужиком и изучи английский: https://docs.godotengine.org/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 и начнет грузить проект из него и из файлов, лежащих в распакованном виде в той же директории.
В версии 3.2 появилась возможность прикреплять pck к бинарнику. Бриллиант для любителей однофайлового продукта!
Редактор персонажей на основе makehuman: https://github.com/Lexpartizan/Go_MakeHuman_dot
Все языки в одном месте: https://vk.com/topic-70467171_35982467
Тест-бенчмарк:
Веб-версия - https://govdot.herokuapp.com
Вишмастер для винды - https://govdot.herokuapp.com/4Anon.rar
Предыдущий тонет там: >>643188 (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/
14 http://arhivach.ng/thread/533171/
>>58439
Пости его сюда скорее
Пости его сюда скорее
>>58422
Ну где ж ты раньше был?
Ну где ж ты раньше был?
>>658558 →
Так я и не программист ._.
Так я и не программист ._.
Смотрите, какую я чорную магию изобрёл:
Ответ, что функция делает - под спойлером. Сначала догадайтесь сами.
Когда вызываешь функцию без параметра, она работает, как переключатель. На входе получается инвертированное состояние паузы. Однако, ты всегда можешь вызвать функцию с явным параметром, и она уже сработает как включатель: либо гарантированно включит, либо гарантированно выключит.
> func pause_game(state : bool = !get_tree().paused):
> > get_tree().paused = state
Ответ, что функция делает - под спойлером. Сначала догадайтесь сами.
Когда вызываешь функцию без параметра, она работает, как переключатель. На входе получается инвертированное состояние паузы. Однако, ты всегда можешь вызвать функцию с явным параметром, и она уже сработает как включатель: либо гарантированно включит, либо гарантированно выключит.
>>58892
Точно ли это работает? Вдруг там кешируется значение, а не вызывается по честному функция. Ну я конечно таким пользоваться не буду, предпочел бы тут три метода с четкими названиями - pause(), unpause() и toggle_pause
Точно ли это работает? Вдруг там кешируется значение, а не вызывается по честному функция. Ну я конечно таким пользоваться не буду, предпочел бы тут три метода с четкими названиями - pause(), unpause() и toggle_pause
Как скопировать\переместить узел из одной сцены в другую, а то я объебался со структурой узлов и сцен, и я заебусь заново ее пересоздавать
В вот Camera - это наследник Spatial, поэтому у нее есть поле Visibility. На что оно у нее влияет?
>>59146
В редакторе - правый клик в дереве новых сцен, там merge from scene... откроется меню откуда можно выбрать подветку.
В редакторе - правый клик в дереве новых сцен, там merge from scene... откроется меню откуда можно выбрать подветку.
>>59158
Похоже ни на что. Я особо не вникал, камеры работают примерно по таким правилам: камера рендерит в ближайший вьюпорт выше по дереву (таким образом можно рендерить в текстуру для постпроцессинга), если вьюпорта нет, рендерит в главное окно, если камер несколько, то надо ставить только одной current=true, если current у нескольких, то наверное работает более поздняя по списку (не знаю, гарантируется ли это). Например, если добавить контроллер игрока (сцену с камерой), и после него еще камеру, то включая current у последней, можно включать/выключать вид "извне" на игрока.
Похоже ни на что. Я особо не вникал, камеры работают примерно по таким правилам: камера рендерит в ближайший вьюпорт выше по дереву (таким образом можно рендерить в текстуру для постпроцессинга), если вьюпорта нет, рендерит в главное окно, если камер несколько, то надо ставить только одной current=true, если current у нескольких, то наверное работает более поздняя по списку (не знаю, гарантируется ли это). Например, если добавить контроллер игрока (сцену с камерой), и после него еще камеру, то включая current у последней, можно включать/выключать вид "извне" на игрока.
77 Кб, 1180x532Еще такой вопрос, есть ли ограничение на вложенность нод в пределах сцены или дерева? Иначе поле parent в файле сцены может стать очень безумной длины. Или он все равно внутри это преобразует просто в ссылку на уже загруженную ноду, когда распарсит это поле и ограничений нет?
>>59217
А зачем так делать? Они реально все должны быть поднодами, или тебе было просто лень располагать их параллельно?
А зачем так делать? Они реально все должны быть поднодами, или тебе было просто лень располагать их параллельно?
>>59227
Понятно, что в реальном проекте этого надо избегать. Просто знакомлюсь с особенностями движка.
Понятно, что в реальном проекте этого надо избегать. Просто знакомлюсь с особенностями движка.
Тут кто-нибудь юзал 2д-партиклы?
Пытаюсь сделать выхлоп дульных газов. Но пока не понимаю, как сделать некоторые вещи, буду рад совету или (лучше) подходящему видеотутору. Что я уже посмотрел, там эти вопросы не освещаются.
а) Чтобы частица поворачивалась вместе со стволом. Вот я поворачиваю ствол, источник и направление полёта частиц вертятся вместе с ним; но сами спрайты не поворачиваются. В материале есть настройка Angle, можно фиксированно развернуть спрайт, и он в таком виде будет стрелять в любую сторону. Неужели это придётся кодить? Было бы очень неудобно.
б) Не нахожу никаких настроек прозрачности. Это же дым, он должен не резко исчезать, а постепенно. Но чёт не вижу такой опции. Это странно, вроде ж первейшее применение для партиклей. Сама картинка полупрозрачная, но этого мало же.
в) Как заставить её выплёвывать ровно по одной частице ровно тогда, когда мне нужно? Есть выключатель вкл/выкл, но он работает как-то по-своему, не начинает испускать частицы сразу по включению, а чего-то ждёт. В режиме ваншот после испускания всех частиц источник не хочет включаться вообще, и это типа фича.
Пытаюсь сделать выхлоп дульных газов. Но пока не понимаю, как сделать некоторые вещи, буду рад совету или (лучше) подходящему видеотутору. Что я уже посмотрел, там эти вопросы не освещаются.
а) Чтобы частица поворачивалась вместе со стволом. Вот я поворачиваю ствол, источник и направление полёта частиц вертятся вместе с ним; но сами спрайты не поворачиваются. В материале есть настройка Angle, можно фиксированно развернуть спрайт, и он в таком виде будет стрелять в любую сторону. Неужели это придётся кодить? Было бы очень неудобно.
б) Не нахожу никаких настроек прозрачности. Это же дым, он должен не резко исчезать, а постепенно. Но чёт не вижу такой опции. Это странно, вроде ж первейшее применение для партиклей. Сама картинка полупрозрачная, но этого мало же.
в) Как заставить её выплёвывать ровно по одной частице ровно тогда, когда мне нужно? Есть выключатель вкл/выкл, но он работает как-то по-своему, не начинает испускать частицы сразу по включению, а чего-то ждёт. В режиме ваншот после испускания всех частиц источник не хочет включаться вообще, и это типа фича.
>>59437
Окей, с прозрачностью понял, в разделе Color надо создать градиентную текстуру. Метод "спроси у анона, тут же сам найдёшь ответ" сработал.
С поворотом частиц и единичным выплёвыванием пока не.
Окей, с прозрачностью понял, в разделе Color надо создать градиентную текстуру. Метод "спроси у анона, тут же сам найдёшь ответ" сработал.
С поворотом частиц и единичным выплёвыванием пока не.
>>59439
Ага, методом научного тыка удалось установить, что за поворот отвечает параметр Flags/Align Y.
Осталось разобраться с порционным выплёвыванием партиклей. Тут я вообще не представляю, куда копать, да и тыком уже не получится.
Ага, методом научного тыка удалось установить, что за поворот отвечает параметр Flags/Align Y.
Осталось разобраться с порционным выплёвыванием партиклей. Тут я вообще не представляю, куда копать, да и тыком уже не получится.
>>58384 (OP)
Бамп
Бамп
Можно ли пропукивать материалы в параллельном потоке?
Вот тут описан хак как пропукивать их при загрузке сцены
https://www.reddit.com/r/godot/comments/e7sf82/godot_background_loading_tutorial/
Но всё равно основной поток при этом висит.
Вот тут описан хак как пропукивать их при загрузке сцены
https://www.reddit.com/r/godot/comments/e7sf82/godot_background_loading_tutorial/
Но всё равно основной поток при этом висит.
>>59502
У него нет метода "рестартить", есть только свойство вкл/выкл. Ваншот работает так:
1. Включаем
2. Ждём, пока эмиттер поссыт
3. Ждём, пока умрут все партиклы
4. Эмиттер выключаеся сам, ни в коем случае нельзя его торопить
5. Только после этого можно попробовать заново его включить, и он, может быть, включится.
Да и если бы он просто работал так, как задумано, в любом случае, для автоматического оружия не подходит, потому что у него дым от предыдущего выстрела не успевает рассеяться перед следующим.
Пока что я использую костыльное решение без ваншота: просто подгоняю темп испускания частиц под темп стрельбы и выключаю, когда игрок отжимает кнопку или кончаются патроны. Но это не подходит уже для медленного оружия, когда время жизни пороховых газов меньше времени до следующего выстрела.
У него нет метода "рестартить", есть только свойство вкл/выкл. Ваншот работает так:
1. Включаем
2. Ждём, пока эмиттер поссыт
3. Ждём, пока умрут все партиклы
4. Эмиттер выключаеся сам, ни в коем случае нельзя его торопить
5. Только после этого можно попробовать заново его включить, и он, может быть, включится.
Да и если бы он просто работал так, как задумано, в любом случае, для автоматического оружия не подходит, потому что у него дым от предыдущего выстрела не успевает рассеяться перед следующим.
Пока что я использую костыльное решение без ваншота: просто подгоняю темп испускания частиц под темп стрельбы и выключаю, когда игрок отжимает кнопку или кончаются патроны. Но это не подходит уже для медленного оружия, когда время жизни пороховых газов меньше времени до следующего выстрела.
>>59795
Не очень понял вопрос. Создаешь не Shader Material, а Spatial Material, там всякие цвета и текстуры. Но внутри там шейдеры. Ты имеешь в виду, есть ли специальный рендерер типа как GL1, с glBegin/End? Думаю нет. Примитивы рисования какие-то доступны, конечно. drawLine и т.д.
Не очень понял вопрос. Создаешь не Shader Material, а Spatial Material, там всякие цвета и текстуры. Но внутри там шейдеры. Ты имеешь в виду, есть ли специальный рендерер типа как GL1, с glBegin/End? Думаю нет. Примитивы рисования какие-то доступны, конечно. drawLine и т.д.
>>59816
НУ типа выбрать рендер GLES2, она на GL 2.1 основан
НУ типа выбрать рендер GLES2, она на GL 2.1 основан
>>59856
Прочитал жопой
@
В З О Р В А Л С Я
Специально для тебя повторю задачу: сделать дульную вспышку, которая будет адекватно отрисовываться при любом темпе стрельбы. Поведение вспышки:
1. Единовременно испускается в момент выстрела
2. Испускается после каждого выстрела, а не после некоторых
3. После испускания некоторое время рассеивается в воздухе
4. Последующие выстрелы и вспышки никак не влияют на поведение уже выпущенной
5. Следующий выстрел может быть произведён раньше, чем рассеется вспышка от предыдущего, это тоже не должно на неё повлиять.
Прочитал жопой
@
В З О Р В А Л С Я
Специально для тебя повторю задачу: сделать дульную вспышку, которая будет адекватно отрисовываться при любом темпе стрельбы. Поведение вспышки:
1. Единовременно испускается в момент выстрела
2. Испускается после каждого выстрела, а не после некоторых
3. После испускания некоторое время рассеивается в воздухе
4. Последующие выстрелы и вспышки никак не влияют на поведение уже выпущенной
5. Следующий выстрел может быть произведён раньше, чем рассеется вспышка от предыдущего, это тоже не должно на неё повлиять.
>>59881
Мимо проходил, я партиклами не занимался еще, но если такие условия, то я бы просто создал пул например из 5 эмиттеров, и раскидывал на них по очереди.
Мимо проходил, я партиклами не занимался еще, но если такие условия, то я бы просто создал пул например из 5 эмиттеров, и раскидывал на них по очереди.
>>59883
Это точно такой же костыль, как те два решения, которые я уже придумал:
1. Поставить ваншотный таймер с маленьким временем. Выстрел - партиклы запустились, таймер включился; таймер протикал и выключил партиклы.
2. Для каждого оружия выставляются свои параметры для партиклы, соответствующие скорострельности данного оружия. Партикла включается с началом стрельбы и выключается с концом.
Но хотелось бы что-то менее костыльное. Наверняка в партиклах есть какая-то подходящая опция, просто её расположение не очень очевидно.
Это точно такой же костыль, как те два решения, которые я уже придумал:
1. Поставить ваншотный таймер с маленьким временем. Выстрел - партиклы запустились, таймер включился; таймер протикал и выключил партиклы.
2. Для каждого оружия выставляются свои параметры для партиклы, соответствующие скорострельности данного оружия. Партикла включается с началом стрельбы и выключается с концом.
Но хотелось бы что-то менее костыльное. Наверняка в партиклах есть какая-то подходящая опция, просто её расположение не очень очевидно.
Держу в курсе.
2д-персонаж анимирован из кусочков. Наделал ему кучу анимаций: отдельно для ног и туловища, отдельно для рук и головы. Ко всему этому подвязал AnimationTree, нарисовал там сложное дерево с вложенными стейт-машинами. Теперь пытаюсь это всё заставить работать.
Пока что впечатления: дерево анимаций - очень мощная штука. Завтра, видимо, весь день потрачу на то, чтобы привести в порядок взаимодействия с ней.
2д-персонаж анимирован из кусочков. Наделал ему кучу анимаций: отдельно для ног и туловища, отдельно для рук и головы. Ко всему этому подвязал AnimationTree, нарисовал там сложное дерево с вложенными стейт-машинами. Теперь пытаюсь это всё заставить работать.
Пока что впечатления: дерево анимаций - очень мощная штука. Завтра, видимо, весь день потрачу на то, чтобы привести в порядок взаимодействия с ней.
>>59208
У меня наоборот получалось. Player со своей камерой должен стоять выше остальных сцен с камерами, активной по умолчанию становится первая вошедшая в сцену камера.
По-моему проще вызывать make_current(), а свойство current использовать только для чтения.
>если добавить контроллер игрока (сцену с камерой), и после него еще камеру, то включая current у последней, можно включать/выключать вид "извне" на игрока.
У меня наоборот получалось. Player со своей камерой должен стоять выше остальных сцен с камерами, активной по умолчанию становится первая вошедшая в сцену камера.
>надо ставить только одной current=true
По-моему проще вызывать make_current(), а свойство current использовать только для чтения.
>>60019
Ты прав, но и я тоже прав, ты пишешь про то что если нет ни одной current, то рендерится с первой по списку, а я пишу о том, что если нескольким камерам поставили current, то из них побеждает более поздняя. Проверял в 3.2.1
>Player со своей камерой должен стоять выше остальных сцен с камерами, активной по умолчанию становится первая вошедшая в сцену камера.
Ты прав, но и я тоже прав, ты пишешь про то что если нет ни одной current, то рендерится с первой по списку, а я пишу о том, что если нескольким камерам поставили current, то из них побеждает более поздняя. Проверял в 3.2.1
>>59881
Блять, не отвлекай меня от ТВГ! Так не устроит штоле?
Блять, не отвлекай меня от ТВГ! Так не устроит штоле?
>>60031
Как - "так"? Ты включил партиклю, и она испускает порции частиц с равным промежутком времени. Как думаешь, игрок будет нажимать стрельбу с равными промежутками времени?
Как - "так"? Ты включил партиклю, и она испускает порции частиц с равным промежутком времени. Как думаешь, игрок будет нажимать стрельбу с равными промежутками времени?
>>59891
Я вот не уверен что это костыль. У тебя что, персонаж неподвижен? Если предположим 3д шутер, и во время стрельбы персонаж бежит вперед и поворачивает ствол между выстрелами. Разве это должен быть один эмиттер? С разными тракеториями, исходной точкой, углом? Ну хз может можно как то *текстурой?) передавать в шейдер координаты и углы.
Я вот не уверен что это костыль. У тебя что, персонаж неподвижен? Если предположим 3д шутер, и во время стрельбы персонаж бежит вперед и поворачивает ствол между выстрелами. Разве это должен быть один эмиттер? С разными тракеториями, исходной точкой, углом? Ну хз может можно как то *текстурой?) передавать в шейдер координаты и углы.
>>60037
Включи воображение. На эту партиклю навешиваем ваншот. Дополнительно выставляем частицам глобальные координаты, чтобы дымок оставался в месте выстрела, а не перемещался вместе со стволом. Делаем из неё префаб. Прелоадим его в скрипт оружия. Создаём инстанс при каждом выстреле. Инстанс автоматически срабатывает один раз. Затем он должен удалить сам себя. Можно по таймеру, зная тайминг партикла, можно по сигналу, подбери подходящий.
Но вообще конечно, с таким уровнем тупости ты вряд ли сделаешь игру, если на такой банальной задаче у тебя случился затык на два дня. Без обид, бро, может стоит сменить профессию?
Включи воображение. На эту партиклю навешиваем ваншот. Дополнительно выставляем частицам глобальные координаты, чтобы дымок оставался в месте выстрела, а не перемещался вместе со стволом. Делаем из неё префаб. Прелоадим его в скрипт оружия. Создаём инстанс при каждом выстреле. Инстанс автоматически срабатывает один раз. Затем он должен удалить сам себя. Можно по таймеру, зная тайминг партикла, можно по сигналу, подбери подходящий.
Но вообще конечно, с таким уровнем тупости ты вряд ли сделаешь игру, если на такой банальной задаче у тебя случился затык на два дня. Без обид, бро, может стоит сменить профессию?
>>60026
Скорее всего она не "побеждает", а перезаписывает предыдущую. Т.е. должно быть какое-то свойство типа Viewport.RenderFrom: Camera, в котором лежит ссылка на камеру. У свойства камеры Camera.current вызывается сеттер set_current(), который кроме установки значения true, обращается к вьюпорту и записывает ссылку на эту камеру в соответствующий параметр. Следовательно, не имеет значения, скольким камерам ты сделаешь current = true, поскольку значение имеет ссылка на камеру в текущем вьюпорте. Не будет же вьюпорт бегать по сцене и проверять if Camera.current == true: каждый раз, когда собирается рисовать (т.е. каждый кадр)?
А если не ставить камеру вручную, то вьюпорт идёт по списку вложенных сцен и присваивает своему свойству ссылку на первую попавшуюся камеру; если камеру не найдёт, будет пустота. Как-то так должно быть под капотом устроено...
>если нескольким камерам поставили current, то из них побеждает более поздняя
Скорее всего она не "побеждает", а перезаписывает предыдущую. Т.е. должно быть какое-то свойство типа Viewport.RenderFrom: Camera, в котором лежит ссылка на камеру. У свойства камеры Camera.current вызывается сеттер set_current(), который кроме установки значения true, обращается к вьюпорту и записывает ссылку на эту камеру в соответствующий параметр. Следовательно, не имеет значения, скольким камерам ты сделаешь current = true, поскольку значение имеет ссылка на камеру в текущем вьюпорте. Не будет же вьюпорт бегать по сцене и проверять if Camera.current == true: каждый раз, когда собирается рисовать (т.е. каждый кадр)?
А если не ставить камеру вручную, то вьюпорт идёт по списку вложенных сцен и присваивает своему свойству ссылку на первую попавшуюся камеру; если камеру не найдёт, будет пустота. Как-то так должно быть под капотом устроено...
>>60042
Оптимизация стрельбы уровня /gd/? А потом они ненавидят ООП за медлительность...
>>658013 →
ИМХО, лучше, наверное, наследоваться от общего скрипта. Т.е. есть скрипт human.gd:
class_name Human extends KinematicBody
# тут всё, что нужно для движения человечка
Далее скрипт игрока player.gd:
extends Human
# тут вызываются методы Human в ответ на нажатия клавиш
И скрипт бота bot.gd:
extends Human
# тут вызываются методы Human в соответствии с решениями ИИ
Я так сделал, выглядит вроде логичнее, чем набрасывать отдельный контрол на абстрактного чувака. Хотя, если у тебя какая-нибудь РТС, в которой игрок может попеременно управлять разными юнитами, тогда, похоже, следует именно перекидывать отдельную контролирующую ноду-скрипт (но тогда она сама должна быть потомком, наверное)...
>>658373 →
Там хоткей вроде F9, я часто его случайно нажимаю, т.к. в нормальных IDE компиляция забита на F9, а не F5.
Первый раз точно так же недоумевал, почему у меня брекпойнт возник, пока не понял, что на автомате жму F9...
>Создаём инстанс при каждом выстреле. Инстанс автоматически срабатывает один раз. Затем он должен удалить сам себя.
Оптимизация стрельбы уровня /gd/? А потом они ненавидят ООП за медлительность...
>>658013 →
>Ставлю на сцену двух инстансов от одной и той же сцены "человечек" (игрок и враг). Игрока вкладываю в ноду Control, которая передаёт сигналы с клавиатуры как команды своему человечку-потомку.
ИМХО, лучше, наверное, наследоваться от общего скрипта. Т.е. есть скрипт human.gd:
class_name Human extends KinematicBody
# тут всё, что нужно для движения человечка
Далее скрипт игрока player.gd:
extends Human
# тут вызываются методы Human в ответ на нажатия клавиш
И скрипт бота bot.gd:
extends Human
# тут вызываются методы Human в соответствии с решениями ИИ
Я так сделал, выглядит вроде логичнее, чем набрасывать отдельный контрол на абстрактного чувака. Хотя, если у тебя какая-нибудь РТС, в которой игрок может попеременно управлять разными юнитами, тогда, похоже, следует именно перекидывать отдельную контролирующую ноду-скрипт (но тогда она сама должна быть потомком, наверное)...
>>658373 →
>видимо ты в этой строчке случайно ее жамкнул
Там хоткей вроде F9, я часто его случайно нажимаю, т.к. в нормальных IDE компиляция забита на F9, а не F5.
Первый раз точно так же недоумевал, почему у меня брекпойнт возник, пока не понял, что на автомате жму F9...
>>60042
Чем этот костыль лучше уже придуманных выше костылей >>59891
? Вопрос был про поиск решения встроенными в партиклу средствами (т.е. без других нод и дополнительного кода), а не про обход технических ограничений в виде отсутствия этих средств.
>>60039
Снимаем галку Local Coords и не плодим сущности. Не смотрел, как это работает в 3д, я делаю в 2д, и это работает при любых перемещениях и поворотах ствола.
Чем этот костыль лучше уже придуманных выше костылей >>59891
? Вопрос был про поиск решения встроенными в партиклу средствами (т.е. без других нод и дополнительного кода), а не про обход технических ограничений в виде отсутствия этих средств.
>>60039
>во время стрельбы персонаж бежит вперед и поворачивает ствол между выстрелами. Разве это должен быть один эмиттер? С разными тракеториями, исходной точкой, углом?
Снимаем галку Local Coords и не плодим сущности. Не смотрел, как это работает в 3д, я делаю в 2д, и это работает при любых перемещениях и поворотах ствола.
208 Кб, 1024x1022>>60112
Смирись, программирование - это само по себе костыль.
>Чем этот костыль лучше уже придуманных выше костылей
Смирись, программирование - это само по себе костыль.
77 Кб, 1085x460А как примерно в текстуру рендерить содержимое другой камеры?
Вот есть пара кубов и пара камер. Вторая камера смотрит на второй куб, они оба дочерние узлы вьюпорта.
На первом кубе создаю материал, в нем текстуру вьюпорта.. ?
Вот есть пара кубов и пара камер. Вторая камера смотрит на второй куб, они оба дочерние узлы вьюпорта.
На первом кубе создаю материал, в нем текстуру вьюпорта.. ?
>>60118
Я уже выбрал и использовал из костыльных решений наименее ресурсоёмкое: индивидуальные параметры для каждого оружия. И давно уже разрабатываю дальше. Вопрос был на тот случай, если не костыльное решение вообще существует, и его кто-то знает.
>Смирись
Я уже выбрал и использовал из костыльных решений наименее ресурсоёмкое: индивидуальные параметры для каждого оружия. И давно уже разрабатываю дальше. Вопрос был на тот случай, если не костыльное решение вообще существует, и его кто-то знает.
>>60120
Ну да. Как-то так. Там засада в том, что нужно вручную выставить размеры вьюпорта. Иначе размеры будут 0 на 0 и чорная текстура.
Ну да. Как-то так. Там засада в том, что нужно вручную выставить размеры вьюпорта. Иначе размеры будут 0 на 0 и чорная текстура.
>>60099
Братиш, на твоей планете не осталось никого, вали оттудова.
Братиш, на твоей планете не осталось никого, вали оттудова.
3 Мб, mp4,800x600, 0:50
Залез в старые видосы. Такая ностальгия. Трёшка - уже история.
11 Кб, 1056x480>>60276
не, те примеры слишком громоздкие и непонятные, что этот что с понгом
без них проще было разобраться)
не, те примеры слишком громоздкие и непонятные, что этот что с понгом
без них проще было разобраться)
AnimationTree оказалось гораздо легче, чем можно было предположить. Управление осуществляется буквально одной строчкой кода. Нужно потратить некоторое время на расстановку дерева, конечно, зато дальше оно работает само без каких-либо дополнительных плясок. Интерфейс прост в освоении и интуитивен. Немножко неожиданно ведёт себя только субнода Transition, которая на первый взгляд не делает вообще ничего, но на самом деле у неё просто проблемы с отрисовкой, её нужно дополнительно пнуть, чтобы она отрисовалась после изменений.
В общем, моё монструозное дерево из if'ов пошло под нож, вместо него теперь короткие обращения к дереву анимации. Я прям доволен. Пойду интерфейс пилить теперь.
В общем, моё монструозное дерево из if'ов пошло под нож, вместо него теперь короткие обращения к дереву анимации. Я прям доволен. Пойду интерфейс пилить теперь.
>>60649
Я не он, но вот моё дерево и вот моя стейтмашина.
Как видишь, дерево еле влезло на один экран, хотя там я заморочился со скоростью анимаций, без них на 4 ноды меньше было бы. В стейтмашине тоже можно заморочиться со скоростью, но щас я клепаю проект на ТВГ и там уже не до таких красивостей.
В общем, постигнув суть стейтмашин, я как-то отошёл от дерева. У него какие-то свои специфичные задачи. Стейтмашиной всё то же самое делается быстрее и компактнее.
Я не он, но вот моё дерево и вот моя стейтмашина.
Как видишь, дерево еле влезло на один экран, хотя там я заморочился со скоростью анимаций, без них на 4 ноды меньше было бы. В стейтмашине тоже можно заморочиться со скоростью, но щас я клепаю проект на ТВГ и там уже не до таких красивостей.
В общем, постигнув суть стейтмашин, я как-то отошёл от дерева. У него какие-то свои специфичные задачи. Стейтмашиной всё то же самое делается быстрее и компактнее.
>>60749
Вот как это делается:
В корневую стейтмашину вместо блендспейсов добавляешь бленддеревья, внутри котоых блендспейс и таймскейл. Получается дополнительный уровень вложенности, не критичный для кода. Всё равно пути один раз прописываешь в сеттере.
И всё, получается, легко и просто контролируешь скорость анимаций. Третья пикча показывает сравнение в инспекторе старого walk0, которое просто блендспейс и нового walk, которое теперь поддерево.
Ну и приблизительный код сеттера для нового дерева.
Вот как это делается:
В корневую стейтмашину вместо блендспейсов добавляешь бленддеревья, внутри котоых блендспейс и таймскейл. Получается дополнительный уровень вложенности, не критичный для кода. Всё равно пути один раз прописываешь в сеттере.
И всё, получается, легко и просто контролируешь скорость анимаций. Третья пикча показывает сравнение в инспекторе старого walk0, которое просто блендспейс и нового walk, которое теперь поддерево.
Ну и приблизительный код сеттера для нового дерева.
Че-то я опять туплю: как сделать в годо, чтобы все дальнейший действия проводились с указанным объектом? чтобы не писать каждый раз:
$'object'.a=$'object'.hz_func()
$'object'.do_something('object'.a)
$'object'.a=$'object'.hz_func()
$'object'.do_something('object'.a)
>>60906
Ты мне сейчас предлагаешь просто запихнуть $'object' в переменную some_object? Если да, то это абсолютно не то. Во многих языках существуют конструкции для доступа к разным областям видимости, и меня интересует, есть ли подобное в годо?
Ты мне сейчас предлагаешь просто запихнуть $'object' в переменную some_object? Если да, то это абсолютно не то. Во многих языках существуют конструкции для доступа к разным областям видимости, и меня интересует, есть ли подобное в годо?
>>60914
так он тебе и предлагает получить ссылку на объект один раз и работать уже по ее адресу, а не каждый раз заново ее получать
так он тебе и предлагает получить ссылку на объект один раз и работать уже по ее адресу, а не каждый раз заново ее получать
>>60916
Ясно, значит не совсем понял, сорь.
Ясно, значит не совсем понял, сорь.
13 Кб, 453x704>>60916
Нет, он хочет вот такое (я тоже это очень хочу): <картинка>
>так он тебе и предлагает получить ссылку на объект один раз и работать уже по ее адресу, а не каждый раз заново ее получать
Нет, он хочет вот такое (я тоже это очень хочу): <картинка>
>>60945
То был пример конструкции with <something> do ... на полноценном ЯП.
А так - вроде бы да, можно прикрутить с помощью GDNative, но я пока не пробовал.
>>60959
Первая картинка. Это позволяет пропустить указание типа, определив тип по присваиваемому значению.
Вторая картинка. Кавычки писать не нужно, сам $-синтаксис всего лишь сокращает запись get_node("").
Источник - https://docs.godotengine.org/en/stable/getting_started/scripting/gdscript/gdscript_basics.html
В принципе, писать так:
onready var button := $form/panel/button
button.text = "text"
Проще (и, возможно, оптимальнее), чем так:
$form/panel/button.text = "text"
Но в ряде случаев хотелось бы иметь with-сокращения как в Паскале (и других языках).
>Что? К годоте можно прикрутить паскаль?
То был пример конструкции with <something> do ... на полноценном ЯП.
А так - вроде бы да, можно прикрутить с помощью GDNative, но я пока не пробовал.
>>60959
>Смутили " := "
Первая картинка. Это позволяет пропустить указание типа, определив тип по присваиваемому значению.
>"$" без кавычек
Вторая картинка. Кавычки писать не нужно, сам $-синтаксис всего лишь сокращает запись get_node("").
Источник - https://docs.godotengine.org/en/stable/getting_started/scripting/gdscript/gdscript_basics.html
В принципе, писать так:
onready var button := $form/panel/button
button.text = "text"
Проще (и, возможно, оптимальнее), чем так:
$form/panel/button.text = "text"
Но в ряде случаев хотелось бы иметь with-сокращения как в Паскале (и других языках).
>>60965
Ой, все.
Я вообще хз, почему этого нет в годо. Это же гиперудобная вещь, и, если ее нет, то могли бы хоть добавить заменитель идентичный натуральному.
>В принципе, писать так:
>onready var button := $form/panel/button
>button.text = "text"
>Проще (и, возможно, оптимальнее), чем так:
>$form/panel/button.text = "text"
Ой, все.
>Но в ряде случаев хотелось бы иметь with-сокращения как в Паскале (и других языках).
Я вообще хз, почему этого нет в годо. Это же гиперудобная вещь, и, если ее нет, то могли бы хоть добавить заменитель идентичный натуральному.
>>60967
Согласен.
Решили не добавлять, потому что:
>>60968
(лолшто)
--> "сокращайте код ручками, лалки".
То есть если у меня класс в классе в классе, я должен ручками делать дополнительный метод в главном классе, который упрощает доступ к классу в классе в классе, чтобы сделать несколько таких обращений подряд? Понятное дело, что лучше так не делать, но а что если у меня длинные имена главного класса и длинные имена методов?
Всяко проще было бы сделать:
with EntityWhatDoesSomethingCool do
param1 = param2 # синхронизация внутренних параметров
Чем делать:
EntityWhatDoesSomethingCool.param1 = EntityWhatDoesSomethingCool.param2
Да даже если эта операция пишется в функции:
func sync_params_of_cool_slave_entity():
EntityWhatDoesSomethingCool.param1 = EntityWhatDoesSomethingCool.param2
Всё равно это выглядит отвратительно по сравнению с with.
Впрочем, ладно. Всегда можно прикрутить Паскаль отдельной DLL-кой...
>Я вообще хз, почему этого нет в годо. Это же гиперудобная вещь
Согласен.
>могли бы хоть добавить заменитель идентичный натуральному.
Решили не добавлять, потому что:
>>60968
>I don't think we'll implement any with statement in GDScript, as it is used in different languages for different things...
(лолшто)
>If you need with for a long block of code, it's a hint that this code should likely be placed in the script of that node, and replaced by a single function call in the parent node.
--> "сокращайте код ручками, лалки".
То есть если у меня класс в классе в классе, я должен ручками делать дополнительный метод в главном классе, который упрощает доступ к классу в классе в классе, чтобы сделать несколько таких обращений подряд? Понятное дело, что лучше так не делать, но а что если у меня длинные имена главного класса и длинные имена методов?
Всяко проще было бы сделать:
with EntityWhatDoesSomethingCool do
param1 = param2 # синхронизация внутренних параметров
Чем делать:
EntityWhatDoesSomethingCool.param1 = EntityWhatDoesSomethingCool.param2
Да даже если эта операция пишется в функции:
func sync_params_of_cool_slave_entity():
EntityWhatDoesSomethingCool.param1 = EntityWhatDoesSomethingCool.param2
Всё равно это выглядит отвратительно по сравнению с with.
Впрочем, ладно. Всегда можно прикрутить Паскаль отдельной DLL-кой...
>>60977
Я думаю, Хуан просто не хочет ебать себе мозг с проблемами пространств имён, которые неизбежно возникнут с with при таком-то наследовании.
Я думаю, Хуан просто не хочет ебать себе мозг с проблемами пространств имён, которые неизбежно возникнут с with при таком-то наследовании.
>>60979
В результате проблемами пространств имен ебу себе мозг я
В результате проблемами пространств имен ебу себе мозг я
>>60979
Если ты про такое:
with Player, Enemy do
Position = Position
Достаточно вывести ошибку парсинга:
[error] Position of wich class do you call?
Однако если у классов есть разные поля, то проблемы нет:
with Player, Enemy do
Target = Inventory.Position
Enemy имеет цель преследования Target, Player несёт в себе рюкзак-инвентарь на спине.
Ну, это абстрактный пример, трудно с ходу выдумать что-то реально полезное...
Если ты про такое:
with Player, Enemy do
Position = Position
Достаточно вывести ошибку парсинга:
[error] Position of wich class do you call?
Однако если у классов есть разные поля, то проблемы нет:
with Player, Enemy do
Target = Inventory.Position
Enemy имеет цель преследования Target, Player несёт в себе рюкзак-инвентарь на спине.
Ну, это абстрактный пример, трудно с ходу выдумать что-то реально полезное...
>>60965
Но... на полноценном языке, то есть на си и его потомках нет такой функции. А паскаль для школьников не полноценный язык. Даже автор паскаля от него отказался и перешёл на си-шарп.
> with <something> do … на полноценном ЯП.
Но... на полноценном языке, то есть на си и его потомках нет такой функции. А паскаль для школьников не полноценный язык. Даже автор паскаля от него отказался и перешёл на си-шарп.
>>60984
Это абстрактный пример, но он прекрасно иллюстрирует, почему в настоящем языке (Си, повторюсь) от этой конструкции отказались. Срачом на эту тему форумы забиты с 90х годов, не вижу смысла пересказывать, иди гугли сам, раз вышел из криостаза только в этом году.
Хочешь сокращать? Пожалуйста:
var p = $my/long/player/node/path
var e = $my/long/enemy/node/path
var i = $my/long/player/node/path/inventory
e.position = p.position
e.target = i.position
Так делают сишники, настоящие программисты на настоящем языке программирования, а не на учебном.
Это абстрактный пример, но он прекрасно иллюстрирует, почему в настоящем языке (Си, повторюсь) от этой конструкции отказались. Срачом на эту тему форумы забиты с 90х годов, не вижу смысла пересказывать, иди гугли сам, раз вышел из криостаза только в этом году.
Хочешь сокращать? Пожалуйста:
var p = $my/long/player/node/path
var e = $my/long/enemy/node/path
var i = $my/long/player/node/path/inventory
e.position = p.position
e.target = i.position
Так делают сишники, настоящие программисты на настоящем языке программирования, а не на учебном.
>>60989
Теперь понятно, почему код на C-подобных языках настолько уродлив.
Чтобы не разводить срач, GDScript предназначен для школьников/студентов/дизайнеров, если хочешь обмазываться своим C++ - пиши на C++, никто тебе не мешает, а GDScript нужен для быстрого прототипирования без особых познаний в программировании и всего такого, и я не вижу смысла пилить неудобные однобуквенные костыли там, где можно было бы воспользоваться мощным оператором удобного языка. Между прочим, C++ - это и есть мусорка из "мощных операторов", с каждым годом количество операторов удваивается, каждая задача одинаково решаема десятком разных операторов. Так что не сравнивай.
Алсо, по-моему у тебя бомбануло, потому что в твоём языке with нет, а в моём - есть.
>однобуквенные переменные повсюду
>Так делают сишники
Теперь понятно, почему код на C-подобных языках настолько уродлив.
Чтобы не разводить срач, GDScript предназначен для школьников/студентов/дизайнеров, если хочешь обмазываться своим C++ - пиши на C++, никто тебе не мешает, а GDScript нужен для быстрого прототипирования без особых познаний в программировании и всего такого, и я не вижу смысла пилить неудобные однобуквенные костыли там, где можно было бы воспользоваться мощным оператором удобного языка. Между прочим, C++ - это и есть мусорка из "мощных операторов", с каждым годом количество операторов удваивается, каждая задача одинаково решаема десятком разных операторов. Так что не сравнивай.
Алсо, по-моему у тебя бомбануло, потому что в твоём языке with нет, а в моём - есть.
>>60995
про плюсы согласен, что развиваются куда-то не туда
про gdscript, как раз для прототипирования геймдизами или художниками он тоже плох, постоянно плюются, особенно с значащими отступами
мимо другой анон
про плюсы согласен, что развиваются куда-то не туда
про gdscript, как раз для прототипирования геймдизами или художниками он тоже плох, постоянно плюются, особенно с значащими отступами
мимо другой анон
>>60995
Ага, у меня бомбит от того, что 99% софта написано на си/си++. Конечно. А у тебя НЕБОМБИТ! Твёрдо и чотко!
> по-моему у тебя бомбануло
Ага, у меня бомбит от того, что 99% софта написано на си/си++. Конечно. А у тебя НЕБОМБИТ! Твёрдо и чотко!
>>60995
В однобуквенных переменных нет ничего плохого, когда речь идет об алгоритмах и математике, а код на С-подобных языках благодаря им выглядить компактно и аккуратно.
Прописывать полностью каждый раз имя, иерархию и тип приходится только на всяких маргинальных языках без типизации и нормальной поддержки IDE.
В самом деле, если идет в цикле работа с врагами, его логичнее называть e., чем каждый раз enemy., а че сразу не писать enemy_from_array_of_active_enemies. ?
В однобуквенных переменных нет ничего плохого, когда речь идет об алгоритмах и математике, а код на С-подобных языках благодаря им выглядить компактно и аккуратно.
Прописывать полностью каждый раз имя, иерархию и тип приходится только на всяких маргинальных языках без типизации и нормальной поддержки IDE.
В самом деле, если идет в цикле работа с врагами, его логичнее называть e., чем каждый раз enemy., а че сразу не писать enemy_from_array_of_active_enemies. ?
>>61005
Причина бомбления очевидна: ты юзаешь ЯП только из-за его популярности, а я юзаю ЯП, который мне по нраву.
>>61000
Ну фиг знает, значащие отступы приучают человека писать хорошо читаемый визуально код.
Скажем так, конструкция
if (something) {
action1;
action2;
} else {
action3;
action4;
}
читается намного хуже, чем
if (something) {
_ action1;
_ action2;
} else {
_ action3;
_ action4;
}
А уж без программных скобок вообще не было бы ясно, что к чему относится.
Поэтому синтаксис GDScript в целом лучше для восприятия, чем у классических ЯП.
>>61009
Какое отношение 100500 примеров других языков имеют к GDScript? Я об этом.
>>61010
Только если это абстрактный алгоритм для обработки чего-либо абстрактного, как в математике.
Ты дважды ошибся, пытаясь написать "нечитабельно". Сишники и функции 2-3 буквами обзывают.
Это когда речь идёт о написании кода. Каким образом IDE может помочь тебе в чтении написанного?
В цикле ещё ладно, но только если этот цикл занимает одну строчку, а не несколько экранов.
А так, "e" может быть и entity, и element, и ещё куча всякого. Написав строчку вида
for e in get_children():
уже на следующей строке можно забыть о том, что e - это enemy, а не какая-то там entity.
А уж что говорить о том, когда ты вернёшься к этой e через недельку/месяц/год... Особенно, если это не твоя e.
>Ага, у меня бомбит от того, что 99% софта написано на си/си++. Конечно. А у тебя НЕБОМБИТ! Твёрдо и чотко!
Причина бомбления очевидна: ты юзаешь ЯП только из-за его популярности, а я юзаю ЯП, который мне по нраву.
>>61000
>геймдизами или художниками он тоже плох, постоянно плюются, особенно с значащими отступами
Ну фиг знает, значащие отступы приучают человека писать хорошо читаемый визуально код.
Скажем так, конструкция
if (something) {
action1;
action2;
} else {
action3;
action4;
}
читается намного хуже, чем
if (something) {
_ action1;
_ action2;
} else {
_ action3;
_ action4;
}
А уж без программных скобок вообще не было бы ясно, что к чему относится.
Поэтому синтаксис GDScript в целом лучше для восприятия, чем у классических ЯП.
>>61009
>Там потом 100500 примеров из разных языков и действительно везде свои нюансы.
Какое отношение 100500 примеров других языков имеют к GDScript? Я об этом.
>>61010
>В однобуквенных переменных нет ничего плохого, когда речь идет об алгоритмах и математике
Только если это абстрактный алгоритм для обработки чего-либо абстрактного, как в математике.
>код на С-подобных языках благодаря им выглядить компактно и аккуратно
Ты дважды ошибся, пытаясь написать "нечитабельно". Сишники и функции 2-3 буквами обзывают.
>Прописывать полностью каждый раз имя, иерархию и тип приходится только на всяких маргинальных языках без типизации и нормальной поддержки IDE.
Это когда речь идёт о написании кода. Каким образом IDE может помочь тебе в чтении написанного?
>В самом деле, если идет в цикле работа с врагами, его логичнее называть e., чем каждый раз enemy., а че сразу не писать enemy_from_array_of_active_enemies. ?
В цикле ещё ладно, но только если этот цикл занимает одну строчку, а не несколько экранов.
А так, "e" может быть и entity, и element, и ещё куча всякого. Написав строчку вида
for e in get_children():
уже на следующей строке можно забыть о том, что e - это enemy, а не какая-то там entity.
А уж что говорить о том, когда ты вернёшься к этой e через недельку/месяц/год... Особенно, если это не твоя e.
>>61005
Причина бомбления очевидна: ты юзаешь ЯП только из-за его популярности, а я юзаю ЯП, который мне по нраву.
>>61000
Ну фиг знает, значащие отступы приучают человека писать хорошо читаемый визуально код.
Скажем так, конструкция
if (something) {
action1;
action2;
} else {
action3;
action4;
}
читается намного хуже, чем
if (something) {
_ action1;
_ action2;
} else {
_ action3;
_ action4;
}
А уж без программных скобок вообще не было бы ясно, что к чему относится.
Поэтому синтаксис GDScript в целом лучше для восприятия, чем у классических ЯП.
>>61009
Какое отношение 100500 примеров других языков имеют к GDScript? Я об этом.
>>61010
Только если это абстрактный алгоритм для обработки чего-либо абстрактного, как в математике.
Ты дважды ошибся, пытаясь написать "нечитабельно". Сишники и функции 2-3 буквами обзывают.
Это когда речь идёт о написании кода. Каким образом IDE может помочь тебе в чтении написанного?
В цикле ещё ладно, но только если этот цикл занимает одну строчку, а не несколько экранов.
А так, "e" может быть и entity, и element, и ещё куча всякого. Написав строчку вида
for e in get_children():
уже на следующей строке можно забыть о том, что e - это enemy, а не какая-то там entity.
А уж что говорить о том, когда ты вернёшься к этой e через недельку/месяц/год... Особенно, если это не твоя e.
>Ага, у меня бомбит от того, что 99% софта написано на си/си++. Конечно. А у тебя НЕБОМБИТ! Твёрдо и чотко!
Причина бомбления очевидна: ты юзаешь ЯП только из-за его популярности, а я юзаю ЯП, который мне по нраву.
>>61000
>геймдизами или художниками он тоже плох, постоянно плюются, особенно с значащими отступами
Ну фиг знает, значащие отступы приучают человека писать хорошо читаемый визуально код.
Скажем так, конструкция
if (something) {
action1;
action2;
} else {
action3;
action4;
}
читается намного хуже, чем
if (something) {
_ action1;
_ action2;
} else {
_ action3;
_ action4;
}
А уж без программных скобок вообще не было бы ясно, что к чему относится.
Поэтому синтаксис GDScript в целом лучше для восприятия, чем у классических ЯП.
>>61009
>Там потом 100500 примеров из разных языков и действительно везде свои нюансы.
Какое отношение 100500 примеров других языков имеют к GDScript? Я об этом.
>>61010
>В однобуквенных переменных нет ничего плохого, когда речь идет об алгоритмах и математике
Только если это абстрактный алгоритм для обработки чего-либо абстрактного, как в математике.
>код на С-подобных языках благодаря им выглядить компактно и аккуратно
Ты дважды ошибся, пытаясь написать "нечитабельно". Сишники и функции 2-3 буквами обзывают.
>Прописывать полностью каждый раз имя, иерархию и тип приходится только на всяких маргинальных языках без типизации и нормальной поддержки IDE.
Это когда речь идёт о написании кода. Каким образом IDE может помочь тебе в чтении написанного?
>В самом деле, если идет в цикле работа с врагами, его логичнее называть e., чем каждый раз enemy., а че сразу не писать enemy_from_array_of_active_enemies. ?
В цикле ещё ладно, но только если этот цикл занимает одну строчку, а не несколько экранов.
А так, "e" может быть и entity, и element, и ещё куча всякого. Написав строчку вида
for e in get_children():
уже на следующей строке можно забыть о том, что e - это enemy, а не какая-то там entity.
А уж что говорить о том, когда ты вернёшься к этой e через недельку/месяц/год... Особенно, если это не твоя e.
>>61012
Вот только это делается в IDE автоформатированием, а значащие отступы - это мина замедленного действия.
> отступы приучают человека писать хорошо читаемый визуально код.
Вот только это делается в IDE автоформатированием, а значащие отступы - это мина замедленного действия.
>>61018
Согласен, если ты часто делаешь случайные нажатия на клавиатуре или рандомно правишь код в Блокноте.
Я бы предпочёл обязательные отступы + программные скобки begin..end, но хомячки не обрадуются писать лишние символы.
>мина замедленного действия
Согласен, если ты часто делаешь случайные нажатия на клавиатуре или рандомно правишь код в Блокноте.
Я бы предпочёл обязательные отступы + программные скобки begin..end, но хомячки не обрадуются писать лишние символы.
>>61023
Люто двачаю.
Вторая проблема этих отступов - нельзя просто так взять и обрамить готовый кусок кода дополнительным if'ом, например. Скажем, проверкой на состояние здоровья. Да, в годоте можно выделить текст и нажать tab; но это костыль. Плюс табуляции занимают много места на экране, я бы предпочёл пробелы.
И ещё очень печалит отсутствие комментариев вида / .. / - чтобы быстро закомментировать и раскомментировать блоки кода.
Воспитанием должны заниматься родители. Ну, или хотя бы учителя. Когда взрослый человек берётся самостоятельно заниматься чем-то, предполагается, что он уже приучен ко всяким таким вещам, типа не гадить под себя.
>Я бы предпочёл обязательные отступы + программные скобки begin..end, но хомячки не обрадуются писать лишние символы.
Люто двачаю.
Вторая проблема этих отступов - нельзя просто так взять и обрамить готовый кусок кода дополнительным if'ом, например. Скажем, проверкой на состояние здоровья. Да, в годоте можно выделить текст и нажать tab; но это костыль. Плюс табуляции занимают много места на экране, я бы предпочёл пробелы.
И ещё очень печалит отсутствие комментариев вида / .. / - чтобы быстро закомментировать и раскомментировать блоки кода.
>значащие отступы приучают человека
Воспитанием должны заниматься родители. Ну, или хотя бы учителя. Когда взрослый человек берётся самостоятельно заниматься чем-то, предполагается, что он уже приучен ко всяким таким вещам, типа не гадить под себя.
>>61023
Да даже не случайные. Можно сказать что вообще все ошибки совершаются случайно )
Я тоже предпочитаю обязательные отступы + скобки, сишные компиляторы выдают предупреждение (а при флаге warning as errors - ошибку) на плохое форматирование, в случаях типа
if(c)
foo();
bar();
Но при этом я не хочу чтобы пробелы были значащими символами.
Да даже не случайные. Можно сказать что вообще все ошибки совершаются случайно )
Я тоже предпочитаю обязательные отступы + скобки, сишные компиляторы выдают предупреждение (а при флаге warning as errors - ошибку) на плохое форматирование, в случаях типа
if(c)
foo();
bar();
Но при этом я не хочу чтобы пробелы были значащими символами.
5 Кб, 806x269>>61028
Я обычно код пишу в PS Pad, тут для отступов есть ctrl+shift+I (вправо) и ctrl+shift+U (влево), мне удобно. Да и в любом другом редакторе, заточенном под кодинг, скорее всего будут аналогичные "костыли". Ты ж всё равно будешь вынужден отступы добавлять, даже если они чисто декоративные, если только пишешь не на Форте в одну строчку. Да, есть автоформатирование, но это точно такой же костыль, придуманный для того, чтобы облегчать работу над стилем кода, тогда как стиль кода сам по себе костыль, призванный облегчить чтение кода... >>60118
Это всё настраивается (картинка). Ширина табов, кстати, настраивается во многих текстовых редакторах.
Есть функция IDE для этого (шорткат ctrl+k вроде бы), но да, это тоже костыль получается)
Родители-программисты и учителя информатики? Возможно, но не всем так повезло.
Когда только учишься программировать, не понимаешь многих вещей, связанных с чистотой кода и стандартными практиками. Если бы всё было так просто, никто бы не говорил об "антипаттернах", а теория программирования не развивалась за последние полвека. Если бы можно было кодить прямо на живом русском (английском) языке, тогда, возможно, для программирования достаточно было бы уметь говорить, но пока мы кодим на искусственных языках, нам недостаточно знать используемый язык - приходится овладевать определёнными навыками и изучать то, до чего своим умом доходишь спустя годы досадных ошибок.
Поэтому, имхо, транслятор кода, понятно объясняющий/комментирующий большинство очевидных ошибок, всегда лучше транслятора, который съедает любой валидный код, никак не помогая найти ошибки, связанные с неопытностью пишущего этот код. Пусть лучше транслятор приучает, чем вообще никто.
>нельзя просто так взять и обрамить готовый кусок кода дополнительным if'ом, например
>Да, в годоте можно выделить текст и нажать tab; но это костыль
Я обычно код пишу в PS Pad, тут для отступов есть ctrl+shift+I (вправо) и ctrl+shift+U (влево), мне удобно. Да и в любом другом редакторе, заточенном под кодинг, скорее всего будут аналогичные "костыли". Ты ж всё равно будешь вынужден отступы добавлять, даже если они чисто декоративные, если только пишешь не на Форте в одну строчку. Да, есть автоформатирование, но это точно такой же костыль, придуманный для того, чтобы облегчать работу над стилем кода, тогда как стиль кода сам по себе костыль, призванный облегчить чтение кода... >>60118
>Плюс табуляции занимают много места на экране, я бы предпочёл пробелы.
Это всё настраивается (картинка). Ширина табов, кстати, настраивается во многих текстовых редакторах.
>чтобы быстро закомментировать и раскомментировать блоки кода.
Есть функция IDE для этого (шорткат ctrl+k вроде бы), но да, это тоже костыль получается)
>Воспитанием должны заниматься родители. Ну, или хотя бы учителя
Родители-программисты и учителя информатики? Возможно, но не всем так повезло.
>предполагается, что он уже приучен ко всяким таким вещам, типа не гадить под себя
Когда только учишься программировать, не понимаешь многих вещей, связанных с чистотой кода и стандартными практиками. Если бы всё было так просто, никто бы не говорил об "антипаттернах", а теория программирования не развивалась за последние полвека. Если бы можно было кодить прямо на живом русском (английском) языке, тогда, возможно, для программирования достаточно было бы уметь говорить, но пока мы кодим на искусственных языках, нам недостаточно знать используемый язык - приходится овладевать определёнными навыками и изучать то, до чего своим умом доходишь спустя годы досадных ошибок.
Поэтому, имхо, транслятор кода, понятно объясняющий/комментирующий большинство очевидных ошибок, всегда лучше транслятора, который съедает любой валидный код, никак не помогая найти ошибки, связанные с неопытностью пишущего этот код. Пусть лучше транслятор приучает, чем вообще никто.
5 Кб, 806x269>>61028
Я обычно код пишу в PS Pad, тут для отступов есть ctrl+shift+I (вправо) и ctrl+shift+U (влево), мне удобно. Да и в любом другом редакторе, заточенном под кодинг, скорее всего будут аналогичные "костыли". Ты ж всё равно будешь вынужден отступы добавлять, даже если они чисто декоративные, если только пишешь не на Форте в одну строчку. Да, есть автоформатирование, но это точно такой же костыль, придуманный для того, чтобы облегчать работу над стилем кода, тогда как стиль кода сам по себе костыль, призванный облегчить чтение кода... >>60118
Это всё настраивается (картинка). Ширина табов, кстати, настраивается во многих текстовых редакторах.
Есть функция IDE для этого (шорткат ctrl+k вроде бы), но да, это тоже костыль получается)
Родители-программисты и учителя информатики? Возможно, но не всем так повезло.
Когда только учишься программировать, не понимаешь многих вещей, связанных с чистотой кода и стандартными практиками. Если бы всё было так просто, никто бы не говорил об "антипаттернах", а теория программирования не развивалась за последние полвека. Если бы можно было кодить прямо на живом русском (английском) языке, тогда, возможно, для программирования достаточно было бы уметь говорить, но пока мы кодим на искусственных языках, нам недостаточно знать используемый язык - приходится овладевать определёнными навыками и изучать то, до чего своим умом доходишь спустя годы досадных ошибок.
Поэтому, имхо, транслятор кода, понятно объясняющий/комментирующий большинство очевидных ошибок, всегда лучше транслятора, который съедает любой валидный код, никак не помогая найти ошибки, связанные с неопытностью пишущего этот код. Пусть лучше транслятор приучает, чем вообще никто.
>нельзя просто так взять и обрамить готовый кусок кода дополнительным if'ом, например
>Да, в годоте можно выделить текст и нажать tab; но это костыль
Я обычно код пишу в PS Pad, тут для отступов есть ctrl+shift+I (вправо) и ctrl+shift+U (влево), мне удобно. Да и в любом другом редакторе, заточенном под кодинг, скорее всего будут аналогичные "костыли". Ты ж всё равно будешь вынужден отступы добавлять, даже если они чисто декоративные, если только пишешь не на Форте в одну строчку. Да, есть автоформатирование, но это точно такой же костыль, придуманный для того, чтобы облегчать работу над стилем кода, тогда как стиль кода сам по себе костыль, призванный облегчить чтение кода... >>60118
>Плюс табуляции занимают много места на экране, я бы предпочёл пробелы.
Это всё настраивается (картинка). Ширина табов, кстати, настраивается во многих текстовых редакторах.
>чтобы быстро закомментировать и раскомментировать блоки кода.
Есть функция IDE для этого (шорткат ctrl+k вроде бы), но да, это тоже костыль получается)
>Воспитанием должны заниматься родители. Ну, или хотя бы учителя
Родители-программисты и учителя информатики? Возможно, но не всем так повезло.
>предполагается, что он уже приучен ко всяким таким вещам, типа не гадить под себя
Когда только учишься программировать, не понимаешь многих вещей, связанных с чистотой кода и стандартными практиками. Если бы всё было так просто, никто бы не говорил об "антипаттернах", а теория программирования не развивалась за последние полвека. Если бы можно было кодить прямо на живом русском (английском) языке, тогда, возможно, для программирования достаточно было бы уметь говорить, но пока мы кодим на искусственных языках, нам недостаточно знать используемый язык - приходится овладевать определёнными навыками и изучать то, до чего своим умом доходишь спустя годы досадных ошибок.
Поэтому, имхо, транслятор кода, понятно объясняющий/комментирующий большинство очевидных ошибок, всегда лучше транслятора, который съедает любой валидный код, никак не помогая найти ошибки, связанные с неопытностью пишущего этот код. Пусть лучше транслятор приучает, чем вообще никто.
>>61039
Для обучения существуют учебники, гайды и мануалы. Язык - это инструмент для выполнения работы, а не обучения. Автомобиль тебя ведь не учит ПДД и не учит манерам поведения на дороге, он просто едет туда, куда ты его ведёшь; ведёшь неправильно - твои проблемы. Представь, что автомобиль отказывается поворачивать колёса, если выключен поворотник; по учебной площадке на таком автомобиле ездить можно, однако в город на нём лучше не соваться.
Язык не должен ничего тебе объяснять, он должен просто работать. Не понимаешь - пиздуй в поиск. Особенно когда только учишься.
Хотя да, наверное, я сужу с позиции человека, который умеет учиться. Многие не умеют и всячески сопротивляются.
>Когда только учишься программировать, не понимаешь многих вещей
Для обучения существуют учебники, гайды и мануалы. Язык - это инструмент для выполнения работы, а не обучения. Автомобиль тебя ведь не учит ПДД и не учит манерам поведения на дороге, он просто едет туда, куда ты его ведёшь; ведёшь неправильно - твои проблемы. Представь, что автомобиль отказывается поворачивать колёса, если выключен поворотник; по учебной площадке на таком автомобиле ездить можно, однако в город на нём лучше не соваться.
Язык не должен ничего тебе объяснять, он должен просто работать. Не понимаешь - пиздуй в поиск. Особенно когда только учишься.
Хотя да, наверное, я сужу с позиции человека, который умеет учиться. Многие не умеют и всячески сопротивляются.
https://godotengine.org/article/godot-getting-more-languages
Фрипаскаль пасасал с нативными векторами. В math есть какое-то говно из 70х, не имеющее 90% функционала. То есть, либо велосипедить, либо брать из имеющихся готовых модулей для фрипаскаля.
Какой язык ни пытайся добавить в годо - знание си обязательно.
Титанический, монотонный труд, который Хуаном для си автоматизирован (есть готовые заголовки) - остальные ебитес как хотите.
Основной титанический труд по добавлению связки фрипаскаля с редактором. Если предполагается кодить в лазаре - этот пункт можно пропустить.
>Re-create Godot's basic types in your new language: These are types such as Vector3, int, float, String, etc. Many of these are usually provided already.
Фрипаскаль пасасал с нативными векторами. В math есть какое-то говно из 70х, не имеющее 90% функционала. То есть, либо велосипедить, либо брать из имеющихся готовых модулей для фрипаскаля.
>Create a module: A C++ module that creates binding code needs to be done (creating modules in C++ is well documented). The entire exposed Godot API can be accessed via the static functions in ObjectTypeDB.
Какой язык ни пытайся добавить в годо - знание си обязательно.
>Generate binding code in your new language that accesses the exposed functions in the MethodBind class (there is one for each exposed method).
Титанический, монотонный труд, который Хуаном для си автоматизирован (есть готовые заголовки) - остальные ебитес как хотите.
>Create a ScriptLanguage class and supply the neccesary methods exposed for debugging, profiling, etc. You can supply symbols, code completion helpers, etc. if this language is meant to be edited inside Godot.
Основной титанический труд по добавлению связки фрипаскаля с редактором. Если предполагается кодить в лазаре - этот пункт можно пропустить.
Чёт я не очень понимаю с интерфейсом. Разве зелёные ноды не должны перемещаться вместе с камерой? Ни в одном туториале нет перемещающейся камеры, но из контекста вроде следует, что должны; да и для чего тогда они вообще нужны. А у меня почему-то они намертво прилеплены к картинке уровня. Хотя иерархия нод такая:
-Игра
--Интерфейс
--Уровень
Читаю оф. мануалы и не могу вкурить, нигде про это ничего не говорится.
-Игра
--Интерфейс
--Уровень
Читаю оф. мануалы и не могу вкурить, нигде про это ничего не говорится.
>>61089
Что мешает регекспом конвертнуть? Или по api.json сгенерировать. Или по файлу который для моно генерится.
> >Generate binding code in your new language that accesses the exposed functions in the MethodBind class (there is one for each exposed method).
> Титанический, монотонный труд, который Хуаном для си автоматизирован (есть готовые заголовки) - остальные ебитес как хотите.
Что мешает регекспом конвертнуть? Или по api.json сгенерировать. Или по файлу который для моно генерится.
>>61103
Не совсем так, но для простоты - да.
Например, делаем как на картинке:
UI - это все твое дерево интерфейса. Можно сделать в виде узла control, в которое засунешь весь необходимый интерфейс данного состояния игры.
player - это просто камера, на которую навешен простейший скрипт движения на кнопки влево/вправо (без дублирования на кнопки AD), скрипт на третьем пике
Есть твоя загружаемая сцена уровня, которую меняешь. Сейчас это просто Меш кубика, который окрашен.
Запускаем - нажимаем кнопки, камера перемещается в пространстве, UI "вместе с ней", сцена на месте (первые две картинки)
> Разве зелёные ноды не должны перемещаться вместе с камерой
Не совсем так, но для простоты - да.
Например, делаем как на картинке:
UI - это все твое дерево интерфейса. Можно сделать в виде узла control, в которое засунешь весь необходимый интерфейс данного состояния игры.
player - это просто камера, на которую навешен простейший скрипт движения на кнопки влево/вправо (без дублирования на кнопки AD), скрипт на третьем пике
Есть твоя загружаемая сцена уровня, которую меняешь. Сейчас это просто Меш кубика, который окрашен.
Запускаем - нажимаем кнопки, камера перемещается в пространстве, UI "вместе с ней", сцена на месте (первые две картинки)
>>61109
Забыл сказать, что речь идёт про 2D.
Проблема была в том, что камера масштабирует всю сцену вместе с интерфейсом (HUDом). И перемещается по всей сцене и по интерфейсу. Если интерфейс сделать потомком камеры, он будет перемещаться вместе с игроком (потому что камера - потомок игрока), но не с камерой (потому что у камеры есть всякие плюшки типа смуфинга и драг маргинов).
Решение нашлось. Нигде (НИГДЕ) об этом прямым текстом не говорится. Все туториалы рассматривают либо перемещаемую камеру без интерфейса, либо интерфейс в неподвижной сцене. Итак, решение: интерфейс надо делать потомком CanvasLayer'а. Тогда он адекватно масштабируется и размещается в правильном месте. При этом сам канваслой у меня никак не связан ни с персонажем, ни с уровнем.
Такие дела. Всю ночь тыкался в поисках ответа, только под утро наконец нашёл.
Забыл сказать, что речь идёт про 2D.
Проблема была в том, что камера масштабирует всю сцену вместе с интерфейсом (HUDом). И перемещается по всей сцене и по интерфейсу. Если интерфейс сделать потомком камеры, он будет перемещаться вместе с игроком (потому что камера - потомок игрока), но не с камерой (потому что у камеры есть всякие плюшки типа смуфинга и драг маргинов).
Решение нашлось. Нигде (НИГДЕ) об этом прямым текстом не говорится. Все туториалы рассматривают либо перемещаемую камеру без интерфейса, либо интерфейс в неподвижной сцене. Итак, решение: интерфейс надо делать потомком CanvasLayer'а. Тогда он адекватно масштабируется и размещается в правильном месте. При этом сам канваслой у меня никак не связан ни с персонажем, ни с уровнем.
Такие дела. Всю ночь тыкался в поисках ответа, только под утро наконец нашёл.
>>61111
Ну да, для 2D можно сделать также почти как с 3D, с некоторыми отличиями: например, да, засунуть UI в отдельный CanvasLayer, также поставить самой камере галку в поле current, что она будет текущей камерой.
Ну да, для 2D можно сделать также почти как с 3D, с некоторыми отличиями: например, да, засунуть UI в отдельный CanvasLayer, также поставить самой камере галку в поле current, что она будет текущей камерой.
>>61115
Ок, ушел
Ок, ушел
>>61071
Некоторые вещи можно понять только на практике. Кратковременная память человека очень ограничена.
Автомобиль не взлетает в воздух, когда ты нечаянно дёргаешь руль на себя, и не трансформируется внезапно в самолёт, когда в бак заливается керосин вместо бензина. У реального автомобиля есть жёсткие ограничения - хотя бы тот же ограниченный поворот руля, не позволяющий вертеть его бесконечно долго - тогда как типичный транслятор позволяет совершать намного более жуткие вещи, чем банальный и предсказуемый наезд на пешехода. Транслятор как волшебная палочка, может сделать что угодно, в том числе совсем не то, что ты от него ожидал, особенно если инструкция частично утрачена (не написана).
Умный автомобиль будет включать поворотник при повороте руля. Хотя я не знаю тонкостей ПДД, может, так нельзя...
Дарю тебе сведения о языке программирования Forth. Он просто работает. Всё, что он умеет - это выполнять инструкции, которые ты ему даёшь. Если инструкция выполнилась, он пишет ok. Если stack overflow или underflow, он пишет соответствующее сообщение. Если он не нашёл в словаре твоё слово, он пишет, что слово not found. Ещё может писать division by zero, допустим. Всё остальное зависит исключительно от тебя, и если ты что-нибудь нечаянно сломаешь - а ты обязательно что-нибудь сломаешь - всё рухнет и последствия придётся разгребать именно тебе, в одиночку. То есть ты можешь сделать на Forth всё, что можешь себе вообразить, и никаких встроенных проверок на безопасность и корректность кода тут нет и быть не может; код на Forth - это просто слова, разделённые пробелами, как этот текст (он может быть корректной программой на Forth/Forth-подобном языке). Много людей программирует на Forth? А вот нифига. Потому что все любят, когда кто-нибудь указывает на их ошибки, а не взрывается столпом искр и останавливается до тех пор, пока код не будет изменён на что-нибудь другое. А вот Ada - почему Ada сокращает время отладки на 80%? Потому что она заранее предотвращает твои ошибки, и тебе труднее выстрелить себе в ногу. Язык не должен слепо выполнять твои команды, если это не низкоуровневый язык типа Ассемблера, язык должен упрощать твою работу.
>>61089
В чём проблема написать самому? TVector2, TVector3. Можно в точности повторить функционал из GDScript.
Что-то я не понял, биндинг ведь через DLL идёт, не?.. Ааа, понял, это DLL-ку нужно биндить к Godot, а не Godot к DLL-ке. Лол. Ну ладно, Си - это как Паскаль, только со {скобочками}. Не даром же Паскаль создавался для обучения программированию на Си. В крайнем случае можно скопипастить...
ctrl+c/ctrl+v в основном? В остальном только заголовки функций поправить и типы в аргументах?
Ты меня будто на слабо вызываешь. Но, если честно, не так уж мне хочется делать игры...
>>61109 >>61112
Почему такая разница между 3D/2D? Я думал, логика построения сцены должна быть одинаковой. Что делает CanvasLayer?
>Для обучения существуют учебники, гайды и мануалы
Некоторые вещи можно понять только на практике. Кратковременная память человека очень ограничена.
>Автомобиль ... просто едет туда, куда ты его ведёшь
Автомобиль не взлетает в воздух, когда ты нечаянно дёргаешь руль на себя, и не трансформируется внезапно в самолёт, когда в бак заливается керосин вместо бензина. У реального автомобиля есть жёсткие ограничения - хотя бы тот же ограниченный поворот руля, не позволяющий вертеть его бесконечно долго - тогда как типичный транслятор позволяет совершать намного более жуткие вещи, чем банальный и предсказуемый наезд на пешехода. Транслятор как волшебная палочка, может сделать что угодно, в том числе совсем не то, что ты от него ожидал, особенно если инструкция частично утрачена (не написана).
>Представь, что автомобиль отказывается поворачивать колёса, если выключен поворотник
Умный автомобиль будет включать поворотник при повороте руля. Хотя я не знаю тонкостей ПДД, может, так нельзя...
>Язык не должен ничего тебе объяснять, он должен просто работать
Дарю тебе сведения о языке программирования Forth. Он просто работает. Всё, что он умеет - это выполнять инструкции, которые ты ему даёшь. Если инструкция выполнилась, он пишет ok. Если stack overflow или underflow, он пишет соответствующее сообщение. Если он не нашёл в словаре твоё слово, он пишет, что слово not found. Ещё может писать division by zero, допустим. Всё остальное зависит исключительно от тебя, и если ты что-нибудь нечаянно сломаешь - а ты обязательно что-нибудь сломаешь - всё рухнет и последствия придётся разгребать именно тебе, в одиночку. То есть ты можешь сделать на Forth всё, что можешь себе вообразить, и никаких встроенных проверок на безопасность и корректность кода тут нет и быть не может; код на Forth - это просто слова, разделённые пробелами, как этот текст (он может быть корректной программой на Forth/Forth-подобном языке). Много людей программирует на Forth? А вот нифига. Потому что все любят, когда кто-нибудь указывает на их ошибки, а не взрывается столпом искр и останавливается до тех пор, пока код не будет изменён на что-нибудь другое. А вот Ada - почему Ada сокращает время отладки на 80%? Потому что она заранее предотвращает твои ошибки, и тебе труднее выстрелить себе в ногу. Язык не должен слепо выполнять твои команды, если это не низкоуровневый язык типа Ассемблера, язык должен упрощать твою работу.
>>61089
>Фрипаскаль пасасал с нативными векторами
В чём проблема написать самому? TVector2, TVector3. Можно в точности повторить функционал из GDScript.
>Какой язык ни пытайся добавить в годо - знание си обязательно.
Что-то я не понял, биндинг ведь через DLL идёт, не?.. Ааа, понял, это DLL-ку нужно биндить к Godot, а не Godot к DLL-ке. Лол. Ну ладно, Си - это как Паскаль, только со {скобочками}. Не даром же Паскаль создавался для обучения программированию на Си. В крайнем случае можно скопипастить...
>Титанический, монотонный труд
ctrl+c/ctrl+v в основном? В остальном только заголовки функций поправить и типы в аргументах?
>титанический труд
Ты меня будто на слабо вызываешь. Но, если честно, не так уж мне хочется делать игры...
>>61109 >>61112
Почему такая разница между 3D/2D? Я думал, логика построения сцены должна быть одинаковой. Что делает CanvasLayer?
>>61071
Некоторые вещи можно понять только на практике. Кратковременная память человека очень ограничена.
Автомобиль не взлетает в воздух, когда ты нечаянно дёргаешь руль на себя, и не трансформируется внезапно в самолёт, когда в бак заливается керосин вместо бензина. У реального автомобиля есть жёсткие ограничения - хотя бы тот же ограниченный поворот руля, не позволяющий вертеть его бесконечно долго - тогда как типичный транслятор позволяет совершать намного более жуткие вещи, чем банальный и предсказуемый наезд на пешехода. Транслятор как волшебная палочка, может сделать что угодно, в том числе совсем не то, что ты от него ожидал, особенно если инструкция частично утрачена (не написана).
Умный автомобиль будет включать поворотник при повороте руля. Хотя я не знаю тонкостей ПДД, может, так нельзя...
Дарю тебе сведения о языке программирования Forth. Он просто работает. Всё, что он умеет - это выполнять инструкции, которые ты ему даёшь. Если инструкция выполнилась, он пишет ok. Если stack overflow или underflow, он пишет соответствующее сообщение. Если он не нашёл в словаре твоё слово, он пишет, что слово not found. Ещё может писать division by zero, допустим. Всё остальное зависит исключительно от тебя, и если ты что-нибудь нечаянно сломаешь - а ты обязательно что-нибудь сломаешь - всё рухнет и последствия придётся разгребать именно тебе, в одиночку. То есть ты можешь сделать на Forth всё, что можешь себе вообразить, и никаких встроенных проверок на безопасность и корректность кода тут нет и быть не может; код на Forth - это просто слова, разделённые пробелами, как этот текст (он может быть корректной программой на Forth/Forth-подобном языке). Много людей программирует на Forth? А вот нифига. Потому что все любят, когда кто-нибудь указывает на их ошибки, а не взрывается столпом искр и останавливается до тех пор, пока код не будет изменён на что-нибудь другое. А вот Ada - почему Ada сокращает время отладки на 80%? Потому что она заранее предотвращает твои ошибки, и тебе труднее выстрелить себе в ногу. Язык не должен слепо выполнять твои команды, если это не низкоуровневый язык типа Ассемблера, язык должен упрощать твою работу.
>>61089
В чём проблема написать самому? TVector2, TVector3. Можно в точности повторить функционал из GDScript.
Что-то я не понял, биндинг ведь через DLL идёт, не?.. Ааа, понял, это DLL-ку нужно биндить к Godot, а не Godot к DLL-ке. Лол. Ну ладно, Си - это как Паскаль, только со {скобочками}. Не даром же Паскаль создавался для обучения программированию на Си. В крайнем случае можно скопипастить...
ctrl+c/ctrl+v в основном? В остальном только заголовки функций поправить и типы в аргументах?
Ты меня будто на слабо вызываешь. Но, если честно, не так уж мне хочется делать игры...
>>61109 >>61112
Почему такая разница между 3D/2D? Я думал, логика построения сцены должна быть одинаковой. Что делает CanvasLayer?
>Для обучения существуют учебники, гайды и мануалы
Некоторые вещи можно понять только на практике. Кратковременная память человека очень ограничена.
>Автомобиль ... просто едет туда, куда ты его ведёшь
Автомобиль не взлетает в воздух, когда ты нечаянно дёргаешь руль на себя, и не трансформируется внезапно в самолёт, когда в бак заливается керосин вместо бензина. У реального автомобиля есть жёсткие ограничения - хотя бы тот же ограниченный поворот руля, не позволяющий вертеть его бесконечно долго - тогда как типичный транслятор позволяет совершать намного более жуткие вещи, чем банальный и предсказуемый наезд на пешехода. Транслятор как волшебная палочка, может сделать что угодно, в том числе совсем не то, что ты от него ожидал, особенно если инструкция частично утрачена (не написана).
>Представь, что автомобиль отказывается поворачивать колёса, если выключен поворотник
Умный автомобиль будет включать поворотник при повороте руля. Хотя я не знаю тонкостей ПДД, может, так нельзя...
>Язык не должен ничего тебе объяснять, он должен просто работать
Дарю тебе сведения о языке программирования Forth. Он просто работает. Всё, что он умеет - это выполнять инструкции, которые ты ему даёшь. Если инструкция выполнилась, он пишет ok. Если stack overflow или underflow, он пишет соответствующее сообщение. Если он не нашёл в словаре твоё слово, он пишет, что слово not found. Ещё может писать division by zero, допустим. Всё остальное зависит исключительно от тебя, и если ты что-нибудь нечаянно сломаешь - а ты обязательно что-нибудь сломаешь - всё рухнет и последствия придётся разгребать именно тебе, в одиночку. То есть ты можешь сделать на Forth всё, что можешь себе вообразить, и никаких встроенных проверок на безопасность и корректность кода тут нет и быть не может; код на Forth - это просто слова, разделённые пробелами, как этот текст (он может быть корректной программой на Forth/Forth-подобном языке). Много людей программирует на Forth? А вот нифига. Потому что все любят, когда кто-нибудь указывает на их ошибки, а не взрывается столпом искр и останавливается до тех пор, пока код не будет изменён на что-нибудь другое. А вот Ada - почему Ada сокращает время отладки на 80%? Потому что она заранее предотвращает твои ошибки, и тебе труднее выстрелить себе в ногу. Язык не должен слепо выполнять твои команды, если это не низкоуровневый язык типа Ассемблера, язык должен упрощать твою работу.
>>61089
>Фрипаскаль пасасал с нативными векторами
В чём проблема написать самому? TVector2, TVector3. Можно в точности повторить функционал из GDScript.
>Какой язык ни пытайся добавить в годо - знание си обязательно.
Что-то я не понял, биндинг ведь через DLL идёт, не?.. Ааа, понял, это DLL-ку нужно биндить к Godot, а не Godot к DLL-ке. Лол. Ну ладно, Си - это как Паскаль, только со {скобочками}. Не даром же Паскаль создавался для обучения программированию на Си. В крайнем случае можно скопипастить...
>Титанический, монотонный труд
ctrl+c/ctrl+v в основном? В остальном только заголовки функций поправить и типы в аргументах?
>титанический труд
Ты меня будто на слабо вызываешь. Но, если честно, не так уж мне хочется делать игры...
>>61109 >>61112
Почему такая разница между 3D/2D? Я думал, логика построения сцены должна быть одинаковой. Что делает CanvasLayer?
Антоны, а как наиболее просто, без кода-пустышки, объявить трехмерный массив? Чтоб не куча уебанских циклов с присвоением нулей, а типа такого:
var a=[][][]
a[1][2][3]='Збс!'
print(a[1][2][3])
var a=[][][]
a[1][2][3]='Збс!'
print(a[1][2][3])
>>61419
По-моему никак. Ну сделай себе функцию, которая инициализирует, var a=ArrayInit3Dim()
По-моему никак. Ну сделай себе функцию, которая инициализирует, var a=ArrayInit3Dim()
>>61419
Лучше забудь о больших массивах в GDScript. Эта такая неповоротливая хрень, что пожалеешь, когда начнёшь активно работать с ними. Они ведь целиком на variant'ах, от массива тут только название...
>трехмерный массив
Лучше забудь о больших массивах в GDScript. Эта такая неповоротливая хрень, что пожалеешь, когда начнёшь активно работать с ними. Они ведь целиком на variant'ах, от массива тут только название...
>>61534
Эмм... то есть там какие-то проблемы с производительностью? Я просо не шарю от слова совсем
Эмм... то есть там какие-то проблемы с производительностью? Я просо не шарю от слова совсем
>>61540
Да. В нормальном, строго типизированном ЯП ты мог бы создать массив элементов одного типа, они все размещались бы в памяти последовательно (массив же), и при проходе подряд обрабатывались бы быстро (такой массив вроде должен автоматом подгружаться в кэш процессора). В GDScript обычный массив[] содержит нетипизированные элементы, т.е. "variant", которые могут принимать любое значение. Делается это в ущерб производительности, т.к. для чтения/перезаписи каждой такой переменной тратится время ЦП на проверку или перезапись метки типа (не считая того, что на эту метку тратится память); кроме того, ещё не факт, что они располагаются последовательно, данные могут разбрасываться по памяти (ЦП не сможет подгрузить в кэш). Чтобы обойти этот недостаток, существуют классы с именами Pool<N>Array, где <N> - название типа (например, Int); это одномерные типизированные массивы, оптимизированные по использованию памяти, но вкладывать друг в друга их уже не получится.
Так что если ты собираешься держать в трёхмерном массиве огромный массив информации, который будет часто обновляться, лучше подумать о написании модуля на C++. Впрочем, не знаю, насколько серьёзные просадки будут на практике, сам тестов не проводил, читал только (когда искал типизированные массивы). Если часто обновлять не планируешь, то, возможно, сойдёт и так, просто помни, что по сути будешь палить из пушки (variant'ы) по воробьям (int'ы какие-нибудь).
Да, кстати, для воксельных игр а-ля Майнкрафт как раз-таки пишут модули на C++, GDScript слишком слоупок для этого.
Да. В нормальном, строго типизированном ЯП ты мог бы создать массив элементов одного типа, они все размещались бы в памяти последовательно (массив же), и при проходе подряд обрабатывались бы быстро (такой массив вроде должен автоматом подгружаться в кэш процессора). В GDScript обычный массив[] содержит нетипизированные элементы, т.е. "variant", которые могут принимать любое значение. Делается это в ущерб производительности, т.к. для чтения/перезаписи каждой такой переменной тратится время ЦП на проверку или перезапись метки типа (не считая того, что на эту метку тратится память); кроме того, ещё не факт, что они располагаются последовательно, данные могут разбрасываться по памяти (ЦП не сможет подгрузить в кэш). Чтобы обойти этот недостаток, существуют классы с именами Pool<N>Array, где <N> - название типа (например, Int); это одномерные типизированные массивы, оптимизированные по использованию памяти, но вкладывать друг в друга их уже не получится.
Так что если ты собираешься держать в трёхмерном массиве огромный массив информации, который будет часто обновляться, лучше подумать о написании модуля на C++. Впрочем, не знаю, насколько серьёзные просадки будут на практике, сам тестов не проводил, читал только (когда искал типизированные массивы). Если часто обновлять не планируешь, то, возможно, сойдёт и так, просто помни, что по сути будешь палить из пушки (variant'ы) по воробьям (int'ы какие-нибудь).
Да, кстати, для воксельных игр а-ля Майнкрафт как раз-таки пишут модули на C++, GDScript слишком слоупок для этого.
В чем разница между?
_input(event)
_unhandled_input(event)
Ivent
Когда и что надо использовать?
_input(event)
_unhandled_input(event)
Ivent
Когда и что надо использовать?
>>61213
Эту магию пока не дано мне постичь. Но из побочных эффектов - сбилось глобальное позиционирование, и теперь пули вылетают не из ствола (они рождались по глобальным координатам Position2D, дочерней от оружия), а откуда попало. Другие объекты со своих мест не уехали, и координаты мыши правильно определяются; и вообще, вся сцена с персонажем и оружием находится не в той ветке, в которой интерфейс и канвас. ЧХ выхлопы от генератора частиц, который тоже привязан к стволу, позиционируются правильно.
>Почему такая разница между 3D/2D? Я думал, логика построения сцены должна быть одинаковой. Что делает CanvasLayer?
Эту магию пока не дано мне постичь. Но из побочных эффектов - сбилось глобальное позиционирование, и теперь пули вылетают не из ствола (они рождались по глобальным координатам Position2D, дочерней от оружия), а откуда попало. Другие объекты со своих мест не уехали, и координаты мыши правильно определяются; и вообще, вся сцена с персонажем и оружием находится не в той ветке, в которой интерфейс и канвас. ЧХ выхлопы от генератора частиц, который тоже привязан к стволу, позиционируются правильно.
>>61561
Че-то у годо слишком уж много таких подводных. Еще вопрос тогода знающим: все-таки что лучше для сравнительно крупных 2д проектов, гей мейкер студио 2 десктоп, или годо? Я знаю, что сорта, но все-же
Че-то у годо слишком уж много таких подводных. Еще вопрос тогода знающим: все-таки что лучше для сравнительно крупных 2д проектов, гей мейкер студио 2 десктоп, или годо? Я знаю, что сорта, но все-же
>>61561
Еще момент - такой фокус, я так понял, проворачивается только со встроенными типами? Массив классов так не запилишь (В котором будет свой массив классов, итд, лол)?
>Pool<N>Array, где <N> - название типа (например, Int)
Еще момент - такой фокус, я так понял, проворачивается только со встроенными типами? Массив классов так не запилишь (В котором будет свой массив классов, итд, лол)?
>>61615
Не обращай внимания на поехавшего, он нахватался знаний по верхам и выпендривается сложными словами, в программировании есть принцип предварительная оптимизация зло, все зависит от конкретного случая и нужно тестировать, я один раз тестировал производительность тайлмапов в годоте и замена гдскрипта на плюсы дала прирост порядка 5%, а не 500% как должна была бы, а все потому что система упиралась в скорость вывода графики. Если у тебя какой то простой случай то все спокойно будет работать с 3д массивами, но конечно игру на микровокселях в 1см не сделать
Не обращай внимания на поехавшего, он нахватался знаний по верхам и выпендривается сложными словами, в программировании есть принцип предварительная оптимизация зло, все зависит от конкретного случая и нужно тестировать, я один раз тестировал производительность тайлмапов в годоте и замена гдскрипта на плюсы дала прирост порядка 5%, а не 500% как должна была бы, а все потому что система упиралась в скорость вывода графики. Если у тебя какой то простой случай то все спокойно будет работать с 3д массивами, но конечно игру на микровокселях в 1см не сделать
>>61630
У тебя KinematicBody проваливается сквозь RigidBody? Если так, поставь infinite_inertia = false у move_and_slide().
https://docs.godotengine.org/en/3.1/classes/class_kinematicbody2d.html#class-kinematicbody2d-method-move-and-slide
Если у тебя пролетают очень быстро движущие объекты через тонкие статичные стенки, я полагаю, нужно либо делать стенки физически толще, либо тестировать смещение на более короткую дистанцию, прежде чем "прыгать" далеко.
>>61615
Godot лучше, к тому же Godot универсальнее, его предпочтительнее изучать.
Но ещё зависит от того, что ты называешь "крупным". Terraria-like ни Godot, ни GM "из коробки" не потянут, нужны специфичные для таких игр оптимизации, которые трудно прикрутить к универсальному движку/конструктору.
>>61616
Для "массива классов" используй обычный массив. Экземпляр класса занимает рандомное место в памяти, доступ всегда происходит по ссылке, в массиве хранится только ссылка. Так что работа с большим массивом классов по идее всегда будет медленной, но пока тебе не нужны десятки тысяч классов - всё ок.
>>61651
Я всего лишь предупредил, где могут возникнуть подводные камни, если он замутит какой-нибудь 3D массив 1000x1000x1000 и внезапно обнаружит, что всё стало в разы медленнее (или вообще падает).
И я о том же, но он не сказал конкретики, так что я обрисовал худший сценарий. А то сейчас понасоздают тут массивов в массивах в массивах, а потом будут говорить "чёт Годо медленный, чёт Годо лагает".
>Как настроить свои шары, чтобы они не летали сквозь стены?
У тебя KinematicBody проваливается сквозь RigidBody? Если так, поставь infinite_inertia = false у move_and_slide().
https://docs.godotengine.org/en/3.1/classes/class_kinematicbody2d.html#class-kinematicbody2d-method-move-and-slide
Если у тебя пролетают очень быстро движущие объекты через тонкие статичные стенки, я полагаю, нужно либо делать стенки физически толще, либо тестировать смещение на более короткую дистанцию, прежде чем "прыгать" далеко.
>>61615
>лучше для сравнительно крупных 2д проектов
Godot лучше, к тому же Godot универсальнее, его предпочтительнее изучать.
Но ещё зависит от того, что ты называешь "крупным". Terraria-like ни Godot, ни GM "из коробки" не потянут, нужны специфичные для таких игр оптимизации, которые трудно прикрутить к универсальному движку/конструктору.
>>61616
>Массив классов
Для "массива классов" используй обычный массив. Экземпляр класса занимает рандомное место в памяти, доступ всегда происходит по ссылке, в массиве хранится только ссылка. Так что работа с большим массивом классов по идее всегда будет медленной, но пока тебе не нужны десятки тысяч классов - всё ок.
>>61651
>есть принцип предварительная оптимизация зло
Я всего лишь предупредил, где могут возникнуть подводные камни, если он замутит какой-нибудь 3D массив 1000x1000x1000 и внезапно обнаружит, что всё стало в разы медленнее (или вообще падает).
>все зависит от конкретного случая и нужно тестировать
И я о том же, но он не сказал конкретики, так что я обрисовал худший сценарий. А то сейчас понасоздают тут массивов в массивах в массивах, а потом будут говорить "чёт Годо медленный, чёт Годо лагает".
>>61715
Да, вот этот вот вариант. Про тест мув знаю, но не хотел писать доп код. Ну ок, раз по другому низя.
А единство?
Это же вроде не супербольшой массив, не? Если я не буду каждый фрейм его сортировать, то не должно же вроде быть проседаний фпс? Обращение к элементам по индексам наверное уж не должно так жрать ресурсы?
>Если у тебя пролетают очень быстро движущие объекты через тонкие статичные стенки, я полагаю, нужно либо делать стенки физически толще, либо тестировать смещение на более короткую дистанцию, прежде чем "прыгать" далеко.
Да, вот этот вот вариант. Про тест мув знаю, но не хотел писать доп код. Ну ок, раз по другому низя.
>Но ещё зависит от того, что ты называешь "крупным". Terraria-like ни Godot, ни GM "из коробки" не потянут
А единство?
>1000x1000x1000 и внезапно обнаружит, что всё стало в разы медленнее (или вообще падает).
Это же вроде не супербольшой массив, не? Если я не буду каждый фрейм его сортировать, то не должно же вроде быть проседаний фпс? Обращение к элементам по индексам наверное уж не должно так жрать ресурсы?
Еще вопрос: как наиболее просто и незамороченно передать в строку содержимое переменной-класса
class container
( )var a=1
( )var b=4
var tmp=container.New()
s=str(tmp)
Типа такого, но чтобы передало значения a и b, а не реф
class container
( )var a=1
( )var b=4
var tmp=container.New()
s=str(tmp)
Типа такого, но чтобы передало значения a и b, а не реф
>>61615
Ты бы лучше с проектом точнее определился, тогда уже можно под него инструменты советовать.
Ты бы лучше с проектом точнее определился, тогда уже можно под него инструменты советовать.
>>61722
Покажи, какой код и при каких условиях у тебя пролетает. А то гадаем на кофейной гуще.
Ты про что?
Миллиард указателей, разбросанных по памяти, и указывающих на миллиард разбросанных по памяти классов? Даже если бы это был просто миллиард 32-битных Int, такой массив занял бы почти 4 ГБ оперативной памяти. А безтиповые переменные занимают по идее намного больше места, чем 32-битный Int, плюс каждый класс будет добавлять вес.
Ой, ну попробуй, если вообще запустится, посмотришь, будут ли просадки. Я просто говорю, что не питай особых надежд, скорее всего придётся костылировать что-нибудь.
Воксельные игры вообще-то используют чанки, это, по сути, 5(6)-х мерный массив, два измерения индексируют чанки, а остальные три индексируют малое пространство внутри чанка (16x16x128, допустим). Но даже так, для нормальной игры потребуется ещё куча всяких костылей-оптимизаций, в лоб это не решается.
>Да, вот этот вот вариант. Про тест мув знаю, но не хотел писать доп код. Ну ок, раз по другому низя.
Покажи, какой код и при каких условиях у тебя пролетает. А то гадаем на кофейной гуще.
>А единство?
Ты про что?
>Это же вроде не супербольшой массив, не?
Миллиард указателей, разбросанных по памяти, и указывающих на миллиард разбросанных по памяти классов? Даже если бы это был просто миллиард 32-битных Int, такой массив занял бы почти 4 ГБ оперативной памяти. А безтиповые переменные занимают по идее намного больше места, чем 32-битный Int, плюс каждый класс будет добавлять вес.
>Если я не буду каждый фрейм его сортировать, то не должно же вроде быть проседаний фпс?
>Обращение к элементам по индексам наверное уж не должно так жрать ресурсы?
Ой, ну попробуй, если вообще запустится, посмотришь, будут ли просадки. Я просто говорю, что не питай особых надежд, скорее всего придётся костылировать что-нибудь.
Воксельные игры вообще-то используют чанки, это, по сути, 5(6)-х мерный массив, два измерения индексируют чанки, а остальные три индексируют малое пространство внутри чанка (16x16x128, допустим). Но даже так, для нормальной игры потребуется ещё куча всяких костылей-оптимизаций, в лоб это не решается.
>>61729
Unity
Да я ж как раз не про код. Как в коде сделать я и сам знаю. Думал настройка есть под это, какая-нибудь, для более точного рассчета столкновений
У меня как-раз подобная структура намечается, но немного для других целей
>Ты про что?
Unity
>Покажи, какой код и при каких условиях у тебя пролетает. А то гадаем на кофейной гуще.
Да я ж как раз не про код. Как в коде сделать я и сам знаю. Думал настройка есть под это, какая-нибудь, для более точного рассчета столкновений
>Воксельные игры вообще-то используют чанки, это, по сути, 5(6)-х мерный массив, два измерения индексируют чанки, а остальные три индексируют малое пространство внутри чанка (16x16x128, допустим). Но даже так, для нормальной игры потребуется ещё куча всяких костылей-оптимизаций, в лоб это не решается.
У меня как-раз подобная структура намечается, но немного для других целей
>>61727
Попробуй придумать что-нибудь и потом реализовать это своими руками. Если не получится - ищи другую идею, если получится - уже будет опыт для новых идей. А так ты сейчас обучишься инструменту, а идей как не было, так и не возникнет. Личный опыт...
>>61724
По идее, каждый класс должен сам формировать такую строку, если тебе очень надо:
func to_string():
return бла-бла-бла
Универсальных инструментов под это вроде как нет, это вообще весьма странная задача, если подумать. Зачем тебе?
>Я просто учусь, пока что. Но надо же знать, на что рассчитывать.
Попробуй придумать что-нибудь и потом реализовать это своими руками. Если не получится - ищи другую идею, если получится - уже будет опыт для новых идей. А так ты сейчас обучишься инструменту, а идей как не было, так и не возникнет. Личный опыт...
>>61724
>Еще вопрос: как наиболее просто и незамороченно передать в строку содержимое переменной-класса
>Тут, конечно, для двух переменных все очень просто, но у меня их сильно больше, чем две, в каждом классе.
По идее, каждый класс должен сам формировать такую строку, если тебе очень надо:
func to_string():
return бла-бла-бла
Универсальных инструментов под это вроде как нет, это вообще весьма странная задача, если подумать. Зачем тебе?
>>61731
Ой, хочешь выбрать идеальный движок - иди в движкосрач и там спрашивай. Unity такой же универсальный движок, как и Godot; все кубопесочницы на Unity, что я видел, лагали намного сильнее оригинального майнкрафта. Для кубопесочниц нужен узкоспециализированный движок - либо форкай minetest, либо пиши свой с нуля.
Оптимизировать открытое пространство? Если нужны просто чанки, то чанками размером, условно, 50x50 метров можно покрыть очень большую карту без особых затрат, я так думаю. Сам хотел что-то такое сделать, но потом забил на проект и чот приуныл.
>Unity
Ой, хочешь выбрать идеальный движок - иди в движкосрач и там спрашивай. Unity такой же универсальный движок, как и Godot; все кубопесочницы на Unity, что я видел, лагали намного сильнее оригинального майнкрафта. Для кубопесочниц нужен узкоспециализированный движок - либо форкай minetest, либо пиши свой с нуля.
>У меня как-раз подобная структура намечается, но немного для других целей
Оптимизировать открытое пространство? Если нужны просто чанки, то чанками размером, условно, 50x50 метров можно покрыть очень большую карту без особых затрат, я так думаю. Сам хотел что-то такое сделать, но потом забил на проект и чот приуныл.
>>61737
Вот поэтому и не хотел здесь даже упоминать про юнити, ибо, как понял, для здешнего анона это больная тема.
ЖЫза
>Ой, хочешь выбрать идеальный движок - иди в движкосрач и там спрашивай. Unity такой же универсальный движок, как и Godot; все кубопесочницы на Unity, что я видел, лагали намного сильнее оригинального майнкрафта. Для кубопесочниц нужен узкоспециализированный движок - либо форкай minetest, либо пиши свой с нуля.
Вот поэтому и не хотел здесь даже упоминать про юнити, ибо, как понял, для здешнего анона это больная тема.
> но потом забил на проект и чот приуныл.
ЖЫза
>>61733
А, ты про streaming... Не уверен, есть ли в Godot это в таком виде.
Но можно сохранять ноды/сцены целиком: https://godotengine.org/qa/903/how-to-save-a-scene-at-run-time
Правда, я не уверен, сохраняется ли состояние переменных прикреплённого скрипта, т.к. сам пока не пробовал так.
>В файл писать и обратно
А, ты про streaming... Не уверен, есть ли в Godot это в таком виде.
Но можно сохранять ноды/сцены целиком: https://godotengine.org/qa/903/how-to-save-a-scene-at-run-time
Правда, я не уверен, сохраняется ли состояние переменных прикреплённого скрипта, т.к. сам пока не пробовал так.
>>61744
Збс, что-то такое я и искал
Збс, что-то такое я и искал
>>61737
Кстати, раз уж речь зашла о Майнкрафте, объясните, почему существуют такие моды, как оптифайн? При чем они реально работают. Почему разрабы не закладывают это в код программы? Только ли тут дело в криворукости, или есть какой-то скрытый смысл?
Кстати, раз уж речь зашла о Майнкрафте, объясните, почему существуют такие моды, как оптифайн? При чем они реально работают. Почему разрабы не закладывают это в код программы? Только ли тут дело в криворукости, или есть какой-то скрытый смысл?
>>61762
Понятия не имею, как работает оптифайн, но он вроде какие-то файлы подменяет на свои.
Возможно, несовместимость лицензий. К примеру, код под лицензией GPL, насколько мне известно, не может линковаться с каким-либо кодом под несовместимой с GPL лицензией (т.к. GPL как зомби-вирус - всё, что линкуется с GPL, обязано лицензироваться GPL и выкладываться в виде исходных кодов). Код майнкрафта - закрытый, то есть лицензия проприетарная, а это значит, что в код майнкрафта нельзя легально поместить GPL-код. То есть разрабам майнкрафта либо свой велосипед писать, либо искать код под какой-нибудь лицензией типа MIT, в то время как моддеры могут наплевать на законность и вволю пиратствовать (моддинг игр сам по себе незаконен, пока разраб не сделает ModAPI).
Ну и фиг знает, возможно есть внутренние проблемы, по которым нельзя просто взять и заменить что-то. Майнкрафт - это большая куча легаси кода, насколько я понимаю, выдернешь одно, может рухнуть другое. Его постепенно оптимизируют (и наверняка рефакторят), судя по всему, но процесс трудоёмкий и всё сразу сделать не получается.
>почему существуют такие моды, как оптифайн
Понятия не имею, как работает оптифайн, но он вроде какие-то файлы подменяет на свои.
>Почему разрабы не закладывают это в код программы?
>есть какой-то скрытый смысл?
Возможно, несовместимость лицензий. К примеру, код под лицензией GPL, насколько мне известно, не может линковаться с каким-либо кодом под несовместимой с GPL лицензией (т.к. GPL как зомби-вирус - всё, что линкуется с GPL, обязано лицензироваться GPL и выкладываться в виде исходных кодов). Код майнкрафта - закрытый, то есть лицензия проприетарная, а это значит, что в код майнкрафта нельзя легально поместить GPL-код. То есть разрабам майнкрафта либо свой велосипед писать, либо искать код под какой-нибудь лицензией типа MIT, в то время как моддеры могут наплевать на законность и вволю пиратствовать (моддинг игр сам по себе незаконен, пока разраб не сделает ModAPI).
Ну и фиг знает, возможно есть внутренние проблемы, по которым нельзя просто взять и заменить что-то. Майнкрафт - это большая куча легаси кода, насколько я понимаю, выдернешь одно, может рухнуть другое. Его постепенно оптимизируют (и наверняка рефакторят), судя по всему, но процесс трудоёмкий и всё сразу сделать не получается.
>>61785
Вот всегда интересовало, как можно кому-то предъявить за закрытый код? Он же закрытый))))))) То-есть, если что-либо всплывет, то налицо факт взлома ПО. Поэтому, что мешает использовать что-угодно в закрытом коде? Если нашел нарушение - значит взламывал и сам пидорас.
Хотя, я, конечно, понимаю, что все далеко не так просто
Вот всегда интересовало, как можно кому-то предъявить за закрытый код? Он же закрытый))))))) То-есть, если что-либо всплывет, то налицо факт взлома ПО. Поэтому, что мешает использовать что-угодно в закрытом коде? Если нашел нарушение - значит взламывал и сам пидорас.
Хотя, я, конечно, понимаю, что все далеко не так просто
>>61213
Эх, моя мечта, чтобы годот существовал как ДЛЛ, которая бы через бинды подключалась к Лазарусу как компонент, чтобы весь код создавался и редактировался прямо в ИДЕ, все ресурсы так же в ИДЕ, отдельными окнами-инспекторами, чтобы сцену можно было редактировать в отдельном окошке с OPENGL выводом, как простую форму. А потом билд экзешника средствами фрипаскаля с полным доступом ко всем секциям бинарника, иконки/ресурсы и т.п. Ресурсы вшивать в соответствующие секции бинарника, а не как сейчас - файл PCK приклеивается в хвост заранее скомпилированного "шаблона экспорта". Эх, мечты.
> Ааа, понял, это DLL-ку нужно биндить к Godot, а не Godot к DLL-ке. Лол. Ну ладно
Эх, моя мечта, чтобы годот существовал как ДЛЛ, которая бы через бинды подключалась к Лазарусу как компонент, чтобы весь код создавался и редактировался прямо в ИДЕ, все ресурсы так же в ИДЕ, отдельными окнами-инспекторами, чтобы сцену можно было редактировать в отдельном окошке с OPENGL выводом, как простую форму. А потом билд экзешника средствами фрипаскаля с полным доступом ко всем секциям бинарника, иконки/ресурсы и т.п. Ресурсы вшивать в соответствующие секции бинарника, а не как сейчас - файл PCK приклеивается в хвост заранее скомпилированного "шаблона экспорта". Эх, мечты.
>>61797
Потому что взял ты такой код gpl у васи пупкина и вставил в свою закрытую игру, в потом некий анон выложил исходники твоей игры, т.к. работали вы компанией и произошла утечка (типа как у вальв сейчас). В лучше случае ты как компания найдешь анона а анально покараешь через суд, который обяжет его выплатить штраф, и тот будет тебе по 100 рупий платить каждый месяц до конца жизни. Но и ты как компания в свою очередь выплатишь охуеть какой штраф Васе Пупкину за нарушение лицензии и будешь открывать свой код.
Потому что взял ты такой код gpl у васи пупкина и вставил в свою закрытую игру, в потом некий анон выложил исходники твоей игры, т.к. работали вы компанией и произошла утечка (типа как у вальв сейчас). В лучше случае ты как компания найдешь анона а анально покараешь через суд, который обяжет его выплатить штраф, и тот будет тебе по 100 рупий платить каждый месяц до конца жизни. Но и ты как компания в свою очередь выплатишь охуеть какой штраф Васе Пупкину за нарушение лицензии и будешь открывать свой код.
>>61806
так у него и так есть ядро, которое линкуется статически к редактору, вот его извлеки и компилируй в динамическую либу, может там уже все есть для этого
только вот весь инструментарий будешь заново писать для лазаруса
так у него и так есть ядро, которое линкуется статически к редактору, вот его извлеки и компилируй в динамическую либу, может там уже все есть для этого
только вот весь инструментарий будешь заново писать для лазаруса
>>61808
Это отдельный случай.
А в этом случае, по идее, нужно еще доказать, что это ТВОИ исходники, а не его маняфантазии на тему твоей программы. Хотя, наверное, можно перекомпилить и сравнить хэш или типа того..
>т.к. работали вы компанией и произошла утечка
Это отдельный случай.
>потом некий анон выложил исходники твоей игры
А в этом случае, по идее, нужно еще доказать, что это ТВОИ исходники, а не его маняфантазии на тему твоей программы. Хотя, наверное, можно перекомпилить и сравнить хэш или типа того..
>>61810
Я хочу игоры делать, а не портировать движки. Портированием софта я уже наигрался в нулевых-десятых. Остоебенило. Хочу чтоб мне сделали. Под опенсорц лицензией. Сделойти!
Я хочу игоры делать, а не портировать движки. Портированием софта я уже наигрался в нулевых-десятых. Остоебенило. Хочу чтоб мне сделали. Под опенсорц лицензией. Сделойти!
>>61797
Однако нарушение-то есть. Если вор вломился в дом и увидел маньяка-педофила, вора судить будут за взлом дома, а маньяка - за педофилию. Загугли, были какие-то прецеденты с GPL, прям до суда дошло вроде. Да и, к тому же, закрытый код доступен сотрудникам компании, а те, хоть и подписывают NDA, по-прежнему могут доложить о нарушении, пусть даже анонимно.
Вокруг GPL вообще много срачей, поэтому ровные пацаны, как Godot, лицензируются под чем-то вроде MIT, чтобы не отпугивать людей жёсткими требованиями "только опенсурс" и "только под той же лицензией".
>Если нашел нарушение - значит взламывал
Однако нарушение-то есть. Если вор вломился в дом и увидел маньяка-педофила, вора судить будут за взлом дома, а маньяка - за педофилию. Загугли, были какие-то прецеденты с GPL, прям до суда дошло вроде. Да и, к тому же, закрытый код доступен сотрудникам компании, а те, хоть и подписывают NDA, по-прежнему могут доложить о нарушении, пусть даже анонимно.
Вокруг GPL вообще много срачей, поэтому ровные пацаны, как Godot, лицензируются под чем-то вроде MIT, чтобы не отпугивать людей жёсткими требованиями "только опенсурс" и "только под той же лицензией".
>>61815
Из недавнего - nginx, рамблер доебался к уасе, который начинал писать продукт в рабочее время на рабочем пека рамблерской серверной.
> Загугли, были какие-то прецеденты с GPL
Из недавнего - nginx, рамблер доебался к уасе, который начинал писать продукт в рабочее время на рабочем пека рамблерской серверной.
>>61811
1) ты не проебал исходники
на тебя подают в суд и происходить проверка твоих закрытых кодов группой экспертной комиссии
2) ты клятвенно уверяшь, что ты потерял исходники, т.к. их же украли
берут слитые и ассемблируют, берут твою игру - аналогично.. сверяют до какого-там процента, который в суде считается достаточным
> нужно еще доказать, что это ТВОИ исходники
1) ты не проебал исходники
на тебя подают в суд и происходить проверка твоих закрытых кодов группой экспертной комиссии
2) ты клятвенно уверяшь, что ты потерял исходники, т.к. их же украли
берут слитые и ассемблируют, берут твою игру - аналогично.. сверяют до какого-там процента, который в суде считается достаточным
>>61817
Ну, ок, как то так и подумал.
Едиснтвенное, еще одну вещь спрошу: насколько реально обнаружить свои исходники в сети одним прекрасным утром, если работаешь один?
Ну, ок, как то так и подумал.
>Хотя, наверное, можно перекомпилить и сравнить хэш или типа того..
Едиснтвенное, еще одну вещь спрошу: насколько реально обнаружить свои исходники в сети одним прекрасным утром, если работаешь один?
>>61806
По-моему, в таком виде существуют GLScene и Castle Game Engine, нет? А ещё были DelphiX и ещё что-то...
По-моему у EXE есть строгое ограничение на ресурсы. Во всяком случае, если пытаться через .res запихнуть больше скольких-то десятков мегабайт изображений - приложение сломается. Так что лучше обращаться к внешним файлам (возможно, упакованным в свой формат), чем совать что попало в EXE.
А чем это плохо? Ну, кроме того, что заранее скомпилированный движок тащит в себе кучу лишнего.
>>61814
Эх, все мы хотим, да не у всех хоть что-то получается(
>подключалась к Лазарусу как компонент, чтобы весь код создавался и редактировался прямо в ИДЕ, все ресурсы так же в ИДЕ, отдельными окнами-инспекторами, чтобы сцену можно было редактировать в отдельном окошке с OPENGL выводом, как простую форму
По-моему, в таком виде существуют GLScene и Castle Game Engine, нет? А ещё были DelphiX и ещё что-то...
>Ресурсы вшивать в соответствующие секции бинарника
По-моему у EXE есть строгое ограничение на ресурсы. Во всяком случае, если пытаться через .res запихнуть больше скольких-то десятков мегабайт изображений - приложение сломается. Так что лучше обращаться к внешним файлам (возможно, упакованным в свой формат), чем совать что попало в EXE.
>а не как сейчас - файл PCK приклеивается в хвост заранее скомпилированного
А чем это плохо? Ну, кроме того, что заранее скомпилированный движок тащит в себе кучу лишнего.
>>61814
>Я хочу игоры делать
Эх, все мы хотим, да не у всех хоть что-то получается(
>>61824
Такое может произойти, если:
1. Ты не Неуловимый Джо, и кому-то позарез нужны именно твои исходники;
2. У тебя на компьютере вирус или антивирус, любезно сливающий все файлы в Сеть;
3. Ты был пьян или с температурой 41+ пытался что-то делать, и сам слил исходники;
4. У тебя есть девушка/родственники/дети/друзья/соседи, которые имеют доступ к твоему ПК;
5. У тебя есть кот или любое другое животное, способное осмысленно нажимать клавиши клавиатуры;
6. Твой ПК изъяли менты на экспертизу, а уже у них завелась какая-то крыса или просто приколист;
7. ???
8. Тебя похитили инопланетяне, узнали пароль от компьютера и слили исходники ряди эксперимента.
В остальных случаях, думаю, шансы малы.
>Едиснтвенное, еще одну вещь спрошу: насколько реально обнаружить свои исходники в сети одним прекрасным утром, если работаешь один?
Такое может произойти, если:
1. Ты не Неуловимый Джо, и кому-то позарез нужны именно твои исходники;
2. У тебя на компьютере вирус или антивирус, любезно сливающий все файлы в Сеть;
3. Ты был пьян или с температурой 41+ пытался что-то делать, и сам слил исходники;
4. У тебя есть девушка/родственники/дети/друзья/соседи, которые имеют доступ к твоему ПК;
5. У тебя есть кот или любое другое животное, способное осмысленно нажимать клавиши клавиатуры;
6. Твой ПК изъяли менты на экспертизу, а уже у них завелась какая-то крыса или просто приколист;
7. ???
8. Тебя похитили инопланетяне, узнали пароль от компьютера и слили исходники ряди эксперимента.
В остальных случаях, думаю, шансы малы.
>>61843
Так и думал, что будет куча мистики. Очевидно, интересен только первый вариант
Так и думал, что будет куча мистики. Очевидно, интересен только первый вариант
>>61853
Приведёт кошек через балкон, пока ты за хлебушком вышел. А кошки спиздят твой код. И кота.
Приведёт кошек через балкон, пока ты за хлебушком вышел. А кошки спиздят твой код. И кота.
>>61824
В треде по опенсурсному движку этот вопрос выглядит очень странно. Вы или крест снимите, или штаны наденьте. А лучше заберите этот дискурс обратно в движкосрачи; и шапочку из фольги не забудьте.
>насколько реально обнаружить свои исходники в сети одним прекрасным утром, если работаешь один?
В треде по опенсурсному движку этот вопрос выглядит очень странно. Вы или крест снимите, или штаны наденьте. А лучше заберите этот дискурс обратно в движкосрачи; и шапочку из фольги не забудьте.
>>61894
Эддчайлд что-то там делает противозаконное явно. Т.к. если его убрать, то программа запускается (если оставить, то на экран выводится только логотип годо), хотя print(a) в сохраненной сцене ничего не выводит в аутпут, так что я хз, где эта нода вообще находится, если она вообще загрузилась
Эддчайлд что-то там делает противозаконное явно. Т.к. если его убрать, то программа запускается (если оставить, то на экран выводится только логотип годо), хотя print(a) в сохраненной сцене ничего не выводит в аутпут, так что я хз, где эта нода вообще находится, если она вообще загрузилась
>>61899
Он находится в физикс процесс, так что должен спамить только в путь, если сцена вообще добавилась в игру
>хотя print(a) в сохраненной сцене ничего не выводит в аутпут
Он находится в физикс процесс, так что должен спамить только в путь, если сцена вообще добавилась в игру
>>61811
Посылаешь заказным письмом самому себе диск с исходниками. Не распечатываешь. Теперь у тебя есть пакет с исходниками датой государственной почты.
> А в этом случае, по идее, нужно еще доказать, что это ТВОИ исходники
Посылаешь заказным письмом самому себе диск с исходниками. Не распечатываешь. Теперь у тебя есть пакет с исходниками датой государственной почты.
>>61843
Ты запускаешь демки скачанные с двачей и прочих твг :3
Ты запускаешь демки скачанные с двачей и прочих твг :3
>>61928
А ты что собственно хочешь реализовать?
А ты что собственно хочешь реализовать?
>>61609
https://www.youtube.com/watch?v=MA7jSbXfS34
Стоило решить проблему самому, как тут же появилось решение в сети.
После некоторых тестов оказалось, что положение пуль сбивается вовсе не из-за CanvasLayer'а, а по какой-то причине в коде самих пуль.
https://www.youtube.com/watch?v=MA7jSbXfS34
Стоило решить проблему самому, как тут же появилось решение в сети.
После некоторых тестов оказалось, что положение пуль сбивается вовсе не из-за CanvasLayer'а, а по какой-то причине в коде самих пуль.
Годаны, а lerp ведь быстро работает? Никаких более дешёвых функций уже не придумать, потому что эта и так предельно простая, верно?
Речь про 2д, всякие сглаживания движений на масштабах в 20-30 пикселей.
Речь про 2д, всякие сглаживания движений на масштабах в 20-30 пикселей.
>>62359
Ну а что ты хочешь? Сделай миллион вызовов lerp в цикле, потом замени lerp на какой-нибудь велосипед, сделай сравнение по затраченному времени. Нам за тебя это делать?
Ну а что ты хочешь? Сделай миллион вызовов lerp в цикле, потом замени lerp на какой-нибудь велосипед, сделай сравнение по затраченному времени. Нам за тебя это делать?
>>62365
Какой же ты зануда. Специально для тебя перефразирую вопрос.
Существует ли в годоте функция, которой можно было бы заменить lerp для плавного движения чего-либо? Или же lerp и так предельно дешёвая?
Какой же ты зануда. Специально для тебя перефразирую вопрос.
Существует ли в годоте функция, которой можно было бы заменить lerp для плавного движения чего-либо? Или же lerp и так предельно дешёвая?
>>62359
#преждевременнаяоптимизация #XYпроблема
Он все правильно тебе ответил. Ну если тебе так важно то lerp это обертка над чем то вроде a(1-t)+bt и имеет 1 или 2 умножения, в зависимости от формулы. Что будет быстрее? Во-первых, если у тебя значения только от нуля, то одну половины формулы можно выкинуть. Во-вторых, если у тебя начальное и конечное значение неизменны, то иногда можно вынести все из цикла, а в цикле оставить только x+=delta
#преждевременнаяоптимизация #XYпроблема
Он все правильно тебе ответил. Ну если тебе так важно то lerp это обертка над чем то вроде a(1-t)+bt и имеет 1 или 2 умножения, в зависимости от формулы. Что будет быстрее? Во-первых, если у тебя значения только от нуля, то одну половины формулы можно выкинуть. Во-вторых, если у тебя начальное и конечное значение неизменны, то иногда можно вынести все из цикла, а в цикле оставить только x+=delta
>>62426
Ну вот, ответ по существу, спасибо.
Это приблизительно совпадает с моими догадками. Прежде чем спросить, я, естественно, погуглил, прочекал суть идеи, выяснил, что под словами "линейная интерполяция" скрывается простое ax+b. Сам вопрос возник по той простой причине, что зачастую простые решения, описываемые в гайдах, имеют какие-то недостатки; или, например, в гайдах не упоминаются какие-нибудь тонкости или частные случаи. Например, ситуация с канвасом выше по треду. Или вот, из найденного сегодня: функция lerp_angle меня спасла, потому то я поворачивал lerp'ом ствол вслед за мышкой, и для гладкого поворота из левой верхней четверти круга в верхнюю нижнюю без этого пришлось бы поизвращаться. В конце концов, все эти гайды существуют для обучения, они не рассчитаны на работу проектах в более сложных, чем демка в один экран.
Почему возникли подозрения в скорости lerp'а: ну, например, потому что он принимает разные типы данных, а значит могла бы существовать более строго типизированная функция, которая работает быстрее. Или ещё почему. Хз, что там за код под капотом. Я спросил в треде, потому что тут, может быть, есть кто-то, кто копался в исходниках и смотрел, как оно там реализовано.
Что касается "преждевременной" оптимизации. Лучше я сразу напишу оптимальный код, чем напишу сначала не оптимальный, а потом буду оптимизировать. Времени на написание кода уйдёт одинаково, зато потом на оптимизации сэкономлю. А ещё я узнаю что-то новое, если попробую какой-то метод, который прежде не пробовал.
Такие дела.
Ну вот, ответ по существу, спасибо.
Это приблизительно совпадает с моими догадками. Прежде чем спросить, я, естественно, погуглил, прочекал суть идеи, выяснил, что под словами "линейная интерполяция" скрывается простое ax+b. Сам вопрос возник по той простой причине, что зачастую простые решения, описываемые в гайдах, имеют какие-то недостатки; или, например, в гайдах не упоминаются какие-нибудь тонкости или частные случаи. Например, ситуация с канвасом выше по треду. Или вот, из найденного сегодня: функция lerp_angle меня спасла, потому то я поворачивал lerp'ом ствол вслед за мышкой, и для гладкого поворота из левой верхней четверти круга в верхнюю нижнюю без этого пришлось бы поизвращаться. В конце концов, все эти гайды существуют для обучения, они не рассчитаны на работу проектах в более сложных, чем демка в один экран.
Почему возникли подозрения в скорости lerp'а: ну, например, потому что он принимает разные типы данных, а значит могла бы существовать более строго типизированная функция, которая работает быстрее. Или ещё почему. Хз, что там за код под капотом. Я спросил в треде, потому что тут, может быть, есть кто-то, кто копался в исходниках и смотрел, как оно там реализовано.
Что касается "преждевременной" оптимизации. Лучше я сразу напишу оптимальный код, чем напишу сначала не оптимальный, а потом буду оптимизировать. Времени на написание кода уйдёт одинаково, зато потом на оптимизации сэкономлю. А ещё я узнаю что-то новое, если попробую какой-то метод, который прежде не пробовал.
Такие дела.
>>62448
Нет. Лучше написать lerp в лоб, потом посмотреть а есть ли тормоза, потом в профайлере посмотреть что они реально в этом месте, и только потом переделывать. Разгадка проста - твой lerp может занимать 0,00000001% кадра. Это экономия на спичках.
Нет. Лучше написать lerp в лоб, потом посмотреть а есть ли тормоза, потом в профайлере посмотреть что они реально в этом месте, и только потом переделывать. Разгадка проста - твой lerp может занимать 0,00000001% кадра. Это экономия на спичках.
>>62512
Самая главная проблема преждевременных оптимизаций не в том, что может быть экономия на спичках; порой каждая спичка имеет цену. Самая главная проблема в том, что пока он >>62448 будет искать самый оптимальный способ решения какой-то абстрактной задачи, он будет занят только этой задачей, забыв про собственно разработку конкретной игры. Это как движкописательство, вот ты заметил, что твоей игре в твоём движке не хватает какого-то компонента, сел его писать, и через несколько недель у тебя есть превосходная версия компонента, само совершенство, идеальный код, но за всё это время ты не вспоминал об игре, ради которой этот компонент делался, и в итоге возвращаться к игре трудно... а самое страшное, что после возврата к игре окажется, что планировавшаяся в игре фича неинтересна или работает не так, как хотелось, поэтому написанный за эти недели идеальный компонент придётся убрать в ящик идеальных, но бесполезных вещей, и больше никогда не использовать.
Короче, преимущество движков типа Godot в быстром прототипировании - можно одним пальцем накидать заготовку игры, поиграть в неё и определиться, что нужно для финальной игры. А потом можно даже выкинуть Godot и взять что-то более узкоспециализированное, более сложное в работе, потому что к тому моменту у тебя будет чёткое понимание того, что нужно игре. Раньше игры было трудно делать не потому, что не было простых в освоении готовых инструментов, а потому, что прототипы делались месяцами, а потом выкидывались тем же образом, что выкидываются проекты-однодневки сегодня.
>Разгадка проста - твой lerp может занимать 0,00000001% кадра. Это экономия на спичках.
Самая главная проблема преждевременных оптимизаций не в том, что может быть экономия на спичках; порой каждая спичка имеет цену. Самая главная проблема в том, что пока он >>62448 будет искать самый оптимальный способ решения какой-то абстрактной задачи, он будет занят только этой задачей, забыв про собственно разработку конкретной игры. Это как движкописательство, вот ты заметил, что твоей игре в твоём движке не хватает какого-то компонента, сел его писать, и через несколько недель у тебя есть превосходная версия компонента, само совершенство, идеальный код, но за всё это время ты не вспоминал об игре, ради которой этот компонент делался, и в итоге возвращаться к игре трудно... а самое страшное, что после возврата к игре окажется, что планировавшаяся в игре фича неинтересна или работает не так, как хотелось, поэтому написанный за эти недели идеальный компонент придётся убрать в ящик идеальных, но бесполезных вещей, и больше никогда не использовать.
Короче, преимущество движков типа Godot в быстром прототипировании - можно одним пальцем накидать заготовку игры, поиграть в неё и определиться, что нужно для финальной игры. А потом можно даже выкинуть Godot и взять что-то более узкоспециализированное, более сложное в работе, потому что к тому моменту у тебя будет чёткое понимание того, что нужно игре. Раньше игры было трудно делать не потому, что не было простых в освоении готовых инструментов, а потому, что прототипы делались месяцами, а потом выкидывались тем же образом, что выкидываются проекты-однодневки сегодня.
Сука. Сделал ветвистое дерево анимаций. Всё работает, красота. В одном месте решил поэкспериментировать, воткнуть дополнительный модуль. Всё повисло, причём не просто намертво, а завесило всю систему вместе с мышью и клавой - а так подвесить линух это надо постараться. Причём сначала только годот перестал реагировать, а секунд через 10 мышь начала терять фпс.
Ок, ребут. Последнее сохранение-то, думаю я, было до того, что вызвало это подвисание. Загружаю проект, нажимаю на ноду дерева_анимаций - и она не нажимается, а снова всё вешает. После нескольких попыток я понял, что любое нажатие хоть левой, хоть правой кнопкой вызывает подвисание. Походу, годоте сам граф дерева не нравится.
Открыл в текстовом редакторе файл сцены, нашёл там дерево анимации, стёр. Предварительно забэкапив, конечно же. Часа за два сделал дерево заново. Начал тестить, случайно рассоединил в одном месте. Соединил обратно, и оно снова зависло. И снова это зависание каким-то неведомым образом записалось в файл сцены.
Особая вкуснота ситуация в том, что у меня не винда, а линух. А его подвесить это надо постараться.
Сборкой 3.2.2 пробовал открывать. Точно так же виснет.
Скачал виндовс-версию, запустил через Wine. При нажатии на дерево анимации на пару секунд годотя подвисла, но потом нормально его открыла.
Такой вот опыт.
Ок, ребут. Последнее сохранение-то, думаю я, было до того, что вызвало это подвисание. Загружаю проект, нажимаю на ноду дерева_анимаций - и она не нажимается, а снова всё вешает. После нескольких попыток я понял, что любое нажатие хоть левой, хоть правой кнопкой вызывает подвисание. Походу, годоте сам граф дерева не нравится.
Открыл в текстовом редакторе файл сцены, нашёл там дерево анимации, стёр. Предварительно забэкапив, конечно же. Часа за два сделал дерево заново. Начал тестить, случайно рассоединил в одном месте. Соединил обратно, и оно снова зависло. И снова это зависание каким-то неведомым образом записалось в файл сцены.
Особая вкуснота ситуация в том, что у меня не винда, а линух. А его подвесить это надо постараться.
Сборкой 3.2.2 пробовал открывать. Точно так же виснет.
Скачал виндовс-версию, запустил через Wine. При нажатии на дерево анимации на пару секунд годотя подвисла, но потом нормально его открыла.
Такой вот опыт.
>>62536
Попытка сохранить вин-версией и открыть заново линуксовой провалилась. Пересохранённое дерево всё равно виснет. Попробовал оставить в подвисшем состоянии, через пару минут годо упало.
Попытка сохранить вин-версией и открыть заново линуксовой провалилась. Пересохранённое дерево всё равно виснет. Попробовал оставить в подвисшем состоянии, через пару минут годо упало.
>>62542
По самые помидоры? Ммм... Это сюжет для новой игры!
По самые помидоры? Ммм... Это сюжет для новой игры!
>>62561
Но ведь они же голуби
Но ведь они же голуби
Еее! ГОДОТ!
https://youtu.be/UEDEIksGEjQ
https://youtu.be/UEDEIksGEjQ
И в категории мобилок:
https://youtu.be/AIapugketbs
https://youtu.be/AIapugketbs
>>62536
Я нашёл твою проблему, ты упомянул её как минимум дважды:
Если серьёзно, сколько у тебя RAM и как настроен файл подкачки? Полный висяк линукса мне очень хорошо знаком, у меня он часто происходил из-за переполнения физической RAM без файла подкачки (разные дистрибутивы, 3 полностью разных машины). Учитывая то, что редактор Godot очень любит кушать память (VRAM в т.ч., а при её нехватке отбирается RAM), подозреваю, что у тебя в сцене с деревом анимаций происходит резкое переполнение RAM, которое и вешает линукс. Почему на Windows/Wine такого не случается? У Windows работа с памятью устроена как-то иначе, из моего опыта она стремится во что бы то ни стало сохранить стабильность своих процессов, убивая самые толстые пользовательские процессы, но только когда заканчивается RAM+файл подкачки; т.о. даже забитая до предела память не вешает системные процессы, а только создаёт тормоза на несколько секунд (пока приложение не отдаст память обратно) и некоторые минимальные глюки (диспетчер рабочего стола Explorer может упасть и загрузиться с небольшими глюками, видимо он не входит в число бережно защищаемых процессов).
Короч, попробуй включить/увеличить файл подкачки, по идее должно помочь. И посмотри по диспетчеру задач, что происходит с памятью/процессом Godot сразу после нажатия на файл сцены, если происходит резкий всплеск потребления памяти - это точно оно.
Я нашёл твою проблему, ты упомянул её как минимум дважды:
>линух
Если серьёзно, сколько у тебя RAM и как настроен файл подкачки? Полный висяк линукса мне очень хорошо знаком, у меня он часто происходил из-за переполнения физической RAM без файла подкачки (разные дистрибутивы, 3 полностью разных машины). Учитывая то, что редактор Godot очень любит кушать память (VRAM в т.ч., а при её нехватке отбирается RAM), подозреваю, что у тебя в сцене с деревом анимаций происходит резкое переполнение RAM, которое и вешает линукс. Почему на Windows/Wine такого не случается? У Windows работа с памятью устроена как-то иначе, из моего опыта она стремится во что бы то ни стало сохранить стабильность своих процессов, убивая самые толстые пользовательские процессы, но только когда заканчивается RAM+файл подкачки; т.о. даже забитая до предела память не вешает системные процессы, а только создаёт тормоза на несколько секунд (пока приложение не отдаст память обратно) и некоторые минимальные глюки (диспетчер рабочего стола Explorer может упасть и загрузиться с небольшими глюками, видимо он не входит в число бережно защищаемых процессов).
Короч, попробуй включить/увеличить файл подкачки, по идее должно помочь. И посмотри по диспетчеру задач, что происходит с памятью/процессом Godot сразу после нажатия на файл сцены, если происходит резкий всплеск потребления памяти - это точно оно.
34 Кб, 267x886Годаны! Как же охуенно клепаются интерфейсы в годоте, если юзать боксконтейнеры! Прям веб-вёрстка какая-то получается. Не нужно заботиться о расположении элементов (anchor), всё размещается само, как ты один раз настроил, как бы не менялось окно. И даже при уменьшении более менее сохраняется внятность интерфейса, хотя я понимаю, что при совсем уж уменьшении надо бы масштабировать отдельно скриптом. Но суть в том, что как поют в рекламе корпораций - без единой строчки кода полноценный лук эн фил!
>>62600
Погоди-ка, я правильно понимаю, что ты предлагаешь рекурсивному процессу, отжирающему всю доступную память, дать ещё памяти, чтобы он сожрал и её?
График потребления памяти рос равномерными такими ступеньками. И да, до потолка, а потом и своп. А перед тем, как начать жрать память, на 100% нагрузилось первое ядро процессора.
Вайн сандбоксит приложения, вроде как, поэтому у него краш случается гораздо быстрее, до достижения предела памяти. А вот почему вин-версия иногда вообще не пытается ничего сожрать, и граф открывается за пару секунд, не отъедая память, вот это не очень понятно.
>>62552
Скину, когда точно перепробую все варианты. Да и не очень понятно, как его скидывать: не весь же проект в архив запихивать, там говнокод и заглушки, нельзя такое показывать; а вне проекта не факт, что баг воспроизведётся.
Погоди-ка, я правильно понимаю, что ты предлагаешь рекурсивному процессу, отжирающему всю доступную память, дать ещё памяти, чтобы он сожрал и её?
График потребления памяти рос равномерными такими ступеньками. И да, до потолка, а потом и своп. А перед тем, как начать жрать память, на 100% нагрузилось первое ядро процессора.
Вайн сандбоксит приложения, вроде как, поэтому у него краш случается гораздо быстрее, до достижения предела памяти. А вот почему вин-версия иногда вообще не пытается ничего сожрать, и граф открывается за пару секунд, не отъедая память, вот это не очень понятно.
>>62552
Скину, когда точно перепробую все варианты. Да и не очень понятно, как его скидывать: не весь же проект в архив запихивать, там говнокод и заглушки, нельзя такое показывать; а вне проекта не факт, что баг воспроизведётся.
>>62600
(Автор этого поста был забанен. Помянем.)
>Я нашёл твою проблему, ты упомянул её как минимум дважды:
>godot
(Автор этого поста был забанен. Помянем.)
25 Кб, 724x469Один вот уже допизделся, забыл, что выкатился из своего загона. Репорт ушёл на золото.
>>62662
Какой-то грубый тон однако чувствую я.
Да. Ведь когда-нибудь он остановится, так? Рекурсивные процессы не бывают бесконечными - в какой-то момент переполняется стек вызовов и всё рушится, но в твоём случае ему просто нужно больше памяти (а тебе - не строить такие деревья). Даже если у тебя файл подкачки на SSD, ничего страшного не случится, в следующий раз просто не будешь делать такие жирные сцены.
Возможно, какой-то баг конкретно линуксовой версии, попробуй открыть issue на гитхабе.
Вообще, ты так бойко отвечаешь, будто хочешь сказать "я и без тебя всё это знал" или будто обиделся, что линукс, оказывается, проще уронить, чем винду. А ведь я просто попытался подсказать, в чём может быть проблема. С:
>>62670
Если немного подумать, в чём-то ты прав. У Godot как минимум какое-то фиговое хранение сцен. То есть если уровней вложенности мало, всё ОК, но как только ты пытаешься вложить сцену в сцену в сцену в сцену, в какой-то момент всё начинает дико тормозить на СОХРАНЕНИИ этой сцены, и это очень огорчает.
>Погоди-ка, я правильно понимаю
Какой-то грубый тон однако чувствую я.
>ты предлагаешь рекурсивному процессу, отжирающему всю доступную память, дать ещё памяти, чтобы он сожрал и её?
Да. Ведь когда-нибудь он остановится, так? Рекурсивные процессы не бывают бесконечными - в какой-то момент переполняется стек вызовов и всё рушится, но в твоём случае ему просто нужно больше памяти (а тебе - не строить такие деревья). Даже если у тебя файл подкачки на SSD, ничего страшного не случится, в следующий раз просто не будешь делать такие жирные сцены.
>А вот почему вин-версия иногда вообще не пытается ничего сожрать, и граф открывается за пару секунд, не отъедая память, вот это не очень понятно.
Возможно, какой-то баг конкретно линуксовой версии, попробуй открыть issue на гитхабе.
Вообще, ты так бойко отвечаешь, будто хочешь сказать "я и без тебя всё это знал" или будто обиделся, что линукс, оказывается, проще уронить, чем винду. А ведь я просто попытался подсказать, в чём может быть проблема. С:
>>62670
Если немного подумать, в чём-то ты прав. У Godot как минимум какое-то фиговое хранение сцен. То есть если уровней вложенности мало, всё ОК, но как только ты пытаешься вложить сцену в сцену в сцену в сцену, в какой-то момент всё начинает дико тормозить на СОХРАНЕНИИ этой сцены, и это очень огорчает.
>>62674
Я сюда залез, потому что пытаюсь сделать игру на Godot, очевидно же)
А пост было в том смысле, что он >>62610 открыл Америку - древовидные GUI с контейнерами были ещё в первых RAD. Godot может многим похвастаться, но древовидный GUI - это не изобретение Godot, вот я о чём.
>Ну и делай игры в своем дельфи. К нам-то в тред чего залез и ноешь?
Я сюда залез, потому что пытаюсь сделать игру на Godot, очевидно же)
А пост было в том смысле, что он >>62610 открыл Америку - древовидные GUI с контейнерами были ещё в первых RAD. Godot может многим похвастаться, но древовидный GUI - это не изобретение Godot, вот я о чём.
>>62674
Их там два с половиной экрана по 1080p. Я пересоздавал сцену, копипастил анимации, задолбался. Больше чёт не хочется.
У меня почему-то эта кнопочка неактивна. Можно попытаться сохранить tree_root, но работает это весьма криво.
Не вижу, почему бы ему не быть достаточно прожорливым, чтобы не всосать ещё пару гигов, которые я чисто теоретически мог бы ему дать.
Переделать дерево анимаций - это да, это мне видится единственным адекватным решением. Перераспределить по стейт-машинам, чтобы было меньше всяких блендов.
Ты зря пытаешься уловить интонации в печатном тексте.
Я так отвечаю, потому что в моём понимании это нелогично: дать ещё памяти, если процесс без причины съедает её всю. Это всё равно что пытаться затушить пожар из ведра и кастрюли, когда одного ведра оказалось мало. Да, наверное, если дать терабайт подкачки, может, что-то и получится. Но это всё равно очень сомнительно.
Если быть точным, там полнейший бардак. Ресурсы раскиданы по файлу без какого-либо порядка, ссылаются друг на друга по номерам, которые тоже не по порядку. Я хотел аккуратненько вырезать дерево вместе со всеми внутренностями, но оказалось, что это не так-то легко сделать. Почему там нет хотя бы подобия иерархической структуры не очень понятно.
>В анимплеере анимации тоже схорони в файлы.
Их там два с половиной экрана по 1080p. Я пересоздавал сцену, копипастил анимации, задолбался. Больше чёт не хочется.
>Сохрани ресурс в ресурсный файл
У меня почему-то эта кнопочка неактивна. Можно попытаться сохранить tree_root, но работает это весьма криво.
>Рекурсивные процессы не бывают бесконечными
Не вижу, почему бы ему не быть достаточно прожорливым, чтобы не всосать ещё пару гигов, которые я чисто теоретически мог бы ему дать.
>в следующий раз просто не будешь делать такие жирные сцены.
Переделать дерево анимаций - это да, это мне видится единственным адекватным решением. Перераспределить по стейт-машинам, чтобы было меньше всяких блендов.
>Вообще, ты так бойко отвечаешь, будто хочешь сказать "я и без тебя всё это знал" или будто обиделся, что линукс
Ты зря пытаешься уловить интонации в печатном тексте.
Я так отвечаю, потому что в моём понимании это нелогично: дать ещё памяти, если процесс без причины съедает её всю. Это всё равно что пытаться затушить пожар из ведра и кастрюли, когда одного ведра оказалось мало. Да, наверное, если дать терабайт подкачки, может, что-то и получится. Но это всё равно очень сомнительно.
>У Godot как минимум какое-то фиговое хранение сцен.
Если быть точным, там полнейший бардак. Ресурсы раскиданы по файлу без какого-либо порядка, ссылаются друг на друга по номерам, которые тоже не по порядку. Я хотел аккуратненько вырезать дерево вместе со всеми внутренностями, но оказалось, что это не так-то легко сделать. Почему там нет хотя бы подобия иерархической структуры не очень понятно.
>>62716
А вот же, глянь, анончик сначала юзал дерево, потом заменил его на КА: >>60760 >>60749 и получил нехилый буст, судя по его восторженному тону.
> Переделать дерево анимаций — это да, это мне видится единственным адекватным решением. Перераспределить по стейт-машинам, чтобы было меньше всяких блендов.
А вот же, глянь, анончик сначала юзал дерево, потом заменил его на КА: >>60760 >>60749 и получил нехилый буст, судя по его восторженному тону.
>>62716
Поэтому я лично рекомендую все ресурсы по возможности сохранять в отдельные файлы. Файл tscn по возможности должен содержать ТОЛЬКО пути к файлам ресурсов. Но вообще, это сложно, когда привык лепить ресурсы, как это принято в видеотуториалах. Вот я специально для тебя заморочился и сохранил все вложенные ресурсы одной из своих сцен в отдельные файлы. Файл сцены похудел очень сильно (я не подумал заранее и не запомнил предыдущий размер, было около 40 Кб, стало 2 Кб). Пикрелейтед содержание начала файла вместо длинных текстов с описаниями ресурсов.
И ещё одна полезная фишка: Файлы tscn - это текстовые файлы, есть бинарный формат scn, который сильно тоньше (вышеуказанная сплеш-сцена в бинарном виде стала 1 Кб). То же самое с ресурсами, когда ты их сохраняешь через "сохранить как", тебе диалог предлагает фильтр .tres, .material или *.anim, так вот tres - текстовый и раза в два больше, чем файлы с аббревиатурой ресурса. Выглядят бинарные сцены и ресурсы как второй пик.
Вроде как при экспорте это всё равно в ПАК-файл конвертируется как бинарное, но это не точно. В любом случае, ты можешь нехило бустануть работу с проектом в редакторе, если будешь сохранять всё в бинарные форматы. А если требуется что-то ручками в блокноте подшаманить - всегда можно сохранить копию в текстовый формат, подшаманить, открыть, проверить что всё норм и пересохранить в бинарном.
> Если быть точным, там полнейший бардак. Ресурсы раскиданы по файлу без какого-либо порядка, ссылаются друг на друга по номерам, которые тоже не по порядку. Я хотел аккуратненько вырезать дерево вместе со всеми внутренностями, но оказалось, что это не так-то легко сделать. Почему там нет хотя бы подобия иерархической структуры не очень понятно.
Поэтому я лично рекомендую все ресурсы по возможности сохранять в отдельные файлы. Файл tscn по возможности должен содержать ТОЛЬКО пути к файлам ресурсов. Но вообще, это сложно, когда привык лепить ресурсы, как это принято в видеотуториалах. Вот я специально для тебя заморочился и сохранил все вложенные ресурсы одной из своих сцен в отдельные файлы. Файл сцены похудел очень сильно (я не подумал заранее и не запомнил предыдущий размер, было около 40 Кб, стало 2 Кб). Пикрелейтед содержание начала файла вместо длинных текстов с описаниями ресурсов.
И ещё одна полезная фишка: Файлы tscn - это текстовые файлы, есть бинарный формат scn, который сильно тоньше (вышеуказанная сплеш-сцена в бинарном виде стала 1 Кб). То же самое с ресурсами, когда ты их сохраняешь через "сохранить как", тебе диалог предлагает фильтр .tres, .material или *.anim, так вот tres - текстовый и раза в два больше, чем файлы с аббревиатурой ресурса. Выглядят бинарные сцены и ресурсы как второй пик.
Вроде как при экспорте это всё равно в ПАК-файл конвертируется как бинарное, но это не точно. В любом случае, ты можешь нехило бустануть работу с проектом в редакторе, если будешь сохранять всё в бинарные форматы. А если требуется что-то ручками в блокноте подшаманить - всегда можно сохранить копию в текстовый формат, подшаманить, открыть, проверить что всё норм и пересохранить в бинарном.
>>62716
Ох, я тебе говорю - если ты в следующий раз столкнёшься с такой проблемой, просто докинь ещё гигов 8 памяти, а потом удали из сцены всё лишнее, чтобы она больше так не делала. Это только чтобы попытаться разрулить ситуацию, которую сам же случайно и создал, чтобы не пределывать всё с нуля с тем же результатом.
Или в линуксе файл подкачки занимает фиксированное пространство? Когда я пользовался, там вроде вместо "файла" была "папка подкачки"... У меня на Windows сейчас 8 ГБ физической RAM, 2 ГБ исходного файла подкачки (на всякий случай) и верхний предел 16 ГБ, чтобы в сумме получалось 24 ГБ. Раньше было меньше (16 ГБ в сумме), недавно расширил, т.к. заметил переполнение, когда попытался поиграть в одну игру, не закрывая редактор Godot...
Условно, может быть два варианта:
1. Процесс заглючил и вошёл в бесконечный цикл и будет жрать столько, сколько дадут;
2. Процесс в порядке, просто ты задал ему слишком тяжёлую задачу, ресурсов не хватает.
Ты думаешь про 1-й вариант, а я тебе говорю про 2-й. Тем более, как я уже говорил, у меня линукс вис намертво от простейшего переполнения памяти, а это как минимум говорит о том, что железо не тянет (в моём случае памяти реально мало было, <1 ГБ). Если физическая оператива не тянет и нет возможности её проапгрейдить (как у меня, 8 ГБ потолок), остаётся только расширять файл подкачки (подкачка с SSD вообще незаметна), если хочешь стабильно работать с тяжёлыми проектами. А то у тебя так и будет всё чуть что падать от переполнения...
Вариант с бесконечной утечкой памяти, разумеется, возможен, но узнать наверняка это невозможно, всегда возможна ситуация "ещё бы полгига докинуть сверху и всё завершилось бы" - не попробуешь, не узнаешь. Это вроде бы относится к принципиально неразрешимой задаче останова...
Глупости. Просто скажи, что тебе лень докинуть десяток гигабайт про запас и забыть об этом)
>>62734
У меня как раз с таким методом сохранения получилась какая-то фигня, правда у меня получается что-то вроде "tscn <- tscn <- tscn <- tscn <- tscn <- tscn", очень глубокая степень вложенности, может из-за этого сохранение так жутко тормозит.
>Не вижу, почему бы ему не быть достаточно прожорливым, чтобы не всосать ещё пару гигов, которые я чисто теоретически мог бы ему дать.
Ох, я тебе говорю - если ты в следующий раз столкнёшься с такой проблемой, просто докинь ещё гигов 8 памяти, а потом удали из сцены всё лишнее, чтобы она больше так не делала. Это только чтобы попытаться разрулить ситуацию, которую сам же случайно и создал, чтобы не пределывать всё с нуля с тем же результатом.
Или в линуксе файл подкачки занимает фиксированное пространство? Когда я пользовался, там вроде вместо "файла" была "папка подкачки"... У меня на Windows сейчас 8 ГБ физической RAM, 2 ГБ исходного файла подкачки (на всякий случай) и верхний предел 16 ГБ, чтобы в сумме получалось 24 ГБ. Раньше было меньше (16 ГБ в сумме), недавно расширил, т.к. заметил переполнение, когда попытался поиграть в одну игру, не закрывая редактор Godot...
>в моём понимании это нелогично: дать ещё памяти, если процесс без причины съедает её всю
Условно, может быть два варианта:
1. Процесс заглючил и вошёл в бесконечный цикл и будет жрать столько, сколько дадут;
2. Процесс в порядке, просто ты задал ему слишком тяжёлую задачу, ресурсов не хватает.
Ты думаешь про 1-й вариант, а я тебе говорю про 2-й. Тем более, как я уже говорил, у меня линукс вис намертво от простейшего переполнения памяти, а это как минимум говорит о том, что железо не тянет (в моём случае памяти реально мало было, <1 ГБ). Если физическая оператива не тянет и нет возможности её проапгрейдить (как у меня, 8 ГБ потолок), остаётся только расширять файл подкачки (подкачка с SSD вообще незаметна), если хочешь стабильно работать с тяжёлыми проектами. А то у тебя так и будет всё чуть что падать от переполнения...
Вариант с бесконечной утечкой памяти, разумеется, возможен, но узнать наверняка это невозможно, всегда возможна ситуация "ещё бы полгига докинуть сверху и всё завершилось бы" - не попробуешь, не узнаешь. Это вроде бы относится к принципиально неразрешимой задаче останова...
>Да, наверное, если дать терабайт подкачки, может, что-то и получится.
Глупости. Просто скажи, что тебе лень докинуть десяток гигабайт про запас и забыть об этом)
>>62734
>рекомендую все ресурсы по возможности сохранять в отдельные файлы
У меня как раз с таким методом сохранения получилась какая-то фигня, правда у меня получается что-то вроде "tscn <- tscn <- tscn <- tscn <- tscn <- tscn", очень глубокая степень вложенности, может из-за этого сохранение так жутко тормозит.
>>62716
Ох, я тебе говорю - если ты в следующий раз столкнёшься с такой проблемой, просто докинь ещё гигов 8 памяти, а потом удали из сцены всё лишнее, чтобы она больше так не делала. Это только чтобы попытаться разрулить ситуацию, которую сам же случайно и создал, чтобы не пределывать всё с нуля с тем же результатом.
Или в линуксе файл подкачки занимает фиксированное пространство? Когда я пользовался, там вроде вместо "файла" была "папка подкачки"... У меня на Windows сейчас 8 ГБ физической RAM, 2 ГБ исходного файла подкачки (на всякий случай) и верхний предел 16 ГБ, чтобы в сумме получалось 24 ГБ. Раньше было меньше (16 ГБ в сумме), недавно расширил, т.к. заметил переполнение, когда попытался поиграть в одну игру, не закрывая редактор Godot...
Условно, может быть два варианта:
1. Процесс заглючил и вошёл в бесконечный цикл и будет жрать столько, сколько дадут;
2. Процесс в порядке, просто ты задал ему слишком тяжёлую задачу, ресурсов не хватает.
Ты думаешь про 1-й вариант, а я тебе говорю про 2-й. Тем более, как я уже говорил, у меня линукс вис намертво от простейшего переполнения памяти, а это как минимум говорит о том, что железо не тянет (в моём случае памяти реально мало было, <1 ГБ). Если физическая оператива не тянет и нет возможности её проапгрейдить (как у меня, 8 ГБ потолок), остаётся только расширять файл подкачки (подкачка с SSD вообще незаметна), если хочешь стабильно работать с тяжёлыми проектами. А то у тебя так и будет всё чуть что падать от переполнения...
Вариант с бесконечной утечкой памяти, разумеется, возможен, но узнать наверняка это невозможно, всегда возможна ситуация "ещё бы полгига докинуть сверху и всё завершилось бы" - не попробуешь, не узнаешь. Это вроде бы относится к принципиально неразрешимой задаче останова...
Глупости. Просто скажи, что тебе лень докинуть десяток гигабайт про запас и забыть об этом)
>>62734
У меня как раз с таким методом сохранения получилась какая-то фигня, правда у меня получается что-то вроде "tscn <- tscn <- tscn <- tscn <- tscn <- tscn", очень глубокая степень вложенности, может из-за этого сохранение так жутко тормозит.
>Не вижу, почему бы ему не быть достаточно прожорливым, чтобы не всосать ещё пару гигов, которые я чисто теоретически мог бы ему дать.
Ох, я тебе говорю - если ты в следующий раз столкнёшься с такой проблемой, просто докинь ещё гигов 8 памяти, а потом удали из сцены всё лишнее, чтобы она больше так не делала. Это только чтобы попытаться разрулить ситуацию, которую сам же случайно и создал, чтобы не пределывать всё с нуля с тем же результатом.
Или в линуксе файл подкачки занимает фиксированное пространство? Когда я пользовался, там вроде вместо "файла" была "папка подкачки"... У меня на Windows сейчас 8 ГБ физической RAM, 2 ГБ исходного файла подкачки (на всякий случай) и верхний предел 16 ГБ, чтобы в сумме получалось 24 ГБ. Раньше было меньше (16 ГБ в сумме), недавно расширил, т.к. заметил переполнение, когда попытался поиграть в одну игру, не закрывая редактор Godot...
>в моём понимании это нелогично: дать ещё памяти, если процесс без причины съедает её всю
Условно, может быть два варианта:
1. Процесс заглючил и вошёл в бесконечный цикл и будет жрать столько, сколько дадут;
2. Процесс в порядке, просто ты задал ему слишком тяжёлую задачу, ресурсов не хватает.
Ты думаешь про 1-й вариант, а я тебе говорю про 2-й. Тем более, как я уже говорил, у меня линукс вис намертво от простейшего переполнения памяти, а это как минимум говорит о том, что железо не тянет (в моём случае памяти реально мало было, <1 ГБ). Если физическая оператива не тянет и нет возможности её проапгрейдить (как у меня, 8 ГБ потолок), остаётся только расширять файл подкачки (подкачка с SSD вообще незаметна), если хочешь стабильно работать с тяжёлыми проектами. А то у тебя так и будет всё чуть что падать от переполнения...
Вариант с бесконечной утечкой памяти, разумеется, возможен, но узнать наверняка это невозможно, всегда возможна ситуация "ещё бы полгига докинуть сверху и всё завершилось бы" - не попробуешь, не узнаешь. Это вроде бы относится к принципиально неразрешимой задаче останова...
>Да, наверное, если дать терабайт подкачки, может, что-то и получится.
Глупости. Просто скажи, что тебе лень докинуть десяток гигабайт про запас и забыть об этом)
>>62734
>рекомендую все ресурсы по возможности сохранять в отдельные файлы
У меня как раз с таким методом сохранения получилась какая-то фигня, правда у меня получается что-то вроде "tscn <- tscn <- tscn <- tscn <- tscn <- tscn", очень глубокая степень вложенности, может из-за этого сохранение так жутко тормозит.
>>62736
Скорее всего. Как я выше написал, форматы с приставкой t - текстовые, соответственно их парсинг будет обладать всеми тормозами работы с текстом. Попробуй организовать
внутри которых
> правда у меня получается что-то вроде "tscn <- tscn <- tscn <- tscn <- tscn <- tscn", очень глубокая степень вложенности, может из-за этого сохранение так жутко тормозит.
Скорее всего. Как я выше написал, форматы с приставкой t - текстовые, соответственно их парсинг будет обладать всеми тормозами работы с текстом. Попробуй организовать
> "scn <- scn <- scn <- scn <- scn <- scn"
внутри которых
> "scn <- res <- material <- texture <- anim <- etc"
>>62737
... И отпишись о результатах, если не затруднит. А я пошёл на боковую. Чот поздно уже.
... И отпишись о результатах, если не затруднит. А я пошёл на боковую. Чот поздно уже.
>>62736
В момент возникновения этой проблемы решать докидывать что-либо будет уже поздно, всё зависнет.
А потом я лучше воспользуюсь вайн-версией для удаления всего лишнего. Нынешний объём подкачки меня устраивает, нет никаких задач (работающих как задумано), где бы мне понадобилось больше.
HDD-боярина благородные речи
Раздел на диске. Увеличить-уменьшить его довольно проблематично.
Ну да. Потому что, если софтина потребляла около ста мегабайт памяти, а потом вдруг после тривиального действия, выполнявшегося прежде без употребления дополнительной памяти, съела 10 гигов, 2-й вариант не выглядит чем-то правдоподобным.
Пиксельное 2д, какие там тяжёлые проекты.
Не, с тяжёлыми я работаю, но это не годот и вообще не геймдев, а обработка звука. И там всё упирается в процессор, а не в память. Мне памяти всегда хватает с запасом.
>>62734
Кстати, дельный совет, только я бы применил его лишь к самым крупным ресурсам. Типа того же дерева анимаций. Потому что они действительно сильно запутывают файл проекта.
Я тут повкладывал бленддеревья одно в другое. Вместо одного огромного разветвлённого бленддерева получилось много маленьких. И это, кажется, сработало. По крайней мере, пока что всё нормально открывается. Да и ориентироваться стало, в общем-то, удобнее.
Теперь воюю с новой странностью:
var a: bool = True #тут сначала было false
var b: float = PI #там могут быть разные значения от -PI до PI, это на самом деле результат работы angle_to
print(b)
#3.14...
if a and abs(b) > PI/2:
#и тут мы падаем с ошибкой:
#Invalid type in built-in function 'abs'. Cannot convert argument 1 from Nil to float
Я даже явным образом задавал значение b непосредственно перед проблемным местом. Если непосредственно перед условным блоком написать var c = abs(b) и потом в условие добавлять это самое c, то всё работает. Либо это какое-то очень сильное колдунство, либо я чего-то не знаю о том, как работают условия в гдскрипте. Либо просто спать ночью надо было.
>если ты в следующий раз столкнёшься с такой проблемой
В момент возникновения этой проблемы решать докидывать что-либо будет уже поздно, всё зависнет.
А потом я лучше воспользуюсь вайн-версией для удаления всего лишнего. Нынешний объём подкачки меня устраивает, нет никаких задач (работающих как задумано), где бы мне понадобилось больше.
>просто докинь ещё гигов 8 памяти
>Просто скажи, что тебе лень докинуть десяток гигабайт про запас
HDD-боярина благородные речи
>Когда я пользовался, там вроде вместо "файла" была "папка подкачки"
Раздел на диске. Увеличить-уменьшить его довольно проблематично.
>Ты думаешь про 1-й вариант, а я тебе говорю про 2-й.
Ну да. Потому что, если софтина потребляла около ста мегабайт памяти, а потом вдруг после тривиального действия, выполнявшегося прежде без употребления дополнительной памяти, съела 10 гигов, 2-й вариант не выглядит чем-то правдоподобным.
>если хочешь стабильно работать с тяжёлыми проектами.
Пиксельное 2д, какие там тяжёлые проекты.
Не, с тяжёлыми я работаю, но это не годот и вообще не геймдев, а обработка звука. И там всё упирается в процессор, а не в память. Мне памяти всегда хватает с запасом.
>>62734
>рекомендую все ресурсы по возможности сохранять в отдельные файлы.
Кстати, дельный совет, только я бы применил его лишь к самым крупным ресурсам. Типа того же дерева анимаций. Потому что они действительно сильно запутывают файл проекта.
Я тут повкладывал бленддеревья одно в другое. Вместо одного огромного разветвлённого бленддерева получилось много маленьких. И это, кажется, сработало. По крайней мере, пока что всё нормально открывается. Да и ориентироваться стало, в общем-то, удобнее.
Теперь воюю с новой странностью:
var a: bool = True #тут сначала было false
var b: float = PI #там могут быть разные значения от -PI до PI, это на самом деле результат работы angle_to
print(b)
#3.14...
if a and abs(b) > PI/2:
#и тут мы падаем с ошибкой:
#Invalid type in built-in function 'abs'. Cannot convert argument 1 from Nil to float
Я даже явным образом задавал значение b непосредственно перед проблемным местом. Если непосредственно перед условным блоком написать var c = abs(b) и потом в условие добавлять это самое c, то всё работает. Либо это какое-то очень сильное колдунство, либо я чего-то не знаю о том, как работают условия в гдскрипте. Либо просто спать ночью надо было.
>>62736
В момент возникновения этой проблемы решать докидывать что-либо будет уже поздно, всё зависнет.
А потом я лучше воспользуюсь вайн-версией для удаления всего лишнего. Нынешний объём подкачки меня устраивает, нет никаких задач (работающих как задумано), где бы мне понадобилось больше.
HDD-боярина благородные речи
Раздел на диске. Увеличить-уменьшить его довольно проблематично.
Ну да. Потому что, если софтина потребляла около ста мегабайт памяти, а потом вдруг после тривиального действия, выполнявшегося прежде без употребления дополнительной памяти, съела 10 гигов, 2-й вариант не выглядит чем-то правдоподобным.
Пиксельное 2д, какие там тяжёлые проекты.
Не, с тяжёлыми я работаю, но это не годот и вообще не геймдев, а обработка звука. И там всё упирается в процессор, а не в память. Мне памяти всегда хватает с запасом.
>>62734
Кстати, дельный совет, только я бы применил его лишь к самым крупным ресурсам. Типа того же дерева анимаций. Потому что они действительно сильно запутывают файл проекта.
Я тут повкладывал бленддеревья одно в другое. Вместо одного огромного разветвлённого бленддерева получилось много маленьких. И это, кажется, сработало. По крайней мере, пока что всё нормально открывается. Да и ориентироваться стало, в общем-то, удобнее.
Теперь воюю с новой странностью:
var a: bool = True #тут сначала было false
var b: float = PI #там могут быть разные значения от -PI до PI, это на самом деле результат работы angle_to
print(b)
#3.14...
if a and abs(b) > PI/2:
#и тут мы падаем с ошибкой:
#Invalid type in built-in function 'abs'. Cannot convert argument 1 from Nil to float
Я даже явным образом задавал значение b непосредственно перед проблемным местом. Если непосредственно перед условным блоком написать var c = abs(b) и потом в условие добавлять это самое c, то всё работает. Либо это какое-то очень сильное колдунство, либо я чего-то не знаю о том, как работают условия в гдскрипте. Либо просто спать ночью надо было.
>если ты в следующий раз столкнёшься с такой проблемой
В момент возникновения этой проблемы решать докидывать что-либо будет уже поздно, всё зависнет.
А потом я лучше воспользуюсь вайн-версией для удаления всего лишнего. Нынешний объём подкачки меня устраивает, нет никаких задач (работающих как задумано), где бы мне понадобилось больше.
>просто докинь ещё гигов 8 памяти
>Просто скажи, что тебе лень докинуть десяток гигабайт про запас
HDD-боярина благородные речи
>Когда я пользовался, там вроде вместо "файла" была "папка подкачки"
Раздел на диске. Увеличить-уменьшить его довольно проблематично.
>Ты думаешь про 1-й вариант, а я тебе говорю про 2-й.
Ну да. Потому что, если софтина потребляла около ста мегабайт памяти, а потом вдруг после тривиального действия, выполнявшегося прежде без употребления дополнительной памяти, съела 10 гигов, 2-й вариант не выглядит чем-то правдоподобным.
>если хочешь стабильно работать с тяжёлыми проектами.
Пиксельное 2д, какие там тяжёлые проекты.
Не, с тяжёлыми я работаю, но это не годот и вообще не геймдев, а обработка звука. И там всё упирается в процессор, а не в память. Мне памяти всегда хватает с запасом.
>>62734
>рекомендую все ресурсы по возможности сохранять в отдельные файлы.
Кстати, дельный совет, только я бы применил его лишь к самым крупным ресурсам. Типа того же дерева анимаций. Потому что они действительно сильно запутывают файл проекта.
Я тут повкладывал бленддеревья одно в другое. Вместо одного огромного разветвлённого бленддерева получилось много маленьких. И это, кажется, сработало. По крайней мере, пока что всё нормально открывается. Да и ориентироваться стало, в общем-то, удобнее.
Теперь воюю с новой странностью:
var a: bool = True #тут сначала было false
var b: float = PI #там могут быть разные значения от -PI до PI, это на самом деле результат работы angle_to
print(b)
#3.14...
if a and abs(b) > PI/2:
#и тут мы падаем с ошибкой:
#Invalid type in built-in function 'abs'. Cannot convert argument 1 from Nil to float
Я даже явным образом задавал значение b непосредственно перед проблемным местом. Если непосредственно перед условным блоком написать var c = abs(b) и потом в условие добавлять это самое c, то всё работает. Либо это какое-то очень сильное колдунство, либо я чего-то не знаю о том, как работают условия в гдскрипте. Либо просто спать ночью надо было.
>>62748
Нет ничего страшного в том, чтобы объявить локальные переменные. Ты даже можешь объявить:
Нет ничего страшного в том, чтобы объявить локальные переменные. Ты даже можешь объявить:
> c : bool = abs(b) > PI/2
> if a and c:
>>62748
Написано что у тебя в b не float, а Nil. Значит ты что то накосячил в своей angle to print. Не инициализировал возврат во всех ветках, к примеру.
Написано что у тебя в b не float, а Nil. Значит ты что то накосячил в своей angle to print. Не инициализировал возврат во всех ветках, к примеру.
>>62837
Притом, что в его посте нет никакой "angle to print"
Есть отдельная строка с angle to
и есть отдельная строка с print
Притом, что в его посте нет никакой "angle to print"
Есть отдельная строка с angle to
и есть отдельная строка с print
10 Кб, 806x265>>62748
Вот поэтому памяти на ПК нужно иметь с запасом. Когда-нибудь да не хватит, тем более когда игры пилишь.
Мой HDD умер от старости. Но с тех пор, как поставил SSD, держу файл подкачки на SSD, ибо так быстрее.
inb4: нет, SSD не изнашивается слишком быстро, за 3/4 года 24/7-аптайма потратилось всего ~2% износа.
Насколько я помню, в линуксе есть несколько видов виртуальной памяти, их можно переключать между собой.
Однако и такое бывает. Достаточно импортнуть какую-нибудь большую модель в 3D-редактор, например.
Всё относительно)
>>62825
Кроме того, что выделение памяти под локальные переменные должно отнимать дополнительное время.
>>62832
Скорее разрешение мелкое какое-нибудь, или вертикальный дисплей. 3:4 уже редко встречается.
>В момент возникновения этой проблемы решать докидывать что-либо будет уже поздно, всё зависнет.
Вот поэтому памяти на ПК нужно иметь с запасом. Когда-нибудь да не хватит, тем более когда игры пилишь.
>HDD-боярина благородные речи
Мой HDD умер от старости. Но с тех пор, как поставил SSD, держу файл подкачки на SSD, ибо так быстрее.
inb4: нет, SSD не изнашивается слишком быстро, за 3/4 года 24/7-аптайма потратилось всего ~2% износа.
>Раздел на диске. Увеличить-уменьшить его довольно проблематично.
Насколько я помню, в линуксе есть несколько видов виртуальной памяти, их можно переключать между собой.
>2-й вариант не выглядит чем-то правдоподобным
Однако и такое бывает. Достаточно импортнуть какую-нибудь большую модель в 3D-редактор, например.
>Пиксельное 2д, какие там тяжёлые проекты.
Всё относительно)
>>62825
>Нет ничего страшного в том, чтобы объявить локальные переменные
Кроме того, что выделение памяти под локальные переменные должно отнимать дополнительное время.
>>62832
Скорее разрешение мелкое какое-нибудь, или вертикальный дисплей. 3:4 уже редко встречается.
>>63086
ну такое может быть только на новом рендеринге, годо на gles2-3, а тут надо gl3.3+ или vulkan
ну такое может быть только на новом рендеринге, годо на gles2-3, а тут надо gl3.3+ или vulkan
>>62748
Оговариваться стал от бессонницы. Причём написал angle_to, глядя в свой же код, где написано b = self.global_position.direction_to(мышь).angle()
>>62830
Я делал даже присваивание непосредственно перед if'ом. То есть, так и писал:
b = PI
а потом, чтобы убедиться, что оно точно-точно присвоилось, добавлял:
print(b)
И всё равно в abs в условии говорил, что b это nil. Тот же самый abs в том же месте кода, но вызванный на строчку выше условного блока, прекрасно переваривает ту же самую b, никаких nil'ов.
>angle_to(b)
Оговариваться стал от бессонницы. Причём написал angle_to, глядя в свой же код, где написано b = self.global_position.direction_to(мышь).angle()
>>62830
>Значит ты что то накосячил в своей angle to print
Я делал даже присваивание непосредственно перед if'ом. То есть, так и писал:
b = PI
а потом, чтобы убедиться, что оно точно-точно присвоилось, добавлял:
print(b)
И всё равно в abs в условии говорил, что b это nil. Тот же самый abs в том же месте кода, но вызванный на строчку выше условного блока, прекрасно переваривает ту же самую b, никаких nil'ов.
>>63163
Сделай b onready и посмотри на реакцию.
Сделай b onready и посмотри на реакцию.
Антончики, вопрос есть. А делает ли кто-нибудь из вас проект полностью на C# вместо GDScript'а? Ну или есть ли в шоукейсе годота, хоть один проект полностью на C#?
Я просто попробовал для интереса, вроде получилось неплохо и мне понравилось, но слегка смущает что по мануалу поддержка C# еще в 'late alpha' стадии.
Я просто попробовал для интереса, вроде получилось неплохо и мне понравилось, но слегка смущает что по мануалу поддержка C# еще в 'late alpha' стадии.
>>63834
Не смущайся. Там реально полностью законченный проект запилить. Есть даже канал, где чел всё на шарпе в годоте кодит и туториалы пилит. Интересует? Поищу.
Не смущайся. Там реально полностью законченный проект запилить. Есть даже канал, где чел всё на шарпе в годоте кодит и туториалы пилит. Интересует? Поищу.
Причесал все анимации, довёл до работоспособного состояния, остался всего один баг, который я пока не знаю, как исправлять (если прервать OneShot другой анимацией, то при повторном вызове ваншота проиграется только окончание, не довыполненное в прошлый раз). Сделал шесть новых видов оружия и к ним шесть видов пуль, довёл до работоспособного состояния, остался всего один баг, который я пока не знаю, как лучше исправить (чтобы у дульной вспышки частицы извергались с темпом стрельбы, даже если он медленнее, чем время жизни астиц, и прекращали извергаться, если стрельба окончена). Сделал красивый ХУД, в котором отображается здоровье, арсенал и патроны, и тут даже каких-либо багов не уловил, вроде норм работает.
Продуктивненько, в общем. Я долго ковырялся с начальной частью, тыкался в непонятные места и всё никак не мог с ними разобраться; стоило это сделать, как работа пошла отличными темпами. Завтра доделываю всякое по мелочи, после чего можно приступать к работе над ИИ. Я совершенно хз, как ему лучше выстраивать логику, поэтому попробую для начала обучить простой генетический алгоритм; если не получится, буду уже глубже копать материалы по этой теме.
Продуктивненько, в общем. Я долго ковырялся с начальной частью, тыкался в непонятные места и всё никак не мог с ними разобраться; стоило это сделать, как работа пошла отличными темпами. Завтра доделываю всякое по мелочи, после чего можно приступать к работе над ИИ. Я совершенно хз, как ему лучше выстраивать логику, поэтому попробую для начала обучить простой генетический алгоритм; если не получится, буду уже глубже копать материалы по этой теме.
>>63893
Двачую ГОАП для ИИ. В библиотеке ассетов есть готовая реализация.
>>63892
Откажись от дерева и перейди на стейтмашину. Я тебе даже пытался помочь разобраться:
>>60749
>>60760
Двачую ГОАП для ИИ. В библиотеке ассетов есть готовая реализация.
>>63892
> если прервать OneShot другой анимацией, то при повторном вызове ваншота проиграется только окончание, не довыполненное в прошлый раз
Откажись от дерева и перейди на стейтмашину. Я тебе даже пытался помочь разобраться:
>>60749
>>60760
>>63892
Лолшто, зачем тебе ГА в игре? И как ты это себе представляешь? Для ГА нужна какая-то виртуальная машина, которая будет исполнять генетический код, при этом сложность кода должна быть мизерной, иначе годное решение никогда не найдётся.
На ГА удобно сделать симуляцию жизни популяции организмов, но для обычной игори смысла в ГА нет, игре нужны чёткие алгоритмы поведения ботов.
>попробую для начала обучить простой генетический алгоритм
Лолшто, зачем тебе ГА в игре? И как ты это себе представляешь? Для ГА нужна какая-то виртуальная машина, которая будет исполнять генетический код, при этом сложность кода должна быть мизерной, иначе годное решение никогда не найдётся.
На ГА удобно сделать симуляцию жизни популяции организмов, но для обычной игори смысла в ГА нет, игре нужны чёткие алгоритмы поведения ботов.
>>63996
Затем, что
В конце концов, это любительский проект, важной целью которого является познание. Мне всегда было интересно узнать, как будет выглядеть такой ии в играх, но никогда не попадалось адекватных готовых примеров.
У меня есть некоторые соображения, как сделать, чтобы ГА можно было обучить на достаточно сложные задачи за адекватное время. Например, увеличивать количество доступных входов и выходов по мере обучения, чтобы новую фичу получали только самые стабильные экземпляры.
Затем, что
>попробую
В конце концов, это любительский проект, важной целью которого является познание. Мне всегда было интересно узнать, как будет выглядеть такой ии в играх, но никогда не попадалось адекватных готовых примеров.
У меня есть некоторые соображения, как сделать, чтобы ГА можно было обучить на достаточно сложные задачи за адекватное время. Например, увеличивать количество доступных входов и выходов по мере обучения, чтобы новую фичу получали только самые стабильные экземпляры.
>>63996
Что-то типа кучи ботов с параметрами, из которых в следующее поколение переходят те, что выжили, не?
мимо
>Лолшто, зачем тебе ГА в игре? И как ты это себе представляешь?
Что-то типа кучи ботов с параметрами, из которых в следующее поколение переходят те, что выжили, не?
мимо
>>64001
Всё зависит от того, какой будет исполняющая машина. Может получиться так, что изменяя её параметры, ты будешь делать всех текущих выживальщиков нежизнеспособными. ГА - это не нейронка, в нейронке ты можешь зафиксировать часть нейронов и наращивать новые, а в ГА по идее меняется всё сразу.
>>64022
Так можно только отрегулировать значения параметров (есть/нет/%), это не очень интересно. Грубо говоря, если у твоих ботов есть параметр "цвет", то в конечном итоге они все будут одного выигрышного цвета, и дальше никакой эволюции не будет (хотя окей, выбор идеального значения и есть цель ГА). ГА для ботов можно применить иначе. Щас пример набросаю, надеюсь, не ошибусь...
Сначала задаём исходный алфавит из кодов-команд бота:
0 - ожидание, 1 - идти вперёд, 2/3 - поворот влево/вправо, 4 - атака, 5 - защита, ...
Дальше генерируем каких-нибудь рандомных ботов, примеры:
323534 - вращается на месте, защищается и атакует (ходить не умеет)
121300 - движется по диагонали (ничего кроме этого не умеет)
Предположим, они выжили, скрещиваем, получаем:
323300 - вращается на месте (больше ничего не делает)
121534 - движется по диагонали, иногда защищается и атакует
Вероятно, 121534 будет успешнее предков и брата. Но это абстрактно. Чтобы реально протестировать ботов на успешность, нужны регулирующие условия. Скажем, бот может есть - значит, вокруг разбросана еда, а у бота есть параметр "энергия". Если бот не умеет есть или не находит еду - теряет энергию и погибает раньше всех. Если бот жрёт всё подряд, то еда быстро кончается и он опять же мрёт, хоть и позже. Теоретически, можно выстроить такую цепочку кодов, что бот будет двигаться и потреблять пищу оптимально для конкретной среды обитания. Чтобы эту цепочку найти, мы скрещиваем самых живучих ботов и вносим небольшие мутации:
121534 -> 121434 - теперь бот чаще пытается атаковать/есть, но разучился защищаться
Мутации нужны, скорее всего, потому, что простые комбинации кусочков в конечном итоге потеряют некоторые буквы (например, тут уже потерян 0, а другой бот потерял 1, 4 и 5) или их комбинации (если комбинируем половинками или любыми другими группами, без перемешивания букв), из-за чего наступит однообразие и топтание на одном месте. Ну, тут нужно гуглить реальную генетику.
Так вот... Мы можем расширять алфавит, добавляя разные команды (включая конструкции if/loop, переменные и прочее), можем расширять длину кода, можем добавлять регулирующие условия среды (например, днём жарко, и ботам нужно найти укрытие; боты имеют датчики и условия для проверки, а как ими пользоваться - должны дойти до этого сами через сколько-то поколений бессмысленных смертей, лол). Если всё сделать правильно, то боты за какое-то число поколений (каждое поколение добавляются новички, полученные путём скрещивания выживших или умерших позже всех) должны адаптироваться к любым условиям среды. По сути, в их генах будет хаотически формироваться поведенческая программа, дающая оптимальный вариант для конкретной среды.
Ну, это если рассматривать ботов именно как маленькие программируемые машинки. Если ничего не путаю, ДНК в клетках играет отдалённо похожую роль - коды ДНК описывают белки, рибосомы собирают эти белки, белки делают какую-то работу в клетке, эта работа снаружи клетки наблюдается как поведение клетки. Если описывать не команды поведения, а "параметры", то не будет достаточного разнообразия, я так думаю. Хотя конкретно ГА к параметрам применимо, но мы ведь хотим выработать некое сложное поведение ботов, не так ли?
О, кстати, в описанной модели самое интересное начинается не в генах, а выше - на уровне популяций. Когда ботов много, они могут начать разделяться на виды и кооперироваться. Напоминает колонии одноклеточных, которые в природе тоже объединяются, выживая вместе (и жертвуя собой ради коллектива). Когда-то давно видел такое в одном примере реализации ГА на ютубе...
Ещё небольшая идея - можно рассматривать бота как хранилище подпрограмм, каждая из которых скрещивается индивидуально а-ля хромосома. Подпрограммы могут вызываться из одной главной программы или обращаться друг к другу. Суть подпрограмм в том, что в них могут сформироваться отдельные "навыки" ботов, которые можно зафиксировать, продолжив эволюцию в остальном коде. Тогда если мы дрессируем ботов на определённую задачу и заметили, что они сформировали в одной из подпрограмм подходящее под решение части задачи поведение, мы фиксируем эту подпрограмму, чтобы они не потеряли её из-за последующих скрещиваний и мутаций. Скажем, если некоторые боты научились прятаться в тень от жары, но пока что недостаточно хорошо ищут пропитание.
...так, ладно, я немного запутал, наверное, напишу вкратце:
- бот - исполнитель с набором команд и параметров
- бот погибает, если параметры достигают предела
- из команд бота составляются программы поведения
- первые программки составляются чисто рандомно
- бот исполняет программы в некой среде обитания
- среда имеет параметры вроде еды, освещённости
- сумевшие выжить боты скрещиваются друг с другом
- скрещивание - это склейка половинок программ ботов
- ещё есть мутации - случайные опечатки в программах
...ладно, короч, читайте википедию: https://ru.wikipedia.org/wiki/Генетический_алгоритм
Ну вот, теперь мне жутко захотелось реализовать ГА с ботами на Godot. :C
>увеличивать количество доступных входов и выходов по мере обучения, чтобы новую фичу получали только самые стабильные экземпляры
Всё зависит от того, какой будет исполняющая машина. Может получиться так, что изменяя её параметры, ты будешь делать всех текущих выживальщиков нежизнеспособными. ГА - это не нейронка, в нейронке ты можешь зафиксировать часть нейронов и наращивать новые, а в ГА по идее меняется всё сразу.
>>64022
>Что-то типа кучи ботов с параметрами, из которых в следующее поколение переходят те, что выжили, не?
Так можно только отрегулировать значения параметров (есть/нет/%), это не очень интересно. Грубо говоря, если у твоих ботов есть параметр "цвет", то в конечном итоге они все будут одного выигрышного цвета, и дальше никакой эволюции не будет (хотя окей, выбор идеального значения и есть цель ГА). ГА для ботов можно применить иначе. Щас пример набросаю, надеюсь, не ошибусь...
Сначала задаём исходный алфавит из кодов-команд бота:
0 - ожидание, 1 - идти вперёд, 2/3 - поворот влево/вправо, 4 - атака, 5 - защита, ...
Дальше генерируем каких-нибудь рандомных ботов, примеры:
323534 - вращается на месте, защищается и атакует (ходить не умеет)
121300 - движется по диагонали (ничего кроме этого не умеет)
Предположим, они выжили, скрещиваем, получаем:
323300 - вращается на месте (больше ничего не делает)
121534 - движется по диагонали, иногда защищается и атакует
Вероятно, 121534 будет успешнее предков и брата. Но это абстрактно. Чтобы реально протестировать ботов на успешность, нужны регулирующие условия. Скажем, бот может есть - значит, вокруг разбросана еда, а у бота есть параметр "энергия". Если бот не умеет есть или не находит еду - теряет энергию и погибает раньше всех. Если бот жрёт всё подряд, то еда быстро кончается и он опять же мрёт, хоть и позже. Теоретически, можно выстроить такую цепочку кодов, что бот будет двигаться и потреблять пищу оптимально для конкретной среды обитания. Чтобы эту цепочку найти, мы скрещиваем самых живучих ботов и вносим небольшие мутации:
121534 -> 121434 - теперь бот чаще пытается атаковать/есть, но разучился защищаться
Мутации нужны, скорее всего, потому, что простые комбинации кусочков в конечном итоге потеряют некоторые буквы (например, тут уже потерян 0, а другой бот потерял 1, 4 и 5) или их комбинации (если комбинируем половинками или любыми другими группами, без перемешивания букв), из-за чего наступит однообразие и топтание на одном месте. Ну, тут нужно гуглить реальную генетику.
Так вот... Мы можем расширять алфавит, добавляя разные команды (включая конструкции if/loop, переменные и прочее), можем расширять длину кода, можем добавлять регулирующие условия среды (например, днём жарко, и ботам нужно найти укрытие; боты имеют датчики и условия для проверки, а как ими пользоваться - должны дойти до этого сами через сколько-то поколений бессмысленных смертей, лол). Если всё сделать правильно, то боты за какое-то число поколений (каждое поколение добавляются новички, полученные путём скрещивания выживших или умерших позже всех) должны адаптироваться к любым условиям среды. По сути, в их генах будет хаотически формироваться поведенческая программа, дающая оптимальный вариант для конкретной среды.
Ну, это если рассматривать ботов именно как маленькие программируемые машинки. Если ничего не путаю, ДНК в клетках играет отдалённо похожую роль - коды ДНК описывают белки, рибосомы собирают эти белки, белки делают какую-то работу в клетке, эта работа снаружи клетки наблюдается как поведение клетки. Если описывать не команды поведения, а "параметры", то не будет достаточного разнообразия, я так думаю. Хотя конкретно ГА к параметрам применимо, но мы ведь хотим выработать некое сложное поведение ботов, не так ли?
О, кстати, в описанной модели самое интересное начинается не в генах, а выше - на уровне популяций. Когда ботов много, они могут начать разделяться на виды и кооперироваться. Напоминает колонии одноклеточных, которые в природе тоже объединяются, выживая вместе (и жертвуя собой ради коллектива). Когда-то давно видел такое в одном примере реализации ГА на ютубе...
Ещё небольшая идея - можно рассматривать бота как хранилище подпрограмм, каждая из которых скрещивается индивидуально а-ля хромосома. Подпрограммы могут вызываться из одной главной программы или обращаться друг к другу. Суть подпрограмм в том, что в них могут сформироваться отдельные "навыки" ботов, которые можно зафиксировать, продолжив эволюцию в остальном коде. Тогда если мы дрессируем ботов на определённую задачу и заметили, что они сформировали в одной из подпрограмм подходящее под решение части задачи поведение, мы фиксируем эту подпрограмму, чтобы они не потеряли её из-за последующих скрещиваний и мутаций. Скажем, если некоторые боты научились прятаться в тень от жары, но пока что недостаточно хорошо ищут пропитание.
...так, ладно, я немного запутал, наверное, напишу вкратце:
- бот - исполнитель с набором команд и параметров
- бот погибает, если параметры достигают предела
- из команд бота составляются программы поведения
- первые программки составляются чисто рандомно
- бот исполняет программы в некой среде обитания
- среда имеет параметры вроде еды, освещённости
- сумевшие выжить боты скрещиваются друг с другом
- скрещивание - это склейка половинок программ ботов
- ещё есть мутации - случайные опечатки в программах
...ладно, короч, читайте википедию: https://ru.wikipedia.org/wiki/Генетический_алгоритм
Ну вот, теперь мне жутко захотелось реализовать ГА с ботами на Godot. :C
>>64001
Всё зависит от того, какой будет исполняющая машина. Может получиться так, что изменяя её параметры, ты будешь делать всех текущих выживальщиков нежизнеспособными. ГА - это не нейронка, в нейронке ты можешь зафиксировать часть нейронов и наращивать новые, а в ГА по идее меняется всё сразу.
>>64022
Так можно только отрегулировать значения параметров (есть/нет/%), это не очень интересно. Грубо говоря, если у твоих ботов есть параметр "цвет", то в конечном итоге они все будут одного выигрышного цвета, и дальше никакой эволюции не будет (хотя окей, выбор идеального значения и есть цель ГА). ГА для ботов можно применить иначе. Щас пример набросаю, надеюсь, не ошибусь...
Сначала задаём исходный алфавит из кодов-команд бота:
0 - ожидание, 1 - идти вперёд, 2/3 - поворот влево/вправо, 4 - атака, 5 - защита, ...
Дальше генерируем каких-нибудь рандомных ботов, примеры:
323534 - вращается на месте, защищается и атакует (ходить не умеет)
121300 - движется по диагонали (ничего кроме этого не умеет)
Предположим, они выжили, скрещиваем, получаем:
323300 - вращается на месте (больше ничего не делает)
121534 - движется по диагонали, иногда защищается и атакует
Вероятно, 121534 будет успешнее предков и брата. Но это абстрактно. Чтобы реально протестировать ботов на успешность, нужны регулирующие условия. Скажем, бот может есть - значит, вокруг разбросана еда, а у бота есть параметр "энергия". Если бот не умеет есть или не находит еду - теряет энергию и погибает раньше всех. Если бот жрёт всё подряд, то еда быстро кончается и он опять же мрёт, хоть и позже. Теоретически, можно выстроить такую цепочку кодов, что бот будет двигаться и потреблять пищу оптимально для конкретной среды обитания. Чтобы эту цепочку найти, мы скрещиваем самых живучих ботов и вносим небольшие мутации:
121534 -> 121434 - теперь бот чаще пытается атаковать/есть, но разучился защищаться
Мутации нужны, скорее всего, потому, что простые комбинации кусочков в конечном итоге потеряют некоторые буквы (например, тут уже потерян 0, а другой бот потерял 1, 4 и 5) или их комбинации (если комбинируем половинками или любыми другими группами, без перемешивания букв), из-за чего наступит однообразие и топтание на одном месте. Ну, тут нужно гуглить реальную генетику.
Так вот... Мы можем расширять алфавит, добавляя разные команды (включая конструкции if/loop, переменные и прочее), можем расширять длину кода, можем добавлять регулирующие условия среды (например, днём жарко, и ботам нужно найти укрытие; боты имеют датчики и условия для проверки, а как ими пользоваться - должны дойти до этого сами через сколько-то поколений бессмысленных смертей, лол). Если всё сделать правильно, то боты за какое-то число поколений (каждое поколение добавляются новички, полученные путём скрещивания выживших или умерших позже всех) должны адаптироваться к любым условиям среды. По сути, в их генах будет хаотически формироваться поведенческая программа, дающая оптимальный вариант для конкретной среды.
Ну, это если рассматривать ботов именно как маленькие программируемые машинки. Если ничего не путаю, ДНК в клетках играет отдалённо похожую роль - коды ДНК описывают белки, рибосомы собирают эти белки, белки делают какую-то работу в клетке, эта работа снаружи клетки наблюдается как поведение клетки. Если описывать не команды поведения, а "параметры", то не будет достаточного разнообразия, я так думаю. Хотя конкретно ГА к параметрам применимо, но мы ведь хотим выработать некое сложное поведение ботов, не так ли?
О, кстати, в описанной модели самое интересное начинается не в генах, а выше - на уровне популяций. Когда ботов много, они могут начать разделяться на виды и кооперироваться. Напоминает колонии одноклеточных, которые в природе тоже объединяются, выживая вместе (и жертвуя собой ради коллектива). Когда-то давно видел такое в одном примере реализации ГА на ютубе...
Ещё небольшая идея - можно рассматривать бота как хранилище подпрограмм, каждая из которых скрещивается индивидуально а-ля хромосома. Подпрограммы могут вызываться из одной главной программы или обращаться друг к другу. Суть подпрограмм в том, что в них могут сформироваться отдельные "навыки" ботов, которые можно зафиксировать, продолжив эволюцию в остальном коде. Тогда если мы дрессируем ботов на определённую задачу и заметили, что они сформировали в одной из подпрограмм подходящее под решение части задачи поведение, мы фиксируем эту подпрограмму, чтобы они не потеряли её из-за последующих скрещиваний и мутаций. Скажем, если некоторые боты научились прятаться в тень от жары, но пока что недостаточно хорошо ищут пропитание.
...так, ладно, я немного запутал, наверное, напишу вкратце:
- бот - исполнитель с набором команд и параметров
- бот погибает, если параметры достигают предела
- из команд бота составляются программы поведения
- первые программки составляются чисто рандомно
- бот исполняет программы в некой среде обитания
- среда имеет параметры вроде еды, освещённости
- сумевшие выжить боты скрещиваются друг с другом
- скрещивание - это склейка половинок программ ботов
- ещё есть мутации - случайные опечатки в программах
...ладно, короч, читайте википедию: https://ru.wikipedia.org/wiki/Генетический_алгоритм
Ну вот, теперь мне жутко захотелось реализовать ГА с ботами на Godot. :C
>увеличивать количество доступных входов и выходов по мере обучения, чтобы новую фичу получали только самые стабильные экземпляры
Всё зависит от того, какой будет исполняющая машина. Может получиться так, что изменяя её параметры, ты будешь делать всех текущих выживальщиков нежизнеспособными. ГА - это не нейронка, в нейронке ты можешь зафиксировать часть нейронов и наращивать новые, а в ГА по идее меняется всё сразу.
>>64022
>Что-то типа кучи ботов с параметрами, из которых в следующее поколение переходят те, что выжили, не?
Так можно только отрегулировать значения параметров (есть/нет/%), это не очень интересно. Грубо говоря, если у твоих ботов есть параметр "цвет", то в конечном итоге они все будут одного выигрышного цвета, и дальше никакой эволюции не будет (хотя окей, выбор идеального значения и есть цель ГА). ГА для ботов можно применить иначе. Щас пример набросаю, надеюсь, не ошибусь...
Сначала задаём исходный алфавит из кодов-команд бота:
0 - ожидание, 1 - идти вперёд, 2/3 - поворот влево/вправо, 4 - атака, 5 - защита, ...
Дальше генерируем каких-нибудь рандомных ботов, примеры:
323534 - вращается на месте, защищается и атакует (ходить не умеет)
121300 - движется по диагонали (ничего кроме этого не умеет)
Предположим, они выжили, скрещиваем, получаем:
323300 - вращается на месте (больше ничего не делает)
121534 - движется по диагонали, иногда защищается и атакует
Вероятно, 121534 будет успешнее предков и брата. Но это абстрактно. Чтобы реально протестировать ботов на успешность, нужны регулирующие условия. Скажем, бот может есть - значит, вокруг разбросана еда, а у бота есть параметр "энергия". Если бот не умеет есть или не находит еду - теряет энергию и погибает раньше всех. Если бот жрёт всё подряд, то еда быстро кончается и он опять же мрёт, хоть и позже. Теоретически, можно выстроить такую цепочку кодов, что бот будет двигаться и потреблять пищу оптимально для конкретной среды обитания. Чтобы эту цепочку найти, мы скрещиваем самых живучих ботов и вносим небольшие мутации:
121534 -> 121434 - теперь бот чаще пытается атаковать/есть, но разучился защищаться
Мутации нужны, скорее всего, потому, что простые комбинации кусочков в конечном итоге потеряют некоторые буквы (например, тут уже потерян 0, а другой бот потерял 1, 4 и 5) или их комбинации (если комбинируем половинками или любыми другими группами, без перемешивания букв), из-за чего наступит однообразие и топтание на одном месте. Ну, тут нужно гуглить реальную генетику.
Так вот... Мы можем расширять алфавит, добавляя разные команды (включая конструкции if/loop, переменные и прочее), можем расширять длину кода, можем добавлять регулирующие условия среды (например, днём жарко, и ботам нужно найти укрытие; боты имеют датчики и условия для проверки, а как ими пользоваться - должны дойти до этого сами через сколько-то поколений бессмысленных смертей, лол). Если всё сделать правильно, то боты за какое-то число поколений (каждое поколение добавляются новички, полученные путём скрещивания выживших или умерших позже всех) должны адаптироваться к любым условиям среды. По сути, в их генах будет хаотически формироваться поведенческая программа, дающая оптимальный вариант для конкретной среды.
Ну, это если рассматривать ботов именно как маленькие программируемые машинки. Если ничего не путаю, ДНК в клетках играет отдалённо похожую роль - коды ДНК описывают белки, рибосомы собирают эти белки, белки делают какую-то работу в клетке, эта работа снаружи клетки наблюдается как поведение клетки. Если описывать не команды поведения, а "параметры", то не будет достаточного разнообразия, я так думаю. Хотя конкретно ГА к параметрам применимо, но мы ведь хотим выработать некое сложное поведение ботов, не так ли?
О, кстати, в описанной модели самое интересное начинается не в генах, а выше - на уровне популяций. Когда ботов много, они могут начать разделяться на виды и кооперироваться. Напоминает колонии одноклеточных, которые в природе тоже объединяются, выживая вместе (и жертвуя собой ради коллектива). Когда-то давно видел такое в одном примере реализации ГА на ютубе...
Ещё небольшая идея - можно рассматривать бота как хранилище подпрограмм, каждая из которых скрещивается индивидуально а-ля хромосома. Подпрограммы могут вызываться из одной главной программы или обращаться друг к другу. Суть подпрограмм в том, что в них могут сформироваться отдельные "навыки" ботов, которые можно зафиксировать, продолжив эволюцию в остальном коде. Тогда если мы дрессируем ботов на определённую задачу и заметили, что они сформировали в одной из подпрограмм подходящее под решение части задачи поведение, мы фиксируем эту подпрограмму, чтобы они не потеряли её из-за последующих скрещиваний и мутаций. Скажем, если некоторые боты научились прятаться в тень от жары, но пока что недостаточно хорошо ищут пропитание.
...так, ладно, я немного запутал, наверное, напишу вкратце:
- бот - исполнитель с набором команд и параметров
- бот погибает, если параметры достигают предела
- из команд бота составляются программы поведения
- первые программки составляются чисто рандомно
- бот исполняет программы в некой среде обитания
- среда имеет параметры вроде еды, освещённости
- сумевшие выжить боты скрещиваются друг с другом
- скрещивание - это склейка половинок программ ботов
- ещё есть мутации - случайные опечатки в программах
...ладно, короч, читайте википедию: https://ru.wikipedia.org/wiki/Генетический_алгоритм
Ну вот, теперь мне жутко захотелось реализовать ГА с ботами на Godot. :C
>>64171
Ой, сам того не зная, описал ГП вместо ГА: https://ru.wikipedia.org/wiki/Генетическое_программирование
Но суть та же, ГП - это когда ГА применяется для построения программ (в данном случае - поведения ботов).
Ой, сам того не зная, описал ГП вместо ГА: https://ru.wikipedia.org/wiki/Генетическое_программирование
Но суть та же, ГП - это когда ГА применяется для построения программ (в данном случае - поведения ботов).
Весь день сражался с настройкой оружия ближнего боя. Почему-то тело убитого врага не хотело падать рэгдоллом, несмотря на то, что успешно падало, если убивать его из огнестрела. С точки зрения тела вовсе никакой разницы, потому что вызывается одинаковая функция Hurt, которая уже внутри тела вызывает Die, если здоровье опускается до нуля. Только вот поражающая часть ближнего оружия была создана из Area2D, в то время как пули это кинематики. Хотя хз, какая разница, потому что к любому раненому объекту применялось apply_central_impulse и от пули, и от мелии.
В общем, я переделал лезвие в KinematicBody2D, и тела стали падать. Почему сразу так не сделал? Потому что кинематик сталкивался с телом и съезжал со своего места на оружии. Оказалось, это работал move_and_collide, унаследованный от пули. Стоило его отключить, как всё починилось.
Окей. Труп должен выпускать оружие из рук. Но оно почему-то зависало в воздухе. Хотя было риджидбодей. И вот этот баг я так и не смог починить: он починился сам. Хотя до того в течение часа постоянно воспроизводился.
Но ладно. Больше всего времени было убито на коллизии оружия ближнего боя. Они должны были включаться и выключаться по таймерам, но почему-то при зажатой кнопке атаки эти таймеры начинали съезжать. Оказалось, что анимации длятся несколько дольше своей номинальной длятельности. Стоило таймеру задержки до следующего удара выставить время на 0.1с больше, как всё пришло в норму.
Последняя проблема была очень странной. Почему-то персонаж игрока, когда садился, левитировал в полуметре над полом; но если враг умирал, то игрок уже садился на пол нормально. Почему? Потому что коллизия у них одна на двоих. Решение нашлось уже во время написания этого поста: галочка "local_to_scene" под ресурсом коллижен-шейпа. С этой галочкой каждый новый инстанс получал свою уникальную копию ресурса. Вот это, я считаю, важный урок, которым следует поделиться с аноном: в некоторых ситуациях для инстансов нужно ресурсы делать локальными.
Всё. Все активные баги исправлены (про некоторые не упомянул, потому что времени на них почти не потратил). Теперь точно можно дальше двигаться. ИИ пилить. Или подбираемые предметы накодить, типа аптечек.
В общем, я переделал лезвие в KinematicBody2D, и тела стали падать. Почему сразу так не сделал? Потому что кинематик сталкивался с телом и съезжал со своего места на оружии. Оказалось, это работал move_and_collide, унаследованный от пули. Стоило его отключить, как всё починилось.
Окей. Труп должен выпускать оружие из рук. Но оно почему-то зависало в воздухе. Хотя было риджидбодей. И вот этот баг я так и не смог починить: он починился сам. Хотя до того в течение часа постоянно воспроизводился.
Но ладно. Больше всего времени было убито на коллизии оружия ближнего боя. Они должны были включаться и выключаться по таймерам, но почему-то при зажатой кнопке атаки эти таймеры начинали съезжать. Оказалось, что анимации длятся несколько дольше своей номинальной длятельности. Стоило таймеру задержки до следующего удара выставить время на 0.1с больше, как всё пришло в норму.
Последняя проблема была очень странной. Почему-то персонаж игрока, когда садился, левитировал в полуметре над полом; но если враг умирал, то игрок уже садился на пол нормально. Почему? Потому что коллизия у них одна на двоих. Решение нашлось уже во время написания этого поста: галочка "local_to_scene" под ресурсом коллижен-шейпа. С этой галочкой каждый новый инстанс получал свою уникальную копию ресурса. Вот это, я считаю, важный урок, которым следует поделиться с аноном: в некоторых ситуациях для инстансов нужно ресурсы делать локальными.
Всё. Все активные баги исправлены (про некоторые не упомянул, потому что времени на них почти не потратил). Теперь точно можно дальше двигаться. ИИ пилить. Или подбираемые предметы накодить, типа аптечек.
Весь день сражался с настройкой оружия ближнего боя. Почему-то тело убитого врага не хотело падать рэгдоллом, несмотря на то, что успешно падало, если убивать его из огнестрела. С точки зрения тела вовсе никакой разницы, потому что вызывается одинаковая функция Hurt, которая уже внутри тела вызывает Die, если здоровье опускается до нуля. Только вот поражающая часть ближнего оружия была создана из Area2D, в то время как пули это кинематики. Хотя хз, какая разница, потому что к любому раненому объекту применялось apply_central_impulse и от пули, и от мелии.
В общем, я переделал лезвие в KinematicBody2D, и тела стали падать. Почему сразу так не сделал? Потому что кинематик сталкивался с телом и съезжал со своего места на оружии. Оказалось, это работал move_and_collide, унаследованный от пули. Стоило его отключить, как всё починилось.
Окей. Труп должен выпускать оружие из рук. Но оно почему-то зависало в воздухе. Хотя было риджидбодей. И вот этот баг я так и не смог починить: он починился сам. Хотя до того в течение часа постоянно воспроизводился.
Но ладно. Больше всего времени было убито на коллизии оружия ближнего боя. Они должны были включаться и выключаться по таймерам, но почему-то при зажатой кнопке атаки эти таймеры начинали съезжать. Оказалось, что анимации длятся несколько дольше своей номинальной длятельности. Стоило таймеру задержки до следующего удара выставить время на 0.1с больше, как всё пришло в норму.
Последняя проблема была очень странной. Почему-то персонаж игрока, когда садился, левитировал в полуметре над полом; но если враг умирал, то игрок уже садился на пол нормально. Почему? Потому что коллизия у них одна на двоих. Решение нашлось уже во время написания этого поста: галочка "local_to_scene" под ресурсом коллижен-шейпа. С этой галочкой каждый новый инстанс получал свою уникальную копию ресурса. Вот это, я считаю, важный урок, которым следует поделиться с аноном: в некоторых ситуациях для инстансов нужно ресурсы делать локальными.
Всё. Все активные баги исправлены (про некоторые не упомянул, потому что времени на них почти не потратил). Теперь точно можно дальше двигаться. ИИ пилить. Или подбираемые предметы накодить, типа аптечек.
В общем, я переделал лезвие в KinematicBody2D, и тела стали падать. Почему сразу так не сделал? Потому что кинематик сталкивался с телом и съезжал со своего места на оружии. Оказалось, это работал move_and_collide, унаследованный от пули. Стоило его отключить, как всё починилось.
Окей. Труп должен выпускать оружие из рук. Но оно почему-то зависало в воздухе. Хотя было риджидбодей. И вот этот баг я так и не смог починить: он починился сам. Хотя до того в течение часа постоянно воспроизводился.
Но ладно. Больше всего времени было убито на коллизии оружия ближнего боя. Они должны были включаться и выключаться по таймерам, но почему-то при зажатой кнопке атаки эти таймеры начинали съезжать. Оказалось, что анимации длятся несколько дольше своей номинальной длятельности. Стоило таймеру задержки до следующего удара выставить время на 0.1с больше, как всё пришло в норму.
Последняя проблема была очень странной. Почему-то персонаж игрока, когда садился, левитировал в полуметре над полом; но если враг умирал, то игрок уже садился на пол нормально. Почему? Потому что коллизия у них одна на двоих. Решение нашлось уже во время написания этого поста: галочка "local_to_scene" под ресурсом коллижен-шейпа. С этой галочкой каждый новый инстанс получал свою уникальную копию ресурса. Вот это, я считаю, важный урок, которым следует поделиться с аноном: в некоторых ситуациях для инстансов нужно ресурсы делать локальными.
Всё. Все активные баги исправлены (про некоторые не упомянул, потому что времени на них почти не потратил). Теперь точно можно дальше двигаться. ИИ пилить. Или подбираемые предметы накодить, типа аптечек.
>>64244
can_sleep?
sleeping?
Проверь эти параметры, по умолчанию физические тела "засыпают" при бездействии.
> Труп должен выпускать оружие из рук. Но оно почему-то зависало в воздухе. Хотя было риджидбодей. И вот этот баг я так и не смог починить: он починился сам. Хотя до того в течение часа постоянно воспроизводился.
can_sleep?
sleeping?
Проверь эти параметры, по умолчанию физические тела "засыпают" при бездействии.
>>64369
Ствол уже нормально падает.
Тут новая магия творится. Добавляю взрывы. Взрыв - area2d, наносит повреждения бодям по on_Area2D_body_entered и дополнительно делает apply_central_impulse всем попавшим в зону риджидам. Телу особой разницы нет, что именно наносит ему повреждение: если в test() вызывать Die() или даже Hurt(100), оно ведёт себя точно так же, как и при попадании пули: превращается в рэгдолл. Но почему-то взрыв вызывает другой эффект. Тушка замирает и больше не реагирует ни на какие физические воздействия.
Такая же ерунда была, когда я делал холодное оружие на ареа2д. Тогда так и не разобрался, в чём причина, просто заменил на кинематик.
Но теперь причина выяснена. Дело в том, что всё происходящее с телом персонажа обрабатывается через физикс_процесс, а тут происходил вызов через сигналы. Подозреваю, что оно что-то ломало в памяти, после чего тело вообще переставало обрабатываться физическим движком.
Перенёс взрыву код ранения в физикс-процесс, всё равно живёт он доли секунды. Это сработало, умирающие стали нормально превращаться в рэгдоллы.
Ствол уже нормально падает.
Тут новая магия творится. Добавляю взрывы. Взрыв - area2d, наносит повреждения бодям по on_Area2D_body_entered и дополнительно делает apply_central_impulse всем попавшим в зону риджидам. Телу особой разницы нет, что именно наносит ему повреждение: если в test() вызывать Die() или даже Hurt(100), оно ведёт себя точно так же, как и при попадании пули: превращается в рэгдолл. Но почему-то взрыв вызывает другой эффект. Тушка замирает и больше не реагирует ни на какие физические воздействия.
Такая же ерунда была, когда я делал холодное оружие на ареа2д. Тогда так и не разобрался, в чём причина, просто заменил на кинематик.
Но теперь причина выяснена. Дело в том, что всё происходящее с телом персонажа обрабатывается через физикс_процесс, а тут происходил вызов через сигналы. Подозреваю, что оно что-то ломало в памяти, после чего тело вообще переставало обрабатываться физическим движком.
Перенёс взрыву код ранения в физикс-процесс, всё равно живёт он доли секунды. Это сработало, умирающие стали нормально превращаться в рэгдоллы.
>>64497
А что они делают? По идее должны выставлять флаги:
wanna_die = true
wanna_hurt = 100
Потом в обработчике _physics_process:
if wanna_die:
_ dead = true
if wanna_hurt > 0:
_ health -= wanna_hurt
_ wanna_hurt = 0
Тогда всё должно быть чотко.
>вызывать Die() или даже Hurt(100),
А что они делают? По идее должны выставлять флаги:
wanna_die = true
wanna_hurt = 100
Потом в обработчике _physics_process:
if wanna_die:
_ dead = true
if wanna_hurt > 0:
_ health -= wanna_hurt
_ wanna_hurt = 0
Тогда всё должно быть чотко.
Не кидайтесь камнями, но все же - есть желание создать игру на подобии космических рейнджеров т.е пошаговая стратегия/рпг, в связи с чем возник вопрос, насколько логично это делать в годоте (и не имеет ли смысла поискать другой движок), и что приоритетнее изучить - внутренний язык или сразу шарп?
>>64529
Пошаговые игры делаются без проблем, язык простой, почти копия питона. Шарп лучше, но документация хуже, экспорт пока хуже, так что одно на одно и выйдет.
Пошаговые игры делаются без проблем, язык простой, почти копия питона. Шарп лучше, но документация хуже, экспорт пока хуже, так что одно на одно и выйдет.
>>64531
Благодарю, займусь на выходных.
Благодарю, займусь на выходных.
>>64531
Была хуже в прошлом году. Сейчас я например практически всегда в доках вижу обе версии кода.
> Шарп лучше, но документация хуже
Была хуже в прошлом году. Сейчас я например практически всегда в доках вижу обе версии кода.
>>64529
Лично я предпочитаю следующий "пайплайн": Сначала делаешь прототип на gdscript, после чего, если имеются неоптимизированные места, переписываешь их на шарпе, а ещё лучше на си.
Лично я предпочитаю следующий "пайплайн": Сначала делаешь прототип на gdscript, после чего, если имеются неоптимизированные места, переписываешь их на шарпе, а ещё лучше на си.
>>64497
Тебя ещё ждёт интересное открытие, что некоторые вещи с физикой даже в physics_process делать нельзя, а нужно добавлять особую функцию _integrate_forces(Physics2DDirectBodyState state), в которой уже именно со state производить операции.
> теперь причина выяснена. Дело в том, что всё происходящее с телом персонажа обрабатывается через физикс_процесс, а тут происходил вызов через сигналы. Подозреваю, что оно что-то ломало в памяти, после чего тело вообще переставало обрабатываться физическим движком.
> Перенёс взрыву код ранения в физикс-процесс, всё равно живёт он доли секунды. Это сработало, умирающие стали нормально превращаться в рэгдоллы.
Тебя ещё ждёт интересное открытие, что некоторые вещи с физикой даже в physics_process делать нельзя, а нужно добавлять особую функцию _integrate_forces(Physics2DDirectBodyState state), в которой уже именно со state производить операции.
>>64556
Ну зачем так сложно-то, а?((
>нужно добавлять особую функцию _integrate_forces(Physics2DDirectBodyState state), в которой уже именно со state производить операции
Ну зачем так сложно-то, а?((
>>64559
Да разве ж это сложно? Вот получить направление на врага, произведя скалярное умножение векторов, вот это неподъёмная хрень. До сих пор осилить не могу.
Да разве ж это сложно? Вот получить направление на врага, произведя скалярное умножение векторов, вот это неподъёмная хрень. До сих пор осилить не могу.
>>64556
Тащемта у меня в риджидах почти нет кода. А для всех остальных это не актуально.
Тащемта у меня в риджидах почти нет кода. А для всех остальных это не актуально.
190 Кб, 1052x550Как можно подправить тень?
На пике полусфера на поверхности, отбрасывает тень с зазубринами.
Терминатор между тенью и светом на самой полусфере нормально победил, здесь как-то не выходит.
На пике полусфера на поверхности, отбрасывает тень с зазубринами.
Терминатор между тенью и светом на самой полусфере нормально победил, здесь как-то не выходит.
>>64600
Если тень не от солнца, то в настройках проекта есть разрешение текстуры теней - чем больше, тем меньше зазубрины.
Если тень не от солнца, то в настройках проекта есть разрешение текстуры теней - чем больше, тем меньше зазубрины.
2 Кб, 352x160Просто оставлю это здесь.
Кидаешь слоем в фотошоп, а сверху рисуешь свои тайлы, согласно этой маске.
Кидаешь слоем в фотошоп, а сверху рисуешь свои тайлы, согласно этой маске.
>>64638
Имхо, без пояснений не разобраться, что к чему. Я понял только что это обозначения угловых тайлов...
Имхо, без пояснений не разобраться, что к чему. Я понял только что это обозначения угловых тайлов...
>>64641
32 в названии видишь? Видишь. Сетку 32х32 в своём графическом редакторе установи - и сразу всё увидишь.
32 в названии видишь? Видишь. Сетку 32х32 в своём графическом редакторе установи - и сразу всё увидишь.
3 Кб, 764x375>>64642
Об этом я догадался, но не стал сразу делать. Я спрашиваю, что именно рисовать поверх? Переходы между разными видами спрайтов, типа трава/песок и песок/вода? Этот тайлсет только на два материала? Просто для тех, кто ни разу не рисовал тайлсет, как я, это всё вообще тёмный лес. А пиксель-арт - вообще слишком сложен.
>32 в названии видишь? Видишь. Сетку 32х32 в своём графическом редакторе установи - и сразу всё увидишь.
Об этом я догадался, но не стал сразу делать. Я спрашиваю, что именно рисовать поверх? Переходы между разными видами спрайтов, типа трава/песок и песок/вода? Этот тайлсет только на два материала? Просто для тех, кто ни разу не рисовал тайлсет, как я, это всё вообще тёмный лес. А пиксель-арт - вообще слишком сложен.
>>64663
А потом в годоте по этим серым кубикам выставляешь битовую маску для автотайла в формате 3х3 минимал. И у тебя будет корректный автотайл.
А потом в годоте по этим серым кубикам выставляешь битовую маску для автотайла в формате 3х3 минимал. И у тебя будет корректный автотайл.
19 Кб, 1220x71Годотаны. Помогите с проблемой.
Есть 2Д проект.
В нем ест CanvasLayer. На нем есть TouchScreenButton.
Когда я в скрипте пытаюсь спрятать TouchScreenButton, (с помощью Hide() или SetVisible(false) ) - у меня каждый раз выскакивает ошибка (приложение продолжает работать):
_input: Condition "!is_visible_in_tree()" is true.
(см пикрелейтед)
Если кнопку показать опять то все нормально. Кнопка работает только в видимом состоянии.
При попытке кнопку спрятать она гасится, но в консоли вываливается эта ошибка.
Что с ней можно сделать? Может я как то неправильно наэкранные кнопки прячу и их надо по другому убирать с канваса?
Есть 2Д проект.
В нем ест CanvasLayer. На нем есть TouchScreenButton.
Когда я в скрипте пытаюсь спрятать TouchScreenButton, (с помощью Hide() или SetVisible(false) ) - у меня каждый раз выскакивает ошибка (приложение продолжает работать):
_input: Condition "!is_visible_in_tree()" is true.
(см пикрелейтед)
Если кнопку показать опять то все нормально. Кнопка работает только в видимом состоянии.
При попытке кнопку спрятать она гасится, но в консоли вываливается эта ошибка.
Что с ней можно сделать? Может я как то неправильно наэкранные кнопки прячу и их надо по другому убирать с канваса?
15 Кб, 1060x76>>64831
Извиняюсь, не тот пик скинул. Вот правильный.
Извиняюсь, не тот пик скинул. Вот правильный.
Вопрос по математике.
Есть sqrt(). А как корни других степеней извлекать?
Или через дробные pow()?
Есть sqrt(). А как корни других степеней извлекать?
Или через дробные pow()?
>>64882
Сделай модуль на си, в котором реализуй нужные тебе вычисления и сконпелируй движок со своим модулем.
Сделай модуль на си, в котором реализуй нужные тебе вычисления и сконпелируй движок со своим модулем.
>>64896
Блин, не в этом дело. У мея тоже все работает - прячет и показывает кнопку. И приложение продолжает работать нормально без вылетов.
Проблема в том, что при отключении кнопки оно спамит в консоль этим эксепшеном. Даже если это пустая кнопка и она ни к чему не привязана.
>Изучай свой код, у меня всё работает, см. скрин
Блин, не в этом дело. У мея тоже все работает - прячет и показывает кнопку. И приложение продолжает работать нормально без вылетов.
Проблема в том, что при отключении кнопки оно спамит в консоль этим эксепшеном. Даже если это пустая кнопка и она ни к чему не привязана.
>>64944
Тебе английским языком, чёрным по белому написано: у тебя кнопка скрыта, но у неё инпут обрабатывается. При скрытии делай ей set_input(false) а при отображении - наоборот.
Тебе английским языком, чёрным по белому написано: у тебя кнопка скрыта, но у неё инпут обрабатывается. При скрытии делай ей set_input(false) а при отображении - наоборот.
>>64896
Нужны. Немного сложной математики в движении есть. Про затраты понятно. Но это, думаю, вполне нивелируется тем, что вычисляется значение раз в значительный промежуток времени, в остальных случаях уже готовое расчитанное значение используется.
>>64935
Прототип же.
>Но тебе точно нужны эти корни? Просто в играх даже квадратный корень - очень затратная операция...
Нужны. Немного сложной математики в движении есть. Про затраты понятно. Но это, думаю, вполне нивелируется тем, что вычисляется значение раз в значительный промежуток времени, в остальных случаях уже готовое расчитанное значение используется.
>>64935
Прототип же.
>>64969
Так о том и речь. нахуй в прототипе заморачиваться с корнями? Юзай дробный пов, как те сразу сказали.
> Прототип же.
Так о том и речь. нахуй в прототипе заморачиваться с корнями? Юзай дробный пов, как те сразу сказали.
>>64973
Потому что тема раскрашивает панель после твоего шейдера. Юзай безтемные контролы, колоррект, например.
Потому что тема раскрашивает панель после твоего шейдера. Юзай безтемные контролы, колоррект, например.
>>64978
Так там же есть дефолтная тема, он же серым-то рисуется.
Так там же есть дефолтная тема, он же серым-то рисуется.
Уууу, да! Я реализовал сложнейший (для меня) алгоритм, при котором есть два набора данных: дефолтный и кастомный, внешний код обращается к менеджеру данных и если искомые данные есть в кастоме - отдаются они, если их нет, ищутся в дефолте и отдаются оттуда, если нет нигде, возвращается либо нуль, либо поданный на вход функции новый образец данных, который записывается в кастомные данные.
Таким образом у нас есть зашитый в игру дефолтный мир, при начале игры объекты активно пишут данные в кастомный словарь, затем при сохранениях этот кастомный словарь сохраняется как сейвфайл, собственно. И восстанавливается при загрузке он же.
Это очень важный этап, а то у меня при сохранениях в файл ебошилось всё подряд: список локаций из дефолтного мира, список персонажей, реплики, триггеры. Всё это не нужно в файлах сохранения, при этом, сохраняется возможность всё таки добавлять и такие данные в файл сохранения, например, если в игру установлен мод, добавляющий локации, эти данные могут быть добавлены. Хотя тут тоже есть над чем подумать, можно же в файл записывать только список модов, а у модов держать свои дефолт-данные, которые так же будут читаться.
Таким образом у нас есть зашитый в игру дефолтный мир, при начале игры объекты активно пишут данные в кастомный словарь, затем при сохранениях этот кастомный словарь сохраняется как сейвфайл, собственно. И восстанавливается при загрузке он же.
Это очень важный этап, а то у меня при сохранениях в файл ебошилось всё подряд: список локаций из дефолтного мира, список персонажей, реплики, триггеры. Всё это не нужно в файлах сохранения, при этом, сохраняется возможность всё таки добавлять и такие данные в файл сохранения, например, если в игру установлен мод, добавляющий локации, эти данные могут быть добавлены. Хотя тут тоже есть над чем подумать, можно же в файл записывать только список модов, а у модов держать свои дефолт-данные, которые так же будут читаться.
>>64986
Очевидно он про цвет нод в редакторе, красные - 3д (наследники spatial), синие - 2д (наследники Node2D), фиолетовые - анимация, белые - абстрактные или служебные, а зеленые - наследники Control, и у него действительно появляется поле theme, которого нет у canvasitem от которого он наследуется.
Очевидно он про цвет нод в редакторе, красные - 3д (наследники spatial), синие - 2д (наследники Node2D), фиолетовые - анимация, белые - абстрактные или служебные, а зеленые - наследники Control, и у него действительно появляется поле theme, которого нет у canvasitem от которого он наследуется.
>>64986
Когда у движка нет цветовой дифференциации объектов, то нет цели! А когда нет цели - нет будущего!
Когда у движка нет цветовой дифференциации объектов, то нет цели! А когда нет цели - нет будущего!
80 Кб, 1301x535>>65028
Где тебе выше писали тему создать? Тебе писали заменить панель на колоррект.
Ничего создавать не надо.
> Создал я тему у контрола, как выше написали
Где тебе выше писали тему создать? Тебе писали заменить панель на колоррект.
Ничего создавать не надо.
73 Кб, 1339x555>>65037
Какая разница какой элемент? Ну поменял на колоррект, он рисует Rect цвета, который есть в его свойстве color, материал точно также не применяется.
Какая разница какой элемент? Ну поменял на колоррект, он рисует Rect цвета, который есть в его свойстве color, материал точно также не применяется.
>>64945
Не. Нихуя. Я пробовал отрубать все инпуты (и обычный и унхендленые и в дереве) - не помогло.
Знаешь в чем дело было?
Оказалось, надо чтобы кнопки которые мне надо было спрятать, в дереве ноды стояли после той кнопки, по нажатию на которую я их скрывал/показывал и сообщения об ошибке прекратились.
>Тебе английским языком, чёрным по белому написано: у тебя кнопка скрыта, но у неё инпут обрабатывается. При скрытии делай ей set_input(false) а при отображении - наоборот.
Не. Нихуя. Я пробовал отрубать все инпуты (и обычный и унхендленые и в дереве) - не помогло.
Знаешь в чем дело было?
Оказалось, надо чтобы кнопки которые мне надо было спрятать, в дереве ноды стояли после той кнопки, по нажатию на которую я их скрывал/показывал и сообщения об ошибке прекратились.
>>65045
Потому что у тебя материал Spatial, а нужно выставить ему режим CanvasItem.
>>65047
Воистину чудны пути программистьи! А код к самим кнопкам прикреплён? Если да, то рекомендую сделать общий код у парента всех этих кнопок, который будет осуществлять всё управление их поведением.
> материал точно также не применяется
Потому что у тебя материал Spatial, а нужно выставить ему режим CanvasItem.
>>65047
Воистину чудны пути программистьи! А код к самим кнопкам прикреплён? Если да, то рекомендую сделать общий код у парента всех этих кнопок, который будет осуществлять всё управление их поведением.
>>65067
Не это просто кнопки которые определенные экшены задают вроде ui_left или ui_up и т.д. Но такая же петрушка была и с полностью пустыми кнопками и с теми на которые я какие-то скрипты вешал.
Я поэкспериментировал по разному. Единственное что влияло на появление ошибки - это положение скрываемой кнопки в дереве относительно кнопки которая выдает сигнал в скрипт в котором прячется нужная кнопка (выше или ниже). Вложенность в другие узлы роли не играет. Скрипт тоже не важен, он может быть прикреплен к любой другой ноде. Дело только в положении кнопки с сигналом.
Не пробовал только еще отключать не через сигнал, а через отдельный экшен, но чет мне влом отдельный ui_ на это дело вешать.
Не это просто кнопки которые определенные экшены задают вроде ui_left или ui_up и т.д. Но такая же петрушка была и с полностью пустыми кнопками и с теми на которые я какие-то скрипты вешал.
Я поэкспериментировал по разному. Единственное что влияло на появление ошибки - это положение скрываемой кнопки в дереве относительно кнопки которая выдает сигнал в скрипт в котором прячется нужная кнопка (выше или ниже). Вложенность в другие узлы роли не играет. Скрипт тоже не важен, он может быть прикреплен к любой другой ноде. Дело только в положении кнопки с сигналом.
Не пробовал только еще отключать не через сигнал, а через отдельный экшен, но чет мне влом отдельный ui_ на это дело вешать.
Анон такой вопрос. Читаю инструкцию к C# в годоте. Там есть вот такое:
public override void _Ready()
{
// This function is called after _enter_tree, but it ensures
// that all children nodes have also entered the Scene Tree,
// and became active.
base._Ready();
}
public override void _Process(float delta)
{
// This function is called every frame.
base._Process(delta);
}
Зачем base. в данном случае нужны?
public override void _Ready()
{
// This function is called after _enter_tree, but it ensures
// that all children nodes have also entered the Scene Tree,
// and became active.
base._Ready();
}
public override void _Process(float delta)
{
// This function is called every frame.
base._Process(delta);
}
Зачем base. в данном случае нужны?
>>65102
Это ООП. Вызов такой же функции у класса, от которого отнаследовались. Не факт что это вообще используется.
Ну например у тебя может быть класс Vehicle: Node, и класс Tank: Vehicle. И ты хочешь чтобы когда создается Vehicle, загружалась моделька шасси. А когда создается Tank, загружалась моделька башни, но при этом чтобы сначала все равно загружалась моделька шасси.
Это ООП. Вызов такой же функции у класса, от которого отнаследовались. Не факт что это вообще используется.
Ну например у тебя может быть класс Vehicle: Node, и класс Tank: Vehicle. И ты хочешь чтобы когда создается Vehicle, загружалась моделька шасси. А когда создается Tank, загружалась моделька башни, но при этом чтобы сначала все равно загружалась моделька шасси.
>>65106
А разве это не автоматом делаться должно? Ну в смысле по умолчанию же вроде базовый конструктор должен вызываться, не?
А если в этих методах есть другие отличные от базового, то мануале годота о них вообще ни слова.
А разве это не автоматом делаться должно? Ну в смысле по умолчанию же вроде базовый конструктор должен вызываться, не?
А если в этих методах есть другие отличные от базового, то мануале годота о них вообще ни слова.
>>65116
Так все таки нужен он или нет?
Я еще полазил по мануалу. Где-то в примерах эти методы приводятся с base. где-то без него. Не пойму логику.
Так все таки нужен он или нет?
Я еще полазил по мануалу. Где-то в примерах эти методы приводятся с base. где-то без него. Не пойму логику.
>>65121
Дак тебе надо информатику учить, игры делать тебе рано. Пока не поймёшь, как работают вызовы функций и методов - не возвращайся.
Дак тебе надо информатику учить, игры делать тебе рано. Пока не поймёшь, как работают вызовы функций и методов - не возвращайся.
>>65124
Ты ведь в курсе, что сыровато только сопряжение с редактором? В отдельном ИДЕ это шарп как шарп. Достаточно полноценный для шарпа.
Ты ведь в курсе, что сыровато только сопряжение с редактором? В отдельном ИДЕ это шарп как шарп. Достаточно полноценный для шарпа.
>>65121
А хз анон, не проверял. Мое предположение - не нужен, если только ты сам такую логику не закладывал.
А хз анон, не проверял. Мое предположение - не нужен, если только ты сам такую логику не закладывал.
>>65126
сами биндинги
сами биндинги
>>65130
Нинужна. Мабилашобпазванить.
Нинужна, фу пидорство.
Нинужна. Веб чтоб двачи скроллить.
> андроид
Нинужна. Мабилашобпазванить.
> айфон
Нинужна, фу пидорство.
> и особенно веб
Нинужна. Веб чтоб двачи скроллить.
>>65128
Пока все пробовал без base. делать, вроде бы все работает тип-топ.
>>65124
В курсе. Но пока полет нормальный.
>>65130
Я х.з, у меня все нормально. Использую V3.2.2.beta1. Экспорт под веб и андроид работает без проблем. Даже деплой в один клик и туда и туда работает. Яблока у меня нет - проверить не могу.
-----
> хз анон, не проверял. Мое предположение - не нужен, если только ты сам такую логику не закладывал.
Пока все пробовал без base. делать, вроде бы все работает тип-топ.
>>65124
>Ты ведь в курсе, что шарп в годо сыроват еще?
В курсе. Но пока полет нормальный.
>>65130
>Сыроват экспорт на андроид, айфон и особенно веб.
Я х.з, у меня все нормально. Использую V3.2.2.beta1. Экспорт под веб и андроид работает без проблем. Даже деплой в один клик и туда и туда работает. Яблока у меня нет - проверить не могу.
-----
Смотрите, что придумал! У нас есть VisibilityNotifier и нам нужно организовать автоподгрузку уровней (локаций). Мы расставляем эти нотифаеры на домиках деревянных и когда они получают сигнал видимости происходит автоподгрузка внутренностей домика, а когда получают сигнал о невидимости, происходит выгрузка. Таким образом, когда ты подходишь к дверям, за ними уже загружена локация. Как идея?
>>65174
Не уверен что будет надежно, отвернулся не вовремя и домик из под ног выгрузился, я бы просто на area делал.
Не уверен что будет надежно, отвернулся не вовремя и домик из под ног выгрузился, я бы просто на area делал.
16 Кб, 601x188>>65151
Ну так на ios нет.
Ну так на ios нет.
>>65190
Можно и так, но в любом случае получается, локации будут грузиться даже если ты просто мимо проходил. Как бы этого избежать. Получается, только анимацией долгого, обстоятельного открывания дверей. Во время которой идёт подгрузка.
Можно и так, но в любом случае получается, локации будут грузиться даже если ты просто мимо проходил. Как бы этого избежать. Получается, только анимацией долгого, обстоятельного открывания дверей. Во время которой идёт подгрузка.
Годаны, а вам не попадались ли туториалы по 2D-лестницам в годоте? По ladders ещё более-менее нашёл кое-что (но хотелось бы больше и внятнее), а вот stairs - вообще ничего.
Ситуация: герой стоит на полу и может пойти прямо, а может пойти вперёд-вверх по лестнице. А если есть таковая, то вперёд-вниз. А если платформа закончилась, то только по лестнице. А если подпрыгнет с лестницы, то приземляться будет на неё же. Но если сверху платформа, то на платформу. Но если с пола подпрыгнет, то и приземлится на пол.
Крч есть какая-нибудь структурированная инфа по теме?
nb: я очень прошу НЕ рассказывать своё мнение и расписывать мини-тутор прямо в треде. Только ссылки, умоляю.
Ситуация: герой стоит на полу и может пойти прямо, а может пойти вперёд-вверх по лестнице. А если есть таковая, то вперёд-вниз. А если платформа закончилась, то только по лестнице. А если подпрыгнет с лестницы, то приземляться будет на неё же. Но если сверху платформа, то на платформу. Но если с пола подпрыгнет, то и приземлится на пол.
Крч есть какая-нибудь структурированная инфа по теме?
nb: я очень прошу НЕ рассказывать своё мнение и расписывать мини-тутор прямо в треде. Только ссылки, умоляю.
Если делать на Годоте аналог Террарии, то не будет ли она дико тормозить? Или под Террарию нужно что-то попроще?
>>65704
Из коробки если просто накидать, будет, если оптимизировать и использовать разные трюки с батчингом, шейдерами, то не будет.
Из коробки если просто накидать, будет, если оптимизировать и использовать разные трюки с батчингом, шейдерами, то не будет.
>>65663
https://godotengine.org/qa/47794/one-way-collision
https://godotengine.org/article/godot-31-will-get-many-improvements-kinematicbody
> я очень прошу НЕ рассказывать своё мнение и расписывать мини-тутор прямо в треде. Только ссылки, умоляю.
https://godotengine.org/qa/47794/one-way-collision
https://godotengine.org/article/godot-31-will-get-many-improvements-kinematicbody
Народ просвятите за работу освещения, в частности как сделать, чтоб свет не проходил через меши?
Вот первый пик поставил omni light, но при этом все горизонтальные поверхности подсвечены, например пик 2, с другой сотороны стены виден свет. Если включаю тени, то этого не происходит, но тут уже сами тени могут выглядеть как говно, третий пик, я как понимаю, в такм случаи мне нужно будет отдельно заморачиваться над дизайном всех элементов окружения, чтоб они отпрасывали красивую тень? или может есть какие-то более простое выходы из ситуации?
Вот первый пик поставил omni light, но при этом все горизонтальные поверхности подсвечены, например пик 2, с другой сотороны стены виден свет. Если включаю тени, то этого не происходит, но тут уже сами тени могут выглядеть как говно, третий пик, я как понимаю, в такм случаи мне нужно будет отдельно заморачиваться над дизайном всех элементов окружения, чтоб они отпрасывали красивую тень? или может есть какие-то более простое выходы из ситуации?
2 Кб, 509x372>>65906
Прочитал задачу жопой
@
Выдал первое из гугла
Между тем, я так и не придумал и не нагуглил ничего годного. Тредик, давай подумаем вместе. Пикрилейтед - разные виды взаимодействия с лестницами. Односторонней коллизией тут ничего не добиться, хотя, конечно же, она понадобится. В принципе, можно нагородить целую груду кода и пройтись по куче частных случаев. Но я подозреваю, что должно быть какое-то более общее решение, которое лежит настолько на поверхности для людей, плотно знакомых с геймдевом, что им не приходит в голову его обсужить. Или же каждый раз выстраиваются леса из костылей, такой вариант я тоже не исключаю.
В общем. Выкидываем тезис про "только ссылки". Анон, если бы тебе надо было реализовать лестницы, как бы ты это делал в своей игре?
Прочитал задачу жопой
@
Выдал первое из гугла
Между тем, я так и не придумал и не нагуглил ничего годного. Тредик, давай подумаем вместе. Пикрилейтед - разные виды взаимодействия с лестницами. Односторонней коллизией тут ничего не добиться, хотя, конечно же, она понадобится. В принципе, можно нагородить целую груду кода и пройтись по куче частных случаев. Но я подозреваю, что должно быть какое-то более общее решение, которое лежит настолько на поверхности для людей, плотно знакомых с геймдевом, что им не приходит в голову его обсужить. Или же каждый раз выстраиваются леса из костылей, такой вариант я тоже не исключаю.
В общем. Выкидываем тезис про "только ссылки". Анон, если бы тебе надо было реализовать лестницы, как бы ты это делал в своей игре?
>>66005
Делаешь лестницу one-way и на своем отдельном слое коллизий. Цепляешь к лестнице area. От этого area кидаешь сигналы bodyEntered и bodyExited в скрипт который меняет игроку флаг onStairs.
Далее уже в своем обработчике физики в зависимости от инпута, текущего стейта игрока и флага onStairs, включаешь/отключаешь коллизии игрока со слоем лестниц и переводишь его в нужный стейт (walk, walk_on_stairs, fall и т.д.).
Собственно? подобным же образом делается обработка верхних платформ для ladders, когда нужно пролезать вверх/вниз через них. Можешь поискать туториалы на эту тему.
Делаешь лестницу one-way и на своем отдельном слое коллизий. Цепляешь к лестнице area. От этого area кидаешь сигналы bodyEntered и bodyExited в скрипт который меняет игроку флаг onStairs.
Далее уже в своем обработчике физики в зависимости от инпута, текущего стейта игрока и флага onStairs, включаешь/отключаешь коллизии игрока со слоем лестниц и переводишь его в нужный стейт (walk, walk_on_stairs, fall и т.д.).
Собственно? подобным же образом делается обработка верхних платформ для ladders, когда нужно пролезать вверх/вниз через них. Можешь поискать туториалы на эту тему.
>>65993
Читай доки про свет, грубо говоря у тебя толщина стены меньше какого-то шага сетки, попробуй крутить bias, contact shadows.
Читай доки про свет, грубо говоря у тебя толщина стены меньше какого-то шага сетки, попробуй крутить bias, contact shadows.
>>66005
Поскольку то что ты нарисовал невозможно (нельзя одновременно идти по полу и при этом спускаться вниз по лестнице), то надо рассматривать эту систему как железнодорожные стрелки - ты можешь или идти по полу, или спускаться по лестнице. А реализация, как анон выше расписал, видимо. Только надо продумать что если у тебя враги тоже могут так ходить, тогда придется все это раскидать по слоям еще, и на каждом слое может быть свое состояние.
Поскольку то что ты нарисовал невозможно (нельзя одновременно идти по полу и при этом спускаться вниз по лестнице), то надо рассматривать эту систему как железнодорожные стрелки - ты можешь или идти по полу, или спускаться по лестнице. А реализация, как анон выше расписал, видимо. Только надо продумать что если у тебя враги тоже могут так ходить, тогда придется все это раскидать по слоям еще, и на каждом слое может быть свое состояние.
>>66031
Двачую. По умолчанию дорога ведёт по сплошной поверхности (извне), при подходе к развилке появляется подсказка "Press F to" которая переключает на спуск по лестнице. При подходе снизу/изнутри подсказка/операция не требуется.
> рассматривать эту систему как железнодорожные стрелки
Двачую. По умолчанию дорога ведёт по сплошной поверхности (извне), при подходе к развилке появляется подсказка "Press F to" которая переключает на спуск по лестнице. При подходе снизу/изнутри подсказка/операция не требуется.
>>66054
Ты как будто стримов ТВГ не смотрел: игроки впадают в ступор на самых очевидных моментах. Такшто подсказка нужна. По правилам хорошего тона можешь сделать чекбокс отключения подсказки при первом её появлении.
Ты как будто стримов ТВГ не смотрел: игроки впадают в ступор на самых очевидных моментах. Такшто подсказка нужна. По правилам хорошего тона можешь сделать чекбокс отключения подсказки при первом её появлении.
>>66076
Ну уж геймдизайну точно не на маньках с двача учиться, лол.
Ну уж геймдизайну точно не на маньках с двача учиться, лол.
Столкнулся с такой вещью как лицензирование. Сейчас нужно публиковать свою игру. Godot использует MIT лицензию, поэтому два вопроса:
1) почему при скачивании редактора движка в виде одного exe файла с ним также не предоставляется копия файла лицензии MIT ?
2) Когда я публикую свою игру, а она у меня тоже состоит из одного запускаемого файла, то мне нужно прикладывать этот файл лицензии или можно распространять в виде одного своего бинарника?
1) почему при скачивании редактора движка в виде одного exe файла с ним также не предоставляется копия файла лицензии MIT ?
2) Когда я публикую свою игру, а она у меня тоже состоит из одного запускаемого файла, то мне нужно прикладывать этот файл лицензии или можно распространять в виде одного своего бинарника?
>>66179
Значит я могу в игру встроить также типа gredits пункт и там засунуть лицензию и не распространять дополнительным файлом? MIT это позволяет? Просто там трактовка такая размытая.
Значит я могу в игру встроить также типа gredits пункт и там засунуть лицензию и не распространять дополнительным файлом? MIT это позволяет? Просто там трактовка такая размытая.
пиздец, в нем либы под апач лицензией, а она явно говорит распространять с исходными бинарниками два файла
>>66017
где можно подробно про это прочитать? я все это дело затеял, что разобраться, я ничего про uv2 не знаю
>>66029
bias это где? я все параметры уже как только не крутил и у света и у материала стены.
>>66174
не понял, как это поможет в моем вопросе?
>Увеличь разрешение лайтмапов (UV2 которое генерируется в блендере для модели).
где можно подробно про это прочитать? я все это дело затеял, что разобраться, я ничего про uv2 не знаю
>>66029
bias это где? я все параметры уже как только не крутил и у света и у материала стены.
>>66174
не понял, как это поможет в моем вопросе?
>>66183
Нет, не говорит.
Нет, не говорит.
>in at least one of the following places: within a NOTICE text file distributed... or, within a display generated by the Derivative Works, if and wherever such third-party notices normally appear.
Опять же большинство этих внутренних либ мне тоже нужно как минимум упомянуть, т.к. я являюсь продуктом от производного
>>66197
http://www.apache.org/licenses/LICENSE-2.0
ну да
только когда я создаю игру, то она уже собрана не с редактором, а с ядром движка и там нет этого доступа к тому, чтобы прочитать лицензии, поэтому нужно самому в игре делать примерно тоже, что в редакторе, но с меньшим количеством либ: апач, мит, либпнг, злиб..
http://www.apache.org/licenses/LICENSE-2.0
ну да
только когда я создаю игру, то она уже собрана не с редактором, а с ядром движка и там нет этого доступа к тому, чтобы прочитать лицензии, поэтому нужно самому в игре делать примерно тоже, что в редакторе, но с меньшим количеством либ: апач, мит, либпнг, злиб..
>>66203
Судя по всему можно просто хуячить этот файл
https://github.com/godotengine/godot/blob/master/COPYRIGHT.txt
Судя по всему можно просто хуячить этот файл
https://github.com/godotengine/godot/blob/master/COPYRIGHT.txt
>>66207
пиздец.. мне заказчик уже все мозги выебал
пиздец.. мне заказчик уже все мозги выебал
>>66181
Хули там размытого, все четко написано.
Достаточно линк в на лицензию годота в кридитах игры кинуть и все.
Хули там размытого, все четко написано.
>Note however that the Godot Engine binary that you would distribute with your game is a copy of the "Software" as defined in the license, and you are therefore required to include the copyright notice and license statement somewhere in your documentation.
>The Godot Engine developers consider that a link to this page (godotengine.org/license) in your game documentation or credits would be an acceptable way to satisfy the license terms.
Достаточно линк в на лицензию годота в кридитах игры кинуть и все.
>>66272
Видишь ли, мнение разработчиков движка это просто мнение, а есть лицензии, в том числе лицензии тех, чей код разработчики движка позаимствовали.
Видишь ли, мнение разработчиков движка это просто мнение, а есть лицензии, в том числе лицензии тех, чей код разработчики движка позаимствовали.
>>66272
А еще в кредитсы надо засунуть часть библиотек, которые он использует и лицензии которых также требуют упоминания от производных продуктов..
А еще в кредитсы надо засунуть часть библиотек, которые он использует и лицензии которых также требуют упоминания от производных продуктов..
>>66336
Ну так запихни, в чем проблема? Сделай Ctrl+C, Ctrl+V из справки годота и запихни в свой проект.
Ну так запихни, в чем проблема? Сделай Ctrl+C, Ctrl+V из справки годота и запихни в свой проект.
>>66338
Что ты нервный такой, попей мяты. Я разбираюсь с лицензиями, попутно другие уже не будут наступать на эти же грабли и будут знать, что делать в этой ситуации. Хотя по идее уже в треде должно быть достаточно людей, кто выпускал коммерческий продукт на нем и знает, что там и как правильно.
Что ты нервный такой, попей мяты. Я разбираюсь с лицензиями, попутно другие уже не будут наступать на эти же грабли и будут знать, что делать в этой ситуации. Хотя по идее уже в треде должно быть достаточно людей, кто выпускал коммерческий продукт на нем и знает, что там и как правильно.
>>58384 (OP)
Кароче, пытался скомпилить движок с https://github.com/perbone/luascript, вроде все ок, создал скрипт но чет не ворк ничерта, скрипт вроде рабочий, но hello world банально не выводит...
windows godot 3.2.1 (пробовал с 3.2)
Кароче, пытался скомпилить движок с https://github.com/perbone/luascript, вроде все ок, создал скрипт но чет не ворк ничерта, скрипт вроде рабочий, но hello world банально не выводит...
windows godot 3.2.1 (пробовал с 3.2)
>>66375
По описанию репы, думаю там ничего пока и не работает.
По описанию репы, думаю там ничего пока и не работает.
>With this in place it will be possible to start answering engine call backs, like for example, _ready(), _process() etc.
>For now not much is done
>>66375
А вот в это больше верится, это же Westnoth
https://github.com/wesnoth/jessenehttps://github.com/wesnoth/jessene
А вот в это больше верится, это же Westnoth
https://github.com/wesnoth/jessenehttps://github.com/wesnoth/jessene
>>66344
Я вот тут подумал, технически, в лицензировании нужно отталкиваться от требований заказчика/издателя, т.к. это он потом будет использовать/распространять продукт. Такие вещи, по идее еще на стадии т.з. согласовываться должны. А то может он собирается игруху полностью закрытой сделать, а у каких-то компонентов которые ты использовал нужно обязательно открытый код выкладывать. Или наоборот, он захочет полный опенсорц сделать, а у каких-то модулей есть запрет на выкладывание исходников (я кстати с таким столкнулся, хотел к своему проекту прикрутить один модуль диалогов, а потом уже прочитал, что с ним можно делать все, что угодно, кроме выкладывания сорцев в составе проекта, а у меня реп полностью открытый. Хорошо не успел его туда включить).
Поэтому нужно сразу говорить заказчику "Я буду делать проект с тем-то тем-то, лицензии лежат вон там. Пиздуй читать, согласен - делаем, нет - думаем чем заменить". И если по ходу разработки прикручивается какой-то сторонний модуль, то тоже уведомлять об этом.
>Я разбираюсь с лицензиями
Я вот тут подумал, технически, в лицензировании нужно отталкиваться от требований заказчика/издателя, т.к. это он потом будет использовать/распространять продукт. Такие вещи, по идее еще на стадии т.з. согласовываться должны. А то может он собирается игруху полностью закрытой сделать, а у каких-то компонентов которые ты использовал нужно обязательно открытый код выкладывать. Или наоборот, он захочет полный опенсорц сделать, а у каких-то модулей есть запрет на выкладывание исходников (я кстати с таким столкнулся, хотел к своему проекту прикрутить один модуль диалогов, а потом уже прочитал, что с ним можно делать все, что угодно, кроме выкладывания сорцев в составе проекта, а у меня реп полностью открытый. Хорошо не успел его туда включить).
Поэтому нужно сразу говорить заказчику "Я буду делать проект с тем-то тем-то, лицензии лежат вон там. Пиздуй читать, согласен - делаем, нет - думаем чем заменить". И если по ходу разработки прикручивается какой-то сторонний модуль, то тоже уведомлять об этом.
>>66631
Ну примерно так и было. Заказчик сказал, что хочет такую-то такую-то игру на годоте, чтобы я написал. Лицензия MIT и все дела. Ну я написал, попутно оказалось, что ему нужно, чтобы распространялся строго один файл, т.е. надо как у редактора годо засунуть текст лицензии MIT и то, что игра создавалась на этом движке. А потом оказалось, что у кучи внутренних либ, которые годо использует, есть тоже не с простыми лицензиями и что и всех их тоже надо прикладывать и уведомлять.
Когда есть возможность распространять с кучей файлов - там как выше писали создаешь текстовый файл и все в него вписываешь, но тоже надо не только годо указать, а еще некоторые части, которые под мит, апач, бсд..
Ну примерно так и было. Заказчик сказал, что хочет такую-то такую-то игру на годоте, чтобы я написал. Лицензия MIT и все дела. Ну я написал, попутно оказалось, что ему нужно, чтобы распространялся строго один файл, т.е. надо как у редактора годо засунуть текст лицензии MIT и то, что игра создавалась на этом движке. А потом оказалось, что у кучи внутренних либ, которые годо использует, есть тоже не с простыми лицензиями и что и всех их тоже надо прикладывать и уведомлять.
Когда есть возможность распространять с кучей файлов - там как выше писали создаешь текстовый файл и все в него вписываешь, но тоже надо не только годо указать, а еще некоторые части, которые под мит, апач, бсд..
>>66406
Спасибо анон, чет не увидел.
Спасибо анон, чет не увидел.
>>66407
Не со всем то, здесь получается надо вызывать луа внутри gdscript.
Не со всем то, здесь получается надо вызывать луа внутри gdscript.
Продублирую вопрос сюда, а то в ньюфаготреде меня уже третий раз с ним динамят походу а здесь вроде более отзывчивые антоши:
Че почитать по созданию ботов? И еще, поясните за эту книгу: Алекс Дж. Шампандар. "Искусственный интеллект в компьютерных играх.", стоит ли ее читать? А то я, блять, уже на 120 странице, а суть даже не начиналась)))))
Че почитать по созданию ботов? И еще, поясните за эту книгу: Алекс Дж. Шампандар. "Искусственный интеллект в компьютерных играх.", стоит ли ее читать? А то я, блять, уже на 120 странице, а суть даже не начиналась)))))
>>66733
Сколько я ни читал книг по программированию игр, ни одна не принесла мне никакой пользы.
Сколько я ни читал книг по программированию игр, ни одна не принесла мне никакой пользы.
>>66737
А я откуда знаю? Я ж говорю - книги читал, никакой пользы не принесло. Следовательно, в теме я нихуя не шарю.
А я откуда знаю? Я ж говорю - книги читал, никакой пользы не принесло. Следовательно, в теме я нихуя не шарю.
>>66739
Ну ты ващет сказал, что книги по программированию игр, так что я думал, что есть альтернатива... Ладно, проехали.
Ну ты ващет сказал, что книги по программированию игр, так что я думал, что есть альтернатива... Ладно, проехали.
В CollisionShape2D есть куча опций для всяких форм коллизий. Помимо интуитивных круга, квадрата, капсулы и произвольного многогранника (который, кстати, не имеет удобного интерфейса редактирования) есть ещё всякие линии и лучи, которые вообще хз как работает. В доках про них сплошной сепулькарий, никаких объяснений, как это работает, чем отличается и в каких ситуациях вообще может понадобиться. В гугле я хз как искать, выдаёт только всякие кидсканкоде и другие пособия для начинающих. Упоминание RayShape2D было у чувака с платформером-медвежонком, но и он не разъяснял подробностей, просто пользовался.
Итак, годаны. Где может узнать про все эти формы коллизий и про их применение?
Итак, годаны. Где может узнать про все эти формы коллизий и про их применение?
>>66733
Хотел что то посоветовать, но оказалось что сам еще ничего не прочитал и даже в закладках и закачках ничего не нашел. Есть только пара обзорных статей в закладах
https://habr.com/en/post/420219/
https://habr.com/ru/post/173187/
https://habr.com/ru/company/intel/blog/265679/
https://habr.com/ru/company/it-grad/blog/306214/
В общем по моему ограниченному пониманию, есть всякие штуки как поиск пути, там в основном a* (a-star), в том числи и по тайлам, и по навмешу (сетке узлов). Там свои приколы как оптимизировать все это, быстрые эвристики для неточного пути, отсечения в точках схождения, например дверях.
В играх типа шахмат используется min-max, он по очереди пытается сделать лучший ход за одного игрока, потом за другого, до какой-то глубины перебора, фишка в том, что прирост очков для одного игрока является таким же уменьшением очков для второго, поэтому можно его просто вызывать рекурсивно со знаком минус. Оценочная фунция приблизительно считает очки за состояние поля - сколько каких фигур осталось, какие угрозы они создают. Там свои оптимизации, проверять сначала ходы на которые обязательно отвечать, такие как шах.
Дальше, в обычных видеоиграх, как я понимаю в почете GOAP - Goal oriented planning, также используются деревья решений (decision tree), конечные автоматы (FSM, finite-state-machine), конечные автоматы конечных автоматов (вложенные). Некие реализации можно глянуть для годота
https://github.com/RodZill4/godot-goap
https://github.com/godot-addons/godot-behavior-tree-plugin
Слышал есть еще что-то вроде координатора, не помню как называется, идея в том что он раздает приказы юнитам, такое вроде было в старике и в халфе для команд солдат, т.к. если каждый будет думать индивидуально возможны конфликты, а координатор может выдать команды двое налево, двое направо, один прикрывает.
Есть еще такая вещь, как Steering behavior -это типа рулевого, как если бы искуственный интеллект отдал команду переместиться в точку x,y, а steering behavior отвечает за то, как плавно изменить скорость, повернуть на курс и т.д. это касается и движения персонажей, не только техники.
Дальше уже идут нейронные сети, там я еще хуже разбираюсь, но в /pr мне сказали что оно пока не готово. По причине хрен отладишь. Тут примерно то же пишут https://www.quora.com/Are-there-any-video-games-that-use-neural-networks-for-their-AI Идея, думается, такая - на вход нейронке подается то, что она видит - позиции врагов, хитпоинты юнитов, на выходе она выдает аналог нажатий на кнопочки - пойти влево, прожать атаку, в результате это все оценивается функцией оценки, и выигрышное поведение закрепляется, все это проворачивается на десятках тысяч игр самой с собой.
>Че почитать по созданию ботов?
Хотел что то посоветовать, но оказалось что сам еще ничего не прочитал и даже в закладках и закачках ничего не нашел. Есть только пара обзорных статей в закладах
https://habr.com/en/post/420219/
https://habr.com/ru/post/173187/
https://habr.com/ru/company/intel/blog/265679/
https://habr.com/ru/company/it-grad/blog/306214/
В общем по моему ограниченному пониманию, есть всякие штуки как поиск пути, там в основном a* (a-star), в том числи и по тайлам, и по навмешу (сетке узлов). Там свои приколы как оптимизировать все это, быстрые эвристики для неточного пути, отсечения в точках схождения, например дверях.
В играх типа шахмат используется min-max, он по очереди пытается сделать лучший ход за одного игрока, потом за другого, до какой-то глубины перебора, фишка в том, что прирост очков для одного игрока является таким же уменьшением очков для второго, поэтому можно его просто вызывать рекурсивно со знаком минус. Оценочная фунция приблизительно считает очки за состояние поля - сколько каких фигур осталось, какие угрозы они создают. Там свои оптимизации, проверять сначала ходы на которые обязательно отвечать, такие как шах.
Дальше, в обычных видеоиграх, как я понимаю в почете GOAP - Goal oriented planning, также используются деревья решений (decision tree), конечные автоматы (FSM, finite-state-machine), конечные автоматы конечных автоматов (вложенные). Некие реализации можно глянуть для годота
https://github.com/RodZill4/godot-goap
https://github.com/godot-addons/godot-behavior-tree-plugin
Слышал есть еще что-то вроде координатора, не помню как называется, идея в том что он раздает приказы юнитам, такое вроде было в старике и в халфе для команд солдат, т.к. если каждый будет думать индивидуально возможны конфликты, а координатор может выдать команды двое налево, двое направо, один прикрывает.
Есть еще такая вещь, как Steering behavior -это типа рулевого, как если бы искуственный интеллект отдал команду переместиться в точку x,y, а steering behavior отвечает за то, как плавно изменить скорость, повернуть на курс и т.д. это касается и движения персонажей, не только техники.
Дальше уже идут нейронные сети, там я еще хуже разбираюсь, но в /pr мне сказали что оно пока не готово. По причине хрен отладишь. Тут примерно то же пишут https://www.quora.com/Are-there-any-video-games-that-use-neural-networks-for-their-AI Идея, думается, такая - на вход нейронке подается то, что она видит - позиции врагов, хитпоинты юнитов, на выходе она выдает аналог нажатий на кнопочки - пойти влево, прожать атаку, в результате это все оценивается функцией оценки, и выигрышное поведение закрепляется, все это проворачивается на десятках тысяч игр самой с собой.
>>66733
Хотел что то посоветовать, но оказалось что сам еще ничего не прочитал и даже в закладках и закачках ничего не нашел. Есть только пара обзорных статей в закладах
https://habr.com/en/post/420219/
https://habr.com/ru/post/173187/
https://habr.com/ru/company/intel/blog/265679/
https://habr.com/ru/company/it-grad/blog/306214/
В общем по моему ограниченному пониманию, есть всякие штуки как поиск пути, там в основном a* (a-star), в том числи и по тайлам, и по навмешу (сетке узлов). Там свои приколы как оптимизировать все это, быстрые эвристики для неточного пути, отсечения в точках схождения, например дверях.
В играх типа шахмат используется min-max, он по очереди пытается сделать лучший ход за одного игрока, потом за другого, до какой-то глубины перебора, фишка в том, что прирост очков для одного игрока является таким же уменьшением очков для второго, поэтому можно его просто вызывать рекурсивно со знаком минус. Оценочная фунция приблизительно считает очки за состояние поля - сколько каких фигур осталось, какие угрозы они создают. Там свои оптимизации, проверять сначала ходы на которые обязательно отвечать, такие как шах.
Дальше, в обычных видеоиграх, как я понимаю в почете GOAP - Goal oriented planning, также используются деревья решений (decision tree), конечные автоматы (FSM, finite-state-machine), конечные автоматы конечных автоматов (вложенные). Некие реализации можно глянуть для годота
https://github.com/RodZill4/godot-goap
https://github.com/godot-addons/godot-behavior-tree-plugin
Слышал есть еще что-то вроде координатора, не помню как называется, идея в том что он раздает приказы юнитам, такое вроде было в старике и в халфе для команд солдат, т.к. если каждый будет думать индивидуально возможны конфликты, а координатор может выдать команды двое налево, двое направо, один прикрывает.
Есть еще такая вещь, как Steering behavior -это типа рулевого, как если бы искуственный интеллект отдал команду переместиться в точку x,y, а steering behavior отвечает за то, как плавно изменить скорость, повернуть на курс и т.д. это касается и движения персонажей, не только техники.
Дальше уже идут нейронные сети, там я еще хуже разбираюсь, но в /pr мне сказали что оно пока не готово. По причине хрен отладишь. Тут примерно то же пишут https://www.quora.com/Are-there-any-video-games-that-use-neural-networks-for-their-AI Идея, думается, такая - на вход нейронке подается то, что она видит - позиции врагов, хитпоинты юнитов, на выходе она выдает аналог нажатий на кнопочки - пойти влево, прожать атаку, в результате это все оценивается функцией оценки, и выигрышное поведение закрепляется, все это проворачивается на десятках тысяч игр самой с собой.
>Че почитать по созданию ботов?
Хотел что то посоветовать, но оказалось что сам еще ничего не прочитал и даже в закладках и закачках ничего не нашел. Есть только пара обзорных статей в закладах
https://habr.com/en/post/420219/
https://habr.com/ru/post/173187/
https://habr.com/ru/company/intel/blog/265679/
https://habr.com/ru/company/it-grad/blog/306214/
В общем по моему ограниченному пониманию, есть всякие штуки как поиск пути, там в основном a* (a-star), в том числи и по тайлам, и по навмешу (сетке узлов). Там свои приколы как оптимизировать все это, быстрые эвристики для неточного пути, отсечения в точках схождения, например дверях.
В играх типа шахмат используется min-max, он по очереди пытается сделать лучший ход за одного игрока, потом за другого, до какой-то глубины перебора, фишка в том, что прирост очков для одного игрока является таким же уменьшением очков для второго, поэтому можно его просто вызывать рекурсивно со знаком минус. Оценочная фунция приблизительно считает очки за состояние поля - сколько каких фигур осталось, какие угрозы они создают. Там свои оптимизации, проверять сначала ходы на которые обязательно отвечать, такие как шах.
Дальше, в обычных видеоиграх, как я понимаю в почете GOAP - Goal oriented planning, также используются деревья решений (decision tree), конечные автоматы (FSM, finite-state-machine), конечные автоматы конечных автоматов (вложенные). Некие реализации можно глянуть для годота
https://github.com/RodZill4/godot-goap
https://github.com/godot-addons/godot-behavior-tree-plugin
Слышал есть еще что-то вроде координатора, не помню как называется, идея в том что он раздает приказы юнитам, такое вроде было в старике и в халфе для команд солдат, т.к. если каждый будет думать индивидуально возможны конфликты, а координатор может выдать команды двое налево, двое направо, один прикрывает.
Есть еще такая вещь, как Steering behavior -это типа рулевого, как если бы искуственный интеллект отдал команду переместиться в точку x,y, а steering behavior отвечает за то, как плавно изменить скорость, повернуть на курс и т.д. это касается и движения персонажей, не только техники.
Дальше уже идут нейронные сети, там я еще хуже разбираюсь, но в /pr мне сказали что оно пока не готово. По причине хрен отладишь. Тут примерно то же пишут https://www.quora.com/Are-there-any-video-games-that-use-neural-networks-for-their-AI Идея, думается, такая - на вход нейронке подается то, что она видит - позиции врагов, хитпоинты юнитов, на выходе она выдает аналог нажатий на кнопочки - пойти влево, прожать атаку, в результате это все оценивается функцией оценки, и выигрышное поведение закрепляется, все это проворачивается на десятках тысяч игр самой с собой.
1 Кб, 217x208>>66031
Чего блять?
>>66050
"Чтобы пройти по лестнице вверх, поднесите левую руку к клавиатуре, поместите средний палец на клавишу W, а затем небольшим усилием надавите на неё до упора."
>>66010
Я тоже думал в таком направлении. Но в конструкции пикрилейтед (а они предполагаются повсеместно) начинается жопа. Потому что неизбежно при спуске происходит area_exited верхней лестницы.
Короче, надо ещё учитывать, на какой именно лестнице стоит персонаж. Так что, видимо, не обойтись простым onStairs, придётся передавать self в параметрах, а при выходе сравнивать.
>Поскольку то что ты нарисовал невозможно (нельзя одновременно идти по полу и при этом спускаться вниз по лестнице)
Чего блять?
>>66050
>при подходе к развилке появляется подсказка
"Чтобы пройти по лестнице вверх, поднесите левую руку к клавиатуре, поместите средний палец на клавишу W, а затем небольшим усилием надавите на неё до упора."
>>66010
Я тоже думал в таком направлении. Но в конструкции пикрилейтед (а они предполагаются повсеместно) начинается жопа. Потому что неизбежно при спуске происходит area_exited верхней лестницы.
Короче, надо ещё учитывать, на какой именно лестнице стоит персонаж. Так что, видимо, не обойтись простым onStairs, придётся передавать self в параметрах, а при выходе сравнивать.
>>66823
Я просто иногда ленюсь чекать ньюфаго тред, там 1000 постов
Я просто иногда ленюсь чекать ньюфаго тред, там 1000 постов
>>66812
Кажется, я нашёл изящное решение лестниц.
Смотрим коллизии. Если среди них есть объект из слоя stairs, то коллизия с лестницами включается; если нет - выключается. Также коллизия с лестницами включена при нажатой клавише "вверх" при одновременном is_on_floor. В верхней части каждой лестницы есть небольшой участок со слоями коллизии world и stairs, а весь остальной пролёт имеет только слой stairs.
И никаких дополнительных зон с дополнительными событиями. При такой системе, пожалуй, только спуск вниз с ровного пола может быть немного сложнее, но не сильно. И от прыжков на лестницах придётся отказаться, иначе придётся кучу условий нагромождать. Хотя, если опрашивать коллизии только при is_on_floor, то не придётся, зато можно будет перепрыгивать с одной лестницы на другую.
Кажется, я нашёл изящное решение лестниц.
Смотрим коллизии. Если среди них есть объект из слоя stairs, то коллизия с лестницами включается; если нет - выключается. Также коллизия с лестницами включена при нажатой клавише "вверх" при одновременном is_on_floor. В верхней части каждой лестницы есть небольшой участок со слоями коллизии world и stairs, а весь остальной пролёт имеет только слой stairs.
И никаких дополнительных зон с дополнительными событиями. При такой системе, пожалуй, только спуск вниз с ровного пола может быть немного сложнее, но не сильно. И от прыжков на лестницах придётся отказаться, иначе придётся кучу условий нагромождать. Хотя, если опрашивать коллизии только при is_on_floor, то не придётся, зато можно будет перепрыгивать с одной лестницы на другую.
>>66898
Я так полагаю, что при падении, кагда !is_on_floor коллизия тоже включена, чтобы падая, персонаж приземлился на первую попавшуюся лестницу, а не пролетел сквозь неё?
Я так полагаю, что при падении, кагда !is_on_floor коллизия тоже включена, чтобы падая, персонаж приземлился на первую попавшуюся лестницу, а не пролетел сквозь неё?
>>66968
Кстати да, хорошая идея - автоматом включать коллизию с лестницами, когда !is_on_floor.
Кстати да, хорошая идея - автоматом включать коллизию с лестницами, когда !is_on_floor.
>>66898
Ты, наверное, имеешь в виду не коллизии, а просто intersects? Потому что если у тебя не включена коллизия с лестницами, как ты ее поймаешь?
>Смотрим коллизии. Если среди них есть объект из слоя stairs, то коллизия с лестницами включается
Ты, наверное, имеешь в виду не коллизии, а просто intersects? Потому что если у тебя не включена коллизия с лестницами, как ты ее поймаешь?
>>66997
Перечитай внимательно и целиком, ответ во втором и третьем предложениях.
Перечитай внимательно и целиком, ответ во втором и третьем предложениях.
>>66997
Сначала происходит collision, затем, если хотя бы одно тело не solid, происходит intersect. В Godot для этого используется Area.
> имеешь в виду не коллизии, а просто intersects?
Сначала происходит collision, затем, если хотя бы одно тело не solid, происходит intersect. В Godot для этого используется Area.
https://godotengine.org/article/dev-snapshot-godot-3-2-2-beta-2
Не, ну вы видели? Видели?
Не, ну вы видели? Видели?
>>67158
Правильно я решил делать игоры на глес2, невзирая на скудный шейдерпайплайн.
>The new 2D batching is only implemented for the GLES2 renderer
>GLES3 renderer is being deprecated by Vulkan in Godot 4.0
Правильно я решил делать игоры на глес2, невзирая на скудный шейдерпайплайн.
>>67157
Перечитай мой вопрос. Если "коллизия с лестницами включается" "если средих них есть объект из слоя stairs", то коллизии со слоем stairs были отключены. Если коллизии со слоем stairs были отключены, откуда коллизия со stairs возьмется в "Смотрим коллизии"?
Перечитай мой вопрос. Если "коллизия с лестницами включается" "если средих них есть объект из слоя stairs", то коллизии со слоем stairs были отключены. Если коллизии со слоем stairs были отключены, откуда коллизия со stairs возьмется в "Смотрим коллизии"?
>>67158
Пока сыровата, в анимированной модельке какие-то нераскрашенные части начали торчать, при импорте ассетов редактор падал через раз. Правда я из мастера 3.2 собирал, но это вроде то же самое должно быть.
Пока сыровата, в анимированной модельке какие-то нераскрашенные части начали торчать, при импорте ассетов редактор падал через раз. Правда я из мастера 3.2 собирал, но это вроде то же самое должно быть.
>>67227
Ни в коем случае не то же самое. Мастер максимально нестабилен. А по ссылкам в статье - более менее стабильные релизы.
> это вроде то же самое должно быть
Ни в коем случае не то же самое. Мастер максимально нестабилен. А по ссылкам в статье - более менее стабильные релизы.
>>67230
Мастер 3.2 тега. Как раз вчера собирал, вряд ли там сильно разошлось. Ну могу и бету попробовать конечно.
Мастер 3.2 тега. Как раз вчера собирал, вряд ли там сильно разошлось. Ну могу и бету попробовать конечно.
>>67232
Если я правильно понял гит вообще и гитхаб в частности (поправьте меня, если ошибаюсь), это система для синхронизации сорцов для программистов. Вот, допустим я программист (хаха, вот это был бы прекол!) и мне требуется работать над проектом в главном офисе, дома, в дополнительном офисе, который в производственном моногородке, куда я езжу с командировками. Конечно, можно возить с собой внешний хдд и не париться, но все программисты делятся на две категории: 1) кто не парится и возит хдд, 2) потерявший кучу исходников, просравший сроки, контракты, обанкротившийся.
Так воот. И эта система гит вообще кароч предлагает облачное хранение сорцов на любой удобной тебе серверной площадке, синхронизацию, древовидный функционал версий. А гитхаб предлагает уже готовое физическое хранилище, площадку.
Так воооот. В случае с годотом, как и в случае с большинством проектов на гитхабе, мастер ветка является текущей работой этого программиста (или команды их). В этой текущей работе могут быть недоделки, уровня "пойду выпью кофе и допишу, но пока синхронизирую". А если программист хочет опубликовать свою работу, то в момент, когда ему кажется, что текущая версия программы достойна релиза, он создаёт копию и помещает её в специальный раздел гитхаба "релизы". В этом разделе так же можно разместить уже собранные бинарники, инструкции, дополнительные файлы, которых нет в мастер-ветке, ибо данные эти не синхронизируются, так как статичны (например, звуки, текстуры, модели, и т.п.) и просто лежат в трёх экземплярах на ноуте программиста, на рабочем компе и на гугл-диске, на случай если понадобятся в новом месте, а ноута под рукой нет.
Так вот! Качать мастер чтобы заценить движок это ну такое себе, потому что работоспособность пилящегося ПРЯМО ЩАС проекта гарантировать сложно. Из какой ветви мастер не возьми - это будет нестабильная, модифицируемая наживо версия. Неважно какой ты там тег выбрал.
Если я правильно понял гит вообще и гитхаб в частности (поправьте меня, если ошибаюсь), это система для синхронизации сорцов для программистов. Вот, допустим я программист (хаха, вот это был бы прекол!) и мне требуется работать над проектом в главном офисе, дома, в дополнительном офисе, который в производственном моногородке, куда я езжу с командировками. Конечно, можно возить с собой внешний хдд и не париться, но все программисты делятся на две категории: 1) кто не парится и возит хдд, 2) потерявший кучу исходников, просравший сроки, контракты, обанкротившийся.
Так воот. И эта система гит вообще кароч предлагает облачное хранение сорцов на любой удобной тебе серверной площадке, синхронизацию, древовидный функционал версий. А гитхаб предлагает уже готовое физическое хранилище, площадку.
Так воооот. В случае с годотом, как и в случае с большинством проектов на гитхабе, мастер ветка является текущей работой этого программиста (или команды их). В этой текущей работе могут быть недоделки, уровня "пойду выпью кофе и допишу, но пока синхронизирую". А если программист хочет опубликовать свою работу, то в момент, когда ему кажется, что текущая версия программы достойна релиза, он создаёт копию и помещает её в специальный раздел гитхаба "релизы". В этом разделе так же можно разместить уже собранные бинарники, инструкции, дополнительные файлы, которых нет в мастер-ветке, ибо данные эти не синхронизируются, так как статичны (например, звуки, текстуры, модели, и т.п.) и просто лежат в трёх экземплярах на ноуте программиста, на рабочем компе и на гугл-диске, на случай если понадобятся в новом месте, а ноута под рукой нет.
Так вот! Качать мастер чтобы заценить движок это ну такое себе, потому что работоспособность пилящегося ПРЯМО ЩАС проекта гарантировать сложно. Из какой ветви мастер не возьми - это будет нестабильная, модифицируемая наживо версия. Неважно какой ты там тег выбрал.
>>67223
Первоначальная коллизия со слоем stairs возьмётся из:
а) Нажатия кнопки
б) Коллизии с телом, которое находится в слое stairs и ещё каком-нибудь. Самая-самая верхняя ступенька - это статик_боди со слоями stairs и world, а весь остальной лестничный пролёт - только world.
Первоначальная коллизия со слоем stairs возьмётся из:
а) Нажатия кнопки
б) Коллизии с телом, которое находится в слое stairs и ещё каком-нибудь. Самая-самая верхняя ступенька - это статик_боди со слоями stairs и world, а весь остальной лестничный пролёт - только world.
>>67247
Читай может неправильно выразился, повторюсь я собирал из текущей ветки с тегом 3.2. Не из мастера 4.0. Собирал вчера, и новость про бету вчера, расхождение не больше одного дня. Отдельной ветки для беты мне не поадалось, поэтому я предполагаю, что у меня версия очень близкая к бете.
Читай может неправильно выразился, повторюсь я собирал из текущей ветки с тегом 3.2. Не из мастера 4.0. Собирал вчера, и новость про бету вчера, расхождение не больше одного дня. Отдельной ветки для беты мне не поадалось, поэтому я предполагаю, что у меня версия очень близкая к бете.
>>67255
Видосик бы на эту тему, чтобы визуально заценить красоту идеи.
Видосик бы на эту тему, чтобы визуально заценить красоту идеи.
169 Кб, 800x595Посоны, что за глюки с AnimationPlayer? Я увел альфа канал спрайта в ноль, но спрайт почему то появляется на мгновение и мигает по ходу дальнейшей анимации. В чем же дело?
>>67445
Становишься в начало анимации, создаёшь ключ с желаемым значением прозрачности. Становишься в конец анимации. Дублируешь первый ключ.
После этого добавляешь в середину анимации сколько хочешь ключей и значений.
Становишься в начало анимации, создаёшь ключ с желаемым значением прозрачности. Становишься в конец анимации. Дублируешь первый ключ.
После этого добавляешь в середину анимации сколько хочешь ключей и значений.
>>67255
вщи, перепутал, правильно так:
>а весь остальной лестничный пролёт - только world
вщи, перепутал, правильно так:
>>а весь остальной лестничный пролёт - только stairs
>>67466
Потому что интерполяция. Издержки алгоритма. Алгоритм интерполирует везде, между ключами, которые ты проставил, а там, где ты их не поставил, обычно от начала и/или от конца, там он пытается предугадать, интерполируя между последним ключом и первым ключом.
Потому что интерполяция. Издержки алгоритма. Алгоритм интерполирует везде, между ключами, которые ты проставил, а там, где ты их не поставил, обычно от начала и/или от конца, там он пытается предугадать, интерполируя между последним ключом и первым ключом.
Поддержка райдера завезена https://www.youtube.com/watch?v=N4M5eV982n0
https://github.com/godotengine/godot-demo-projects/tree/master/audio/generator
Херассе, в годоте теоретически можно написать полноценный звуковой синтезтор. Правда, как пишут, гдскрипт работает слишком медленно, чтобы сделать что-то более-менее сложное практически. Жаль, у меня есть в загашнике идея, чтобы абсолютно все звуки в игре синтезировались "на лету", без записанных семплов.
Херассе, в годоте теоретически можно написать полноценный звуковой синтезтор. Правда, как пишут, гдскрипт работает слишком медленно, чтобы сделать что-то более-менее сложное практически. Жаль, у меня есть в загашнике идея, чтобы абсолютно все звуки в игре синтезировались "на лету", без записанных семплов.
>>67761
Возьми бинды в сишарп любого понравившегося тебе звукового синтезатора и зделой себе класс-адаптер по паттерну адаптера, разумеется, затем остальные скрепты можешь продолжать писать на гдскрипте, просто релиз у тебя будет с дополнительной либой.
Ах да, на иосе соснешь с шарпом, ну, надо подождать.
Возьми бинды в сишарп любого понравившегося тебе звукового синтезатора и зделой себе класс-адаптер по паттерну адаптера, разумеется, затем остальные скрепты можешь продолжать писать на гдскрипте, просто релиз у тебя будет с дополнительной либой.
Ах да, на иосе соснешь с шарпом, ну, надо подождать.
>>67761
Сомневаюсь что скорость гдскрипта в синтезаторе на что то повлияет, ведь всю работу делают микшеры на плюсах и железо.
Сомневаюсь что скорость гдскрипта в синтезаторе на что то повлияет, ведь всю работу делают микшеры на плюсах и железо.
>>68055
Прикольно, вроде и очевидно, но никогда не сталкивался.
Прикольно, вроде и очевидно, но никогда не сталкивался.
88 Кб, 319x255>>68060
Можно лепить спрайты/партикли/декали
Можно деформить террейн
Можно блендить текстуры террейна
Можно рисовать polyboard (не знаю как называется, смотри пик)
Можно лепить спрайты/партикли/декали
Можно деформить террейн
Можно блендить текстуры террейна
Можно рисовать polyboard (не знаю как называется, смотри пик)
>>68055
Сорян, заснул вчера. Вот следующий пост, если кто-то ждал.
Сорян, заснул вчера. Вот следующий пост, если кто-то ждал.
>>68099
Жалко, что шаблоны не могут содержать выражения, а то можно бы сделать ещё короче.
И в шарпе, кстати даже так не получится сделать. Там жёстко требует константы в кейсах свича.
12 строка не нужна. Это из другого теста.
Жалко, что шаблоны не могут содержать выражения, а то можно бы сделать ещё короче.
И в шарпе, кстати даже так не получится сделать. Там жёстко требует константы в кейсах свича.
12 строка не нужна. Это из другого теста.
>>67985
Ну так я говорю о реалистичных звуках, а не просто о синусоиде.
Ну так я говорю о реалистичных звуках, а не просто о синусоиде.
>>67832
Что ты блять несёшь?
1. Уже лет 20 как не слишком тяжёл. А основные алгоритмы так вообще полвека известны.
2. Для создания реалистичных звуков он не предназначен, так что полного реализма добиться нельзя.
Основная причина, почему обычно используются предзаписанные семплы вместо синтеза: это проще и дешевле. Синтез нужен для того, чтобы создавать не существовавшие ранее звуки, которые невозможно издать никаким естественным источником, потому что, если бы такой источник существовал, проще записать его на микрофон и не ебать мозги сложными алгоритмами.
Сравни с анимацией. Её можно делать вручную (синтез) или мокапом (заись). В обоих случаях понадобятся определённые затраты, и мокап тоже придётся потом руками редактировать. Для мультяшности лучше подходит ручная анимация, а для реализма мокап. Можно наборот, но только если это действительно необходимо.
Что касается моторов в GTA5 и, скажем, фортепианного синтезатора Pianoteq, то это исключения ввиду изначальной постановки задачи. В обоих случаях имеет место пересечение двух проблем:
1. Нужно много семплов. Каждый автомобиль имеет несколько передач, свои звуки старта и остановки, автомобилей в игре много. Клавиш у пианины 88 штук, на разных громкостях характер звука меняется.
2. Взаимное влияние и вариативность. Разгон и торможение, смена передач - всё это не так просто между собой соединить. Фортепиано резонирует сложным образом, высокие струны при нажатой клавише улавливают колебания более низких.
В результате получается выбор между двумя стульями: пожертвовать производительностью и получить более гибкую систему или пожертвовать гибкостью и получить более дешёвую систему. И всё это имеет к вопросу "синтез или семплы" мало отношения, потому что в большинстве случаев ответ на него примерно совпадает с "сфотографировать или нарисовать".
>Риалтайм-синтез реалистичных звуков всё ещё слишком тяжёл для современных процессоров.
Что ты блять несёшь?
1. Уже лет 20 как не слишком тяжёл. А основные алгоритмы так вообще полвека известны.
2. Для создания реалистичных звуков он не предназначен, так что полного реализма добиться нельзя.
Основная причина, почему обычно используются предзаписанные семплы вместо синтеза: это проще и дешевле. Синтез нужен для того, чтобы создавать не существовавшие ранее звуки, которые невозможно издать никаким естественным источником, потому что, если бы такой источник существовал, проще записать его на микрофон и не ебать мозги сложными алгоритмами.
Сравни с анимацией. Её можно делать вручную (синтез) или мокапом (заись). В обоих случаях понадобятся определённые затраты, и мокап тоже придётся потом руками редактировать. Для мультяшности лучше подходит ручная анимация, а для реализма мокап. Можно наборот, но только если это действительно необходимо.
Что касается моторов в GTA5 и, скажем, фортепианного синтезатора Pianoteq, то это исключения ввиду изначальной постановки задачи. В обоих случаях имеет место пересечение двух проблем:
1. Нужно много семплов. Каждый автомобиль имеет несколько передач, свои звуки старта и остановки, автомобилей в игре много. Клавиш у пианины 88 штук, на разных громкостях характер звука меняется.
2. Взаимное влияние и вариативность. Разгон и торможение, смена передач - всё это не так просто между собой соединить. Фортепиано резонирует сложным образом, высокие струны при нажатой клавише улавливают колебания более низких.
В результате получается выбор между двумя стульями: пожертвовать производительностью и получить более гибкую систему или пожертвовать гибкостью и получить более дешёвую систему. И всё это имеет к вопросу "синтез или семплы" мало отношения, потому что в большинстве случаев ответ на него примерно совпадает с "сфотографировать или нарисовать".
>>68139
Он разбирается, ты - нет.
Он разбирается, ты - нет.
Пасаны, кто юзал накаму? https://github.com/heroiclabs/nakama-godot
Годный ассет?
Годный ассет?
>>68099
А чем тебе не угодил elif? Я пока вижу в нём одни плюсы против твоей инструкции:
1. Меньше отступов
2. Можно использовать выражения сразу в шаблонах, без промежуточных переменных
А чем тебе не угодил elif? Я пока вижу в нём одни плюсы против твоей инструкции:
1. Меньше отступов
2. Можно использовать выражения сразу в шаблонах, без промежуточных переменных
>>68170
Думаю тут таких богов пока нет. А как ты кстати решаешь вопросы с GDPR и ПД, если у тебя по соцсети логинятся?
Думаю тут таких богов пока нет. А как ты кстати решаешь вопросы с GDPR и ПД, если у тебя по соцсети логинятся?
>>68174
Адвокат мой решает эти вопросики, кабанчиком на созвоне.
Адвокат мой решает эти вопросики, кабанчиком на созвоне.
>>67247
Никогда, слышишь, НИКОГДА, блядь, так не делай. Master не для этого.
>мастер ветка является текущей работой этого программиста (или команды их). В этой текущей работе могут быть недоделки, уровня "пойду выпью кофе и допишу, но пока синхронизирую". А если программист хочет опубликовать свою работу, то в момент,
Никогда, слышишь, НИКОГДА, блядь, так не делай. Master не для этого.
>>66812
Два варианта тебе на выбор:
1) Свойство onStairs делай тогда не флагом, а счетчиком. И каждый заход в зону лестницы плюс 1, каждый выход минус 1. Если 0 то чел на лестнице, если больше нуля, то на какой-либо лестнице.
2) Делаешь для правых и левых лестниц разные флаги (onLeftStair и onRightStair) и соответсвенно разные стейты для них в стейт-машине игрока. Да, это ведет к дублированию кода, но может оказаться проще в реализации.
>Я тоже думал в таком направлении. Но в конструкции пикрилейтед (а они предполагаются повсеместно) начинается жопа. Потому что неизбежно при спуске происходит area_exited верхней лестницы.
>Короче, надо ещё учитывать, на какой именно лестнице стоит персонаж. Так что, видимо, не обойтись простым onStairs, придётся передавать self в параметрах, а при выходе сравнивать.
Два варианта тебе на выбор:
1) Свойство onStairs делай тогда не флагом, а счетчиком. И каждый заход в зону лестницы плюс 1, каждый выход минус 1. Если 0 то чел на лестнице, если больше нуля, то на какой-либо лестнице.
2) Делаешь для правых и левых лестниц разные флаги (onLeftStair и onRightStair) и соответсвенно разные стейты для них в стейт-машине игрока. Да, это ведет к дублированию кода, но может оказаться проще в реализации.
>>68313
быстрофикс.
Если 0, то чел НЕ на лестнице...
>сли 0 то чел на лестнице, если больше нуля, то на какой-либо лестнице.
быстрофикс.
Если 0, то чел НЕ на лестнице...
>>68311
Я так не делаю! Но 90% блядь софта который я качал с гитхаба сорцами с мастера и пытался собрать - был неработоспособен! А работоспособны обычно сорцы, выложенные в релизах.
Я так не делаю! Но 90% блядь софта который я качал с гитхаба сорцами с мастера и пытался собрать - был неработоспособен! А работоспособны обычно сорцы, выложенные в релизах.
Долбаные риджиды так и норовят проснуться.
Сделал сцену, в которой к RigidBody2D добавляются всякие полезные мелочи типа звука удара, таймера самоуничтожения и прочие.
Расставил по сцене кучу таких вот тел, проставил им всем галки "sleeping". Но эти гады всё равно просыпаются сами по себе. Ударил по одному ящику, а проснулся другой; иногда они сами по себе дёргаются, если ударить какой-то посторонний предмет. Я очень подозреваю, что виноваты общие ресурсы, не захотевшие сделаться local_to_scene. Поискал, нашёл соответствующую галку для скрипта. Не помогло. Коллизиям проставил галки, тоже не помогло. Я подозреваю, что где-то в самом риджидбоди надо искать. Но хз где, глазами по двадцать раз каждый пиксель просмотрел. Чего я не знаю? Где мог не посмотреть? Где-то скрыта какая-то не вполне очевидная опция?
Сделал сцену, в которой к RigidBody2D добавляются всякие полезные мелочи типа звука удара, таймера самоуничтожения и прочие.
Расставил по сцене кучу таких вот тел, проставил им всем галки "sleeping". Но эти гады всё равно просыпаются сами по себе. Ударил по одному ящику, а проснулся другой; иногда они сами по себе дёргаются, если ударить какой-то посторонний предмет. Я очень подозреваю, что виноваты общие ресурсы, не захотевшие сделаться local_to_scene. Поискал, нашёл соответствующую галку для скрипта. Не помогло. Коллизиям проставил галки, тоже не помогло. Я подозреваю, что где-то в самом риджидбоди надо искать. Но хз где, глазами по двадцать раз каждый пиксель просмотрел. Чего я не знаю? Где мог не посмотреть? Где-то скрыта какая-то не вполне очевидная опция?
>>68341
Судя по посту, у тебя какие-то неудачные решения в архитектуре проекта были предприняты. Подозреваю, у тебя очень большая вложенность ресурсов друг в друга с неконтролируемыми тобой взаимопересечениями, при которых, скажем, у одного куба оказывается коллайдер второго куба, например.
Что с этим делать? Возьми карандаш и бумагу и нарисуй схему своей сцены так, как ты это видишь. Затем открывай субсцены в редакторе и сверяй со своим листком на соответствие.
Судя по посту, у тебя какие-то неудачные решения в архитектуре проекта были предприняты. Подозреваю, у тебя очень большая вложенность ресурсов друг в друга с неконтролируемыми тобой взаимопересечениями, при которых, скажем, у одного куба оказывается коллайдер второго куба, например.
Что с этим делать? Возьми карандаш и бумагу и нарисуй схему своей сцены так, как ты это видишь. Затем открывай субсцены в редакторе и сверяй со своим листком на соответствие.
>>68355
Не вижу более простого, вижу костыли.
Не вижу более простого, вижу костыли.
>>68353
>>66898
Может быть. Но вот это:
мне кажется не сильно продуктивным. Если я правильно понял, то тебе придется дрочить проверку коллизий с лестницами каждый игровой цикл, чтобы понимать где игрок находится. В случае с area, твой игрок просто получает сообщения в момент выхода/входа в зону лестницы, а дальше ты уже работаешь с полями своего объекта-игрока.
>Зачем это всё? Нашлось же простое работающее решение:
>>66898
Может быть. Но вот это:
>Смотрим коллизии. Если среди них есть объект из слоя stairs
мне кажется не сильно продуктивным. Если я правильно понял, то тебе придется дрочить проверку коллизий с лестницами каждый игровой цикл, чтобы понимать где игрок находится. В случае с area, твой игрок просто получает сообщения в момент выхода/входа в зону лестницы, а дальше ты уже работаешь с полями своего объекта-игрока.
>>58384 (OP)
Анончики. Можно ли как нибудь в проекте получить доступ к значению дата/время когда был сделан билд проекта?
Анончики. Можно ли как нибудь в проекте получить доступ к значению дата/время когда был сделан билд проекта?
>>68372
Никогда не интересовался. Но скорре всего ты можешь просто получить доступ к файлу PCK и узнать время его создания, если в АПИ не найдётся функционала. Но вообще тебе зачем? Моды? Сетевая синхронизация версий клиентов и сервера?
Никогда не интересовался. Но скорре всего ты можешь просто получить доступ к файлу PCK и узнать время его создания, если в АПИ не найдётся функционала. Но вообще тебе зачем? Моды? Сетевая синхронизация версий клиентов и сервера?
>>68374
Вот что нашлось
http://docs.godotengine.org/en/3.2/classes/class_file.html#class-file-method-get-modified-time
> просто получить доступ к файлу PCK и узнать время его создания
Вот что нашлось
http://docs.godotengine.org/en/3.2/classes/class_file.html#class-file-method-get-modified-time
>>62679
Ёптумать, его ещё не пофиксили?
Ёптумать, его ещё не пофиксили?
Всё работало нормально, как вдруг...
Корень сцены AnimatedSprite по имени Door, в нём StaticBody2D по имени Body.Не наоборот, чтобы без редактирования потомков можно было легко поменять текстуру двери. В скрипте к спрайту в разных местах есть обращение к $Body. И почему-то он его не хочет видеть, говорит, что нет такого:
var B = $Body
print(B)
#выводит: null
При этом Body я не вручную писал, а выковырял из всплывающей подсказки, которая возникла после написания $. Через get_node тоже не видит. Скрипт точно прикреплён к Door, Door точно корень.
Штобля? Как это вообще? Почему в других нодах нормально работает? Где вообще тут можно накосячить?
Корень сцены AnimatedSprite по имени Door, в нём StaticBody2D по имени Body.Не наоборот, чтобы без редактирования потомков можно было легко поменять текстуру двери. В скрипте к спрайту в разных местах есть обращение к $Body. И почему-то он его не хочет видеть, говорит, что нет такого:
var B = $Body
print(B)
#выводит: null
При этом Body я не вручную писал, а выковырял из всплывающей подсказки, которая возникла после написания $. Через get_node тоже не видит. Скрипт точно прикреплён к Door, Door точно корень.
Штобля? Как это вообще? Почему в других нодах нормально работает? Где вообще тут можно накосячить?
>>68374
Помечать билды для тестеров.
Сейчас я просто на экран вывожу label в который руками прописываю версию и дату создания билда.
Хотелось бы, чтобы либо эта дата сама где-то фиксировалась при экспорте проекта, либо можно было как нибудь получить доступ к хэшу текущего коммита в репозитории проекта.
>Но вообще тебе зачем? Моды? Сетевая синхронизация версий клиентов и сервера?
Помечать билды для тестеров.
Сейчас я просто на экран вывожу label в который руками прописываю версию и дату создания билда.
Хотелось бы, чтобы либо эта дата сама где-то фиксировалась при экспорте проекта, либо можно было как нибудь получить доступ к хэшу текущего коммита в репозитории проекта.
2,8 Мб, 506x400>>68372
>>68374
>>68382
Вобщем, сделал пока так
создал батник stamp.bat в корне который пишет в файл res://data/stamp.txt, дату, время и инфу из репа по hg id (батник и текстовик записал в игнор в проекте)
В проекте кинул на канвас label в которой в _Ready() прописал простой скрипт, который во время запуска при наличии в ресурсах stamp.txt помещает инфу из него в label.text.
Теперь перед экспортом проекта просто запускаю батник и у меня в билде выводится нужная инфа.
Пример на пике.
В будущем когда в годоте починят экспорт проекта из командной строки, можно будет все одним нажатием делать.
>>68374
>>68382
Вобщем, сделал пока так
создал батник stamp.bat в корне который пишет в файл res://data/stamp.txt, дату, время и инфу из репа по hg id (батник и текстовик записал в игнор в проекте)
В проекте кинул на канвас label в которой в _Ready() прописал простой скрипт, который во время запуска при наличии в ресурсах stamp.txt помещает инфу из него в label.text.
Теперь перед экспортом проекта просто запускаю батник и у меня в билде выводится нужная инфа.
Пример на пике.
В будущем когда в годоте починят экспорт проекта из командной строки, можно будет все одним нажатием делать.
>>68543
А чем не устраивает делать то же самое из кода в проекте?
Просто нравится батники вызывать?
Можно ведь сделать проще:
А чем не устраивает делать то же самое из кода в проекте?
Просто нравится батники вызывать?
> кинул на канвас label в которой в _Ready() прописал простой скрипт, который во время запуска при наличии в ресурсах stamp.txt помещает инфу из него в label.text
Можно ведь сделать проще:
> кинул на канвас label в которой в _Ready() прописал простой скрипт, который во время запуска помещает инфу из репа по hg id в label.text
>>68596
1) Запускать из игры какие-то сторонние приложения - это крайне плохо. За такое по лицу бьют. Плюс, подозреваю, половина антивирусов будет матом орать на подобные телодвижения.
Может быть это можно сделать в виде плагина к редактору, который бы перед экспортом получал информацию, но я пока не нашел как такое сделать.
2) У тестеров нету репозитория, откуда тогда игра будет инфу брать, когда она построена. А даже если и есть, то реп может быть совсем на другой ветке открыт и т.д.
>во время запуска помещает инфу из репа по hg id в label.text
1) Запускать из игры какие-то сторонние приложения - это крайне плохо. За такое по лицу бьют. Плюс, подозреваю, половина антивирусов будет матом орать на подобные телодвижения.
Может быть это можно сделать в виде плагина к редактору, который бы перед экспортом получал информацию, но я пока не нашел как такое сделать.
2) У тестеров нету репозитория, откуда тогда игра будет инфу брать, когда она построена. А даже если и есть, то реп может быть совсем на другой ветке открыт и т.д.
>>68603
Причём тут сторонние приложения? Получить инфу из репа - это обычный веб-запрос. За такое только брандмауер разрешение на сеть запросит.
Причём тут сторонние приложения? Получить инфу из репа - это обычный веб-запрос. За такое только брандмауер разрешение на сеть запросит.
>>68605
Учитывая современные системы защиты от ператов типа денувы, игроки не удивятся запросу на сеть.
Учитывая современные системы защиты от ператов типа денувы, игроки не удивятся запросу на сеть.
>>68605
1) Реп закрыт о тех кто будет запускать приложение.
2) Даже если есть доступ, откуда приложение будет знать из какой ветки репозитория я его собирал.
3) Нахер мне еще своему приложению доступ в сеть давать если он ему объективно не нужен.
>>68606
Игроки играющие в игры с активной денувой и анальному зонду в своей заднице не удивятся.
>Причём тут сторонние приложения? Получить инфу из репа - это обычный веб-запрос. За такое только брандмауер разрешение на сеть запросит.
1) Реп закрыт о тех кто будет запускать приложение.
2) Даже если есть доступ, откуда приложение будет знать из какой ветки репозитория я его собирал.
3) Нахер мне еще своему приложению доступ в сеть давать если он ему объективно не нужен.
>>68606
>Учитывая современные системы защиты от ператов типа денувы, игроки не удивятся запросу на сеть.
Игроки играющие в игры с активной денувой и анальному зонду в своей заднице не удивятся.
>>68616
Очень странно слышать пиратско-воровские с примесью шапочки из фольги речи от сторонника опенсорца. Стапэ. А с чего это я решил, что он сторонник опенсорца?
> Игроки играющие в игры с активной денувой
Очень странно слышать пиратско-воровские с примесью шапочки из фольги речи от сторонника опенсорца. Стапэ. А с чего это я решил, что он сторонник опенсорца?
>>68525 (Del)
Вполне норм. Простой, удобный двиг, дающий знания обо всех современных фишках и тенденциях геймдева. Даже если захочешь уйти - время, потраченное на изучение не пройдёт впустую, ибо в Годо не используется ни единого вендорлока, все данные ты сможешь использовать в открытом виде и при желании забрать их с собой на другие платформы.
Вполне норм. Простой, удобный двиг, дающий знания обо всех современных фишках и тенденциях геймдева. Даже если захочешь уйти - время, потраченное на изучение не пройдёт впустую, ибо в Годо не используется ни единого вендорлока, все данные ты сможешь использовать в открытом виде и при желании забрать их с собой на другие платформы.
>>68615 (Del)
Репорт.
Репорт.
>>68618
Ничего воровского. Денува (и прочие подобные защиты, вроде старфорса) такая срань, что ну его нахуй. Я принципиально не покупаю и даже не пирачу игры с такими защитами, идут они лесом.
Я х.з. с чего ты это решил. Но таки да, после окончания разработки я сорцы всех своих проектов открываю. Но на время разработки реп закрытым держу.
Так-то я геймдевом по фану занимаюсь. Для себя и друзяшек. А сам процесс разработки и есть мое веселье.
>Очень странно слышать пиратско-воровские с примесью шапочки из фольги речи от сторонника опенсорца. Стапэ.
Ничего воровского. Денува (и прочие подобные защиты, вроде старфорса) такая срань, что ну его нахуй. Я принципиально не покупаю и даже не пирачу игры с такими защитами, идут они лесом.
>А с чего это я решил, что он сторонник опенсорца?
Я х.з. с чего ты это решил. Но таки да, после окончания разработки я сорцы всех своих проектов открываю. Но на время разработки реп закрытым держу.
Так-то я геймдевом по фану занимаюсь. Для себя и друзяшек. А сам процесс разработки и есть мое веселье.
Кто-нибудь делал что-нибудь типа гауссова размытия годотскими шейдерами? Всё, что я нагуглил, не работает в актуальной версии.
18 Кб, 368x370>>68628
Плохо гуглил.
1. https://www.google.com/search?q=godot+gaussian+shader
2. https://godotforums.org/discussion/20506/a-good-blur-shader
3. https://github.com/godotengine/godot-demo-projects/blob/master/2d/screen_space_shaders/shaders/blur.shader
> Всё, что я нагуглил, не работает в актуальной версии.
Плохо гуглил.
1. https://www.google.com/search?q=godot+gaussian+shader
2. https://godotforums.org/discussion/20506/a-good-blur-shader
3. https://github.com/godotengine/godot-demo-projects/blob/master/2d/screen_space_shaders/shaders/blur.shader
923 Кб, 1662x768>>68666
Попробовал, оф. демо, все работает в GLES3. Исходя из того что пишут, в GLES2 да, не будет работать, потому что там не строят автоматом мипмапы, поэтому при чтении через textureLod возвращается только фулл разрешение.
Попробовал, оф. демо, все работает в GLES3. Исходя из того что пишут, в GLES2 да, не будет работать, потому что там не строят автоматом мипмапы, поэтому при чтении через textureLod возвращается только фулл разрешение.
>>68684
Для глес2 открывай википедию, бери формулу и ебошь программный блюр. Медленный и велосипедный.
Зачем тебе блюр в глес2? Глес2 не для красивостей выбирают, а для ублажения нищенок со встройкой вместо видеокарты
Для глес2 открывай википедию, бери формулу и ебошь программный блюр. Медленный и велосипедный.
Зачем тебе блюр в глес2? Глес2 не для красивостей выбирают, а для ублажения нищенок со встройкой вместо видеокарты
Годаны, а слышно что-нибудь по вопросу разделения окна редактора на два? Хотелось бы редактор шейдера держать на одном мониторе, а вьюпорт с итоговым результатом видеть на другом.
Здарова, бандиты.
Я же правильно понимаю, что для того, чтобы хуйнуть в свой проект модуль для андройда мне этот самый модуль нужно сначала в апкашку скомпилить? И для этого придется наебнуть все, что написано в доках https://docs.godotengine.org/en/stable/development/compiling/compiling_for_android.html ?
Есть более халявные варианты, вообще нет желания ебаться с окружением и настройкой десятка пекедж билдеров и прочей хуйни
Я же правильно понимаю, что для того, чтобы хуйнуть в свой проект модуль для андройда мне этот самый модуль нужно сначала в апкашку скомпилить? И для этого придется наебнуть все, что написано в доках https://docs.godotengine.org/en/stable/development/compiling/compiling_for_android.html ?
Есть более халявные варианты, вообще нет желания ебаться с окружением и настройкой десятка пекедж билдеров и прочей хуйни
>>69545
Нет, не шарп, я тебе повторяю, плагин годота завозит в райдер гдскрипт с полной поддержкой подсветки, плюс запуск проекта прямо из райдера в годоте, используя годот, как интерпретатор.
Нет, не шарп, я тебе повторяю, плагин годота завозит в райдер гдскрипт с полной поддержкой подсветки, плюс запуск проекта прямо из райдера в годоте, используя годот, как интерпретатор.
>>69540
В vs code есть плагин, про качество хз не пользовался.
В vs code есть плагин, про качество хз не пользовался.
>>69543
В 3.2.2 уже в бете есть. Но там все равно же плагин кому то собирать придется.
В 3.2.2 уже в бете есть. Но там все равно же плагин кому то собирать придется.
>>69527
Там ничего особо сложного нет, я недавно винду переставлял и за пол дня все вернул. По памяти там всего-то надо: python (самый свежий сойдет), scons (pip install scons), java (кошерная с AdoptOpenJDK.net), android sdk и ndk (далее-далее-готово), плюсовый компилятор вроде в ndk идет. Потом берешь за основу этот батник https://gist.github.com/Calinou/44edbd5d9c4a2ac0dbc8f165b8b7f0ce есть такой же под линь, меняешь пути, дописываешь флаги из твоей ссылки если надо и все.
Там ничего особо сложного нет, я недавно винду переставлял и за пол дня все вернул. По памяти там всего-то надо: python (самый свежий сойдет), scons (pip install scons), java (кошерная с AdoptOpenJDK.net), android sdk и ndk (далее-далее-готово), плюсовый компилятор вроде в ndk идет. Потом берешь за основу этот батник https://gist.github.com/Calinou/44edbd5d9c4a2ac0dbc8f165b8b7f0ce есть такой же под линь, меняешь пути, дописываешь флаги из твоей ссылки если надо и все.
>>69152
Пока такого нет, в 4.0 вроде уже сделано. В 3.х я слышал можно открыть просто два годота рядом, но увы картинка будет обновляться только есть жать сохранить, и альт-табаться. Можно конечно это автоматизировать хоть через autoit, но такое себе.
Пока такого нет, в 4.0 вроде уже сделано. В 3.х я слышал можно открыть просто два годота рядом, но увы картинка будет обновляться только есть жать сохранить, и альт-табаться. Можно конечно это автоматизировать хоть через autoit, но такое себе.
>>68429
Продолжаю ковыряться.
Теперь Sprite. Пытаюсь к спрайту прикрепить скрипт с какими-то действиями. Пишу $что-нибудь и получаю ошибку: метод get_node() не объявлен в этом классе.
Походу, в этом проблема. Спрайты (и их анимированные наследники) по какой-то причине не могут иметь здоровое потомство. Придётся городить огород из системы Node2D/Sprite
Продолжаю ковыряться.
Теперь Sprite. Пытаюсь к спрайту прикрепить скрипт с какими-то действиями. Пишу $что-нибудь и получаю ошибку: метод get_node() не объявлен в этом классе.
Походу, в этом проблема. Спрайты (и их анимированные наследники) по какой-то причине не могут иметь здоровое потомство. Придётся городить огород из системы Node2D/Sprite
>>69959
Что у тебя написано в первой строке файла после слова extends?
> получаю ошибку: метод get_node() не объявлен в этом классе
Что у тебя написано в первой строке файла после слова extends?
>>69959
Почему-то у меня могут. А что с тобой не так?
> Спрайты (и их анимированные наследники) по какой-то причине не могут иметь здоровое потомство.
Почему-то у меня могут. А что с тобой не так?
>>69961
У меня такая вот конструкция:
foo.gd:
extends Sprite
class_name foo
bar.gd:
extends foo
И вот как раз bar уже не имеет метода get_node()
Сделал всё то же самое, но не от спрайта, а от Node2D - полёт нормальный.
>Что у тебя написано в первой строке файла после слова extends?
У меня такая вот конструкция:
foo.gd:
extends Sprite
class_name foo
bar.gd:
extends foo
И вот как раз bar уже не имеет метода get_node()
Сделал всё то же самое, но не от спрайта, а от Node2D - полёт нормальный.
Неожиданная проблема и решение.
foo.gd:
var My_Array: PoolIntArray
...
var.gd:
foo.My_Array.append(12345)
В массив ничего не добавляется. Я хз почему и куда пишутся эти данные, ошибки никакой не выдаёт. Решение:
foo.gd:
var My_Array: PoolIntArray
func My_Append(value: int):
My_Array.append(value)
...
var.gd:
foo.My_Append(12345)
Теперь массив заполняется корректно.
В принципе, наверное, так всё равно лучше и типобезопаснее.
Кто понимает матчасть, разъясните, почему оно именно так работает.
foo.gd:
var My_Array: PoolIntArray
...
var.gd:
foo.My_Array.append(12345)
В массив ничего не добавляется. Я хз почему и куда пишутся эти данные, ошибки никакой не выдаёт. Решение:
foo.gd:
var My_Array: PoolIntArray
func My_Append(value: int):
My_Array.append(value)
...
var.gd:
foo.My_Append(12345)
Теперь массив заполняется корректно.
В принципе, наверное, так всё равно лучше и типобезопаснее.
Кто понимает матчасть, разъясните, почему оно именно так работает.
>>70066
Массивы передаются по значению в гдскрипте. поэтому да, при обращении к массиву через класс, класс выдаёт копию массива, в которую ты что-то добавляешь, после чего эта копия исчезает в недрах оперативки.
Массивы передаются по значению в гдскрипте. поэтому да, при обращении к массиву через класс, класс выдаёт копию массива, в которую ты что-то добавляешь, после чего эта копия исчезает в недрах оперативки.
>>69977
Перепроверяй свой код. Ты что-то напортачил, ибо наследование работает, как ожидалось:
Перепроверяй свой код. Ты что-то напортачил, ибо наследование работает, как ожидалось:
16 Кб, 983x516Нахуй он мне показывает cnd с информацией, доступной в консольке самого годота?
>>70233
Для дебага в случае чего.
Для дебага в случае чего.
>>70237
Это для девелоперов, а не пользователей и нахуй не нужно в релизе включенное по дефолту
Это для девелоперов, а не пользователей и нахуй не нужно в релизе включенное по дефолту
>>68642
Я юзаю вот такой для глес2, но он медленный как сука. Мобилочки не вывозят. https://pastebin.com/uXjK1pca
Если тебе это нужно для окна паузы, где никаких визуальных изменений не будет происходить и шейдер тебе не нужен в риалтайме, то можешь его запускать таким костылём всего на пару фреймов:
Здесь на сцене тупо друг над другом стоят ColorRect (на котором и запущен шейдер) и пустой TextureRect, которые друг друга заменяют.
func show_menu():
self.visible=true #Показать меню
yield(get_tree(), "idle_frame")
yield(get_tree(), "idle_frame")
var pic = get_viewport().get_texture().get_data()
pic.flip_y() #Нужно т.к. вьюпорт возвращается перевёрнутым
var img = ImageTexture.new()
img.create_from_image(pic)
$TextureRect.texture=img
$TextureRect.visible=true
$ColorRect.visible=false
Мб кто-то мне подскажет, как это сделать лучше, а не этим костылём. Буду благодарен
Я юзаю вот такой для глес2, но он медленный как сука. Мобилочки не вывозят. https://pastebin.com/uXjK1pca
Если тебе это нужно для окна паузы, где никаких визуальных изменений не будет происходить и шейдер тебе не нужен в риалтайме, то можешь его запускать таким костылём всего на пару фреймов:
Здесь на сцене тупо друг над другом стоят ColorRect (на котором и запущен шейдер) и пустой TextureRect, которые друг друга заменяют.
func show_menu():
self.visible=true #Показать меню
yield(get_tree(), "idle_frame")
yield(get_tree(), "idle_frame")
var pic = get_viewport().get_texture().get_data()
pic.flip_y() #Нужно т.к. вьюпорт возвращается перевёрнутым
var img = ImageTexture.new()
img.create_from_image(pic)
$TextureRect.texture=img
$TextureRect.visible=true
$ColorRect.visible=false
Мб кто-то мне подскажет, как это сделать лучше, а не этим костылём. Буду благодарен
>>70332
Быстрофикс: \t = таб. Забыл, что двачи не способны в табы
Быстрофикс: \t = таб. Забыл, что двачи не способны в табы
>>70332
Чисто с дивана предполагаю, что циклы можно попробовать заменить индусским кодом (копипащенными строчками с магическими числами), там всего по 8 раз нужно все направления вокруг пиксела обработать. ЕМНИП, циклы в ЖЛШЛ тормозные.
> но он медленный как сука
> как это сделать лучше
Чисто с дивана предполагаю, что циклы можно попробовать заменить индусским кодом (копипащенными строчками с магическими числами), там всего по 8 раз нужно все направления вокруг пиксела обработать. ЕМНИП, циклы в ЖЛШЛ тормозные.
А есть какое-то движковое решение для тороидных поверхностей? В смысле, вот хочу я, чтобы объекты, уходящие за левый край экрана, появлялись справа, пишу им:
position.x = wrapf(position.x, 0, 1000)
и получаю на границах перехода лютые мерцания объектов на границе плюс глючащую физику, которая не знает, что ей надо детектить коллизии с другого конца игрового мира.
Есть какая-то более-менее простая опция, которая бы решала эти проблемы и другие, связанные с тороидным миром, о которых я ещё не знаю? Или надо писать свои костыли?
position.x = wrapf(position.x, 0, 1000)
и получаю на границах перехода лютые мерцания объектов на границе плюс глючащую физику, которая не знает, что ей надо детектить коллизии с другого конца игрового мира.
Есть какая-то более-менее простая опция, которая бы решала эти проблемы и другие, связанные с тороидным миром, о которых я ещё не знаю? Или надо писать свои костыли?
>>70364
Есть. Зацикливание перемещения физических объектов делается обращением к их физическому состоянию в колбэке _integrate_forces() и вообще обращения к физике лучше делать там. Тогда всё будет фрейм к фрейму, без мерцаний и подёргиваний.
> Есть какая-то более-менее простая опция
Есть. Зацикливание перемещения физических объектов делается обращением к их физическому состоянию в колбэке _integrate_forces() и вообще обращения к физике лучше делать там. Тогда всё будет фрейм к фрейму, без мерцаний и подёргиваний.
>>70411
Пик 1. Что будет, если a>b? Круг докатится до правого края экрана, телепортируется на левый край, обнаружит себя глубоко погружённым в квадрат, вытолкнется за левый край, телепортируется снова в правую часть. Время, вектор и точка столкновения будут совсем не такими, какими они были бы на бесшовном цилиндре. Плюс отрисовка: круг на один кадр мигнёт слева и снова окажется справа.
Пик 2. Квадрат и зелёный круг сильно тяжелее серого. И вот зелёный утолкал серого настолько, что стало b<a. Серый круг каждый кадр телепортируется через границу экрана и проникает в коллизию то с квадратом, то с зелёным кругом. Полноценно передать импульс от двух столкновений он не может, потому что эти два столкновения никогда не происходят одновременно. На бесшовном цилиндре серый круг бы в какой-то момент получил две коллизии одновременно и напрямую передал импульс от квадрата в зелёный круг.
Пик 1. Что будет, если a>b? Круг докатится до правого края экрана, телепортируется на левый край, обнаружит себя глубоко погружённым в квадрат, вытолкнется за левый край, телепортируется снова в правую часть. Время, вектор и точка столкновения будут совсем не такими, какими они были бы на бесшовном цилиндре. Плюс отрисовка: круг на один кадр мигнёт слева и снова окажется справа.
Пик 2. Квадрат и зелёный круг сильно тяжелее серого. И вот зелёный утолкал серого настолько, что стало b<a. Серый круг каждый кадр телепортируется через границу экрана и проникает в коллизию то с квадратом, то с зелёным кругом. Полноценно передать импульс от двух столкновений он не может, потому что эти два столкновения никогда не происходят одновременно. На бесшовном цилиндре серый круг бы в какой-то момент получил две коллизии одновременно и напрямую передал импульс от квадрата в зелёный круг.
>>70364
Можно использовать три камеры с углом обзора в 120 градусов по горизонтали и сшивать их в одно изображение. Не знаю, может ли годот в такое.
Можно использовать три камеры с углом обзора в 120 градусов по горизонтали и сшивать их в одно изображение. Не знаю, может ли годот в такое.
>>70477
Для этого нужно писать свой собственный интегратор физических сил. Гугли custom integrator.
Алсо, оффтоп, почему такие пространства называются торроидными? Тор это же просто бублик. А описываемое тобой пространство сферическое вроде?
Для этого нужно писать свой собственный интегратор физических сил. Гугли custom integrator.
Алсо, оффтоп, почему такие пространства называются торроидными? Тор это же просто бублик. А описываемое тобой пространство сферическое вроде?
>>70487
То есть надо не писать собственную физику. А просто засунуть игровой мир в обычный тор в обычном пространстве и спроецировать изображение с камер(ы) на плоскость.
То есть надо не писать собственную физику. А просто засунуть игровой мир в обычный тор в обычном пространстве и спроецировать изображение с камер(ы) на плоскость.
31 Кб, 697x496>>70490
Если представить себе карту мира как в первой Циве, то она не натягивается на сферу, но натягивается на тор (это когда закольцованы и верх с низом, и лево с право). У сферы верх и низ должны схлопываться в одну точку. мимо
> почему такие пространства называются торроидными?
Если представить себе карту мира как в первой Циве, то она не натягивается на сферу, но натягивается на тор (это когда закольцованы и верх с низом, и лево с право). У сферы верх и низ должны схлопываться в одну точку. мимо
>>70490
Если сшито по одной координате, то цилиндр. Если по двум - тор. Принципиальная разница в том, что на сфере параллельные прямые могут пересекаться (меридианы на полюсах, например), а на торе нет. Сферическую поверхность в 2д я вообще хз как симулировать. Хотя было б круто.
Гугли какого-нибудь Савватеева про топологию, он понятно объясняет. И ещё физики в лекциях про устройство вселенной любят эту тему рассказывать.
Сложна. Погуглю, но чёт кажется, что такая задача мне не по зубам. Придётся от цилиндра отказаться.
>>70505
Боюсь, что такую конструкцию из костылей даже бубном 80лвла не выстроить.
Если сшито по одной координате, то цилиндр. Если по двум - тор. Принципиальная разница в том, что на сфере параллельные прямые могут пересекаться (меридианы на полюсах, например), а на торе нет. Сферическую поверхность в 2д я вообще хз как симулировать. Хотя было б круто.
Гугли какого-нибудь Савватеева про топологию, он понятно объясняет. И ещё физики в лекциях про устройство вселенной любят эту тему рассказывать.
>свой собственный интегратор физических сил
Сложна. Погуглю, но чёт кажется, что такая задача мне не по зубам. Придётся от цилиндра отказаться.
>>70505
Боюсь, что такую конструкцию из костылей даже бубном 80лвла не выстроить.
>>70477
Есть одна идея, не факт что тебе подойдет. Использовалась в Portal. Заключается в том, что сбоку карта продолжается на какое-то расстояние, и там размещаются "копии" объектов. Но да, думаю все равно придется возиться с integrate force. Потому что копия не имеет самостоятельной физики.
Есть одна идея, не факт что тебе подойдет. Использовалась в Portal. Заключается в том, что сбоку карта продолжается на какое-то расстояние, и там размещаются "копии" объектов. Но да, думаю все равно придется возиться с integrate force. Потому что копия не имеет самостоятельной физики.
>>70525
Собсно да. Вот какое найдено решение в гугле: https://steemit.com/utopian-io/@sp33dy/tutorial-godot-engine-v3-gdscript-generic-screen-wrapping-sprite
С физикой всё будет осложняться необходимостью копировать объекты. А учитывая, что они могут быть интерактивные, могут взаимодействовать между собой и даже соединяться пружинами... В общем, раз нету нативного решения, придётся забить, дабы не строить костыльных замков.
Хотя я тут подумал, что можно было бы попозже поиграться в 3Д с порталами, как в первом Prey. В ситуации, когда не нужно продвинутое взаимодействие между предметами, можно даже и немножко копировать их на входе в портал. А обстановку позади порталов рисовать шейдерами.
Собсно да. Вот какое найдено решение в гугле: https://steemit.com/utopian-io/@sp33dy/tutorial-godot-engine-v3-gdscript-generic-screen-wrapping-sprite
С физикой всё будет осложняться необходимостью копировать объекты. А учитывая, что они могут быть интерактивные, могут взаимодействовать между собой и даже соединяться пружинами... В общем, раз нету нативного решения, придётся забить, дабы не строить костыльных замков.
Хотя я тут подумал, что можно было бы попозже поиграться в 3Д с порталами, как в первом Prey. В ситуации, когда не нужно продвинутое взаимодействие между предметами, можно даже и немножко копировать их на входе в портал. А обстановку позади порталов рисовать шейдерами.
>>70518
Ну так с физикой ещё большие костыли. Не знаю, есть ли такое в годоте, но вот в Панда 3д я такое делал с помощью класса NonlinearImager, который склеивает изображения с разных камер. Можно отобразить на плоскости сферическую проекцию, полусферическую, цилиндрическую. И шейдер сверху, чтобы корректировать искажения.
Ну так с физикой ещё большие костыли. Не знаю, есть ли такое в годоте, но вот в Панда 3д я такое делал с помощью класса NonlinearImager, который склеивает изображения с разных камер. Можно отобразить на плоскости сферическую проекцию, полусферическую, цилиндрическую. И шейдер сверху, чтобы корректировать искажения.
>>70670
С отображением проекций и в годоте проблемы нет. Но анону нужна именно корректно работающая физика. По факту - портальная, где порталы это края экрана. А на углах экрана вообще должен корректно работать двойной портал, считывающий коллизии и горизонтально и вертикально. Вот это задачка так задачка!
С отображением проекций и в годоте проблемы нет. Но анону нужна именно корректно работающая физика. По факту - портальная, где порталы это края экрана. А на углах экрана вообще должен корректно работать двойной портал, считывающий коллизии и горизонтально и вертикально. Вот это задачка так задачка!
>>70942
ИЧСХ у старых игр с таким поведением никаких особых проблем нет. практически вся аркадная классика выстроена на цилиндрических мирах. Сразу приходит на ум Mario Bros, например, который ещё не Super.
ИЧСХ у старых игр с таким поведением никаких особых проблем нет. практически вся аркадная классика выстроена на цилиндрических мирах. Сразу приходит на ум Mario Bros, например, который ещё не Super.
>>70942
Так при склеивании проекций с трёх камер объект с правого края экрана автоматически появляется на левом, и наоборот. Правда, немного размазывается у нулевых координат, но этом можно просто отсечь. Не был бы ты анонимом с двача, продемонстрировал бы.
Так при склеивании проекций с трёх камер объект с правого края экрана автоматически появляется на левом, и наоборот. Правда, немного размазывается у нулевых координат, но этом можно просто отсечь. Не был бы ты анонимом с двача, продемонстрировал бы.
>>70950
Зачем велосипедить то, что уже продемонстрировано на ютубе? Вот, с 13 минуты смотри: https://www.youtube.com/watch?v=Eu5sBPqE6Ag
> продемонстрировал бы
Зачем велосипедить то, что уже продемонстрировано на ютубе? Вот, с 13 минуты смотри: https://www.youtube.com/watch?v=Eu5sBPqE6Ag
Как это вообще возможно?
1. var foo = $RayCast2D
2. if foo != null:
3. _ if foo.is_colliding():
4. _ _ var collider = foo.get_collider()
5. _ _ if collider.has_method("bar"):
А дальше не важно, потому что дальше мы вываливаемся с ошибкой, что, дескать, у коллайдера нету метода has_method(), потому что коллайдер у нас null. Как так? Как вообще можно оказаться на 5 строчке, если мы прошли через 3, и там точно-точно is_colliding, то есть коллайдер точно-точно не null, а вполне себе Object, а значит и has_method() у него обязан быть.
Где можно было накосячить так, чтобы данная ситуация вообще сложилась? И как это исправить?
1. var foo = $RayCast2D
2. if foo != null:
3. _ if foo.is_colliding():
4. _ _ var collider = foo.get_collider()
5. _ _ if collider.has_method("bar"):
А дальше не важно, потому что дальше мы вываливаемся с ошибкой, что, дескать, у коллайдера нету метода has_method(), потому что коллайдер у нас null. Как так? Как вообще можно оказаться на 5 строчке, если мы прошли через 3, и там точно-точно is_colliding, то есть коллайдер точно-точно не null, а вполне себе Object, а значит и has_method() у него обязан быть.
Где можно было накосячить так, чтобы данная ситуация вообще сложилась? И как это исправить?
>>70973
Мы находимся в теле функции, так что всё давно уже реди. Вне тела редактор не даст запустить без onready в таком объявлении. И вообще, данная строчка чисто для твоего понимания, что речь идёт про рейкаст.
И да, строка 2. Если foo не инициализировался, то дальше программа не пойдёт. А даже если и пойдёт, то упадёт на строке 3, скажет, мол, нет такого метода id_colliding().
Мы находимся в теле функции, так что всё давно уже реди. Вне тела редактор не даст запустить без onready в таком объявлении. И вообще, данная строчка чисто для твоего понимания, что речь идёт про рейкаст.
И да, строка 2. Если foo не инициализировался, то дальше программа не пойдёт. А даже если и пойдёт, то упадёт на строке 3, скажет, мол, нет такого метода id_colliding().
>>70981
У тебя там реально фу/бар или нормальные имена? Потому что вдруго у тебя там ещё где то в проекте такие же имена и они конфликтуют на локальном и глобальном уровне?
Чисто предположение с дивана.
Алсо, в любом случае нужно больше деталей, больше кода. Совершенно непонятно, что там у тебя творится. Воспроизводится ли проблема на пустом проекте?
У тебя там реально фу/бар или нормальные имена? Потому что вдруго у тебя там ещё где то в проекте такие же имена и они конфликтуют на локальном и глобальном уровне?
Чисто предположение с дивана.
Алсо, в любом случае нужно больше деталей, больше кода. Совершенно непонятно, что там у тебя творится. Воспроизводится ли проблема на пустом проекте?
>>70986
Нормальные имена. Всё, кроме первой строки, переписано из проекта с заменой имён. Вкидывать в тред весь проект не буду, он довольно объёмный.
Одинаковые имена я даю в двух случаях:
1. Это константа, которую по какой-то причине я не хочу переносить в синглтон, поэтому добавляю её в каждый скрипт. Например, потому что этого синглтона нет.
2. Это имя скопипащено из соседнего скрипта вместе со всем, что оно делает.
Оба варианта не про здесь, потому что такой вот лучик у меня только в одной сцене. Имена уникальные. Но инстансов может быть много.
В пустом проекте оно не воспроизводится. Оно и в наполненном-то случается далеко не всегда, только когда инстансов много. Все скрипты у них local_to_scene, есичо.
Да и вообще. В том как раз и состоит мой вопрос. Что надо сделать, чтобы такое вообще произошло? Как воспроизвести это в пустом проекте?
Нормальные имена. Всё, кроме первой строки, переписано из проекта с заменой имён. Вкидывать в тред весь проект не буду, он довольно объёмный.
Одинаковые имена я даю в двух случаях:
1. Это константа, которую по какой-то причине я не хочу переносить в синглтон, поэтому добавляю её в каждый скрипт. Например, потому что этого синглтона нет.
2. Это имя скопипащено из соседнего скрипта вместе со всем, что оно делает.
Оба варианта не про здесь, потому что такой вот лучик у меня только в одной сцене. Имена уникальные. Но инстансов может быть много.
В пустом проекте оно не воспроизводится. Оно и в наполненном-то случается далеко не всегда, только когда инстансов много. Все скрипты у них local_to_scene, есичо.
Да и вообще. В том как раз и состоит мой вопрос. Что надо сделать, чтобы такое вообще произошло? Как воспроизвести это в пустом проекте?
>>70969
А почему ты уверен, что он коллайдится именно с тем у объектом у которого есть этот метод, а не с каким-нибудь другим.
После 4. _ _ var collider = foo.get_collider() сделай вывод в консоль collider и посмотри, что там.
>а вполне себе Object, а значит и has_method() у него обязан быть.
А почему ты уверен, что он коллайдится именно с тем у объектом у которого есть этот метод, а не с каким-нибудь другим.
После 4. _ _ var collider = foo.get_collider() сделай вывод в консоль collider и посмотри, что там.
>>70969
Да, это очень странно.
Да, это очень странно.
>>70969
Я бы проверил что твой $RayCast:
1. enabled
2. Настроен на нужные фильтры (collide with bodies, collide with areas)
3. Включена маска на физ слои, в которых находятся интересующие тебя объекты
4. Настроен ли в нем вообще вектор cast_to
5. По описанию вроде это не требуется при таком использовании, но попробуй перенести код в physics_process
6. По описанию, можно и не проверять на is colliding если баг в ней - get collision вернет null при отсутствиии коллизий.
Я бы проверил что твой $RayCast:
1. enabled
2. Настроен на нужные фильтры (collide with bodies, collide with areas)
3. Включена маска на физ слои, в которых находятся интересующие тебя объекты
4. Настроен ли в нем вообще вектор cast_to
5. По описанию вроде это не требуется при таком использовании, но попробуй перенести код в physics_process
6. По описанию, можно и не проверять на is colliding если баг в ней - get collision вернет null при отсутствиии коллизий.
>>70999
Потому что
а) метод has_method() есть у всех объектов. Вообще у всех. В этом смысл его применения. https://docs.godotengine.org/en/stable/classes/class_object.html#class-object-method-has-method
б) Вываливается с ошибкой Attempt to call function "has_method"in base "null instance"on a null instance.
Принт в данной ситуации, кстати, не поможет, потому что будет говорить, мол, "вы слишком много выводите, мне столько не съесть", и похерит часть текста.
Кстати, я уже придумал, как исправить ошибку конкретно в этом месте.
1. var foo = $RayCast2D
2. if foo != null:
3. _ var collider = foo.get_collider()
4. _ if collider != null:
5. _ _ if collider.has_method("bar"):
Но это не избавляет проблемы более крупной, которая происходит где-то в памяти, ведь изменение коллайдера происходило явно не тут. И действительно, теперь код падает молча, не выдавая никаких ошибок, чёрт знает в какой момент, просто когда объектов много; может упасть при 1000, а может при 50, тут как повезёт.
Потому что
а) метод has_method() есть у всех объектов. Вообще у всех. В этом смысл его применения. https://docs.godotengine.org/en/stable/classes/class_object.html#class-object-method-has-method
б) Вываливается с ошибкой Attempt to call function "has_method"in base "null instance"on a null instance.
Принт в данной ситуации, кстати, не поможет, потому что будет говорить, мол, "вы слишком много выводите, мне столько не съесть", и похерит часть текста.
Кстати, я уже придумал, как исправить ошибку конкретно в этом месте.
1. var foo = $RayCast2D
2. if foo != null:
3. _ var collider = foo.get_collider()
4. _ if collider != null:
5. _ _ if collider.has_method("bar"):
Но это не избавляет проблемы более крупной, которая происходит где-то в памяти, ведь изменение коллайдера происходило явно не тут. И действительно, теперь код падает молча, не выдавая никаких ошибок, чёрт знает в какой момент, просто когда объектов много; может упасть при 1000, а может при 50, тут как повезёт.
>>71536
Хоспаде, пошто я такой тупой? Такое простое и элегантное решение, а я не додумался.
> Эти дополнительные area над лестницами.
Хоспаде, пошто я такой тупой? Такое простое и элегантное решение, а я не додумался.
>>71558
Для справки красные платформы, на самом верху лестниц, находятся на отдельном слое коллизий. Когда игрок переходит в STATE_CLIMB, то коллизии с этим слоем отключаются, все остальное время они включены. Это позволяет без геморроя пролезать через платформы при CLIMB вверх-вниз по лестнице, и спокойно IDLE, WALK, JUMP на них.
>Хоспаде, пошто я такой тупой? Такое простое и элегантное решение, а я не додумался.
Для справки красные платформы, на самом верху лестниц, находятся на отдельном слое коллизий. Когда игрок переходит в STATE_CLIMB, то коллизии с этим слоем отключаются, все остальное время они включены. Это позволяет без геморроя пролезать через платформы при CLIMB вверх-вниз по лестнице, и спокойно IDLE, WALK, JUMP на них.
>>71536
Конечно работает. Никто и не сомневался, что она работать будет. Она и должна работать. Ты доказал, что работающая конструкция работает. И я вообще не понимаю, что надо сделать в проекте, чтобы она не работала. Однако факт: я таки сделал это случайно. Какими-то другими действиями сломал эту работающую конструкцию. Соответственно, ни в пустом проекте, ни в твоём, ни в каком-либо ещё она не будет сломана, если повторить только её, но не повторить эти ломающие действия. А что именно её сломало? Что вообще могло её сломать?
>Попробовал впихнуть твою конструкцию в свой проект - вроде работает
Конечно работает. Никто и не сомневался, что она работать будет. Она и должна работать. Ты доказал, что работающая конструкция работает. И я вообще не понимаю, что надо сделать в проекте, чтобы она не работала. Однако факт: я таки сделал это случайно. Какими-то другими действиями сломал эту работающую конструкцию. Соответственно, ни в пустом проекте, ни в твоём, ни в каком-либо ещё она не будет сломана, если повторить только её, но не повторить эти ломающие действия. А что именно её сломало? Что вообще могло её сломать?
>>71561
А у меня всё проще было организовано: У контроллера персонажа два режима движения: ходьба и полёт. При ходьбе работает гравитация и есть прыжки, при полёте гравитации нет, вместо прыжков полное перемещение по 2м осям. На лестницы накидываю area2d которая при появлении в нем игрока в общем случае посылает ему команду перейти в режим полёта. И всё. Несмотря на некоторую костыльность, как мне кажется, работает всё достаточно гладко. Кроме ебучих верхушек лестниц. Как я с ними ни мучился! А оказывается всё так просто было. Делаешь дополнительную area2d которая выталкивает вверх.
Я бы так не стал делать ибо есть односторонняя коллизия.
А у меня всё проще было организовано: У контроллера персонажа два режима движения: ходьба и полёт. При ходьбе работает гравитация и есть прыжки, при полёте гравитации нет, вместо прыжков полное перемещение по 2м осям. На лестницы накидываю area2d которая при появлении в нем игрока в общем случае посылает ему команду перейти в режим полёта. И всё. Несмотря на некоторую костыльность, как мне кажется, работает всё достаточно гладко. Кроме ебучих верхушек лестниц. Как я с ними ни мучился! А оказывается всё так просто было. Делаешь дополнительную area2d которая выталкивает вверх.
> то коллизии с этим слоем отключаются
Я бы так не стал делать ибо есть односторонняя коллизия.
Псст, пацан. Ищешь базу данных для своего проекта?
https://www.youtube.com/watch?v=TdWWiVd1IxQ
https://www.youtube.com/watch?v=TdWWiVd1IxQ
Щас очередной эпик словил:
if foo <= 1:
Остановился с ошибкой: Invalid operands 'Array' and 'Int' in operator '=='
Смотрю стек. Нахожу там foo, вижу значение: 3. В смысле да, не Array (size 4), а просто 3.
Я в ступоре нахуй. Как так-то? Как переменная может быть числом и массивом одновременно?
if foo <= 1:
Остановился с ошибкой: Invalid operands 'Array' and 'Int' in operator '=='
Смотрю стек. Нахожу там foo, вижу значение: 3. В смысле да, не Array (size 4), а просто 3.
Я в ступоре нахуй. Как так-то? Как переменная может быть числом и массивом одновременно?
>>71608
У меня ничего никуда не выталкивается. Область над лестницей просто служит ограничителем и устанавливает свой флаг onLadderTop, видя который контролер просто либо не дает ползти дальше вверх, либо позволяет ползти вниз (если игрок до этого стоит на верхней платформе и нажимает вниз)
А как ты будешь слезать вниз когда ты на верхней платформе? Коллизию все равно как-то отключать придется.
>>71608
Слишком просто для моего случая. У меня во время только прыжка может быть три стейта JUMP, FALL и ROLL. На лестницах тоже несколько возможных CLIMB, CLIMB_IDLE, CLIMB_WALK. Плюс еще всяких вроде IDLE, WALK, SWIM и т.д.
>Делаешь дополнительную area2d которая выталкивает вверх.
У меня ничего никуда не выталкивается. Область над лестницей просто служит ограничителем и устанавливает свой флаг onLadderTop, видя который контролер просто либо не дает ползти дальше вверх, либо позволяет ползти вниз (если игрок до этого стоит на верхней платформе и нажимает вниз)
>Я бы так не стал делать ибо есть односторонняя коллизия.
А как ты будешь слезать вниз когда ты на верхней платформе? Коллизию все равно как-то отключать придется.
>>71608
>А у меня всё проще было организовано: У контроллера персонажа два режима движения: ходьба и полёт.
Слишком просто для моего случая. У меня во время только прыжка может быть три стейта JUMP, FALL и ROLL. На лестницах тоже несколько возможных CLIMB, CLIMB_IDLE, CLIMB_WALK. Плюс еще всяких вроде IDLE, WALK, SWIM и т.д.
>>71755
Х.з. но с этой их динамической типизацей все возможно. Насколько я понимаю в GDScripte любая переменная может свой тип в любой момент поменять. Собсно это одна из многих причин (помимо производительности, форматирования отступами и других) почему я его дропнул в пользу C#.
>Я в ступоре нахуй. Как так-то? Как переменная может быть числом и массивом одновременно?
Х.з. но с этой их динамической типизацей все возможно. Насколько я понимаю в GDScripte любая переменная может свой тип в любой момент поменять. Собсно это одна из многих причин (помимо производительности, форматирования отступами и других) почему я его дропнул в пользу C#.
>>71580
Ну ты же понимаешь, что однозначно это сказать можно только увидев твой проект полностью.
Попробуй как я уже писал после var collider = foo.get_collider() хоть какой-нибудь вывод сделать и посмотреть, что конкретно у тебя попадает в collider. Хотя бы ID объекта получить или его тип. Может туда нихрена не object попадает, а что-то другое. Если же попадает то, что надо, возможно придется открывать issue с багом.
>А что именно её сломало? Что вообще могло её сломать?
Ну ты же понимаешь, что однозначно это сказать можно только увидев твой проект полностью.
Попробуй как я уже писал после var collider = foo.get_collider() хоть какой-нибудь вывод сделать и посмотреть, что конкретно у тебя попадает в collider. Хотя бы ID объекта получить или его тип. Может туда нихрена не object попадает, а что-то другое. Если же попадает то, что надо, возможно придется открывать issue с багом.
>>58384 (OP)
Блин, а есть какой-нибудь ПОЛНЫЙ туториал по созданию контроллера персонажа в 3D со всеми нюансами типа захода на бордюры и перемещения по лестницам? Движение в одной плоскости - это легко, но лестницы уже кажутся чем-то принципиально непреодолимым, но ведь как-то их делают. Я месяц бился со своим контроллером, пока не забил на игрострой из-за всех этих дурацких проблем, и сейчас не хочу снова с этим биться чтобы снова проиграть. Готовые контроллеры не подходят, т.к. там быдлокот какой-то и вообще есть фатальный недостаток, короч никакой возможности модификации.
Блин, а есть какой-нибудь ПОЛНЫЙ туториал по созданию контроллера персонажа в 3D со всеми нюансами типа захода на бордюры и перемещения по лестницам? Движение в одной плоскости - это легко, но лестницы уже кажутся чем-то принципиально непреодолимым, но ведь как-то их делают. Я месяц бился со своим контроллером, пока не забил на игрострой из-за всех этих дурацких проблем, и сейчас не хочу снова с этим биться чтобы снова проиграть. Готовые контроллеры не подходят, т.к. там быдлокот какой-то и вообще есть фатальный недостаток, короч никакой возможности модификации.
>>71820
Да при чём тут вообще инверсная кинематика? Я до этапа анимирования ещё не дополз вообще. Мне бы хотя бы кубик заставить по лестницам "шагать"... Нет, хотя бы чтобы он перестал подпрыгивать на маленьком бордюре так, будто врезается в почти вертикальный трамплин.
Вообще думаю нафиг 3D-модели, сделаю персонажей 2D-спрайтами с подменой на правильный ракурс при повороте камеры (хочу попробовать что-то типа GTA 2, только с видом сверху-сбоку, а не чисто сверху). Потому что в 3D всё равно хрень колючая получается, в 2D можно хотя бы сказать "это стиль такой". Но для этого мне сначала нужно реализовать правильное движение, а это ад какой-то, постоянно какие-то глюки, неужели так трудно было внедрить готовый контроллер прямо в движок?
>Inverse_kinematics
Да при чём тут вообще инверсная кинематика? Я до этапа анимирования ещё не дополз вообще. Мне бы хотя бы кубик заставить по лестницам "шагать"... Нет, хотя бы чтобы он перестал подпрыгивать на маленьком бордюре так, будто врезается в почти вертикальный трамплин.
Вообще думаю нафиг 3D-модели, сделаю персонажей 2D-спрайтами с подменой на правильный ракурс при повороте камеры (хочу попробовать что-то типа GTA 2, только с видом сверху-сбоку, а не чисто сверху). Потому что в 3D всё равно хрень колючая получается, в 2D можно хотя бы сказать "это стиль такой". Но для этого мне сначала нужно реализовать правильное движение, а это ад какой-то, постоянно какие-то глюки, неужели так трудно было внедрить готовый контроллер прямо в движок?
>>71755
Сделал print(foo) непосредственно перед сравнением. Выдаёт 3, как и следовало ожидать.
print(foo <= 1) выдаёт false. Но if после этого всё равно вываливается за несоответствие типов.
var bar: bool = (foo <= 1)
if bar:
ТО ЖЕ САМОЕ!!!!
И тут я нашёл проблему.
Кароч. На самом деле текст был такой:
1. func my_func() -> bool:
2. _ if foo <= 1: return true
3. _ if bar == 0: return true
4. _ return false
Вооот. Вываливалось всё на второй строке. Но со второй строкой на самом деле не было никаких проблем, и она работала корректно. Ошибка была на третьей строке, так как bar это на самом деле массив. У меня всё равно остался вопрос, какого чёрта дебаггер ругался не на то место, но уже понятно, что это действительно мой косяк.
Вывод: иногда дебаггер неверно указывает строку.
>>71783
Обсосали и обсудили же, что там null.
Сделал print(foo) непосредственно перед сравнением. Выдаёт 3, как и следовало ожидать.
print(foo <= 1) выдаёт false. Но if после этого всё равно вываливается за несоответствие типов.
var bar: bool = (foo <= 1)
if bar:
ТО ЖЕ САМОЕ!!!!
И тут я нашёл проблему.
Кароч. На самом деле текст был такой:
1. func my_func() -> bool:
2. _ if foo <= 1: return true
3. _ if bar == 0: return true
4. _ return false
Вооот. Вываливалось всё на второй строке. Но со второй строкой на самом деле не было никаких проблем, и она работала корректно. Ошибка была на третьей строке, так как bar это на самом деле массив. У меня всё равно остался вопрос, какого чёрта дебаггер ругался не на то место, но уже понятно, что это действительно мой косяк.
Вывод: иногда дебаггер неверно указывает строку.
>>71783
Обсосали и обсудили же, что там null.
>>71841
Изначально капсулу и пробовал. Но с лестниц капсула сползает/подпрыгивает...
>Попробуй CapsuleShape.
Изначально капсулу и пробовал. Но с лестниц капсула сползает/подпрыгивает...
>>71853
Тебе анон не просто дал статью на инверсную кинематику. Да, ты, блять не дошёл ещё до анимаций. Но когда дойдёшь, у тебя уже будет шагающий невидимыми ногами по лестницам контроллер.
>>71819
Так что, вариантов не остаётся. Ты либо сразу делаешь контроллер на инверсной кинематике, либо проигрываешь снова, потому что контроллер на простой капсуле/кубе это прошлый век геймдева. И очень верно, что ты подметил то, что все туториалы, опирающиеся на это обладают быдлокодом. Потому что пилит эти туториалы либо быдло, либо инфоцыгане. В первом случае просто бесполезный кривой туториал, во втором случае замануха для платных курсов, причём инфоцыганен может быть одновременно быдлокодером и заплатив ему ты получишь ещё один кривой туториал, но уже за деньги.
Нет туториалов. Никто в здравом уме не будет бесплатно раздавать такое. Ты либо читаешь фундаментальные статьи, типа той, что дал анон и по ссылкам из неё на источники. Либо продолжаешь раз за разом делать то же самое говно по кривым туториалам. Кстати, я уже рассказывал тебе, что такое - безумие?
Тебе анон не просто дал статью на инверсную кинематику. Да, ты, блять не дошёл ещё до анимаций. Но когда дойдёшь, у тебя уже будет шагающий невидимыми ногами по лестницам контроллер.
>>71819
Так что, вариантов не остаётся. Ты либо сразу делаешь контроллер на инверсной кинематике, либо проигрываешь снова, потому что контроллер на простой капсуле/кубе это прошлый век геймдева. И очень верно, что ты подметил то, что все туториалы, опирающиеся на это обладают быдлокодом. Потому что пилит эти туториалы либо быдло, либо инфоцыгане. В первом случае просто бесполезный кривой туториал, во втором случае замануха для платных курсов, причём инфоцыганен может быть одновременно быдлокодером и заплатив ему ты получишь ещё один кривой туториал, но уже за деньги.
Нет туториалов. Никто в здравом уме не будет бесплатно раздавать такое. Ты либо читаешь фундаментальные статьи, типа той, что дал анон и по ссылкам из неё на источники. Либо продолжаешь раз за разом делать то же самое говно по кривым туториалам. Кстати, я уже рассказывал тебе, что такое - безумие?
>>71855
Разве в играх инверсная кинематика используется для чего-то кроме анимации? Это ведь когда движение ступни корректно сдвигает коленный сустав, или движение кисти руки сдвигает локтевой сустав...
Скажем, в прямой кинематике мы должны сначала согнуть бедренный шарнир, потом согнуть коленный шарнир, потом согнуть ступню. А в инверсной кинематике мы просто делаем смещение ступни по прямой, и вслед за ней сгибаются все связанные шарниры.
Вот только как это может помочь в движении по неровной местности, если инверсная кинематика никоим образом не связана со взаимодействием с поверхностями? Ну да, суставы можно согнуть, т.о. нога, визуально стоящая на кочке, будет правдоподобно сгибаться - но ведь по факту это только 3D-модель, реальная модель персонажа стоит на определённой высоте и представляет из себя точку.
Алсо, ну вот какой мне смысл симулировать смещения коленных суставов, если у меня вместо визуальной модельки будет плоский спрайт? Ведь, по факту, у меня не будет НИКАКИХ суставов...
Так, кажется, я понял. Нужно сделать вращающиеся ступни, а всё остальное тело заменить кубиком...
>контроллер на инверсной кинематике
Разве в играх инверсная кинематика используется для чего-то кроме анимации? Это ведь когда движение ступни корректно сдвигает коленный сустав, или движение кисти руки сдвигает локтевой сустав...
Скажем, в прямой кинематике мы должны сначала согнуть бедренный шарнир, потом согнуть коленный шарнир, потом согнуть ступню. А в инверсной кинематике мы просто делаем смещение ступни по прямой, и вслед за ней сгибаются все связанные шарниры.
Вот только как это может помочь в движении по неровной местности, если инверсная кинематика никоим образом не связана со взаимодействием с поверхностями? Ну да, суставы можно согнуть, т.о. нога, визуально стоящая на кочке, будет правдоподобно сгибаться - но ведь по факту это только 3D-модель, реальная модель персонажа стоит на определённой высоте и представляет из себя точку.
Алсо, ну вот какой мне смысл симулировать смещения коленных суставов, если у меня вместо визуальной модельки будет плоский спрайт? Ведь, по факту, у меня не будет НИКАКИХ суставов...
Так, кажется, я понял. Нужно сделать вращающиеся ступни, а всё остальное тело заменить кубиком...
>>71857
Не хочется тебе давать вредных советов. Осторожно напомню, что кинематика - это раздел физики. Следовательно, инверсная кинематика помимо анимации используется в физических движках. НАВЕРНОЕ. Чтобы естественным образом идти по лестнице, должно быть некоторое основное тело и два контрольных тела-ступни, которые инверсным образом вычисляются лежащими на поверхностях ступенек. Всё, больше ничего не скажу, чтобы не нести хуйню. Я сам в этом вопросе плаваю.
> Разве в играх инверсная кинематика используется для чего-то кроме анимации?
Не хочется тебе давать вредных советов. Осторожно напомню, что кинематика - это раздел физики. Следовательно, инверсная кинематика помимо анимации используется в физических движках. НАВЕРНОЕ. Чтобы естественным образом идти по лестнице, должно быть некоторое основное тело и два контрольных тела-ступни, которые инверсным образом вычисляются лежащими на поверхностях ступенек. Всё, больше ничего не скажу, чтобы не нести хуйню. Я сам в этом вопросе плаваю.
>>71858
Так мне не нужно "естественным образом". Мне нужно, чтобы не было бесконечного сползания вниз и прыжков вверх.
А зачем инверсным-то? Ведь у них нет коленок. То есть они должны просто вращаться друг относительно друга как лопасти колёс парохода, "загребая" под себя любые препятствия. Ну, как я это вижу сейчас. Просто если делать реальные ступни, то придётся запариваться с их навигацией в пространстве - мы ведь ступни на ступеньки ставим не просто так, а на ощупь, следовательно опять-таки нужно мудрить с обнаружением столкновений и опять будет какая-нибудь глючная хрень...
Собственно хочется что-нибудь простое, типа капсулы, потому что у простых решений не бывает внезапных глюков. Но в готовых движках такое невозможно, наверное...
>Чтобы естественным образом идти по лестнице
>естественным образом
Так мне не нужно "естественным образом". Мне нужно, чтобы не было бесконечного сползания вниз и прыжков вверх.
>два контрольных тела-ступни, которые инверсным образом
А зачем инверсным-то? Ведь у них нет коленок. То есть они должны просто вращаться друг относительно друга как лопасти колёс парохода, "загребая" под себя любые препятствия. Ну, как я это вижу сейчас. Просто если делать реальные ступни, то придётся запариваться с их навигацией в пространстве - мы ведь ступни на ступеньки ставим не просто так, а на ощупь, следовательно опять-таки нужно мудрить с обнаружением столкновений и опять будет какая-нибудь глючная хрень...
Собственно хочется что-нибудь простое, типа капсулы, потому что у простых решений не бывает внезапных глюков. Но в готовых движках такое невозможно, наверное...
>>71859
Используй вектора, Люк.
(рейкасты, нормали, снапы... вот это вот все...)
>Мне нужно, чтобы не было бесконечного сползания вниз и прыжков вверх.
Используй вектора, Люк.
(рейкасты, нормали, снапы... вот это вот все...)
>>71862
Ты думаешь, я этого не пробовал? Фигня какая-то получается.
>рейкасты, нормали, снапы
>Я месяц бился со своим контроллером
Ты думаешь, я этого не пробовал? Фигня какая-то получается.
>>71867
Ну шо тут сказати? Плохо пробовал, потому что у меня получалось ещё на 3.0 по видеотуториалу (англоязычному разумеется, может в этом твоя проблема, кстати) настраивал контроллер в триде, с капсулем, не скатывающийся на наклонных поверхностях, причём угол наклона можно было регулировать. Лестницы в таком случае делаются как пандусы, без ступенек. Ступеньки просто меши, а коллижншейп = пандус. Всё как мы любили в конце девяностых начале нулевых.
> Фигня какая-то получается.
Ну шо тут сказати? Плохо пробовал, потому что у меня получалось ещё на 3.0 по видеотуториалу (англоязычному разумеется, может в этом твоя проблема, кстати) настраивал контроллер в триде, с капсулем, не скатывающийся на наклонных поверхностях, причём угол наклона можно было регулировать. Лестницы в таком случае делаются как пандусы, без ступенек. Ступеньки просто меши, а коллижншейп = пандус. Всё как мы любили в конце девяностых начале нулевых.
Сделал основу AI. Это был долгий квест.
Сколько-то времени назад я писал здесь, что собираюсь сделать AI на основе генетического алгоритма. И тогда я не очень понимал, как вообще это надо делать. По такому случаю сделал проект попроще, чтобы обкатать алгоритм.
Это была искусственная жизнь, ничего особенного. Но из этого проекта я извлёк два важных вывода:
1. Генетическому алгоритму нужно выстраивать баланс из условий
2. Иерархическая структура
По второму пункту поподробнее. На самом деле это почти то, что я уже давно хотел сделать с искусственной жизнью. Генотип срабатывает один раз при создании клетки, он регулирует создание органелл и их наполнение. Каждая органелла это нода, дочерняя клетке, имеет свою собственную программу - то самое наполнение. Органеллы имеют разные типы: ядро, митохондрия, хлоропласт и т.д. У каждого типа своя функция, ничего другого он выполнять не может. Например: ядро умеет только размножать, хлоропласт только питаться светом и т.д. И есть особая органелла рибосома, которая умеет выполнять умную программу: запоминать что-нибудь и сравнивать ещё что-нибудь с памятью, в зависимости от результата сравнения изменять порядок выполнения органелл. Раз в цикл действует только одна органелла, на которую указывает указатель. В норме они все опрашиваются по очереди, если только рибосома не переместит указатель.
До конца этот проект я так и не довёл. Понял, что закапываюсь и ухожу слишком далеко от главного, пришлось оставить до лучших времён. Так и не смог пофиксить джоинты, вызывавшие молчаливый краш и вообще не работавшие корректно. Не нашёл баланса, чтобы оказались полезны рибосомы. Не нашёл баланса, чтобы оказалось полезно не только уменьшение размера, но и увеличение. Доделаю демку основного проекта - допилю жизнь и обязательно поделюсь с анонами, занимательно получилось.
Но это я всё к чему. Иерархическая структура. Я понял, что применить генетический алгоритм на мобах не получится, по крайней мере, в том виде, в каком понимал тогда. Зато нашёл удобный способ организации для AI.
1. Одна нода AI управляет одним юнитом. В ней распределяются общие состояния: патрулировать или нападать, например. Каждое состояние представляет собой набор задач, каждая из которых является отдельной нодой, дочерней к основной. Всегда выполняется только самая первая задача; если их нет, включается перепроверка всего состояния и добавление списка задач заново.
2. Задание работает аналогично, только распределяет уже примитивные действия. Например: пройти до координаты. Или: стрелять. У задания есть определённые условия, при которых оно самоуничтожится и уступит место следующему заданию. Задание это такое промежуточное звено между общей задачей и последовательностью нажатий на кнопки. Действия точно так же являются нодами и добавляются как дочерние объекты, точно так же выполняется всегда самое первое действие.
3. Действия уже не могут иметь потомков, потому что они сами примитивнее некуда. Но у них есть условия самоуничтожения. Например, для стрельбы таким условием может быть пустая обойма.
Вооот. Это всё я за вчера-сегодня запилил. Теперь предстоит прописать довольно большое количество таких вот AI-нод. К ним по желанию можно добавлять всякие там рейкасты, если надо, например, оценить присутствие врага в поле зрения. Совсем-совсем простой уровень уже реализовал, болванчики ходят туда-сюда, при виде игрока стреляют.
Если кто прочитал эту стену текста, любые соображения велкам.
Сколько-то времени назад я писал здесь, что собираюсь сделать AI на основе генетического алгоритма. И тогда я не очень понимал, как вообще это надо делать. По такому случаю сделал проект попроще, чтобы обкатать алгоритм.
Это была искусственная жизнь, ничего особенного. Но из этого проекта я извлёк два важных вывода:
1. Генетическому алгоритму нужно выстраивать баланс из условий
2. Иерархическая структура
По второму пункту поподробнее. На самом деле это почти то, что я уже давно хотел сделать с искусственной жизнью. Генотип срабатывает один раз при создании клетки, он регулирует создание органелл и их наполнение. Каждая органелла это нода, дочерняя клетке, имеет свою собственную программу - то самое наполнение. Органеллы имеют разные типы: ядро, митохондрия, хлоропласт и т.д. У каждого типа своя функция, ничего другого он выполнять не может. Например: ядро умеет только размножать, хлоропласт только питаться светом и т.д. И есть особая органелла рибосома, которая умеет выполнять умную программу: запоминать что-нибудь и сравнивать ещё что-нибудь с памятью, в зависимости от результата сравнения изменять порядок выполнения органелл. Раз в цикл действует только одна органелла, на которую указывает указатель. В норме они все опрашиваются по очереди, если только рибосома не переместит указатель.
До конца этот проект я так и не довёл. Понял, что закапываюсь и ухожу слишком далеко от главного, пришлось оставить до лучших времён. Так и не смог пофиксить джоинты, вызывавшие молчаливый краш и вообще не работавшие корректно. Не нашёл баланса, чтобы оказались полезны рибосомы. Не нашёл баланса, чтобы оказалось полезно не только уменьшение размера, но и увеличение. Доделаю демку основного проекта - допилю жизнь и обязательно поделюсь с анонами, занимательно получилось.
Но это я всё к чему. Иерархическая структура. Я понял, что применить генетический алгоритм на мобах не получится, по крайней мере, в том виде, в каком понимал тогда. Зато нашёл удобный способ организации для AI.
1. Одна нода AI управляет одним юнитом. В ней распределяются общие состояния: патрулировать или нападать, например. Каждое состояние представляет собой набор задач, каждая из которых является отдельной нодой, дочерней к основной. Всегда выполняется только самая первая задача; если их нет, включается перепроверка всего состояния и добавление списка задач заново.
2. Задание работает аналогично, только распределяет уже примитивные действия. Например: пройти до координаты. Или: стрелять. У задания есть определённые условия, при которых оно самоуничтожится и уступит место следующему заданию. Задание это такое промежуточное звено между общей задачей и последовательностью нажатий на кнопки. Действия точно так же являются нодами и добавляются как дочерние объекты, точно так же выполняется всегда самое первое действие.
3. Действия уже не могут иметь потомков, потому что они сами примитивнее некуда. Но у них есть условия самоуничтожения. Например, для стрельбы таким условием может быть пустая обойма.
Вооот. Это всё я за вчера-сегодня запилил. Теперь предстоит прописать довольно большое количество таких вот AI-нод. К ним по желанию можно добавлять всякие там рейкасты, если надо, например, оценить присутствие врага в поле зрения. Совсем-совсем простой уровень уже реализовал, болванчики ходят туда-сюда, при виде игрока стреляют.
Если кто прочитал эту стену текста, любые соображения велкам.
Сделал основу AI. Это был долгий квест.
Сколько-то времени назад я писал здесь, что собираюсь сделать AI на основе генетического алгоритма. И тогда я не очень понимал, как вообще это надо делать. По такому случаю сделал проект попроще, чтобы обкатать алгоритм.
Это была искусственная жизнь, ничего особенного. Но из этого проекта я извлёк два важных вывода:
1. Генетическому алгоритму нужно выстраивать баланс из условий
2. Иерархическая структура
По второму пункту поподробнее. На самом деле это почти то, что я уже давно хотел сделать с искусственной жизнью. Генотип срабатывает один раз при создании клетки, он регулирует создание органелл и их наполнение. Каждая органелла это нода, дочерняя клетке, имеет свою собственную программу - то самое наполнение. Органеллы имеют разные типы: ядро, митохондрия, хлоропласт и т.д. У каждого типа своя функция, ничего другого он выполнять не может. Например: ядро умеет только размножать, хлоропласт только питаться светом и т.д. И есть особая органелла рибосома, которая умеет выполнять умную программу: запоминать что-нибудь и сравнивать ещё что-нибудь с памятью, в зависимости от результата сравнения изменять порядок выполнения органелл. Раз в цикл действует только одна органелла, на которую указывает указатель. В норме они все опрашиваются по очереди, если только рибосома не переместит указатель.
До конца этот проект я так и не довёл. Понял, что закапываюсь и ухожу слишком далеко от главного, пришлось оставить до лучших времён. Так и не смог пофиксить джоинты, вызывавшие молчаливый краш и вообще не работавшие корректно. Не нашёл баланса, чтобы оказались полезны рибосомы. Не нашёл баланса, чтобы оказалось полезно не только уменьшение размера, но и увеличение. Доделаю демку основного проекта - допилю жизнь и обязательно поделюсь с анонами, занимательно получилось.
Но это я всё к чему. Иерархическая структура. Я понял, что применить генетический алгоритм на мобах не получится, по крайней мере, в том виде, в каком понимал тогда. Зато нашёл удобный способ организации для AI.
1. Одна нода AI управляет одним юнитом. В ней распределяются общие состояния: патрулировать или нападать, например. Каждое состояние представляет собой набор задач, каждая из которых является отдельной нодой, дочерней к основной. Всегда выполняется только самая первая задача; если их нет, включается перепроверка всего состояния и добавление списка задач заново.
2. Задание работает аналогично, только распределяет уже примитивные действия. Например: пройти до координаты. Или: стрелять. У задания есть определённые условия, при которых оно самоуничтожится и уступит место следующему заданию. Задание это такое промежуточное звено между общей задачей и последовательностью нажатий на кнопки. Действия точно так же являются нодами и добавляются как дочерние объекты, точно так же выполняется всегда самое первое действие.
3. Действия уже не могут иметь потомков, потому что они сами примитивнее некуда. Но у них есть условия самоуничтожения. Например, для стрельбы таким условием может быть пустая обойма.
Вооот. Это всё я за вчера-сегодня запилил. Теперь предстоит прописать довольно большое количество таких вот AI-нод. К ним по желанию можно добавлять всякие там рейкасты, если надо, например, оценить присутствие врага в поле зрения. Совсем-совсем простой уровень уже реализовал, болванчики ходят туда-сюда, при виде игрока стреляют.
Если кто прочитал эту стену текста, любые соображения велкам.
Сколько-то времени назад я писал здесь, что собираюсь сделать AI на основе генетического алгоритма. И тогда я не очень понимал, как вообще это надо делать. По такому случаю сделал проект попроще, чтобы обкатать алгоритм.
Это была искусственная жизнь, ничего особенного. Но из этого проекта я извлёк два важных вывода:
1. Генетическому алгоритму нужно выстраивать баланс из условий
2. Иерархическая структура
По второму пункту поподробнее. На самом деле это почти то, что я уже давно хотел сделать с искусственной жизнью. Генотип срабатывает один раз при создании клетки, он регулирует создание органелл и их наполнение. Каждая органелла это нода, дочерняя клетке, имеет свою собственную программу - то самое наполнение. Органеллы имеют разные типы: ядро, митохондрия, хлоропласт и т.д. У каждого типа своя функция, ничего другого он выполнять не может. Например: ядро умеет только размножать, хлоропласт только питаться светом и т.д. И есть особая органелла рибосома, которая умеет выполнять умную программу: запоминать что-нибудь и сравнивать ещё что-нибудь с памятью, в зависимости от результата сравнения изменять порядок выполнения органелл. Раз в цикл действует только одна органелла, на которую указывает указатель. В норме они все опрашиваются по очереди, если только рибосома не переместит указатель.
До конца этот проект я так и не довёл. Понял, что закапываюсь и ухожу слишком далеко от главного, пришлось оставить до лучших времён. Так и не смог пофиксить джоинты, вызывавшие молчаливый краш и вообще не работавшие корректно. Не нашёл баланса, чтобы оказались полезны рибосомы. Не нашёл баланса, чтобы оказалось полезно не только уменьшение размера, но и увеличение. Доделаю демку основного проекта - допилю жизнь и обязательно поделюсь с анонами, занимательно получилось.
Но это я всё к чему. Иерархическая структура. Я понял, что применить генетический алгоритм на мобах не получится, по крайней мере, в том виде, в каком понимал тогда. Зато нашёл удобный способ организации для AI.
1. Одна нода AI управляет одним юнитом. В ней распределяются общие состояния: патрулировать или нападать, например. Каждое состояние представляет собой набор задач, каждая из которых является отдельной нодой, дочерней к основной. Всегда выполняется только самая первая задача; если их нет, включается перепроверка всего состояния и добавление списка задач заново.
2. Задание работает аналогично, только распределяет уже примитивные действия. Например: пройти до координаты. Или: стрелять. У задания есть определённые условия, при которых оно самоуничтожится и уступит место следующему заданию. Задание это такое промежуточное звено между общей задачей и последовательностью нажатий на кнопки. Действия точно так же являются нодами и добавляются как дочерние объекты, точно так же выполняется всегда самое первое действие.
3. Действия уже не могут иметь потомков, потому что они сами примитивнее некуда. Но у них есть условия самоуничтожения. Например, для стрельбы таким условием может быть пустая обойма.
Вооот. Это всё я за вчера-сегодня запилил. Теперь предстоит прописать довольно большое количество таких вот AI-нод. К ним по желанию можно добавлять всякие там рейкасты, если надо, например, оценить присутствие врага в поле зрения. Совсем-совсем простой уровень уже реализовал, болванчики ходят туда-сюда, при виде игрока стреляют.
Если кто прочитал эту стену текста, любые соображения велкам.
>>72057
Бля, анон, утром прочитаю, засыпаю уже. Чисто мысль перед сном: не зря ИИ пилят на питоне. Видать синтаксис питона способствует. А раз гдскрипт потянул синтаксис, то чем чёрт не шутит, может и самые интеллектуальные боты будут у нас? А? (Будет обломно, если ты тот анон, который пилит на шарпе, мда)
Бля, анон, утром прочитаю, засыпаю уже. Чисто мысль перед сном: не зря ИИ пилят на питоне. Видать синтаксис питона способствует. А раз гдскрипт потянул синтаксис, то чем чёрт не шутит, может и самые интеллектуальные боты будут у нас? А? (Будет обломно, если ты тот анон, который пилит на шарпе, мда)
Обнаружен баг! Предупреждены - значит вооружены:
https://www.youtube.com/watch?v=uuP3dOH2y6w
Краткое содержание:
Если массив объявлен, как экспортируемый, он начинает передаваться по ссылке. Если при объявлении нескольких таких массивов их проинициализировать одинаковой конструкцией [] то из-за чудес оптимизации всем им выдастся ссылка на один массив, что неочевидно и нигде не описано. Автор видоса побежал ишью пилить. А я из видоса вынес для себя, что существует возможность объявить передаваемый по ссылке массив, что может быть полезно в ряде случаев, ибо в нормальном (не экспортируемом) состоянии простые массивы передаются в гдскрипте по значению.
https://www.youtube.com/watch?v=uuP3dOH2y6w
Краткое содержание:
Если массив объявлен, как экспортируемый, он начинает передаваться по ссылке. Если при объявлении нескольких таких массивов их проинициализировать одинаковой конструкцией [] то из-за чудес оптимизации всем им выдастся ссылка на один массив, что неочевидно и нигде не описано. Автор видоса побежал ишью пилить. А я из видоса вынес для себя, что существует возможность объявить передаваемый по ссылке массив, что может быть полезно в ряде случаев, ибо в нормальном (не экспортируемом) состоянии простые массивы передаются в гдскрипте по значению.
24 Кб, 334x390Обновить тред
Двач.hk не отвечает.
Вы видите копию треда, сохраненную 30 июля 2021 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
Вы видите копию треда, сохраненную 30 июля 2021 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.