Malandrinus

Удалось заставить выполняться функцию alife_simulator:kill_entity(npc, gvid, sheduled) здесь npc - это сталкер или монстр, которого надо прикончить в оффлайне, gvid - вроде как геймвертекс, куда ляжет тушка, sheduled - по идее должно быть аномалией, которая по идее что-то должна спавнить по факту смерти в ней непися, но этот аргумент я не проверял и его можно игнорировать. Ранее всегда при выполнении был вылет. Удалось выяснить, что там стоит проверка на непустой инвентарь. Почему-то вылетает, если в инвентаре непися что-то есть. Если перед убиением перебрать шмотки и удалить все объекты, у которых parent_id равен id непися, то вылета нет и непись исправно подыхает. На самом деле особенного практического смысла в этой функции нет, поскольку методов прикончить непися в оффлайне хватает, и фактически они даже лучше работают, чем этот. Просто было непонятно, что этот метод делает и почему виснет. Между прочим, это фактически единственный сохранившийся метод из родной системы оффлайновой боёвки. Музейный экспонат, так сказать =)

FANAT, Погляди в corrections_list.txt

FANAT, Давно уже есть эта правка для ТЧ.

Artos, ок, давай обобщим, чтобы была польза от обсуждения. вариант с _G[<имя модуля>][<имя функции>] достоинства: быстрый, годится для частых вызовов недостатки: 1. Требует парсинга исходной строки для разбиения ее на имя модуля / имя функции. 2. Ограничивает общий вид строки с полным адресом функции. Грубо говоря, количество точек должно быть фиксированное. Более точно, строка должна иметь предсказуемый формат для парсинга. вариант с loadstring достоинства: 1. Простой. Код для вызова элементарен 2. Нет ограничения на вид строки с именем вызываемой функции. Это даже может быть что-то нетривиальное, лишь бы было кодом Lua. недостатки: Затратный с точки зрения времени выполнения. loadstring компилирует вспомогательную функцию, что естественно требует затрат. Во многих случаях это не критично, как в упомянутых таймерах. Там это используется для разового действия создания таймера. Частично недостаток можно скомпенсировать, сохранив вспомогательную функцию.

Artos, все же вариант Real Wolf более общий и гибкий. Примерно так у меня было сделано в моей реализации сохраняемых таймеров. local f, msg = loadstring("return "..timer_class.."(...)" local timer = f() timer_class - это строка с именем класса (функции создания) таймера, которая сохраняется и потом загружается заново. Так я избежал необходимости делить строку на части, т.е. об этом можно вообще не думать. Полный текст приводил в этом посте.

Говорилось много раз. Рендер не заменить, проще игру с нуля переписать.

Fan fan, на скрине вылет, а говоришь, что вылетов нет и всё нормально.

Обновил плагины для Total Commander для распаковки игровых архивов. плагин файловой системы (для распаковки всей игры) архиваторный плагин (для отдельных архивов) Архиваторный плагин по-сути не изменился, но добавил x64 версию (для x64 версии Total Commander). Вдруг кому-то пригодится. Основные изменения в плагине файловой системы: 1. Изменена логика поиска и определения приоритетов загрузки архивов для ЧН и ЗП. Теперь это происходит на основе парсинга fsgame.ltx и почти следует алгоритму движка. 2. Добавлено автоопределение английской/русской версии для ТЧ 3. Можно добавлять кастомные установки игр в добавок к тем, что установлены штатно и прописаны в реестре. Для этого их надо прописать в файле настройки. Там в readme всё это написано. 4. Также есть версия x64.

А кстати, хороший вопрос, а зачем вообще нужно "округление с оставлением N знаков после запятой" ? Если для вывода, типа выведутся только имеющиеся знаки, то, как совершенно верно заметил abramcumner, это не прокатит. Округляем мы в десятичной системе, в двоичной число может оказаться периодическим и при выводе мы получим совсем не то, что хотели. Для этого конечно нужно использовать format. А зачем может потребоваться округлить не до конца именно с целью получить новое значение? Мы в итоге получаем некое нецелое число, которому сложно найти практическое применение. Так что лучше сделать функцию попроще, которая безо всяких степеней и умножений будет округлять к целому.

cj ayho, Если бы math.floor работал как "оставить целую часть", то действительно бы не работало для отрицательных чисел. Но эта функция приводит к меньшему целому, т.е. всегда работает на уменьшение независимо от знака. Таким образом, метода с добавлением 0.5 работает корректно для всего диапазона чисел. Добавлено через 149 мин.: Lua почти ничего не добавляет к стандартным функциям СИ, а по части математики набор стандартных СИ-шных функций мягко говоря непоследователен. Вот, к примеру, отсутствие человеческой функции округления. Я СИ занялся не сразу, а после паскаля, фортрана, бейсика и т.п. Довольно скоро потребовалось выполнить округление. Во всех нормальных языках либо число с плавающей запятой само округляется при приведении, либо есть человеческая функция с названием типа round. Но не в СИ. Ну вот тоже сидел тогда и тупил, а как это сделать =)

