Malandrinus

@mortan, понятно. Это называется опережающее объявление класса. Такого объявления достаточно для объявления в свою очередь указателя или ссылки на переменную такого класса, поскольку в этом случае не надо знать размер класса (и вообще ничего не надо о нём знать, кроме того, что это класс, а не, скажем, имя шаблона или переменной). Т.е. объявив существование класса CTrade таким образом далее можно написать например так: CTrade* ptrade; Но уже разыменование указателя потребует полного объявления, т.е. инклюда. Как правило, опережающее объявление класса используется в заголовках, если в заголовках в свою очередь только объявления прототипов методов классов, где идёт передача по ссылке или указателю. Типа такого: class CTrade; class some_class { CTrade* ptrade; public: void member_fun(CTrade* pt); }; Тогда в заголовке можно ограничиться только вот такой декларацией. Соответственно, в модуле, где будет тело функции-члена, уже потребуется инклюд с полным объявлением класса CTrade. Это всё позволяет не раздувать объём заголовков (реальный, после фазы препроцессора). В ряде случаев это позволяет решить циклические зависимости между заголовками. Это также один из стимулов не злоупотреблять инлайновыми функциями-членами, поскольку они как раз могут заставить включить заголовок вместо простой декларации.

@mortan, без инклюда класс использовать невозможно, поскольку компилятор ничего о нём не знает. Вообще же мало информации, и не вполне понятна проблема. Лень прописать инклюд перед использованием типа?

@MADMAX666, по правке с солнцем к сожалению мало чем можно помочь. Правка используется в OGSE/OGSR, а там погодный менеджер скриптовый, и даже выброс реализуется в режиме прямого управления погодой, а не через погодный эффект. Поэтому там таких проблем нет, и разбираться с тем, что там ещё поломалось и почему, не было необходимости. А сейчас уже нет и желания/возможности.

Потому что это компиляция одного выделенного файла. Скомпилировать проект (построить или build) - значит скомпилировать все изменённые файлы, входящие в этот проект, а также слинковать, что тоже занимает время. Да, и ещё конечно надо собрать и подчинённые проекты, если там что-то изменилось, а это почти все остальные проекты в случае xrGame.dll. С другой стороны, если проект уже собирался, то все файлы уже скомпилированы, и если реально изменён всего один файл (и через заголовки не затронуты другие файлы), то сборка должна занять относительно немного: собственно скомпилировать один файл и слинковать. Время линковки - это обычно что-то в районе до минуты. Что-то слишком долго. У меня минут 7 собирает с нуля. При оптимальных настройках меньше пяти Это конечно зависит от компьютера, но и у меня далеко не топовая машина (Intel Core i7 970 3.2Ghz).

Почитай ридми к игре, раздел "лицензия". Там всё популярно расписано =)

Я наверное полный чайник в автомобилях, но о каких мостах речь? Колёса - это вроде как специальный тип сочленения, так и называется в SDK - wheel, Чему-то там в ODE соответствует. Я также не понимаю, почему нельзя сделать колёса как в БТР. Там же не улетают. Это, на мой взгляд, надо делать вершинным шейдером, который будет деформировать покрышку в нижней части. Как эти траки так плавно изгибаются? Почему они вообще изгибаются, если привязка не работает? Они же только привязкой по идее деформироваться и могут. И вообще, совсем непонятно, что и к чему ты привязывал.

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

Либо физический объект с вращением колёс физикой, либо объект с анимацией, но не то и другое одновременно. Если объект с анимацией, то он "стоять" не может, поскольку нет физики и нет взаимодействия с землёй. Будет просто висеть в воздухе и крутить колёсами. Чтобы закрыть вопрос с колёсами. Да, машине в сталкире реально едет с приводом от колёс. Там просто перебираются все ведущие колёса и им назначается скорость вращения. Остальное очевидно делает физика. Не очень удачное с точки зрения устойчивости решение на мой взгляд. Как я говорил, лучше было бы оставить колёса свободно вращающимися, а "привод" сделать имитацией, за счёт глобальной силы, приложенной к корпусу машины. Типа как тележка, которую тянут или толкают. Внешне никакой разницы, а устойчивость численного решения намного выше.

