Malandrinus

Real Wolf, В Luabind - на userobject. ColR_iT, Ну вообще-то это некислый api для связи C/C++ кода с Lua. Это его основное назначение. Разумеется, если мы этим не занимаемся и ограничены рамками Lua, то нам остаётся доступен в качестве полезного сервиса только небольшой кусочек, помогающий строить (псевдо)классы. Обёртка? Это на мой взгляд неправильный термин здесь. Не обёртка, а расширение. Очень специфическая библиотека. Gun12, Мне кажется, вы все усложняете мой вопрос. Если помните, то вопрос был вызван тем, что всплыл редко используемый синтаксис вызова функции function_name{<arguments>}. В связи с этим я и предложил интересующимся подумать над синтаксисом строки объявления класса. Я только хотел сказать, что такой код: class "new_class_name" (existing_class) это синтаксически корректный Lua, хотя и выглядит как конструкция какого-то другого языка. По крайней мере для меня так выглядело в начале, пока я не рассмотрел эту конструкцию поближе. Вот и вам предлагаю рассмотреть поближе, мне кажется это интересно. Вопрос же, что там делает Luabind, выходит за рамки данного обсуждения, поскольку это Luabind, он от нас скрыт. В том числе вопрос есть там копирование или нет. Вообще-то есть, как же иначе мы скопируем методы базового класса в унаследованный. Другое дело, как оно технически происходит, что Luabind там внутри себя делает с метатаблицами и пр. - это уже другой вопрос.

Gun12, Не сразу очевидно, что "meta" - это функция, поскольку это довольно редко использующийся способ вызова. Всем интересующимся, Раз уж зашла речь о нетипичных вызовах. В эту степь предлагаю подумать (кто ещё не знает), что именно происходит при использовании вот такой конструкции: class "class_name" (base_class)Напоминаю, что это объявление псевдокласса при использовании расширения luabind. Здесь объявляется класс "class_name", производный от существующего класса "base_class". Но при этом данная строка - синтаксически корректная конструкция. Вопрос, что же этой строке происходит с точки зрения Lua?

Gun12, я опять тебя не понимаю. что это за синтаксис? Если при обращении к ключу "insert" я что-то получаю, чего я не записывал, то мне без разницы, есть там поле или это оператор индексирования сработал из метатаблицы. Для меня такая таблица становится непригодной к использованию. Я ведь добавил про динамическое наполнение. Такое поле там может появиться не по воле программиста. Я могу в таблице хранить список кнопок или список команд или список каких-то лексем после парсинга или что угодно ещё, что может привести к появлению такого поля даже при том, что программист этого не планировал. Не заставлять же юзера заучивать список исключений. Это если юзер есть, а что если ввод автоматический? А что если разработчики языка решат переименовать библиотечную функцию, как это уже не раз было? Мне кажется, что здесь нечего обсуждать. Разменивать фундаментальную универсальность на мелкое удобство звучит как-то неправильно. Причём и неудобство-то - даже не столько неудобство, сколько вопрос привычки. Неужели настолько замедляет процесс написания программы отсутствие подобных фишек? К слову сказать, это на мой погляд и с точки зрения написания программы не самый лучший подход. Всё по той же причине: как программисту разделять внешне свои поля и "системные"? Неизбежна путаница, затруднение восприятия программы, замедление разработки. Конечно негативный эффект оценить трудно, и сказать, перевесит выгоды или нет, тоже сложно, но то, что негатив будет - это совершенно однозначно. Ещё аргумент. Функции из table - это всего лишь библиотечные функции. Их можно выкинуть при желании и заменить на что-то другое. Синтаксис же таблиц как таковой - это основа языка. Даже из этих соображений фишка не выдерживает критики.

