Курилка программистов

[Malandrinus 624]

@Kirgudu,

у меня вместо такой формы какая-то текстовая белиберда со словами о каких-то внутренних исключениях. Студия 2015.

 

Да и всё равно, работает или нет. Я понял, что именно было сделано, и также понял, что для меня это не вариант. К чёрту всех этих мелкософтовских мутантов. Меня достало это стремление сжить со свету С++. Поскольку я не связан в данном случае никакими корпоративными ограничениями, то я и не обязан прогибаться под их мерзоту. Есть прекрасные альтернативы под чистые плюсы, хотя бы wxWidgets. Отлично работает со студией 2015, и там есть полный спектр GUI красот, включая docking. Проблему вижу только в том, что там некое время назад убрали сборку под ANSI строки, и сделали чисто под юникод. Это напрягает. Уже столкнулся с этим при работе над редактором диалогов (это в Stalker Plot Editor). Приходится там и здесь конвертировать туда-обратно. Но это пережить можно. А в целом надо просто завести в движке ещё один проект с интерфейсом, основанным на wxWidgets, класс приложения при этом надо создать не в основном потоке, а в отдельно созданном, чтобы была своя виндовая очередь сообщений.

[Malandrinus 624]

Вдогонку к сказанному по поводу интерфейса редактора на wxWidgets. Вот тестовая сборка ЗП с дополнительным внешним окошком на базе wxWidgets, которое запускается в отдельном потоке.

https://yadi.sk/d/RNFiyFwNufMrU

Примечания (просто чтобы было понятно, что это и о чём вообще):

В комплекте несколько файлов скриптов/конфигов, чтобы запускалось.

В архиве всё нужное содержимое папки bin (подразумевается рантайм от 2015 студии).

Все библиотеки вкомпилированы в экзешник, кроме openal32.dll (там какие-то проблемы с инициализацией при сборке в виде статической либы) и eax.dll, которая вообще имеется только в виде dll.

В силу монолитной сборки рендер только один, четвёртый..

Это не рабочий движок "под ключ", а просто демонстрация присоединения внешнего GUI. Если повезёт, то получится запустить игру, но сохранение/загрузка в целом поломаны моими экспериментами.

Внешнее окошко взято от балды. Это просто один из примеров от wxWidgets с какими-то пустыми фреймами с возможностью докинга. Никакого взаимодействия его с игрой нет. Поскольку окно рендера захватывает мышь, то надо переключаться по Alt-Tab, чтобы иметь возможность манипулировать этим окном.

 

В целом потребовалась совершенно минимальная адаптация проекта примера для включения его в общий проект движка. В самом движке в функции

void CRenderDevice::Run()

там где создаётся второй поток, добавил создание ещё одного.

thread_spawn(wx_Thread, "external GUI thread", 0, 0);

 

В проекте wxWidgets убрал дефолтовый метод запуска приложения в виде макроса

wxIMPLEMENT_APP(Docking2App);
чтобы не создавалась функция WinMain, и вместо этого в функции потока wx_Thread вставил следующее:

void wx_Thread(void *ptr)
{
    wxDISABLE_DEBUG_SUPPORT();
    wxApp::SetInstance(new Docking2App());
    wxEntryStart(g_hInstance, g_hPrevInstance, g_lpCmdLine, g_nCmdShow);
    wxTheApp->OnInit();
    wxTheApp->OnRun();
    wxTheApp->OnExit();
    wxEntryCleanup();
}

Т.е. там создаётся экземпляр класса приложения и вручную запускается его цикл выборки сообщений.
 

И всё. Гораздо больше было возни с тем, чтобы найти нужные настройки проекта, чтобы всё собиралось. Особенно пришлось повозиться с исключениями и настройкой библиотек. Но это всё делается один раз.

 

 

[Malandrinus 624]

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

 