@Дизель, да я вообще не о движении. Без разницы, как именно движется машина. Я только говорил про соотношение физической и визуальной геометрии. Вот картинка, если словами непонятно. Слева обычное колесо машины. Физическая геометрия (синий круг) совпадает с визуальной (красный). Справа - приблизительная идея трака и катка у танка. Визуально видимый трак меньше физического диаметра на толщину трака. Таким образом танк будет опираться на физическое колесо, но видимый каток будет как бы висеть над землёй. А под ним будет трак, который соответственно будет визуально касаться земли (при этом у него не будет своей физической геометрии, только визуальная).

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

Это о чём? Я догадываюсь, что колёса не двигают машину. Актора тоже не ноги двигают. С точки зрения физики актор - это что-то вроде тумбочки, которая скользит по земле, а чтобы он двигался в ту или иную сторону (или прыгал) ему даётся соответствующий импульс. Подозреваю, что с машиной примерно также, хотя и не лазил туда. Тем не менее колёса же земли касаются. Физической геометрией разумеется, не визуалом. Если обматывать колёса траками, то физическая геометрия (то, что называют шейпом в просторечии), должна быть на толщину трака больше визуальной. Вроде как банальная мысль, разве нет? Ну почему? Я же всё это говорил в контексте наличия исходников. Ну конечно до какой-то степени надо знать С++ и студию, но это далеко не те заморочки, что в игровой логике. В окошках скучный и простой код безо всяких изысков. Если он понятен на Lua, то будет понятен и на С++. Кстати, здесь прямо всплывает один из "тормозов развития" - крайне плохая структура модулей движка. GUI должен быть отдельным модулем и подпроектом, а сейчас является частью самого замороченного модуля - xrGame. Туда залезть и что-то там поменять страшно само по себе. Был бы отдельный модуль - только для окошек - даже чисто психологически было бы легче туда залезть и что надо подкрутить, не говоря уже о том, что это и объективно упрощает дело: меньше модуль - легче понять, быстрее скомпилить, меньше зависимостей и т.д.

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

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

@Tayler, да, был неправ. Тогда действительно схема ph_door не подходит. В случаях таких непоняток, но при наличии рабочего примера я обычно беру и сравниваю свой объект с тем, который работает. Как настроены кости рабочего объекта и твоего в акторедиторе. Нет ли там случаем каких-то конфигов в модели. Как он добавлен в спавне. Нет ли там чего дополнительного в кастомдате. Здесь можно попытаться распаковать спавн в текстовый вид и сравнить буквально построчно. Вообще анимированные двери - редкая птица. По-моему даже разрабы предпочитали использовать двери на физике. А кстати, что мешает эту дверь тоже сделать на физике?

Тебе @Карлан совершенно верно сказал, ты пытаешься приделать к двери схему кнопки, которая разумеется никаких анимаций открывания/закрывания делать не умеет. Схема определяется по началу названия секции логики. Для двери это будет соответственно ph_door. Возьми готовый пример для двери Сидора, это файл config\scripts\esc_trader_door.ltx. Изучи его внимательно, там в общем-то типовая дверь. В той же папке ещё много схем с дверями.

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

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