, Таблица, в отличие от тех же строк - это более универсальное средство. Возможно причина в том, что разрабы не хотели "засорять" универсальный элемент языка частными возможностями. В том числе не хотели, чтобы в каждой таблице присутствовали имена стандартных функций (все из набора часто используемых имён). Таблицы часто используют для построения классов. Включение функций из библиотеки "table" автоматом заблокирует такие широко используемые имена методов как insert, remove и sort. С другой стороны, если сильно надо, то ничто не мешает добавить эти стандартные методы самому. добавил: Если подумать, то это не "возможно", а совершенно точно из-за этого. Ведь даже используя таблицу просто как таблицу, будет невозможно использовать поля (любого назначения, в том числе динамически образующиеся) с именами, совпадающими с именами стандартных функций. Что тогда делать? Прописывать в стандарте языка, что программист не может использовать ключи "insert", "remove" и т.д. ? Ерунда выходит.

, ничего не понял.

Язык Lua. Общие вопросы программирования Уроки по модостроению Справочник по функциям и классам Редактор иконок инвентаря X-Ray extensions Zones Editor Гравипушка Готово.

@Снайпер56, возможно, надо исправить свойства звука в SDK. Там надо увеличить дальность звучания.

Тогда не знаю. Лучше спросить KD87, эти его правки.

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

Оригинальный файл присутствует? Должен иметь имя xrGame_orig.dll и, если правильный файл, то размер должен быть 7258816 байт.

У меня работает. Какой версии ml.exe ? Kontro-zzz, Сейчас вряд ли этим займусь. Не то, чтобы не хотелось. Просто нет времени.

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

Alex535, схема пси-антенны не имеет никакого отношения к контролёру. Эффект от антенны достаточно простой: постпроцесс + периодический спавн фантомов. Причём это всё сделано скриптами. Контролёр же управляется целиком и полностью движком, скриптового в нём вообще нет ни строчки. Поведение его и эффекты, связанные с ним, достаточно сложные: проверка видимости актора с его стороны, расстояния до актора, телепатические хиты, постэффекты, звуки, эффекторы камеры. Всего и не скажешь, поскольку оно там внутри, и как работает - до конца не ясно. Посему твоё желание сделать схему радара как у контролёра просто невыполнимо, да и смысла не имеет по большому счёту, поскольку радар - это не контролёр и не может иметь всех его особенностей поведения. Вообще, непонятно, что ты там так заморачиваешься с этим радаром. Все эффекты урона, которые здесь можно придумать - это периодический хит телепатического типа и может быть постпроцесс + эффектор камеры типа опьянения, чтобы изображение качалось и двоилось. Скомбинируй по вкусу, и всех делов.

@Alex535, а кто сказал, что это скрипт? Все эффекты контролёра внутри движка.

@S.t.A.l.K.e.Z, Неправильно понимаешь. Как раз таки ассемблерный код может отличаться даже от патча к патчу того-же ТЧ. При переносе правки с ТЧ на, скажем, ЧН измениться может вообще всё. Фактически, надо повторять большую часть работы заново. Это если конкретно это место движка не изменилось по смыслу. В случае со слотами же ситуация такова, что менялось и сильно. Там надо не только делать, но и разбираться по-новой. В corection_list список врезок. Смысл в каждой строке имеют только первые два числа: адрес врезки в hex формате и длина врезки как десятичное число. Этот файл нужен для работы патчера, который переносит кусочки кода из файла правок в целевой файл. Файл правок собирается таким образом, чтобы по разметке строго соответствовать целевому, так что при переносе фрагменты ложатся на своё место.

тот что в masm32 не годится, нужен от MS Visual Studio не младше 10-й версии. Сам пользуюсь- никаких проблем. ColR_iT

Вампир35, судя по неполному логу, ты используешь какой-то средневековый ассемблер, который не распознаёт некоторые инструкции.

С рендерными делами не ко мне. Этим занимается в основном KD87.

S.t.A.l.K.e.Z, Не уверен, но тени возможно выключены консольной командой. плюшки все