Начать можно с того, а с чего собственно вообще скрипты. Исторически никаких скриптов в сталкире не было. Все схемы логики были внутри, квестовая составляющая также прекрасно обходилась без скриптов. Есть даже билды, не помню за какой год и с каким номером, где это хорошо видно - вполне можно обойтись без скриптов. Добавили их позже. Официальная версия - чтобы загнать симуляцию в квестовые рамки. Вот здесь возникает вопрос, а что мешало это сделать без скриптов? Что мешало ограничить миграцию неписей и добавить аналог гулага и скриптовых работ на уровне движка? На мой взгляд, если бы изначально такая задача стояла, то не было бы никаких проблем с её реализацией. У меня есть только одна версия, почему так поступили. Я думаю, что на тот момент попросту уже ничего было не сделать с движком. Его сложность превысила пределы, за которыми можно оперативно внести такие изменения. В итоге со скриптами вышел мутант. Вместо того, чтобы использовать скрипты для склейки движковых компонент, скрипты по сути использовались для написания весомой части игровой логики, которая заменила собой часть внутренней. Большая часть движковых схем поведения осталась неактивной. Даже управление анимациями сделали через внешний планировщик. На мой взгляд, всё это совершенно ненормально. Скрипты попросту не предназначены для такой серьёзной алгоритмической работы, как написание схем поведения. Прекондишены в диалогах и квестах - вот разумный диапазон применения.

 

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

 

Соответственно, вывод простой: роль скриптов при наличии открытой архитектуры и отсутствии коммерческих рамок надо радикально снижать. Логику реализовывать исключительно внутри движка. GUI - может да, может нет. Откровенно говоря, для окошек тоже нет особой нужды в скриптах. Мне до сих пор непонятно, зачем заскриптовано главное меню. Где можно оставить, это в квестовой логике, проверять сложные условия, которые тяжело сформулировать единственной инфопорцией, и выполнять примитивные действия там же (передача предметов, выдача денег и т.п.). Для последней задачи скриптовая модель требуется куда проще, чем она есть сейчас. Нужны только классы и функции для получения информации и простейших инвентарных манипуляций.

 

Что думаете?

[Malandrinus 624]

 

 

главное в скрости внесения правок

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

 

Сборка движка, если не требуется каждый раз собирать его с нуля, а просто скомпилировать пару файлов с последующей линковкой, занимает секунд 10-15, особенно если не заморачиваться на полную оптимизацию. Так что сравнивать надо уже время отладки. А вот тут начинается самое интересное. Если в случае отладки сложного скрипта нужно запускать игру десятки раз с вылетами и последующим анализом лога (который даёт далеко не полную информацию), то в случае отладки в среде разработки количество запусков сокращается на порядок из-за существенно большей информативности (можно остановить отладку, посмотреть все переменные, пройти по шагам и т.п.).

 

Если вдаваться в лирику, то отладка скриптов в сталкире живо напомнила мне отладку программ на ассемблере под Спектрум (олдфаги помнят эту машинку). Грузишь с кассетного магнитофона ассемблер, грузишь с магнитофона программу, компилишь, запускаешь, отлаживаешь почти вслепую. От малейшего чиха всё перезагружается и начинаешь всё сначала: грузишь одно, другое... Лепота. Терпение развивало просто железное.

[Malandrinus 624]

 

 

Ты исходишь из ложного убеждения

Действительно ли ложного? Соображений, которые подтверждают эту мысль, достаточно много. Возьмём Lua, тем более что нет особенного смысла обсуждать что-то иное в контексте сталкира.

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

2. Ограничения библиотек и скриптовой модели. По-простому, что экспортировано, то и доступно, что из стандартных библиотек, что из API игры. Заведомо невозможно иметь настолько же полный доступ как к системе, так и к игре, как из С++.

3. Производительность. При уместном употреблении скриптов этот вопрос не должен возникать, однако скриптов явно перебор. поэтому не спасает даже LuaJIT. Если бы скрипты использовались только в уместном объёме и в уместных местах, то было бы по большому счёту без разницы, JIT там или голый интерпретируемый Lua.

4. Среда разработки, точнее её отсутствие. Таки нету её, и это реальный недостаток со всеми вытекающими, в первую очередь невозможность полноценной отладки.

 

 

