Malandrinus

Могу сходу назвать несколько причин: 1. Нет единого и принятого всеми собираемого проекта движка. Т.е. проекты то есть, но вот "единого и принятого всеми" пока нету. 2. Даже если бы и был, то собирать проект - это действие на порядок более сложное, чем собрать бинарную правку. И долгое. Даже и тут не все окучили, что уж говорить про установку студии, всех библиотек, возни с конфигурациями и т.п. 3. Ряд правок неочевидны с точки зрения исходников. Авторов некоторых уже не найти, и каждый автор знает только свои правки, а насчёт остальных ещё надо разбираться, что они означают и как их воспроизвести. Хуже того, изрядную часть правок попросту нет смысла воспроизводить в исходниках. Это касается даже примитивного экспорта, который здесь делался часто весьма уродливо: не в том классе/пространстве имён, где следовало бы, с использованием странного списка аргументов или передачи аргументов и результатов через одно место. Т.е. не только соответствующую правку в исходниках надо будет делать иначе, но и совместимость с существующими скриптами неизбежно порушится. 4. Все тормозят же =) По п.1 могу добавить, что проблема с единым проектом обязательно выйдет в политико-организационную плоскость. Здесь, как верно было замечено, каждая правка носит опциональный характер: хочешь используй, хочешь нет. Если будет единый проект с исходниками, то там правки имеют более перманентный характер. Иными словами, вот кто-то что-то внёс - уже не уберёшь без отката репозитария. Учитывая, мягко говоря, разную квалификацию модостроительной публики это приведёт к разным эксцессам, что в итоге вынудит ограничить доступ только узкому кругу людей. Что в итоге, учитывая уже иные реалии модостроя, приведёт к стагнации проекта (вы просто не дозовётесь никого, чтобы внести даже самую мелкую правку).

@тень121, есть такая волшебная утилитка

@Viнt@rь, по себе могу сказать, что мне пришлось поработать над собой, чтобы проникнуться идеями ООП и кое-какими азами ОО дизайна. Это потребовало усилий, а помог в этом дедушка Borland Pascal ещё под DOS. Чем-то меня тогда заворожил и язык и идея ООП. =) Тем более мои усилия были героическими, что начинал я программировать на диалектах Basic-а, где можно было из программы манипулировать текстом программы и переходить по номеру строки. Лепота. Как вспомню, так вздрогну.

Ну наверное можно =) Развивая эту мысль можно также сказать, что неудобно пользоваться тем, чем не владеешь. Нет понимания идеи ООП - конечно и пользоваться им будет неудобно, а скорее всего и невозможно. Поэтому каждый использует те подходы, которые знает. В конечном счёте важен результат. Просто при использовании традиционных процедурно-ориентированных подходов достигаться он будет гораздо большими затратами. Ну как это нет?! Инкапсуляция - это объединение кода и данных. Нет скрытия реализации, поскольку нет атрибутов приватности у полей, но это не так уж критично. Полиморфизм тоже есть. Каждый метод - виртуальный, поскольку каждый объект явно содержит ссылки на функции.