Artos, Ох и тяжелый у тебя характер =) Сразу в лоб: "детский вопрос". Совсем не детский! На стандартные движковые значения завязаны много стандартных же движковых вещей. К примеру часть интерфейса инвентаря, окна диалогов, торговли. Можно конечно завести свои скриптовые значения со смыслом "имя", "описание" и т.п., но в этих движковых диалогах так просто будет не подменить. Выходов из этого есть потенциально несколько, как минимум два. Первый, на самом деле завести чисто свои скриптовые значения. В диалогах придется закрывать поля с движковыми значениями своими окошками со своими строками. Выгода - это чисто скриптовый способ. Недостаток - хлопотная реализация с потенциальными проблемами стабильности работы. Кроме того, если поразмыслить, то это не везде сработает. К примеру, как отследить, что в инвентаре выбран некий предмет, чтобы установить его описание? Второй способ, заменять движковые значения. Штатных средств для этого нет, поэтому это можно делать только модификацией движка. Мы говорим в основном о значениях системного имени, описания предмета, имени персонажа. Все это скриптами доступно только на чтение. Для записи нужно добавлять функции для записи, иногда также в серверный объект. Кроме того, описание с объектом не сохраняется, а каждый раз читается из секции. Поэтому, кроме функции записи, для описания потребуется также некоторая скриптовая обвязка, которая сохраняет это значение в нетпакете объекта и при загрузке прописывает его заново. Достоинства этого пути - это вполне реально и не очень сложно. Недостаток, требуются модификации движка со всеми вытекающими.

подправил http://rghost.net/36172916 в комплекте несколько недостающих текстур и шейдеры из комплекта OGSE 0692. Это то, что нужно для партиклов. Партиклы исходно сделал amik, он и шейдеры в них настраивал. Я в них потом подкрутил только некоторые параметры, но в целом я в партиклах не разбираюсь, поэтому вопросы, как их адаптировать под совсем чистую игру - не ко мне. Обращаю внимание на косяк в файле bind_stalker ещё с оригинала. В конце нестандартные комментарии, после них код не распознаётся. Добавлено через 33 мин.: Вот ещё вспомнил, зачем там используется изменённая xrgame.dll. Там из объекта получается его матрица трансформации с помощью чтения числа по смещению от адреса. Это особенно важно для объектов, которые повёрнуты от исходного положения, а таких может быть немало. Без этой функции я не знаю, как получить этот поворот. Может и можно чистыми скриптами, но разбираться по любому лениво. Добавлено через 7 мин.: Ещё, чтобы не пугались. Инструмент может вызывать спонтанные вылеты с рендером. У меня это происходит нечасто, но бывало. У кого-то может из-за этого не заработать вовсе. Проблема может быть в партиклах, и я решить её не в состоянии, поскольку в партиклах не разбираюсь. Также инструмент замечен в утечках памяти. Это означает, что при слишком долгой работе могут быть вылеты из-за перерасхода каких-либо ресурсов. Я в этом проблемы не вижу, инструмент внутренний - не для игроков, а для разработчиков. Перезапустить игру разрабу несложно. Исправлять я это тоже не буду. Если заглянете внутрь, то думаю поймёте меня. С другой стороны, если инструмент не вызывать, то и проблем он не вызывает. Т.е. его простое присутствие в вашей игре ни на чём не скажется.