полезнее будет сделать такой инструмент.

Т.е. сперва создали проблему использованием скриптов в неподобающих целях, а теперь превозмогаем? Может всё-таки просто не создавать проблемы? Ведь инструмента под Lua нет, под С++ есть, и Lua явно выглядит менее подходящим в целом для серьёзной работы.

[Malandrinus 624]

 

 

Это типа пульта ДУ. Много видел примеров в скриптах, которые заменяют движковые функции.

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

 

 

что есть "серьёзной алгоритмической работы".

Схемы логики. Я кажется обозначал это несколько раз. Я считаю Lua неподходящим для подобной работы. GUI тоже.

 

 

 

Все императивные языки одинаково примитивны. Все основаны на присваиваниях, циклах и ветвлениях. В этом плане lua и семейство C - одинаковы.

У детской тележки четыре колеса. У автомобиля четыре колеса. Детская тележка и автомобиль - одинаковы. Ну нельзя же так. Я ведь даже упоминал одно из отличий, неужели нельзя было его прокомментировать? Кроме отсутствия жёсткой типизации я ещё могу перечислить: малое количество типов вообще, убогая работа с целыми типами, отсутствие препроцессора, бедные возможности ООП, нет обобщённого программирования, нет прямого доступа к памяти, таблицы отнюдь не заменяют все не свете коллекции.

 

 

 

Ну так для этого и существует движок, что бы экспортировать то и делать доступным то, что нужно использовать и к чему нужно иметь доступ скриптам.

Ну т.е. вместо того, чтобы абстрагироваться от движка и красиво ваять скрипты надо за каждой мелочью обратно лезть в движок, чтобы эту каждую мелочь экспортировать. И чего мы в итоге добились?

 

 

 

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

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

[Malandrinus 624]

 

 

Вообще отладчик луа есть

Это не отменяет всего остального, что делает Lua непригодным для серьёзной разработки, и также всё равно остаётся барьер между языками. Барьеры надо стирать. Вот как в случае с DLL. Статически линкуемые компоненты лучше dll потому что снимают многие барьеры.

@TIGER_VLAD, на здоровье =)

[Malandrinus 624]

 

 

надо плясать от понятия "скрипт". Это сценарий поведения игры в целом и каких то объектов в частности. Движок же реализует действия, заданные скриптом. Согласны, не?

Согласен на все сто процентов. Вот только с этой точки зрения скриптом будет вовсе не луашная часть, а XML и LTX файлы. Они собственно и описывают "что делать". К этой части нет никаких претензий. Претензия есть к тому, что на Lua по-сути реализуется часть движка. Присутствует и уместное использование, в предусловиях например. В этом случае Lua всё ещё выступает как вспоможение для описания сюжета. Но всё остальное - схемы логики, общие схемы поведения, GUI навороты и прочее в этом духе - уже от лукавого. Ну если точнее, то просто от отсутствия доступа к исходникам.

[Malandrinus 624]

 

 

Перевидите Сталкер только на Си (трудно, хлопотно... но можно)

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

 

 

 

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

Долгожитель в первую очередь, потому что игра хорошая. Сеттинг и стилистика затягивает. Много изначально скрытого контента. Lua здесь тоже причём, но только лишь потому, что это была открытая часть.

 

 

 

Они все сразу бросятся в Си?

Если бы изначально был доступ к исходникам, то на данный момент мы бы видели куда больший прогресс. Не приходит в голову простая мысль, что все значимые достижения в скриптинге были сделаны людьми, которые также были и неплохими программистами на Си (а некоторые, как поговаривают, были и с исходниками знакомы)?

 

 

 

Интересно Вам копаться в движке?

Моя персона не имеет к разговору никакого отношения. Прошу воздерживаться от перехода на личности.

[Malandrinus 624]

Это не тайна,

Это ирония была, если что. Сталкер не нужно переводить на Си, он уже и так на Си. В том числе там присутствует самодостаточный набор схем поведения сталкеров. Был же промежуточный билд безо всяких скриптов и с симуляцией, где сталкеры "решали загадку Зоны" параллельно с игроком. Вот всё это там почти без изменений осталось.

 

