Malandrinus

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

@Earth2Space, из штатовской версии игры.

Функция возвращает то, что сам движок показывает под указателем прицела. Функция на самом деле просто читает уже готовые данные, поэтому повлиять на это невозможно. Движок использует для поиска предмета под курсором функцию рейтрейсинга. Для этой фунции нужен визуал, т.е. набор треугольников, с которыми можно пересечь луч взгляда. У аномалий визуала нет вообще, поэтому с ними не работает в принципе. Большинство ламп на самом деле в большей своей части являются геометрией уровня, а собственно объектом является только колба, да и та скрыта, если лампа выключена.

@Real Wolf, для выполнения произвольного кода в игре я предпочитаю использовать скриптовый тестовый полигон. Надо только переключиться из игры в текстовый редактор, но это не намного хуже, чем открыть консоль. Я проверил на чистой сборке. Да, без движковых изменений команда переключает сразу. Но это как раз и неправильно, что я выше объяснял. Если переключает плавно, то это походу происходит от начала следующего погодного фрейма текущей погоды до ближайшего фрейма новой погоды. За точность не ручаюсь, но примерно так.

@Real Wolf, тогда эта команда НЕ работала как надо. Сейчас вспоминаю, что в своё время сам же написал в справочнике: Видимо сейчас таки заработало =) Кстати, какой смысл использовать консольную команду, если есть функция?

Вообще-то работает. Вот выполняю консольную команду, погода меняется. Не сразу, но это так и должно быть, поскольку консольная команда соответствует варианту вызова level.set_weather("name", false), т.е. второй аргумент false, что означает постепенную смену.

@Real Wolf, эта консольная команда делает ровно тоже самое, что и функция level.set_weather. Тогда непонятен смысл исходного вопроса. Зачем блокировать эту команду?

@Real Wolf, это вспомогательный фикс для перемотки времени и рядом в этой же функции фикс солнца. А что такое "консольное переключение погоды"? Первый раз о таком слышу.

@Dennis_Chikin, т.е. как пустая функция? Это похоже на заглушку, наверняка результат копипасты. Заглушка наверное не нужна сама по себе. С другой стороны и вреда особенного нет. Насчёт дубликата. Скорее всего баг, возможно результат всё той же копипасты. Срабатывать будет вторая функция. Вот смотри, такой код: function generic_object_binder:reload(section) end Является синтаксическим сахаром для вот такого: generic_object_binder.reload = function(self, section) end т.е. сделав это два раза мы просто переписываем поле reload. Естественно, там будет результат от второй записи.

Dennis_Chikin, ок. Первый фрагмент - метод биндера. function generic_object_binder:reinit() object_binder.reinit( self ) end Вызов object_binder.reinit( self ) здесь не делает ничего, поскольку класс биндера не делает ничего, поскольку его единственное назначение - вызывать скриптовый код. Строку можно убрать, ничего не изменится. Второй фрагмент. Переопределён метод класса se_artefact, заменен на скриптовый. function se_artefact:can_switch_offline() return cse_alife_item_artefact.can_switch_offline( self ) end Исходный метод cse_alife_item_artefact.can_switch_offline(self) что-то делал, пока мы его этим самым фрагментом не переопределили. Скорее всего возвращал значение серверного флага, хотя прямо сейчас не буду утверждать наверняка. Соответственно в показанном виде мы попросту воспроизвели то, что в движке было изначально. Теперь есть два выбора: 1. Заменить эту логику. Строку удаляем, тем самым игнорируя значение серверного флажка (предположительно). Вместо этого ставим что-то своё, к примеру return false, что будет означать, что объект означенного класса никогда не перейдёт из онлайна в оффлайн (разумеется до тех пор, пока на одном уровне с актором). 2. Дополнить эту логику. Можно поставить некий код, который при каких-то условиях будет переходить в оффлайн по нашему условию, а в других условиях по серверному флажку. Как-то так: function se_artefact:can_switch_offline() if <какое-то скриптовое условия> then return false end return cse_alife_item_artefact.can_switch_offline( self ) end