Это очень плохая идея. Разделение на движок и скрипты позволяет распределить роли при разработке игры, поскольку скриптёры могут делать своё дело без влезания в дебри движка. Разумеется, это хорошо работает при наличии внятного и хорошо документированного интерфейса. Кстати, разделение на код и данные несёт туже функцию: кто-то написал код, управляемый внешними данными - конфигами, бинарными данными и т.п. Потом код не трогаем, а меняем только данные. Поэтому кстати плохо задавать данные прямо в коде, поскольку их изменение - это изменение кода. Да. фастколл на самом деле в последних патчах игры в точности совпадает по частоте вызовов с апдейтом актора. Это решается только одним способом, использованием класса CTime, который даёт полный доступ к движковому 64-х разрядному счётчику. Других способов нет. Сидит игрок на локации 45 дней или нет - роли не играет, поскольку в игре полно глобальных объектов, которые обновляются и на других локациях: респавнеры те же, да и вообще все процессы, связанные со временем - выброс, таймеры и т.п. С этим не соглашусь, поскольку ООП - это не конкретный синтаксис в конкретном языке, а парадигма. Можно использовать ООП в рамках абсолютно процедурно-ориентированных языков, типа чистого СИ. Наличие в языке определённых средств только добавляет удобства в применении ООП. В этом смысле Lua - более чем ООП язык. Кстати, модель ООП в Lua - это так называемая прототипная модель, когда новые объекты строятся не на основе классов, а на основе существующих экземпляров объектов. Я мог бы с этим согласиться, если бы не поставленный акцент. ООП - это не просто какое-то там удобство. Реальные проблемы при создании крупных программных систем - это не производительность программы, а производительность программистов, которая радикально падает при усложнении создаваемой системы. Падает вплоть до нулевого или даже отрицательного значения (т.е. при определённых условиях деятельность разработчиков становится попросту деструктивной). Поэтому все современные подходы к разработке так или иначе имеют дело с контролем сложности разрабатываемой системы. ООП - это как раз фундаментальный подход к контролю сложности системы. Да, сам по себе ООП не даёт никаких алгоритмических преимуществ. Не становится ОО программа ни быстрее, ни меньше. Но она становится проще, причём надо понимать, что накладные расходы при использовании ООП имеются не только в скорости работы и расходе памяти, но и чисто в тексте кода. Появляются некие дополнительные синтаксические элементы, их надо понимать, они занимают некое дополнительное место, ОО компоненты требуют несколько больших усилий при своём создании, требуются расходы на проектирование системы классов и т.д. Эти расходы выглядят совершенно неприемлемыми при создании минимальной программы аля "Hello, World!", что даёт повод некоторым утверждать, что ООП - шлак и без него можно обойтись. Однако, при разработке мало-мальски сложной системы эти накладные расходы уже становятся существенно меньшими в относительном измерении. При этом сложность разработки снижается радикально, что и является конечной целью. Снижается за счёт инкапсуляции, скрывания реализации, упрощения повторного использования кода за счёт наследования и полиморфизма и т.д. На мой взгляд работа над глобальным модом - более чем весомая причина для контроля сложности и значит широкого внедрения парадигмы ООП. К слову сказать, вся игра в целом, движок да и скриптовые интерфейсы, все сделаны в парадигме ООП. Очень хороший пример такого подхода. Там есть определённые косяки, но вообще стоит поучиться.