Примеры, пожалуйста, в студию и со ссылками желательно.

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

 

без Lua, т.е. возможности динамической правки и развития... Сталкер уже бы забыли лет ...цать тому назад.

Мне кажется, что мои слова как-то не так поняты. При наличии Lua, как единственного доступного инструмента для моддинга, естественно его и используют. И хорошо, что было хоть такое. Но моя мысль в другом, а именно что при наличии доступа к исходникам роль Lua можно существенно уменьшить. Ведь не секрет же, что подходы к разработке опенсорс  и коммерческих программ разные.

 

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

В чём? В сюжете,

 

Да. Большая часть моих правок, что делались в составе команды OGSE, делались по запросу квестовиков. Были бы исходники - было бы куда проще и быстрее.

 

в количестве модификаций?

Да. Равно как и в качестве.

 

И кто бы это всё сделал?

Те же люди, что делали и первые серьёзные моды, особенно в области AI. Почти все они разбирались в C/C++, а некоторые собственно и глядели в эти исходники.

 

Смешно.

Нет, грустно. Я бы не потратил ни секунды на все эти ассемблерные правки и кучу скриптовой работы, если бы имел доступ к исходникам. Сколько было потрачено времени впустую - страшно даже подумать. 

 

Ничего личного.

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

[Malandrinus 624]

 

 

они работали со скриптами и не лезли править движок. Почему интересно.

Потому что были связаны соглашением о неразглашении. Так что как в стрип-баре, смотреть можно, трогать - нельзя =)

[Malandrinus 624]

 

 

предлагаю через ЛС.

Не хотелось бы уходить от формата публичного обсуждения.

 

 

 

А то как получается: Я вам вопрос про конкретные ссылки на вашу же цитату, а Вы мне обратно - "Создаёшь секцию сталкера,..."

Этого не понял. Я дал вполне конкретный ответ на конкретный вопрос. Я только не понял, какие ссылки нужны. На что ссылки?

[Malandrinus 624]

 

 

Разве это не Вы написали: "Сталкеры без скриптовой обвязки полностью работоспособны."? Вот я и попросил ссылку на этот продукт,

"Продукта" нет. Я просто знаю, о чём говорю, поскольку когда-то проделывал подобные эксперименты. Возможно знающие билдоводы назовут билд, где ещё нет скриптов, но присутствует симуляция. Ориентировочно должен быть за 2004 год. Возможно и нет такого в публичном доступе.

 

 

 

чтобы самому убедиться в этом. Лично мне, да ещё в Сталкере, это очень сомнительно.

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

 

 

 

за словоблудие.

Это тема специально для словоблудия. Курилка же.

 

 

 

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

Я ровно такая же личность, как и все остальные. Соблюдаю правила и слежу за орфографией.

 

ЗЫ: Куда-то не туда разговор пошёл. Опять про меня. Да что же это такое?!

[Malandrinus 624]

биндеры оставить

 

Так и кто возражает? Даже применительно к сюжетным задачам у биндера есть применение: собирать там всякую статистику, регистрировать какие-то события и т.п. Главное, чтобы скрипты оставались в рамках разумного объёма и сложности.

 

Насчёт сложности. Я иногда здесь выступал на эту тему и всякий раз продвигал одну и туже мысль. Сложность - главный враг при разработке  больших систем (а игра - это достаточно большая система). Весь прогресс в области разработки ПО так или иначе направлен на снижение сложности. Так вот скрипты с этой точки зрения полезны до тех пор, пока снижают сложность разработки. Теперь зададим простой вопрос. А сколько людей вообще правили схемы логики или создавали новые? Сколько людей меняли содержимое файла xr_logic.script или скриптового менеджера анимаций? В основном все занимались изменением "логики", т.е. содержимого кастомдаты, которое управляет уже готовыми схемами. И это совершенно нормально, это как раз то, что входит в первоочередные задачи при создании сюжета.

 

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

 