Dennis_Chikin, Разница есть, обусловлена разной природой биндера и серверного объекта. Скриптовый серверный объект является обёрткой для истинного движкового объекта, т.е. когда вызываем его метод в скриптах - тем самым явно вызываем соответствующий метод движка. Одно из следствий этого - когда переопределяем метод в скриптах - он полностью заменяет внутренний движковый метод. Если внутренний метод при этом использовал сервис базового класса в виде явного вызова метода базового класса, то это надо/можно повторить и в скриптах. Самый типичный пример - методы сохранения/чтения, где сам скриптовый метод сохраняет только "своё добро", а надо ещё и явно вызвать метод базового класса для сохранения/загрузки его состояния. Или метод проверки выхода в онлайн, где я могу определить свою логику для этого действия, но при этом могу использовать в качестве одной из веток алгоритма дефолтовое значение. А могу и не использовать. В последнем случае метод базового класса вызывать не надо. При этом всё-таки надо отчётливо понимать, что я сознательно выбрасываю определённый движковый функционал. С другой стороны биндер работает совсем иначе. Есть онлайновый класс, у него есть базовый класс CScriptBinder, который входит в состав CGameObject (и значит в состав абсолютно всех классов). Класс CScriptBinder как раз и отвечает за функционал биндера. Там есть указатель на объект биндера, а биндер в свою очередь - это отдельный класс CScriptBinderObject, которому как раз и соответствует скриптовый биндер (является его обёрткой). Объект биндера может быть или не быть, мы сами создаём его в скриптах и цепляем к онлайновому объекту методом клиентского класса bind_object. Если он есть, то это исключительно инициатива клиентского объекта-хозяина вызывать методы биндера и посылать сигналы колбеков. Отсюда идёт важный вывод. Нет никакой необходимости вызывать методы базового класса биндера, поскольку они ничего не делают. Т.е. всё движковое действие происходит в методе клиентского объекта, который сработает вне зависимости от того, вызвался метод биндера или нет, а биндер просто вызывается "до кучи". Я это проверял. Удалял вызовы базового класса биндера, и ничего ровным счётом не менялось.

Earth2Space, Это принципиально не сработает. В качестве входного файла допустим только чистый файл строго определённой версии. Файл не просто патчится, а надстраивается дополнительной секцией и ещё во многом меняется. Короче, становится необратимо несовместим "с собой" и уже никакому "допатчиванию" этим же проектом не подлежит.

@Real Wolf, тогда, во-первых, таки не в той теме пишешь. Во-вторых, плохо искал, ищи лучше.

Real Wolf, Я думаю, что твои затруднения к x-ray extensions не имеют никакого отношения, но если ты так полагал, то надо было постить в соответствующую тему. Я к примеру сюда захожу очень редко. Информации всё равно не хватает, и я могу только догадываться, что именно не так. Ставишь колбек в биндере, а он не срабатывает? Если так, то либо объект этого колбека не имеет, либо установил колбек как-то не правильно. Хотя я всё равно не понимаю, какого рода "приведение типа" ты хочешь сделать (в скриптах? на уровне правок?), но на всякий случай замечу вот что. 1. Движок создаёт объекты "оконечных" типов, т.е. кровосос, жарка, артефакт грави, пистолет ПМ и т.п. Никогда не создаётся (и вообще невозможно создать) объект базового типа: монстр, абстрактная зона, инвентарный предмет и т.п. 2. Объект, будучи создан, изменить свою природу уже не может. Создали кровососа - это будет кровосос. Набор активных колбеков сугубо индивидуальный для каждого класса, и значит какой объект создали, такие колбеки и будут работать, и ничем это (во время работы) не изменить. Изменение движка повлияет на все создаваемые объекты такого типа. 3. Что касается приведения типов. В языке С++ есть разные приведения, но в контексте движка сталкера смысл имеет только приведение указателя. Ну так приведение указателя на объекте не сказывается никаким образом. Привели указатель на CCustomZone к указателю на CGameObject, аномалия от этого не перестала быть аномалией, и её колбеки как работали, так и работают. Обратное тоже справедливо. Есть указатель на CGameObject - это значит на самом деле под ним скрывается объект какого-то из зарегистрированных для создания классов, что в свою очередь означает, что он себя ведёт соответствующим образом вне зависимости от того, кто на него указывает и каким из базовых указателей. Можно определить его тип, привести обратно к его "истинному типу", но опять же - с точки зрения поведения ровным счётом ничего не изменится.