@TIGER_VLAD, Для начала, что там Ясенев говорит до этого, к скриптам как таковым не относится. Он просто объясняет суть используемого AI, а именно метод GOAP, т.е. планировщиков таких специальных. Далее он действительно говорит о скриптах, но тут не надо забывать, что неявно при этом подразумевается, что движок закрыт. На момент интервью, если я правильно понял, ещё даже ТЧ не вышел. А так всё сказанное в равной степени можно применить к расширению, написанному непосредственно на С++. В целом смысл его речи сводится к тому, что можно написать дополнительную схему, которая по некоему условию перехватит управление уже имеющейся схемы. Внутри движка схемы выстроены по определённым приоритетам, внешние скриптовые аналогично выстроены по приоритетам (и забивают внутренние практически полностью, так что мы их и не видим почти никогда). Ну да, самую малость остаётся =) Я вижу здесь вилку решений. Можно попытаться сделать из X-Ray сетевой шутер с открытым миром наподобие того же Сурвариума, но тогда придётся пожертвовать сингловыми фичами, в частности монстрами с приличным AI. В подтверждение я напомню, что ребята из Vostok Games только-только выпустили бета-версию с мобами для пострелушек. Это коммерческая контора, с мотивированными опытными разрабами, которые ничем другим не занимаются, и у них после многих лет разработки до монстров ещё даже близко руки не дошли. Так что лучшее, на что может рассчитывать в таком варианте X-Ray - это просто сетевые пострелушки между игроками, ну может удастся когда-нибудь сталкеров запилить. Второй вариант: пожертвовать сетью и всем, что с ней связано. Уменьшить сложность и повысить эффективность движка за счёт этого. Двигать дальше как приемлемый сингловый открытый движок. Это конечно вообще при условии, что X-Ray кому-то ещё нужен. Я имел в виду другую статистику. Что-то нужное для сюжета. Техническую разумеется надо собирать внутри движка.

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

"Продукта" нет. Я просто знаю, о чём говорю, поскольку когда-то проделывал подобные эксперименты. Возможно знающие билдоводы назовут билд, где ещё нет скриптов, но присутствует симуляция. Ориентировочно должен быть за 2004 год. Возможно и нет такого в публичном доступе. Я написал, что конкретно надо сделать, чтобы в этом убедиться. Верить мне на слово или нет, дело конечно хозяйское. Это тема специально для словоблудия. Курилка же. Я ровно такая же личность, как и все остальные. Соблюдаю правила и слежу за орфографией. ЗЫ: Куда-то не туда разговор пошёл. Опять про меня. Да что же это такое?!

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

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

Это ирония была, если что. Сталкер не нужно переводить на Си, он уже и так на Си. В том числе там присутствует самодостаточный набор схем поведения сталкеров. Был же промежуточный билд безо всяких скриптов и с симуляцией, где сталкеры "решали загадку Зоны" параллельно с игроком. Вот всё это там почти без изменений осталось. Создаёшь секцию сталкера, где не прописываешь биндер. Создаёшь такого сталкера скриптом. Он будет бродить, воевать, подбирать вещи, разговаривать (если у него в профиле прописаны диалоги). Разумеется никаких скриптовых работ выполнять не будет. Т.е. внутри имеется свой менеджер анимаций и, как уже говорил, набор самодостаточных схем поведения. Мне кажется, что мои слова как-то не так поняты. При наличии Lua, как единственного доступного инструмента для моддинга, естественно его и используют. И хорошо, что было хоть такое. Но моя мысль в другом, а именно что при наличии доступа к исходникам роль Lua можно существенно уменьшить. Ведь не секрет же, что подходы к разработке опенсорс и коммерческих программ разные. В чём? В сюжете, Да. Большая часть моих правок, что делались в составе команды OGSE, делались по запросу квестовиков. Были бы исходники - было бы куда проще и быстрее. Да. Равно как и в качестве. Те же люди, что делали и первые серьёзные моды, особенно в области AI. Почти все они разбирались в C/C++, а некоторые собственно и глядели в эти исходники. Нет, грустно. Я бы не потратил ни секунды на все эти ассемблерные правки и кучу скриптовой работы, если бы имел доступ к исходникам. Сколько было потрачено времени впустую - страшно даже подумать. Что мне или кому-то ещё нравится или не нравится не может являться аргументом. Я пытаюсь оставаться в рамках рационального, а меня уже второй раз с начала этого разговора тянут в обсуждение моей персоны.

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

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