Ещё по поводу расширений вообще. А кто сказал, что расширения обязательно надо делать на Lua? Примерно похожую архитектуру, с биндерами и прочим, можно реализовать в виде dll-плагинов на C++. Одним из таких плагинов может быть добавление скриптовой модели, потенциально произвольной, т.е. можно добавить Lua, а можно, например, Python. В проекте OpenXRay сделали одно изменение, которое мне очень понравилось, вынесли скриптовый экспорт из методов классов в глобальную функцию. Не знаю, зачем они это сделали, но я вижу это как шаг к тому, чтобы отделить движок от скриптов вообще. При такой архитектуре если нужны скрипты - добавляем нужный плагин и используем, не нужны - не добавляем.

[Malandrinus 624]

@TIGER_VLAD,

Для начала, что там Ясенев говорит до этого, к скриптам как таковым не относится. Он просто объясняет суть используемого AI, а именно метод GOAP, т.е. планировщиков таких специальных. Далее он действительно говорит о скриптах, но тут не надо забывать, что неявно при этом подразумевается, что движок закрыт. На момент интервью, если я правильно понял, ещё даже ТЧ не вышел. А так всё сказанное в равной степени можно применить к расширению, написанному непосредственно на С++. В целом смысл его речи сводится к тому, что можно написать дополнительную схему, которая по некоему условию перехватит управление уже имеющейся схемы. Внутри движка схемы выстроены по определённым приоритетам, внешние скриптовые аналогично выстроены по приоритетам (и забивают внутренние практически полностью, так что мы их и не видим почти никогда).

 

 

а дальше синхронизацию и прочие потраха пилить

Ну да, самую малость остаётся =)

 

 

а я наоборот вижу этот двиг как раз в открытой, бесплатной, сетевой игре. У этого движка в одно-пользовательских инди-играх нет будущего.

 

Я вижу здесь вилку решений. Можно попытаться сделать из X-Ray сетевой шутер с открытым миром наподобие того же Сурвариума, но тогда придётся пожертвовать сингловыми фичами, в частности монстрами с приличным AI. В подтверждение я напомню, что ребята из Vostok Games только-только выпустили бета-версию с мобами для пострелушек. Это коммерческая контора, с мотивированными опытными разрабами, которые ничем другим не занимаются, и у них после многих лет разработки до монстров ещё даже близко руки не дошли. Так что лучшее, на что может рассчитывать в таком варианте X-Ray - это просто сетевые пострелушки между игроками, ну может удастся когда-нибудь сталкеров запилить.

 

Второй вариант: пожертвовать сетью и всем, что с ней связано. Уменьшить сложность и повысить эффективность движка за счёт этого. Двигать дальше как приемлемый сингловый открытый движок.

 

Это конечно вообще при условии, что X-Ray кому-то ещё нужен.

 

 

По поводу статистики, ее в движке также можно прекрасно собрать

 

Я имел в виду другую статистику. Что-то нужное для сюжета. Техническую разумеется надо собирать внутри движка.

[Malandrinus 624]

 

 

можно ли очередь сообщений обрабатывать в отдельном потоке? Скажем так, некий задел на многопоточность.

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

 

Насчёт Lua я даже не уверен насчёт реентерабилити, т.е. вызова колбека Lua, который приводит к вызову другого колбека Lua (в рамках того же луастейта) в том же потоке. Вроде бы работает на практике, но есть у меня дежавю, что где-то читал, что нельзя так делать.

 

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

 

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

[Malandrinus 624]

@-StalkMen-,

я не понял, о чём ты. Понятие "асинхронный" я знаю применительно к передаче сообщения. Асинхронный в этом контексте означает неодновременный (что понятно из названия, поскольку буквально "не синхронный"). Смысл в том, что обработка сообщения идёт не сразу, как для синхронного вызова, а позже (не важно в этом потоке или другом). А что такое асинхронная физика?

 

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

[Malandrinus 624]

@Дизель,

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

 

Смотреться, правда, будет так себе, поскольку картинка трака будет ездить по статичной угловатой геометрии.

[Malandrinus 624]

 

 