АuReN, О, кстати я ошибся в предыдущем посте. Функция get_holder_class() возвращает этот же объект, но сконвертированный в тип holder.Т.е. её надо вызывать для машины, и она вернёт машину же, но в виде класса holder. А вот get_current_holder() как раз вызывается для актора и возвращает машину/пулемёт, в которой он сидит, или nil. Вот жаль, что нельзя править посты. Как всё неудобно стало. Кстати, в качестве идеи. Можно попробовать сравнить сами объекты холдеров, тот, что получен у актора и тот, который получен из машины. Я сейчас попробовать не могу, но есть некая вероятность, что это может сработать. Если сработает, то тогда всё равно надо перебирать машины, но не придётся мудрить с расстоянием до актора.

АuReN, эта функция возвращает объект типа CHolderCustom, он же скриптовый класс holder (имя класса на самом деле не имеет значения, поскольку нигде явно не используется). Строго говоря, это клиентский класс, но не game_object, поэтому у него нет поля id. Кроме того. как ты делаешь делать нельзя. Если актор не в машине или не за станковыйм пулемётом, то get_holder_class() вернёт nil и вылет будет на следующей строке, но уже по другой причине. Кстати, судя по логу именно это и происходит. Что касается определения id машины, то без правок движка это делается достаточно хлопотно: надо перебирать машины и искать ту, в которой сидит актор, сравнением положения актора и машины. По крайней мере я других способов не знаю. С правками это можно сделать проще.

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

STRIFER, К сожалению такое иногда происходит. Все предметы на уровне - в тайниках, у торговцев и в инвентарях неписей - находятся в онлайне, что означает, что для них загружаются модели и текстуры. Кроме того "нормальный режим игры" - это когда игрок пробегает через десяток локаций. Часть ресурсов с выгружаемого уровня честно выгружается, а часть - оседает в оперативке, даже если не используется. В итоге, загрузившись после старта игры на Кордоне имеем столько-то свободной памяти, а пробежавшись по Зоне и вернувшись на Кордон имеем уже существенно меньше свободной памяти. Эта разница и сколько всего памяти занято вместе определяют, будет ли игра устойчиво работать не только сразу после загрузки, но и после длительной игры. Впрочем, здесь вопрос стоит так, либо хватает памяти, либо нет. Если хватает, то и обсуждать нечего. Просто, поскольку здесь есть акцент на детальных качественных моделях и текстурах, то это (потенциально) может стать проблемой. Если мод собран, все локации на месте, мы пробежались по всем уровням и всё пучком, то значит всё с памятью нормально. Artem_K., можно хоть 64 гига засунуть, это не имеет никакого значения. 32-х разрядному процессу выделяется 4 Гб, из которых программе выделено всего 2 Гб. При этом под завязку эти 2 Гб не забить, поскольку есть дефрагментация и разные служебные расходы.

east1, Признаться, ничего не понял. При чём здесь моя или чья-либо иная конфигурация? Это вопрос скорее не оптимизации, а планирования =)

Модели конечно шикарные, спору нет: винтики сделаны реальными полигонами, на текстурах видно каждую морщинку/трещинку. Реализм зашкаливает. У меня однако вопрос. Это всё тестировалось в составе игры, когда одновременно в памяти десяток-другой подобных стволов? Только не подумайте, что я критику навожу. Вопрос сугубо практический, поскольку движок старый, 32-разрядный, да ещё и управление ресурсами ни к чёрту, т.е. текстуры/звуки/модели выгружать не любит. Реальный сценарий, который я наблюдал не раз: грузишь игру, если не вылетел с памятью сразу, то поиграл на одном уровне, вылетел из-за нехватки памяти при переходе на другой, поскольку большая часть объектов засела в оперативке, а на новом уровне что-то новое - уже не влазит. Причём эти ситуации надо тестировать достаточно тщательно. Надо загрузиться, поиграть, попрыгать по уровням, последить за расходом памяти, чтобы как минимум 15-20% свободной оставалось (поскольку реально её там меньше из-за фрагментации и скрытых расходов).