Real Wolf Насколько я понял, преобразовать CCustomZone в CGameObject нельзя? Упомянутые классы в игре непосредственно недоступны, поэтому вопрос непонятен. Что значит "преобразовать" , что именно ты хочешь сделать?

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

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

, в официальном описании версии 5.1 функции string.gfind нет, значит всё-таки "более". И я вообще-то пытался сказать, что Lua в сталкере не обрезанный, только и всего.

@dukekan, для ограниченного объёма данных можно использовать трюк с хранением данных в имени файла с использованием класса FS. Этот класс не позволяет записывать данные в файл, но позволяет копировать файлы, менять их имена, читать содержимое каталога. Нужно завести таким образом специальные пустые файлы, придумать формат для имён и хранить данные в именах. Это вполне работает, хотя конечно и пахнет трюкачеством за милю. С другой стороны можно рассмотреть использование расширений Lua. Есть проект от RvP, где добавлялись недостающие библиотеки работы с файлами.

Не первый раз слышу про "обрезанный" Lua. Ерунда это. Lua в сталкере совершенно стандартный, точнее соответствует своей версии. Более того, включены опции для расширенной совместимости со старыми версиями. Например, можно взаимозаменяемо использовать string.gmatch и string.gfind. Библиотек некоторых нет, но это не относится к языку, да и исправляемо в общем. Как совершенно верно заметил abramcumner, язык напротив расширен. В luabind для вызова методов классов используется метаметод "call" пользовательского объекта. Т.е. он внутри себя выбирает функцию, которую надо вызвать по аргументу этого метода - имени функции. Без специальных средств выяснить список методов класса не получится.

Earth2Space, Только к ручным. Подствольные - это технически патроны в пачках по одной штуке.

@abramcumner, вроде бы таки отключается. Способ "отключения" конечно весьма хитровывернутый, но по сути работает. Если мне не изменяет память, то эффект получается такой. Там функция заполняет при вызове некую структуру. Если вызвать другую функцию, то часть полей заполнится иначе или не заполнится. Уже не помню деталей, но по сути это и блокирует проверку, поскольку проверяемое поле будет всегда иметь одно и тоже значение, которое смысла не имеет, но и вылета не вызывает. Если я конечно верно понимаю, поскольку сильно в детали не углублялся. Уже толком не помню, что именно там проверяется. Может, доступная физическая память или что-то в этом роде. По моему опыту, эта проверка никогда ни у кого не срабатывает. По-любому, этой правкой не достигается ни ускорение ни расширение доступной памяти. Ускорение к памяти очевидно отношения не имеет, а проверка памяти при старте программы в общем тоже ничего не меняет, поскольку обычно реальные проблемы с памятью начинаются после продолжительной игры и связаны с фрагментацией и исчерпанием адресного пространства.

Насчёт правки с GlobalMemoryStatusEx. Это совершенно бесполезная правка. Как результат правки там отключается некая разовая проверка какой-то занятой памяти при старте программы. Во-первых, потенциально ни к чему хорошему это не приведёт. Если есть проверка, значит не зря. Не вывалится здесь, вывалится позже. Во-вторых, не помню ни одного случая, чтобы эта проверка срабатывала будучи включённой. В третьих, эту проверку можно штатно отключить и без правок с помощью ключа командной строки --skipmemcheck.

power-cat, Не выйдет. В corrections_list.txt только врезки переходов на собственно фрагменты рабочего кода, где и делается основная работа. А эти фрагменты сидять в дополнительном сегменте, который ещё надо сделать, и пишутся на ассемблере. Кроме того, адреса там - это не физические смещения от начала файла, а смещения от начала сегмента кода, которые патчер ещё должен пересчитать.

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