*Shoker*, Там ещё пара функций для работы с векторами/матрицами. В частности умножения вектора на матрицу. Можно конечно скриптами имитировать, но это отдельный геморрой. Сяк, В фале _g.script local fs = getFS() function check_module(module_name) local script_name = fs:update_path("$game_scripts$", module_name..".script") local res, err = loadfile(script_name) if res then log1("module: '"..script_name.."' is correct") else log1("module: "..script_name.."\nerror: "..err) end return res, err end Именовал вручную, мог и ошибиться. К сожалению, сделано исходно под мою сборку OGSE, и я уже сам не помню, что от чего зависит. Мог и ещё что-то забыть, так что придётся так постепенно с вашей помощью делать адаптацию под чистую игру. Кстати, менеджер сигналов там в общем-то не сильно и нужен. При желании можно прописать все вызовы прямо из биндера актора. Их там всего четыре штуки кажется. Была идея для интерактивного режима сделать отдельное окошко с кнопками операций вращения/размеров/смещения, но на это уже сил не хватило.

Шапку обновил. Новая ссылка с добавленными парой полезных для адаптации файлов. Новое видео с примером работы с составным шейпом. Также дано краткое описание работы.

ruslan.barc, на этот счет есть целая тема расчет повреждений

Zones Editor ссылка Предназначен для показа формы различных игровых объектов-зон, имеющих шейп: аномалий, рестрикторов, респавнеров, переходов, лестниц и др. Позволяет смотреть объекты, имеющие сложные составные шейпы, состоящие из набора сфер и произвольно ориентированных боксов. Позволяет редактировать форму шейпов, добавлять и удалять отдельные элементарные шейпы (сферы и боксы). Особая благодарность amik-у за неоценимую помощь с партиклами! Версия игры ТЧ 1.0006 Для работы нужна последняя версия xrGame.dll из проекта X-Ray extensions. Пропатченного файла в проекте нет и не будет, но со страницы скачивания проекта можно взять комплект для патча. Партиклы прилагаются в разобранном виде, только то, что нужно для работы утилиты. Для адаптации можно использовать petool, брать здесь. В комплекте также прилагается версия библиотеки для работы с нетпакетами за авторством xStream (файл xs_netpk_545.script). Не пытайтесь её обновлять! Последняя версия не годится, надо использовать именно ту старую, что идёт в архиве.

Andrey07071977, lua_open вроде как устарела и вместо неё используется lua_newstate. Её я и имел в виду. Ссылки на неё встречаются. По-моему, там описывается ситуация, не имеющая прямого отношения к делу: "каждому потоку С нужен свой Lua-стейт, а стейт можно создать либо с помощью lua_open (и при этом не будет доступа к данным остальных стейтов), либо создать дочерний стейт, создав поток Lua с помощью lua_newthread (нужно использовать мьютексы для исключения конфликтов, но данные будут общими)". В любом случае lua_open не создаёт поток Lua, а только создаёт стейт. Давай рассуждать логически. При разных вызовах глобальные данные остаются доступными, значит, согласно этой же цитате, это не первый вариант с lua_open (точнее с lua_newstate). Т.е. стейт в общем один. С другой стороны, вызовов lua_newthread нет, значит это и не второй вариант =) Так что xStream права, и никаких coroutines там нет, если только сам их не сделаешь. Что интересно, из этой же цитаты следует, что и потоков С/С++, которые общаются с Lua, в движке всего один, иначе бы как раз и потребовались либо новые стейты либо потоки Lua, а ни того ни другого, как мы выяснили, нет. Это вполне согласуется с моими наблюдениями, поскольку никаких особенных мер по межпотоковой синхронизации я вблизи вызовов Lua из движка не наблюдал. Это потому, что особенно нечего синхронизировать, вся игровая логика обсчитывается строго в один поток. Может быть что-то, связанное с физикой или рендером и требует синхронизации, но там я глубоко не копался.