Внесу свои пять копеек насчёт заголовков и исходников. Как верно сказала Анна, то и другое - файлы исходного текста. В целом же с технической точки зрения разницы между заголовочными (*.h/*.hpp) и *.c/*.cpp файлами (которые обычно называют собственно исходниками) нет никакой. Одни включаются в другие инклюдами, а в итоге после препроцессинга получается один комбинированный текстовый файл (называемый единицей трансляции), который и подаётся на вход компилятора. Разница между заголовками и исходниками существует исключительно на уровне принятых соглашений об организации кода. В языке СИ/C++ есть объявления и определения. Определения - это указание выделить память и поэтому они должны быть строго в единственном экземпляре (в единственном не только на единицу трансляции, но и на всю программу). Объявления задают типы и структуру данных, должны предшествовать определениям и часто могут дублироваться. Поэтому объявления собирают в заголовках для их удобного включения "все разом" в начале текста (причём включения в разные единицы трансляции), а определения соответственно находятся в основном тексте (дабы быть в единственном экземпляре). Ещё раз. С точки зрения компилятора никаких заголовков нет. Компилятор всегда компилирует один файл, который должен строго следовать синтаксису языка СИ/C++. Заголовочные файлы - это просто средство удобной организации программы, разделение одного модуля на несколько файлов, а что обычно содержится в заголовке, а что в исходнике - диктуется природой элементов языка и тем простым фактом, что после подстановки всех инклюдов получившаяся единица трансляции должна быть корректным компилируемым файлом.

@BFG, ну что сказать, надо экономить кости =) На мой взгляд, на оружии здесь перерасход. Про руки не скажу, не знаю. Но даже запас в 10 костей даёт свободу для добавления как минимум пяти-шести аддонов. А вообще конечно нелепое ограничение. Выглядит так, что разрабы не хотели влезать в базовые классы костей и навесили заплатку в виде этого поля флагов для поддержки скрывания. Как по мне - чистая халтура.

@k01jan, насчёт 64 костей ситуация к сожалению печальная. Самих то костей может быть 65536, и хранятся они в массиве переменной длины. А вот флаги их видимости хранятся в 64-х битной маске. Судя по используемым алгоритмам, даже если удастся загрузить модель с бОльшим числом костей в игру, то они попросту будут не видны. Но я пытаюсь понять, откуда так много костей. Вот одна рука - 18 костей, две 36, ствол: корпус, затвор, патрон в патроннике, спусковой крючок, магазин, гранатомёт и его спусковой крючок, граната, глушитель, прицел, ещё + 10 костей. Итого 46 костей. На что можно потратить ещё 18?

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

@V92, Это не исправить. Ограничение в 65536 объектов - это размер двухбайтового поля в каждом объекте + масса кода, завязанного на этот размер. Даже имея исходники с полной перекомпиляцией потребуется изрядно переписать часть кода, а просто бинарными правками там ничего не сделать.

Я возможно слишком формально выразился. Я вовсе не имел в виду создание "контактной группы на высшем уровне" и "обсуждение в определённом формате". Подобные инициативы как не работали, так и не будут работать. Имелось в виду, чтобы вообще начать использовать сырцы и собираемый движок. Тогда начнутся и разговоры, а что там внутри и как это изменить. Сами собой начнутся. Есть скриптовые наработки, которые можно оставить, хотя бы как отправной пункт. Но вещам типа нетпакетов или x-ray extensions место на свалке. Я просто не понимаю, как можно тратить на них время сейчас, когда есть такие возможности.

Каким образом?

Позвольте и мне вставить словечко. Чем тратить время на нетпакеты, лучше бы собрались с силами и собрали бы движок со всеми известными модификациями и всем нужным штатно экспортированным в скрипты. Это исключило бы необходимость в нетпакетах в корне. Надо надеяться, такая работа уже ведётся. Вот это и будет 2015 год, а нетпакеты эти надо забыть, как страшный сон. update: Написал и после уже подумал, что даже и это не будет 2015 г., поскольку движок на данный момент мягко говоря подустарел, и реально шагом вперёд было бы активное обсуждение, чего там можно улучшить. Хотя это конечно совсем другая история.

я так понял, что ты сделал некую обёртку для level.add_call(), позволяющую хранить данные до вызова функции? Я то как раз сделал наоборот. Специально для "процедурщиков" написал обёртку над классом таймера, чтобы запускать в процедурно-ориентированном стиле. Правда только для сохраняемых таймеров. В итоге, можно и так сделать ogse_st_mgr.start_timer(timer_name, <задержка>, <имя функции>, <аргументы>) Но это естественно сильно ограничивает поле применения. Аргументы не могут быть любого типа, срабатывает только по задержке. Хотя конечно написать ещё одну обёртку с дополнительной функцией-условием тоже можно, но как по мне - это уже извраты и лучше использовать собственно класс таймера.

Это не ООП, а типичный процедурный подход, поскольку отсутствует инкапсуляция кода и данных. Ответь на простой вопрос, как ты при этом будешь хранить данные, которые надо "донести" от места/момента запуска до места/момента срабатывания? В принципе конечно можно использовать замыкания, но как по мне - это эрзац и вообще не ООП, а элемент функционального программирования. Если вкратце, то в Lua, в силу прототипного ООП, все методы заведомо виртуальные, поскольку определяются ссылками, хранящимися прямо в таблице/юзердате (что аналогично таблице виртуальных методов C++).

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

, по последнему вопросу https://code.google.com/p/xray-extensions/wiki/type_check по create_light01 и к нему относящимся. Это была моя попытка создать источник света на худе. Создавался, но толку не дало, поскольку создавался в координатах игры, а худ рисуется со своим FOV, По остальным вопросам уже не помню, что и зачем. Ещё скажу. wiki проекта x-ray extentions является его официальной документацией. Формат wiki специально предназначен для совместной работы и модификации того, что сделали другие. Так что вся информация в первую очередь должна быть там.

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

Что-то я тебя не понимаю. Допустим, у меня есть specific_character с классами stalker1 и bandit1. Тогда я могу сослаться из двух разных профайлов на этот конкретный specific_character по этим разным классам. Из одного профайла будет искать по одному классу, из другого по другому, но в обоих случаях будет найден этот specific_character. Не вижу, что здесь может не работать. Где это использовать? Ну не знаю. Есть допустим некий уникальный непись со своим визуалом. Допустим, он может перейти по сюжету из одной группировки в другую. Я создаю для него два профайла с разными классами для разных группировок, и из обоих ссылаюсь на один и тот же specific_character, где прописаны оба класса. Хотя наверное это можно сделать и иначе, но просто как иллюстрация.

Я бы сказал, что таймеры АМК, при всём к ним уважении, не подлежат никакому рефакторингу. Для своего времени это был прорыв, но сейчас это уже позавчерашний день. К использованию рекомендуются интегрированные системы компонентов, включающие систему хранения, событий и таймеры. Именно все три, поскольку они друг на друге строятся. Из готовых к применению я лично знаю набор от xStream и мой. Оба имеются в составе OGSE и существенной доработки не требуют. При желании можно перенести в любой мод. Собственно мои таймеры - даже не таймеры, а универсальные сохраняемые объекты с задаваемым условием времени жизни. Одно из условий - по времени, и тогда это таймер. А так можно задать любое условие и сделать объект, ждущий какого-то условия, чтобы совершить некое заданное действие. Используется это в массе разных компонент. У нас и сон есть готовый, основанный правда на движковых правках с перемоткой времени. На чистом движке нормально перемотку времени не сделать. Я с этим долго возился, и так и не смог достичь точной длительности сна стандартными средствами из-за случайных длинных апдейтов. На самом деле аналогично таймерам. Рефакторинг старого сна ничего не даст, надо менять концепцию.

@Карлан, два файла. В первом (specific_character.cpp) читаются все классы в массив m_Classes. void CSpecificCharacter::load_shared (LPCSTR) { //... data()->m_Classes.clear (); int classes_num = pXML->GetNodesNum (pXML->GetLocalRoot(), "class"); for(int i=0; i<classes_num; i++) { LPCSTR char_class = pXML->Read ("class", 0, ""); if(char_class) { char* buf_str = xr_strdup(char_class); xr_strlwr (buf_str); data()->m_Classes.push_back(buf_str); xr_free (buf_str); } } //... Второй фрагмент, где среди прочитанных классов ищется нужный. Файл xrServer_Objects_ALife_Monsters.cpp : shared_str CSE_ALifeTraderAbstract::specific_character() { //... bool class_found = false; // пока не нашли for(std::size_t j=0; j<spec_char.data()->m_Classes.size(); j++) // цикл по всем классам профайла { if(char_info.data()->m_Class == spec_char.data()->m_Classes[j]) { class_found = true; break; } }

Это не так. Читаются все. Могу показать фрагмент этого кода. По-простому никак. Названия костей надо просто знать заранее.

Это насчёт set_ignore_game_state_update? Я уже смутно помню. Какая-то затычка от какого-то нежелательного эффекта при промотке времени. Если вспомню, напишу в вики.

Да Да Мне сейчас достаточно одного дополнительного прицела, чисто для эксперимента. В принципе, магазин - это такой же аддон, и его может будет настраиваться по такой же схеме, как и все остальные аддоны. Разницу вижу только в том, что его будет движково не снять. Т.е. нет контекстного меню "снять", как для других аддонов, и для смены магазина придётся кликнуть в инвентаре на другой магазин. Но это даже и хорошо, поскольку оружие со снятым магазином не имеет смысла. Ну если мы только не замутим специальные стволы, которые не стреляют, именно для имитации оружия без магазина. А может для начала обойдёмся двумя прицелами? Я не могу ничего сказать по картинке. Мне рабочая в игре модель нужна. Что значит "скрытые"? Визуально все прицелы должны быть на своих местах, причём все разом. Я выше, как мне кажется, довольно подробно описал два возможных варианта. Названия для доп. костей не имеют значения. Важно только оставить стандартную кость и её имя "wpn_scope". Это имя зашите в движке. По-моему нет. Я себе представлял, что надо перегнать модель с анимациями из сдк в некий общий редактор (MilkShape, Maya, 3ds Max), там добавить кость и к ней поверхность, затем перегнать модель с новой костью обратно в сдк. В принципе понятно, что кость, которая стоит на месте относительно корневой, на самом деле тоже анимируется, просто никуда не едет. Но редактор как раз и должен взять на себя работу по включению доп. кости в существующую анимацию. Или я не прав? Ну не верится мне, что надо переанимировать вообще всё при добавлении одной неподвижной кости.

Был бы признателен. А там в целом стандартные анимации есть? Стрельба, перезарядка и т.д.? Т.е. аддоны анимировать не надо, но всё остальное должно быть. Так может кто-нибудь сделать такую модель с двумя прицелами? Добавлю ещё, что надо бы два разных варианта, поскольку пока не уверен, как именно это будет лучше делать. Варианты такие: 1. Кости для разных прицелов все используют в качестве корневой кость стандартного прицела "wpn_scope". По-моему, нельзя делать кость совсем без поверхности, поэтому в этом случае надо прицепить к стандартной кости хоть что-то, чтобы не было вылета. 2. Разных прицелы используют в качестве корневой кости корпус. На стандартной кости "wpn_scope" сидит один из прицелов (как обычно). Я пока не знаю, какой из этих двух вариантов сработает лучше. Надо экспериментировать. Стандартные анимации худа должны быть в модели как обычно.