Траки привязкой модификатора линкуются с костями, типа axle, для каждого колеса отдельно

Привязка - это хорошо, а как сами траки перемещаются вверх-вниз? Я смотрю на видео и это не очевидно. То ли физика работает, то ли нечто вроде Inverse Kinematics. По-любому, этого в X-Ray готового нет, поэтому траки будут просто статичной коробочкой вокруг колёс. Сразу, кстати, приходит на ум такая проблема. У автомобиля земли касаются колёса, а у танка земли касаются траки. Поэтому надо ещё и сделать разную физическую геометрию и меш катков. Физическая геометрия должна быть на толщину трака больше.

 

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

 

 

Спросил, что об этом думает Дмитрий Ясенев

С одной стороны конечно интересно, а с другой - почти ничего не сказал. Косвенно подтвердил мою мысль, что попросту не было нужных людей, чтобы развивать собственно движок. Ещё интересна информация о том, что многое делали в потёмках: "если им надо что-то попробовать" и "были непонятны рамки скриптов". Мне то казалось, что на момент введения скриптов уже был ясен план работ, а оно вон как было.

 

Это даже не отвечает на вопрос

 

 

А как дело со скриптами стоит в других движках, аналогичных хрею возможностей?

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

 

Хотя в целом сказанное не противоречит выводам насчёт необходимости снижения роли скриптов.

 

Лично я для себя уже определился - скрипты в таком виде как в сталкире резать. Остались колебания только по поводу GUI. Я здесь вижу две диаметрально противоположные стратегии. Первая согласуется с генеральной линией партии - убрать скрипты из GUI вообще. Вторая - напротив весь GUI делать на скриптах. На движок оставить только самые базовые классы: базовые окна, элементы управления, некоторые крупные блоки типа блока кнопок для главного меню (эта та штуковина с ползунком в виде увеличительного стекла и с интересным названием Shniaga). А всё остальное - скриптами, включая окна типа инвентаря, диалогов, пда и т.д. Разумеется, экспортировать контролы надо более полно и аккуратно, нежели это сделано сейчас. Также нужны все колбеки и ещё до кучи мелочи, но это уже детали. Такая стратегия тоже имеет право на жизнь. Дело в том, что производительность GUI как правило не критична, а это как раз та часть, которая довольно часто меняется модостроителями и при этом действительно в этом случае как-то нет смысла требовать от модостроителя знаний С++. Окошки - это как правило совершенно примитивная алгоритмическая работа, простые структуры данных, простые алгоритмы. В общем, здесь на самом деле можно найти смысл делать их скриптами. Но тогда уж полностью скриптами. Из ровно той же самой идеологии "убрать границы". Просто границу в данном случае можно передвинуть в одну из двух сторон.

[Malandrinus 624]

 

 

Вот ты и спалился

Это о чём?

 

 

 

У авто колёса - не являются процессом движения, просто мишура

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

 

Тем не менее колёса же земли касаются. Физической геометрией разумеется, не визуалом. Если обматывать колёса траками, то физическая геометрия (то, что называют шейпом в просторечии), должна быть на толщину трака больше визуальной. Вроде как банальная мысль, разве нет?

 

 

при таком раскладе нарисовать свое окно мододел не сможет ?

 

Ну почему? Я же всё это говорил в контексте наличия исходников. Ну конечно до какой-то степени надо знать С++ и студию, но это далеко не те заморочки, что в игровой логике. В окошках скучный и простой код безо всяких изысков. Если он понятен на Lua, то будет понятен и на С++.

 

Кстати, здесь прямо всплывает один из "тормозов развития" - крайне плохая структура модулей движка. GUI должен быть отдельным модулем и подпроектом, а сейчас является частью самого замороченного модуля - xrGame. Туда залезть и что-то там поменять страшно само по себе. Был бы отдельный модуль - только для окошек - даже чисто психологически было бы легче туда залезть и что надо подкрутить, не говоря уже о том, что это и объективно упрощает дело: меньше  модуль - легче понять, быстрее скомпилить, меньше зависимостей и т.д.