zoidberg123456789, IDA Pro - это лютый варез, никто здесь не поможет и ссылки тебе здесь не дадут. А в шапке упоминалась только бесплатная и никакая не про версия. её и сейчас можно скачать здесь

Andrey07071977 Можно и так сказать, хотя под менеджером обычно разумеют нечто более сложное. Ты имеешь в виду lua_newstate? Встречается, но это ни о чём не говорит. Ведь хотя бы один стейт надо создать по-любому. нет там в движке coroutines, говорю же. При вызове Lua из СИ выделяется отдельный стек безо всяких новых потоков. Это в документации Lua написано. Потом, создание стейта и создание потока Lua - это две не связанные вещи. Стек у потока отдельный, это да, а стейт уже должен быть создан и может быть и существующий (и скорее всего существующий, видны же все переменные). И насчёт "менеджера". Что ты называешь менеджером? Поток Lua - это вообще-то простая как валенок сущность. Грубо говоря, это просто функция, которая может в любой момент сказать себе остановить своё выполнение и которую можно после этого с этой же точки продолжить. Менеджер чем-то управляет, а здесь нет ничего, кроме того, что сам же и напишешь, так что называть это менеджером как-то язык не поворачивается.

xStream, Я помню, о чём тема. Я ведь её и создал =) Просто в данном случае в этом обсуждении реально нет никакого практического смысла. Движок на эту тему не изменить. Ну почему не падает, я могу и так сказать, и в общем и говорил. Происходит исключение С++, движок это исключение ловит и ничего по этому поводу не делает. Поскольку исключение именно С++, то его соответственно не ловит Lua. Потому и вылета нет с руганью на ошибку Lua. Когда происходит ошибка времени выполнения Lua вылет происходит вполне нормально с сообщением в логе. Это если эту ошибку Lua не поймать в свою очередь с помощью pcall, но это уже другой разговор. Для меня здесь непонятным остаётся только, почему прекращаются дальнейшие вызовы, т.е. что именно там после этой ситуации ломается. Но это "что именно" может быть как уровня Lua, так и уровня luabind, так и уровня движка, у которого вокруг luabind накручено ещё своего кода.

Чтобы не было неясности, я естественно не имел в виду потоки Windows. update: Однако, там на самом деле нет никаких Lua-потоков. Если бы были, то встречались бы вызовы lua_newthread, а ни одного нет. Всего лишь при вызове колбека ему выделяется отдельный стек, который остаётся неразмотанным после сбоя. debug.traceback же просто показывает все стеки: текущий, потоков (если бы они были) и до кучи всех повисших вызовов. Вот если честно, то с практической точки зрения совершенно не интересно, что и как там виснет. С практической точки зрения важно только то, что данный вызов после сбоя перестаёт вызываться. Что касается потоков Lua, то вряд ли им есть какое-то разумное применение в данном случае. Разве что кому-то зачем-то придёт в голову написать свой менеджер кооперативной многозадачности. Но какие задачи в скриптинге под сталкер можно решать с его помощью? В общем, бесполезная вещь.

Тем не менее, если посмотреть с помощью debug.traceback на дамп потоков после подвисания колбека, то видно, что подвисший колбек видно как отдельную нить Lua. И по косвенным данным это видно, поскольку у отдельных колбеков контекст свой, что говорит, что они работают в отдельных нитях Lua. Признаться, я эту механику понимаю не до конца, но не вижу ничего невозможного в том, что отдельный вызов Lua запускается в отдельно создаваемом для него потоке Lua.

Andrey07071977, происходит исключение, его ловит движок, но по каким-то причинам решает не вылетать. Из-за аварийного завершения нить Lua, в которой работал вызов, остается в аварийном состоянии и больше не срабатывает. Как-то так, думаю.

Andrey07071977, Потому что Lua строго однопоточный и движок игры в общем тоже однопоточный, по крайней мере игровая логика вся работает в один поток. Пока не закончится один вызов, другой не начнется, даже если пришло его время. Это в общем-то легко проверить. Поставь в Lua бесконечный цикл - это подвесит всю игру.

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