Перейти к контенту

Malandrinus

Жители
  • Число публикаций

    1 930
  • Регистрация

  • Последнее посещение

  • Дней в топе

    13
  • AMKoin

    120 [Подарить AMKoin]

Весь контент пользователя Malandrinus

  1. @Kondr48, Там есть ссылка на хорошее разъяснение сути. Там правда на английском. Полностью согласен с @abramcumner. Всякие тонкости, которые там обсуждаются, совершенно не важны для проектов на основе x-ray по той простой причине, что они по сути своей нелегальны. Так что беспокоиться не о чем - удалить могут так и так в любой момент.
  2. Ну вот, можно было бы развести сочный пафосный холивар на тему "как единственно верно инициализировать глобальные таблицы". Но это, выходит, только "для посвящённых". Скучно.
  3. @Dennis_Chikin, прошу прощения, но я либо что-то пропустил, либо совсем в танке. Ничего не понял, о каких именно файлах с таблицами речь?
  4. @Дизель, так а какая мораль? Выходит, x-ray не так уж плох, если тянул это без проблем да ещё и на весьма древнем железе.
  5. Эта функция сама аттач не выполняет, а только вызывает метод attach_Actor у холдера. Это именно то, о чём я и говорил. Без наличия основного функционала ничего бы вернуть не удалось. Опять же с точки зрения исходников (а бинарные правки я вообще не вижу смысла обсуждать) и вовсе ничего не вырезано, поскольку разрабы даже не потрудились удалить фрагмент кода. Вернуть обратно - стереть четыре символа.
  6. Malandrinus

    X-Ray extensions

    @dsh, разные авторы правок. Колбек 153 был добавлен позднее. Возможно, его автор не вполне был в курсе всех возможностях колбека 152. С документацией в этом проекте всегда было туго. На мой взгляд колбек 152 покрывает большую часть возможных нужд, поскольку даёт доступ к полной структуре хита, включая адресата, типы пули и пр. Достаточно подробный пример использования можно найти в огсе.
  7. Malandrinus

    X-Ray extensions

    @dsh, цитирую из лога Там есть ещё колбек 152 на событие "прехит", с помощью которого можно сделать всё тоже самое. В частности, в огсе через 152 сделаны иммунитеты актору и игнор дружественного огня неписями.
  8. @Дизель, твои слова фактически подтверждают то, что я сказал. Бинарными правками нельзя вернуть в движок функциональность такой сложности. Если Колмогору это удалось, значит код посадки в машинки там был. И вообще мы же обсуждаем не бинарные сборки, а движок в исходниках. В исходниках всё осталось, и в этом нетрудно убедиться самому. Просто сравни файлы машин в ТЧ и ЗП.
  9. Распространённое заблуждение. Никто транспорт в ЗП не резал. В этом нетрудно убедиться при построчном сравнении кода машин в ТЧ и ЗП. Практически всё осталось на своём месте. Другое дело, что этот код никто не дорабатывал для адаптации к изменениям в движке, вследствие чего функциональность и пострадала. Что-то где-то тронули - что-то где-то отвалилось. Всем знакомая история. Но специально ничего не резали. Посему, на мой взгляд есть единственных правильный движок ЗП, как наиболее продвинутый во всех отношениях. Его и надо использовать и на него опираться в дальнейших разработках. Если таковые конечно будут. Старые версии надо изживать, хотя конечно груз наработанного и тормозит этот процесс.
  10. Malandrinus

    OGSE: КБ разработчиков

    @Winsor, Могу предположить, что надо добавить очередь для рендера прямого затенения и для худовых объектов. Если не изменяет память, то в ТЧ всё шейдеры прямого затенения идут в очередь общей сцены, вне зависимости от того, это худовый или глобальный объект, а у худа должна быть своя очередь, поскольку он рисуется в отдельном пространстве (другой fov и вообще поверх всей сцены).
  11. Так я и говорил насчёт смены грунта - просто квадратику назначается другая типовая модель фрагмента грунта при проходе плуга/бороны. Это хорошо видно на роликах, что смена модели происходит не плавно, а по фрагментам. Ну и трава тоже наверняка привязана всё к тем-же квадратам. Прошла над квадратом косилка - нет травы или заменяем на огрызок. Т.е. тут реализация не выглядит слишком замудрёной, в отличие от тех же следов от колёс. Нет в сталкире никакой многопоточности для физики. Почему? Да и является ли это большим проектом с точки зрения окошек? И на виджетах есть несколько примеров весьма массивных с точки зрения окошек систем. Как уже выясняли, у разрабов был свой отладчик, который нам не достался. Есть только код его поддержки в движке. Тогда возникает проблема коммуникации между потоками. Отдельные стейты будут полностью изолированы друг от друга, соответственно нельзя будет обмениваться данными между скриптами. О динамическом планировании мнопоточности можно сразу забыть, что резко снижает потенциал распараллеливания.
  12. Какие именно фичи? На роликах ничего "такого" не видно, кроме уже обсуждённых следов от машин. Грунт явно рисуется по квадратикам (разбивка на квадраты светится в одном из роликов) и просто моделька квадрата динамически меняется при проходе бороны. Это даже заметно на ряде видео (эффект слегка прикрыт партиклом комьев земли). Ещё лужи есть, но это тоже не новое. Полигонов выходит масса, но текстур самый минимум, и сами модели кусков земли повторяются, поэтому вероятно не сильно грузят систему. Предполагаю, примерно как густая трава в сталкире.
  13. Ты имеешь в виду следы от колёс? По-моему, это ещё сложнее рисования волны. Волны - это достаточно простые шейдеры: вершинный, если надо видимое колыхание поверхности, и пиксельные - для бликов света и преломления. А вот для следа от колеса этого явно мало. Поверхность обычно рисуется огромными патчами - метры в размере - а след от колеса требует детальной сетки в районе углубления. Делать такую сетку заранее - никакой движок не потянет. Напрашивается динамическая тесселяция, т.е. локальное доразбиение на треугольнички по мере необходимости. Такого в сталкире вроде как вообще нет. Дело даже не в используемом директе, а просто явно для такой фишки нужно много дописывать в движке. Кроме того, из роликов мне показалось, что там не только делается вмятина, но и иногда имитируется повреждение грунта (хотя может просто показалось). Тогда это ещё дополнительное рисование на текстуре или техника сродни динамическим хитмаркам. Учитывая масштаб применения эффекта сразу появится проблема с видео- и общей памятью (текстурки хранить). Сталкир такого точно не потянет.
  14. Здесь смотря что имеешь в виду. Не вдаваясь в подробности, то если совсем конвертировать игру в сингл, то это разумеется нетривиально. Это будет означать довольно много аспектов: убрать сеть и это разделение на два объекта и также связанные с этим механизмы (общение через нетпакеты, сохранение через нетпакеты, и т.д.), изменить механизм перехода в оффлайн/онлайн (или в более общем смысле способ поведения объектов на удалении от актора). Всё это означает по сути переписывание движка. Не всего, но весьма изрядной части. Если просто убрать сетевой код, то это вполне возможно сделать, не меняя в сущности (почти) ничего. Я даже этим занимался. В сингле часть кода просто не работает. Сервер вырождается в некий минимальный набор инструкций, который собственно и можно оставить. И везде по коду есть вставочки "если сеть, то делать так, если сингл, то иначе". Там тоже можно повырезать. Ещё вырезать весь код, связанный с сетевыми режимами: разные типы игр и часть интерфейса. Это всё можно сделать. Я даже таким занимался и отчасти преуспел. Всё это скорее просто исследовательские ковыряния. Когда вырезаешь всю эту сетевую муть, то как-то проще понимать, что там происходит. Речи о "взаправдашнем сингле" конечно не идёт. Как я выше написал, это означало бы переписывание половины движка. Не станет. Как было верно сказано, сеть практически не работает в сингле. С другой стороны движок стал бы проще и намного стабильнее. Но это в теории, когда мы бы все переписали и потратили хотя бы половину времени от того, что потратили на отладку разрабы (и это было бы меньше, чем у них, но всё равно очень много). Признаться, я со временем перестал понимать, о каком вообще алайфе идёт речь. Походу коммюнити до сих пор находится во власти неких мифов времён ожидания "того самого сталкира". О чём вообще речь? О том эксперименте с полной симуляцией, что разрабы проводили до 2014 года? Так там нет ничего особенного. Сюжета нет. Сталкеры бродят сами по себе. Есть некая "загадка Зоны", которая решается путём нахождения последовательности артефактов: торговец выдаёт задание на арт, ты его находишь, приносишь, тебе даётся задание на следующий, и т.д. Вся фишка была в том, что эту "загадку" мог решить и непись. Собственно и всё. Сделав это чудо разрабы быстро поняли, что играть в это невозможно и никто и не будет. После чего получили пенделей, взялись за ум, слепили на коленке сюжет, заскриптовали всё по самое немогу, и мы имеем что имеем. Так о каком алайфе речь? Кстати, там внутри даже остался весь этот код, что отвечал за это хождение по цепочке артов, просто заблокирован (хотя врать не буду, может и не весь, но дела это не меняет). С моей точки зрения, что было сделано в том же АМК на предмет оффлайнового поведения неписей на порядок превосходит всю эту странную исходную конструкцию. Как-то иначе. Кто вообще сказал, что сохранение таким образом, как сейчас, - это хорошо? Это ужасно на самом деле. Чтение каких-то обезличенных буферов с данными - что может быть более непрозрачным и ненадёжным?! Как сейчас происходит спавн и загрузка объектов: читается нетпакет из сохранёнки или аллспавна, посылается по сети или передаётся через буфер в памяти в сингле, на другом конце создаётся объект, ему передаётся этот нетпакет и объект заполняется данными. Это ужасно. Концов данных не найти, смещение на байт в одном месте программы приведёт к висяку в неизвестно каком другом месте и т.д. Неудивительно, что отладка этого чуда заняла так долго.
  15. А что тогда развивать? От движка тогда остаётся процентов 20-30. Да и есть уже такое, вот хотя бы Survarium, Это совершенно не критичный элемент. Обычные таблицы с данными, минимальная обработка. Реальные сложности вовсе не в этом, а в синхронизации игровых объектов в реальном времени. Собственно, именно поэтому есть проблемы с ботами, физикой и т.п. Но если снизить требования к ботам, к физике, замаскировать сетевые задержки (в частности отсутствием или уменьшением близкого контакта между объектами), то выходит то, что уже и так есть, и во множестве. Тот-же Сурвариум, да и наверняка не он один.
  16. Malandrinus

    C++

    Professional или Community - разницы нет. Основная проблема - изменения в стандарте языка и в библиотеках. Реально масса геморроя с тем, чтобы это заработало. С другой стороны, можно в студии 2015 использовать тулсет от предыдущих версий (если установлен конечно). В этом варианте вроде и менять ничего не надо, но это наверное не совсем то, что хотелось бы. Я добивался сборки и работы движка ЗП в 2015 студии, но с оговоркой, что это очень сильно изменённый проект, сильно покоцанный и с массой моих изменений. Поэтому даже не могу точно сказать, что именно надо сделать и в каком минимально достаточном объёме, чтобы ванильный вариант заработал на студии 2015.
  17. Да, вертикальную жёсткость "поплавков" надо бы увеличить. И возможно также вертикальный размах колебаний костей-поплавков уменьшить. Надувная лодка так сильно колыхаться не может. Заодно и меньше будет видна вода на дне. А вообще в таком варианте выглядит весьма многообещающе.
  18. @Дизель, @HellRatz, Понятно. Половинчатое конечно решение: лодка и в целом должна неестественно высоко сидеть, да ещё учитывать запас на раскачку (от невидимых колёс). Мне приходит на ум некая манипуляция с шейдерами воды. Вода же рисуется рендером прямого затенения поверх уже нарисованной картинки рендера отложенного затенения. Наверное можно было бы просто не рисовать воду на фоне специального материала дна лодки. Теоретически это наверное не сложнее, чем эффект мягкой воды. И ещё по-любому остаётся проблема травки в воде (и со дна лодки). Проблема ровно та-же, что и с растущей из пола машины травой. В OGSE смогли отчасти бороться с этим, добавив отсечение по расстоянию до актора в шейдер травы. Работает только при посадке в машину и вроде бы травы под ногами не видно. Но там а) траву не сильно видно со стороны в закрытой машине, и б) в машине при посадке обзор намного меньше, чем в лодке плюс не видно земли "за бортом" (и соответственно не бросается в глаза это отсечение). В лодке же дно будет видно полностью, и там там примитивно забороть не получится.
  19. @Дизель, а как воду со дна лодки уберёшь?
  20. Это бессмыслица, поскольку ООП - это как раз набор методов и подходов. ООП - это не наличие в языке специального типа для класса, неужели это непонятно? Ну загляните хотя бы в википедию, а можно почитать весьма старую, но фундаментальную книгу Гради Буча. В ней вообще половина книги - рассуждения на абстрактные темы вроде типов классификации. А ещё есть UML, предназначенный для задания архитектуры объекто-ориентированного программного проекта, и этот язык вообще не привязан ни к какому конкретному ЯП. Проект на UML можно реализовать практически на любом мало-мальски развитом языке, хоть процедурно ориентированном типа СИ, а это всё равно будет ООП. Поэтому вот это неверно. Если что-то выглядит как класс, и может использоваться как класс, то это и есть класс. Кроме того, вот это неверно по сути. Класс создать можно и они там во множестве создаются. А серверные скриптовые классы - это вообще что по вашему? Это простой вопрос, предлагаю на него всё-таки ответить.
  21. цитирую: Впрочем, наверное это была просто оговорка. Да почему же не могу? Вот скриптовые серверные классы игровых объектов - вполне себе новые классы: можно добавить/заменить/дополнить методы, добавить новые данные. Т.е. мы определяем наследованием новый класс, потом даём ему имя (регистрируя в связке с клиентским), затем создаём экземпляры класса функцией create. Ну для начала, если мы используем Luabind, то создаётся не таблица, а userdata. И я здесь не совсем понял сказанное. Мы создаём объект (если совсем точно, то его серверную половинку) так: alife():create("section_name", pos, alvid, agvid) Для этого нам надо уже иметь класс, который здесь неявно присутствует в виде параметра секции class. Создание класса происходит в виде а) наследования скриптового серверного класса от движкового и б) регистрации связки двух составляющих классов "скриптовый серверный / клиентский" с присвоением этой связке идентификатора - имени класса. Что не так? При наличии соответствующего движкового API это вполне можно сделать. Я даже могу сказать, что именно для этого надо: колбек рендера, низкоуровневая функция отрисовки поверхности и соответствующий шейдер. Остальное на себя возьмут скрипты. Да вот хотя бы в OGSE скриптовый менеджер погоды по сути почти полностью заменяет движковый. В каком то смысле именно это и есть - класс "облака". Там от движка используется только блендер двух погод, который (если очень упростить) как раз и занимается тем, что рисует на небе две наложенные текстуры в заданной смеси.
  22. Извиняюсь конечно, но наблюдаю явное незнание терминологии. Экземпляр класса - это и есть объект. Это синонимы. Экземпляр объекта - это масло маслянное. И ещё раз повторяю, класс - это надязыковое понятие, часть парадигмы ООП. Как именно класс реализуется в конкретном языке - дело конкретного языка. Это может быть и специальный тип, как в С++, а может быть нечто другое, как в случае с игровыми объектами сталкира. Или ещё что-то другое, как в случае с НЕигровыми объектами во всё том же сталкире. Класс вообще-то по определению - декларация, обобщённое описание некоего множества объектов (АКА экземпляров класса).
  23. Но в движке то есть. И, кстати, в Lua (точнее в скриптовой модели сталкира) в сущности тоже есть. Это не что иное, как связка двух классов - серверного и клиентского, которую мы регистрируем в class_registrator.script (помимо уже имеющихся). Мы даём этой связке идентификатор - и это не что иное, как имя класса. По имени класса мы создаём конкретный экземпляр класса функцией create. Так что имеем вполне себе полноценный ООП с классами и объектами (экземплярами классов). В принципе и наследование не сказать, чтобы было прототипное. Мы когда конструируем расширения классов, то пишем так: class "new_class" (base_class) и делаем это один раз до того, как создаём экземпляр класса, т.е. в сущности имитируем классическое статичное наследование С++. Ну да, потом можно с классами тоже делать всякие манипуляции, что размывает "классичность" картины, но надо помнить, что Lua здесь сугубо вспомогательный инструмент и призван максимально точно отражать СИ-шные потроха. Его дополнительные плюшки - это уже вторичное. Вообще ООП - это не конкретный набор языковых средств, а парадигма. В том числе класс - это надязыковая идея, и может и не быть специального типа класса, как нет его в Lua, хотя классы как таковые есть (хотя конечно удобнее, когда есть специальные типы). Каждый язык может реализовать парадигму ООП по-разному. Более того, как мы видим в случае сталкира, один и тот же язык может это делать по-разному. Вот в сталкирском Lua имитируется по-сути ООП из С++, и прототипное ООП практически не задействовано.
  24. Торговец - почти в чистом виде подмножество сталкера: инвентарь, торговля, диалоги, но без навигации и боёвки. Поэтому это и возможно. Вряд ли возможно ещё какое-то обобщение классов существ. Всё-таки наверное CCreature, а не CCreator. Для начала, сейчас и так есть класс CEntityAlive, от которого унаследованы все остальные существа. Это мало что даёт для реализации твоей идеи, поскольку в этом классе, как и положено, только самый общий функционал и данные для живых существ, т.е. практически ничего там нет. А непосредственное управление включает множество деталей, относящихся к конкретному существу. Ну скажем собака ходит не так, как человек, а снорк не так, как собака, и даже актор ходит не так, как сталкер. Атакуют они по-разному. Инвентарь у них разный, если вообще есть, и т.д. и т.п. Для реализации такого управления надо по-сути для каждого существа реализовать свою отдельную схему управления, включая худ, интерфейс и т.д. Само по себе это работать не будет. Так и в чём тут простота?
  25. Откуда эти странные идеи, особенно про что было вырезано? Если же предметно это обсуждать с точки зрения ОО дизайна, то отдельные классы вводят потому, что нужно другое поведение. Каким образом ворона и сталкер могут быть соединены в одном классе? Интересно было бы послушать. Мысль сделать актора на "управляемом" сталкере имеет право на жизнь. Однако надо помнить, что актор с технической точки зрения на самом деле сильно отличается от сталкера. К примеру, управляется физикой, а не навигацией по сетке. Это тянет за собой много мелочей, которые на первый взгляд неочевидны. Сидора, АКА CAI_Trader, на самом деле можно вырезать и заменить специализированным сталкером, особенно в ЗП, где вопрос с анимациями проработан куда лучше.

AMK-Team.ru

×
×
  • Создать...