erlik
Не очень понял о 'аи схемке для девиаций npc'. Если ты о кайфаманах под выхлопной трубой, то ... врядли кто серьезно этим займется. ;-)
Заглянул вчера в топик-мастерсукую на сайте АМК. Смотрю вы и там затронули темку о метатаблицах ... и у тебя там (да и тут) остались некоторые вопросы. Дам немного пояснения, может кому и сгодится:
1. Когда копался с динамическим под(отключением) модулей (самописные файлы скриптов/схем) столкнулся с тем, о чем писал ранее - при некоторых ситуациях вызов своей функции приводил к фатальной ошибке и безлоговому вылету (безлоговый: полностью пустой лог-файл или отсутствие в нем секции [FATAL ERROR]). Причем при вводе предпроверки корректности самого файла-скрипта вылеты прекращались.
2. Порой при ковыряниях в скриптах допускал оЧепятки и ... незамечал этого, т.к. нередко скрипты/функции используются эпизодически и в редкие моменты игры. Т.о. ошибки синтаксиса и пр. попадали в публикуемые версии сборки (Симбиона).
Что сделал и можно использовать:
1.
При инициализации файла '_g.script' (см. в самом конце варианта из Симбиона) вызывается проверка наличия и корректности всех файлов из папки скриптов. Т.к. отдельные мусорные файлы, находящиеся в запакованных архивах игры (*.dbX), имеют ошибки или же просто заведомо имеют некорректный синтаксис (тот же lua_help.script), являясь чисто справочной информацией, то введен список и маски, отсекающие явный 'мусор'.
Подобная проверка экономит время, т.к. уже НЕ требуется 'ручная' по-файловая проверка скриптов после внесения в них изменений. При старте игры 'дефектный' скрипт обнаруживается и о нем выводится информация. Кстати, проверяльщики синтаксиса типа 'Lua Checker' далеко не все отлавливают.
Побочным эффектом этой проверки оказалось то, что ... ВСЕ просканированные файлы оказывались в метатаблице _G(!). Т.е. подозреваю, что получение листинга директории приводит к загрузке в буфер (_G) всех файлов.
Т.о. полностью пропала необходимость предварительной инициализации самописных файлов-скриптов.
Недостаток (относительный!) данного способа только в том, что в буфер попадают и файлы (не исключенные по спискам/маскам), которые никогда не используются игрой, т.е. впустую отъедают объем памяти буфера.
Не думаю, что это так критично/важно, как например посетовал singapur22, т.к. этот объем незначителен и гораздо больше (на порядки!) транжирят ресурсы собственно рабочие модули/функции/циклы ... Да и пополнив списки/маски исключений можно отсечь 'раздражающий' мусор.
2.
Т.к. отдельные скрипты требуют инициализации различных переменных/таблиц/... и порой порядок их инициализации важен (взаимозависимости между файлами), то ввел специальную процедуру инициализации требуемых модулей (через init()). Создав нумерованный список этих модулей и флаги необходимости их инициализации (подключения к игре), я получил возможность и предварительной установки всех необходимых переменных ДО обращения к ним, в нужный мне момент старта игры, и возможность динамически управлять в(от)ключением этих модулей. Причем вызовы к отключенным модулям из 'рабочих' модулей не приводят к фатальным ошибкам, как при удалении файлов-скриптов.
Stalk15
tArtefactClasses - банальная табличка, в которой в качестве ключей перечислены class_id имеющихся в оригинальной игре классов артефактов, а в качестве значений - булево значение (истина).
Если вызвать в своей функции проверку типа: if tArtefactClasses[obj:clsid()] then
что по сути эквивалентно такой строке: if tArtefactClasses[obj:clsid()] == true then
то такую строку можно прочитать так: Если класс_айди объекта (obj) имеется в таблице артефактов и эначение соответствующей записи (ключа) тождественно истине то ... (проще говоря, если объект относится к классам артефактов то ...).
Для эрудиции: можно было бы использовать простой список, т.е. только идентификаторы в качестве значений, но т.к. идентификаторы - 'числа', то возможны коллизии.
Также можно, оставив все перечисленные идентификаторы (для памяти), исключить те, которые невостребованы простым приравнованием: [clsid.art_gravi] = false, тем самым исключив из валидных артефактов 'грави'.
Да и ... проверка таблицы по 'ключу-значению' более прост, чем цикл перебора списка.
(хотя даже такая простота вызывает вопросы :-( )
Artos
По разбору _G на сайте АМК. Kolmogor отвечая на мой вопрос написал:
"Есть файл script.ltx, в нем прописан class_registrator.script, из него подгружаются серверные и клиентские классы.
Из конфигов секций объектов подгружаются скрипты биндеров."
Насчет биндеров все понятно - любой биндер, даже самописный я так понимаю должен буферизироваться в _G автоматически(движково) .
Насчет классов - значит ли это, что любой файл в котором есть самописный класс (наследующий от дефолтного) должен также автоматически подгружаться в _G, так как он тоже вызывается\сканируется движком вслед за дефолтными модулями содержащими классы?
Например у singapura'22 скрипт из **50316ea8aab1bb10eeba**
Разработки: "Тотализатор","Kill-zone", "Mega-bomba", Mega_gravi",
"Рандомные тайники(а также декодер, мины+диалоговый аддон"), "Выбрасываемый рюкзак", "Аналоговые часики на худ"
erlik Автономно? Врятли. Одна связь с внешними файлами всётаки есть. А именно метод открытия меню: level.start_stop_menu(_mobile_changer.mobile_changer(), true)
Который находится в другом файле, под постоянным апдейтом, через условия, навязанным из файла bind_stalker.
Проект "Mobile Manager" закрыт, в связи со стечениями неблагоприятных обстоятельств, и последующей потерей всех файлов и справок текущего проекта.
singapur22
Понятно - значит твой файл из mobile_changer'a все таки буферизируется в _G при старте игры вследствие того, что к нему идет обращение извне. И наличие классов тут не причем. Однако ты же в своем детекторе тоже пробовал делать независимый вызов функции - и, как ты писал, вызовы все таки были - хотя и не всегда. А там у тебя стояли обращения к файлу извне?
Разработки: "Тотализатор","Kill-zone", "Mega-bomba", Mega_gravi",
"Рандомные тайники(а также декодер, мины+диалоговый аддон"), "Выбрасываемый рюкзак", "Аналоговые часики на худ"
erlik
К сожалению все наши, включая и Kolmogor'а, выводы - это только некие предположения, базирующиеся на нашей логике из практики программирования и практических изысканиях, т.е. по сути остаются все же предполагалками, хотя порой и со статусом 'истина' иль 'аксиома'.
Насчет 'script.ltx' - тут вроде как и так все (почти!) очевидно. Т.к. игра(движок) должна собрать воедино все необходимые модули, считать конфиги/параметры и т.п., то естественно где-то должны быть прописаны и пути и названия модулей/конфигов/...
То, что в 'script.ltx' как минимум прописаны имена и пути к регистраторам классов и типов игры - это ясно, а вот то, что параметр 'script = _G' из секции [common] используется - неочевидно. Я не исключаю что и это некий рудимент, оставшийся от разрабов.
Простейшая проверка обнулением/закомментированием и этого параметра в ltx'шке и 'prefetch("_G")' в 'class_registrator.script' не приводят к каким-либо изменениям ни в игре ни в лог-файле (по крайней мере у меня в сворке).
Т.о. это или подстраховка (о чем говорит Kolmogor) или рудимент.
Требуется ли использовать именно 'prefetch("module_name")' - опять предполагалки. По крайней мере я, внося многочисленные доп.модули/схемы, со 'своими' классами и/или подклассами от имеющихся родительских, не сталкивался с ситуациями 'НЕ вызова' (не срабатывания при вызове). Возможно то, что я уже описал выше (первичное чтение/проверка всех скриптов) делает невостребованным подстраховки prefetch'ем ...
О твоем случае могу пока предположить ... твоя же ошибка в написанном модуле.
Как то ковыряяс с самописным биндером, добавил (скопипастил) один метод из другого бандера, забыв изменить название класса ... В результате синтаксис не был нарушен, каких либо ошибок ни один чекер не выдавал, но ... мой биндер кроме инициализации объекта перестал что-либо выполнять далее. Исправление названия сняло проблему.
Так что, можно предположить, что твой случай с 'не срабатыванием' был связан с банальной оЧепяткой и особенностью парсера, который, читая твой биндер, натыкался на ссылку из другого биндера или иную некорректность.
Так что ... нам остается только опять 'методом тыка' брать свои коды и проверять - нет ли в них ошибок иль иных особенностей, некорректно распарсиваемых парсером игры, иль действительно имеется некая неучтеная нами особенность движка.
erlik: Насчет классов - значит ли это, что любой файл в котором есть самописный класс (наследующий от дефолтного) должен также автоматически подгружаться в _G, так как он тоже вызывается\сканируется движком вслед за дефолтными модулями содержащими классы?
На сейчас, я отвечаю однозначно - да, убрав 'должен'. По моим исследованиям и выводам - как только файл-модуль считывается (парсится) - все(!) его элементы попадают в буфер игры, если конечно не имею тех или иных ошибок/нюансов в кодах.
И все же напоследок добавлю и ложку дегтя:
Замечал и не раз были сообщения от игроков о том, что вдруг возникали фатальные ошибки и в логе были ссылки на отсутствие тех или иных элементов. То модели (чаще всего), то текстуры ... Хотя однозначно этот элемент был в заархивированных файлах оригинальной игры.
То, что общим для таких случаев было - недостаточная мощность компов (ограниченный объем ОЗУ), наводит на размышления о возможном затирании/освобождении неких выделенных ресурсов-буферов в областях памяти игры и к потере уже прочитанной информации. Причем разархивация именно этих элементов в геймдату - полностью исправляла ситуацию (как будто шло перечтение).
Возможно и с метатаблицами большого объема может происходить нечто подобное ... Ну да это уже чисто предполагали/погадалки высосанные почти из пальца.
erlik
Говорим о том же, но некорректные/куцие формлировки приводят к недопоняткам. Это к сожалению проблемы общения посредством только 'писанины'.
О твоем TestMessage:
Это собственно именно то, о чем мы и говорим, т.е. свой файл скрипта, лежащий в нужной папке, но не связанный ничем с другими. Меня сбивали с толку твои упоминания о содержащемся внутри классе ... и пр.
Естественно, если этот твой файл не был включен/слинкован ни в один другой, то и его кеширования не произошло. Именно о ситуации, когда из, например, диалога на подобный файл ставится ссылка на одну из функций - возможен вылет из игры.
Т.о. чтобы ошибок с подобными файлами не происходило требуется первичная его инициализация. Будет ли это префетч или предварительная проверка 'if my_scriptfile then' или даже получение листинга файлов из папки скриптов - все это приводит к кешированию твоего файла и уже любое обращение к нему и его переменным/функциям проходит без проблем.
Насчет же коллбэка:
Тоже экспериментировал в этом направлении и с эти тоже классом. И тоже столкнулся с этой же проблемой - коллбэк не вызывается. Причем есть некая завязка и на визуал. Если объекту данного класса подсунуть визуал от инвентори бока (какой-нить фейковый), то он становится прозрачным и для путь/осколков и для дальномеров. Если же дать визуал от ящика/кейса/... даже пули рикошетят, но ... хит не отрабатывается.
Пока закинул это на потом, т.к. не вижу достаточной на сейчас для игры пользы. Добиваю фикс3 для сборки и ... может потом окунусь в исследования. P.S. Что я не успел проверить, хотя это и сурогатный вариант обработки хита: попробовать из апдейта получить косвенный хит. Ведь если у объекта есть 'condition' иль даже изменение 'position'/'direction' - то это косвенный признак воздействия на объект. Можно попытаться это как-то обработать ...
ИНКВИЗИТР
~>"", и не стОит мусорить по топикам не по теме.
Люди у меня такой вопрос может у кто знает как его исправить,короче у меня на виндовс виста хочу заменить конфиги для мода,заменяю а он пишет типа нет доступа к этому файлу,а на ЗП все заменяется:-(может кто знает,заранее СПАСИБО
Artos
Окей - по поводу файлов немного стало понятнее. Спасибо за пояснения :-)
---------------------------------------------------------------------------------------------
Теперь другая тема:
Решил проблему с каллбеком на хит - объектам нужно ставить класс P_DSTRBL - хит отрабатывает как надо.
Кстати информация к размышлению - есть такой класс как O_BRKBL.
Любопытен он тем, что его объекты самоудаляются после хитования через заданное в конфиге время.
Но он почему то тоже как и O_INVBOX не имеет физической оболочки - применение к нему метода get_physics_shell() дает nil.
При этом сами объекты этого класса вполне физически осязаемы. И их весьма трудно сдвинуть с места - силой ГГ никак. У меня получилось только выстрелив из своей гравипушки - а там импульс очень сильный.
Раз у класса нет физической оболочки, то получается методы физики к нему не применишь.
Попробовал тогда поэкспериментировать на объектах класса P_DSTRBL -
Есть метод block_breaking() - я предположил что он должен блокировать разрушение объекта.
Однако эффекта получил ноль (тестил на деревянном ящике который умеет рассыпаться).
Проверка на is_breakable() дала false.
Непонятно, а на каких тогда объектах она будет давать true ?
Разработки: "Тотализатор","Kill-zone", "Mega-bomba", Mega_gravi",
"Рандомные тайники(а также декодер, мины+диалоговый аддон"), "Выбрасываемый рюкзак", "Аналоговые часики на худ"
Я так понимаю, тут арты как-то локически по классам разбиты.Вообщем, допустим мне от сюда нужны те арты, которые заражают радиацией.В таблице есть такой класс артов?ЕСли есть - как он называется?
Есть метод block_breaking() - я предположил что он должен блокировать разрушение объекта.
Однако эффекта получил ноль (тестил на деревянном ящике который умеет рассыпаться).
Проверка на is_breakable() дала false.
Непонятно, а на каких тогда объектах она будет давать true ?
А со стеклянными предметами не тестил? (банки, стаканы)
добавлено спустя 3 минут
Stalk15 Гы. Нет. Такого различия там нет. :-) Это же простая установка в конфигах. Тобишь радиацией будут заражать те, кому ты это пропишешь. А посему, создавай отдельную таблицу, вноси туда классы тех артов, которые имеют радиоактивное излучение, и по ней уже равняй.
отредактировал(а) singapur22: 01-09-2010 19:06 GMT3 час. Проект "Mobile Manager" закрыт, в связи со стечениями неблагоприятных обстоятельств, и последующей потерей всех файлов и справок текущего проекта.
singapur22 : А именно метод открытия меню: level.start_stop_menu(_mobile_changer.mobile_changer(), true)
Вот что я искал, чтобы не использовать паузу:
local dev = device()
dev:pause(true)
Спасибо.
----------------- Darien Fx, мне нужна была пауза без надписи "Пауза".
отредактировал(а) SkyLoader: 01-09-2010 19:16 GMT3 час.
singapur22
Не - на бутылках, стаканах не пробовал. Но они ведь тот же класс имеют P_DSTRBL - хотя может проверка не только по классу осуществляется. Надо будет попробовать - хотя бутылки меня как то мало интересуют.
добавлено спустя 2 минут
SkyLoader
Это нефига не пауза - а вызов своего скриптового меню\окна. Просто вызов скриптового меню блокирует доступ к худу. Игра при этом вовсе не тормозит.
отредактировал(а) erlik: 01-09-2010 19:21 GMT3 час. Разработки: "Тотализатор","Kill-zone", "Mega-bomba", Mega_gravi",
"Рандомные тайники(а также декодер, мины+диалоговый аддон"), "Выбрасываемый рюкзак", "Аналоговые часики на худ"
MRN$
Ну в принципе попробовать можно.
Я что делал - спавнил объект, фиксировал, затем расфиксировал - объект начинал пребывать в невесомости, далее давал ему импульс через apply_force() - кстати удобная штука.
Метод имеет три аргумента - три цифры. Задаем допустим apply_force(0, 2000,0) - объект поднимет немного наверх. Зададим apply_force(2000,0,0) - объект подвинет вбок. В общем можно играя цифирками задать направление движения и одновременно силу импульса. А так как объект пребывает в невесомости, то он после импульса остается там куда его подбросили и в том положении какое вышло. После чего его можно опять зафиксировать. Свое состояние объект сохраняет и после сейв\лоада.
Хотя есть еще класс class physics_joint у которого куча методов связанных с углами и направлением - но я его не тестил - так как сначала нужно найти предмет у которого есть и физическая оболочка и joint - сочленения.
Разработки: "Тотализатор","Kill-zone", "Mega-bomba", Mega_gravi",
"Рандомные тайники(а также декодер, мины+диалоговый аддон"), "Выбрасываемый рюкзак", "Аналоговые часики на худ"
Здраствуйте чуваки.
У меня после того, как наспавнил монолитовцев в одной локе вот такая вот ошибка выскакивает,когда я пробегаю мимо одного места:
Expression : fatal error
Function : CScriptEngine::lua_error
File : E:\stalker\patch_1_0004\xr_3da\xrGame\script_engine.cpp
Line : 73
Description :
Arguments : LUA error: ...ker - Зона поражения\gamedata\scripts\xr_kamp.script:672: attempt to index field '?' (a nil value)
erlik
Не ковырялся с is_breakable() и иже ... поэтому ответить нечего. MRN$
(сырая мысль)
При опытах с подобными объектами (зафиксированные ящики) менял им визуалы нет-пакетами. Особенность в том, что требуется для проявления изменений перевод объекта ->оффлайн->онлайн.
Если учесть, что каждый объект (в том числе и без физич.оболочки!) включается в себя 'cse_abstract' в который и отвечает за 'position' и 'direction', то для изменения/поворачивания остается получить доступ к этим параметрам ... Mehanik Yar
По твоему логу можно сказать только то, что в строке xr_kamp.script:672 возникла ошибка обработки таблицы. Т.к. у тебя НЕ чистая игра, а мод "Зона поражения", в котором этот файл скорее всего изменен, то ответить что-то по существу можно только имея этот мод или этот скрипт.
Если скрипт не менялся, то ... что-то связано с освобождением местечка у костерка.
Если учесть, что каждый объект (в том числе и без физич.оболочки!) включается в себя 'cse_abstract' в который и отвечает за '**50036ea8aab1bb10eeba**]cse_abstract.STATE_Write(sobj, packet)
...
...
cse_abstract.STATE_Read(sobj, packet, packet:w_tell())[/code]
Нифига не выходит. Параметры меняются, но объект их к себе не применяет.
Видимо надо, както по другому.
Проект "Mobile Manager" закрыт, в связи со стечениями неблагоприятных обстоятельств, и последующей потерей всех файлов и справок текущего проекта.
MRN$
Если твой объект можно отловить серверным биндером (типа se_item.script), т.е. если для него доступен методы se_OBJECT:STATE_Write(packet) и se_OBJECT:STATE_Read(reader, iSize) (se_OBJECT - класс для твоего объекта), то перепаковка объекта при его скриптовом спавне с изменением позиции и напраления вполне осуществима. Аналогичное, делается для лампочек в моде "Расширенная арена". Аномалии, хотя и не по направлению/позиции перепаковываются в том же АМК. singapur22 В верхнем абзаце уже упомянул где уже есть варианты доступа ко всему нет-пакету объекта.
Пока я точно знаю, что для лампочек перепаковка с изменением 'direction' работает, хотя и в оригинале мода "Расширенная арена" это заглушено и я в своей сборке не стал усложнять.
Mehanik Yar
Твоя ситуация слишком не стандартная. Судя по всему, у тебя стоит мод Зона Поражения - слишком много неизвестных изменений, соответственно и вариантов: "что это может быть". Конкретно ответить на твой вопрос - невозможно. А вот автор мода - смог-бы.
Эта тема закрыта, публикация новых сообщений недоступна.
Продолжая пользоваться сайтом, вы соглашаетесь с использованием файлов cookie. Страницы сайта могут содержать информацию, запрещенную для просмотра посетителям младше 18 лет. Авторское право на серию игр «S.T.A.L.K.E.R» и используемые в ней материалы принадлежит GSC Game World.
