Malandrinus

В игре вообще все пропорции искажены. Реальному километру соответствуют какие-то сотни метров. Так что это не так уж и мало. Параметры винтовок по идее тоже надо адаптировать под искажённые масштабы, ставя им убойность, скорость пули и пр. существенно меньше настоящих. Вообще реализм в игре - это настолько мутная тема, что любой разговор об этом может запросто превратиться в холивар. А что мешает фотографировать хитмарки скриншотом? Разница между точной прицела и хитмарком будет как раз тем расстоянием, на которое надо сместить линию. Только надо поставить для целей отладки рассеяние при выстреле нулевое и дрожание рук убрать. И даже из игры выходить не надо. Отходишь на нужное расстояние, стреляешь, фотографируешь в режиме прицеливания полученную отметину, отходишь дальше и т.д. switch_distance - a.k.a радиус алайфа - параметр, определяющий, на каком расстоянии от ГГ объекты переходят в онлайн. Все объекты дальше этого радиуса автоматом уходят в оффлайн. Ну и соответственно стрельнуть по ним не получится =) находится в файле alife.ltx в секции alife. По умолчанию равен 150

Daeron, Мой вопрос в том, что именно надо сделать, чтобы выполнить пристрелку конкретной сетки. В двух словах.

Думаю, ничуть не легче, чем сменить отдельный файл. Скорее всего невозможно. А в чём суть пристрелки?

Это вряд ли возможно. Хотя бы потому, что многие конфиги не представляют собой отдельных независимых файлов, а являются частью других файлов. Вот например system.ltx в ТЧ включает через все вложенные директивы #include примерно 160 других файлов, а в ЧН уже около 230. Каждый из этих файлов не грузится по отдельности, а представляет собой по-сути фрагмент одного большого мега-system.ltx. Если следовать логике разрабов, то работа производится так: берём корневой файл, разворачиваем все вложенные файлы и их вложенные файлы, получаем один большой файл конфигурации и затем единократно парсим его на предмет секций и параметров в них. Это конечно предположение, но достаточно обоснованное. Если это так, то сюда никак не вклиниться на ходу с одним изменённым файлом. Это как менять на ходу шестерёнку в двигателе.

Встречается только в методах классов. Означает "этот объект" или иными словами "объект, для которого вызван метод"

Посмотри пример в xr_motivator.script. У меня он начинается со строки 296. (версия АМК) Для онлайнового объекта (game_object) есть метод set_condition. Вроде бы им можно. Для оффлайнового можно использовать нетпакеты. Окошко вероятно можно сделать также, как это сделано для матраса. Поищи в топике или в архиве.

Есть метод hit, у него есть единственный параметр - это объект класса hit (см. LuaHelp). У класса hit кроме типа урона и импульса есть ещё и метод bone, который очевидно отвечает за часть тела.

Т.е. определить, в каком именно XML файле одной из установленных игр есть ссылка на текущий файл и в придачу в этом XML есть текстура, соответствующая текущему выделению? При том, что некоторые из XML файлов на самом деле находятся в игровых архивах? Э.. хм.. ну в принципе можно =) В принципе... Кроме шуток. Для этого надо сделать следующее: 1. Поиск всех зарегистрированных XML, в которых прописаны интерфейсные текстуры. Для этого надо ещё распарсить ltx файл конфигурации. Можно конечно вместо этого по-простому взять все файлы из каталога \gamedata\configs\ui\, но по-любому надо учесть, что некоторые из них находятся в запакованном виде в архивах. 2. Надо распарсить XML и определить, что он связан с текущим файлом текстуры, выделить в нём все фрагменты. 3. Надо связать все полученные данные с интерфейсом. Это будет собственно то, что увидит юзер: он крутит мышой, а ему подсвечивается имя фрагмента. Может и сделаю, вот только не знаю когда.

оно родимое =) серверный == оффлайновый клиентский == онлайновый я в коде обычно подчёркиваю это добавляя к имени переменной префикс 'c' - для клиентского и 's' - для серверного: cobj/sobj

Уф... давай сначала. Вот код: ObjSpawn = alife():create(...) ... ObjSpawn:id() Первая строка - это создание пользовательского игрового объекта с помощью вызова alife():create(...). create возвращает серверный объект. Это факт, хотя об этом и так можно догадаться - объект же создаётся на серверной стороне. Далее для этого объекта вызывается метод ObjSpawn:id(). Но у серверного объекта нет метода id, у него есть свойство. А к свойству нужно обращаться иначе: ObjSpawn.id

Это серверный объект, а ты пытаешься вызвать метод клиентского. Используй свойство id, а не метод id().

IQDDD, Объект серверный? Ну значит в ЧН пространство имён io экспортировали. В ТЧ этого точно не было, я спецом проверял. Это как раз и есть стандартные функции Lua для работы с файлами. Смотри справочник по Lua, как с ними работать. Кроме банальной ошибки в какой-либо букве могу предположить, что не вышел из игры перед попыткой вызвать новый скрипт.

1. Вообще говоря в стандартном Lua есть функции работы с файлами, но их наличие в конкретной реализации зависит от разработчика. Поскольку Lua фактически является частью хост-приложения, то в нём будут только те библиотеки, которые пожелает оставить разработчик. Вот в данном случае все стандартные библиотеки для работы с файлами были убраны. Если вопрос в том, есть ли способ записи в ltx файл, предоставленный в API самой игры, то походу тоже нет. 2. нетпакет - это класс движка игры, экспортированный в Lua. Каждый объект этого класса содержит буфер. Любой серверный объект можно записать в этот буфер и считать из него. Кроме того, в этом классе есть функции для последовательного разбора этого буфера. Техника работы с нетпакетом следующая: а) создаем объект класса нетпакет, вот так: local packet = net_packet() б) читаем в него состояние объекта вот так: sobj:STATE_Write(packet) в) разбираем нетпакет на части, читая последовательно все его поля в переменные Lua. Здесь требуется знать внутреннее представление нетпакета для каждого класса. acdc в руки... local game_vertex_id = packet:r_u16() local distance = packet:r_float() local direct_control = packet:r_s32() local level_vertex_id = packet:r_s32() ... и т.д. г)меняем значения полученные переменных, как нам надо, и затем записываем обратно в нетпакет в том же порядке так: res:w_u16(game_vertex_id) res:w_float(distance) res:w_s32(direct_control) ... и т.д. д) записываем нетпакет обратно в объект вот так: local size = res:w_tell() res:r_seek(0) sobj:STATE_Read(res,size) Делать всё это можно только с объектами в оффлайне. Если вдаваться в лирику, то нетпакет - это похоже часть движка, связанная с процессом синхронизации между клиентской и серверной частью. Можно предположить, что при синхронизации клиентской и серверной части объектов клиент записывает в этот самый нетпакет себя и затем посылает этот буфер на серверную сторону (потому и net-пакет). А может сервер клиенту... чёрт его знает. 3. Frect():set(0,658,83,47) - это синтаксис создания неименованного объекта пользовательского типа, экспортированного в Lua. В данном случае Frect. Это класс для хранения координат прямоугольника. Сразу после создания для объекта вызывается его метод set, который устанавливает его значения.

Прошу только по первости смотреть внимательней, всё ли работает как надо. Фишка всё-таки весьма свежая. Если точнее я убрал курсор при выделении и при вставке. Точно помню, что при вставке он закрывал часть иконки и это слегка раздражало. При выделении может и в самом деле зря убрал. Ну, вернуть не проблема. При таскании мышью скорость перемещения картинки не совпадала со скоростью мыши и как-то дёргалась она. Сейчас ездит, как приклеенная к мыши. Вот я думаю. Если за цитату предыдущего поста пистон вставляют, то за цитату последующего... Да это ж как минимум пожизненный эцих с гвоздями =)

Похоже на проблему из предыдущего сообщения. Только в связи с переездом на студию 2008 требуется RunTime library не 2005, а соответственно 2008. линк здесь Пытался установить на виртуальную машину (поскольку реальных машин у меня без этих библиотек просто нет). Столкнулся со следующей ситуацией для Win2000. Для установки пакета с библиотеками нужна не просто винда с сервис паком 4, но и кумулятивное обновление 1 для сервис пака 4. Живёт здесь. Для XP таких проблем быть вроде не должно. Под висту вообще не знаю что будет...

Новая версия 0.6.0 альфа. Ссылки в шапке. Из новшеств: 1. Поддержка DXT1. Теперь поддерживаются DDS(DXT1/3/5/ARGB/ABGR)+PNG. Как и раньше, только полноцветные и только однослойные. 2. Конвертация форматов (через экспорт) 3. В редакторе аддонов можно сбрасывать отдельные выбранные ранее аддоны. 4. Настройка стиля линий сеток. 5. Undo/Redu вплоть до последнего сохранения 6. Парная к "увеличить в два раза" операция "уменьшить в два раза" 7. линия выделения сделана толщиной в один пиксель, курсор на время выделения скрывается 8. Переработан и дополнен диалог настроек 9. Задействовал статусную строку: информация из заголовка (выделение и пр.) теперь показывается внизу, там же текущий формат файла. В заголовке вместо этого - полный путь до текущего файла. 10. Можно прервать операцию вставки кнопкой ESC 11. В связи с использованием нового контрола для управлением страницами кнопка "закрыть текущую закладку" убрана. На текущей закладке есть свой персональный крестик. В меню команда осталась. 12. Запрос на сохранение изменений при закрытии закладки и программы 13. Статус изменённости показывается звёздочкой 14. Исправил баг с перемещением картинки мышью. Странно, что никто не отрапортовал об этом ранее. 15. Всякие мелочи, коих не упомнишь 16. Новые баги.

Ты хотел сказать "кратны степени двойки"? ну не суть... Сгодится Paint.NET Вообще говоря для пакованных текстур (DXT1,3,5) крайне желательно иметь размеры как минимум кратными четырём, поскольку это размер блока данных (4х4). Если размеры не кратны четырём, то реально создаётся картинка с кратной стороной, но часть пикселей не используется. Эта ситуация заложена в формат текстуры, но не всегда корректно обрабатывается произвольно взятым софтом. Кроме того, если подразумевается генерация mipmap уровней, то ещё стороны должны быть кратными степеням двойки (дабы их можно было делить пополам вплоть до размера 1). А зачем надо создавать такую хитрую текстуру? Всегда же можно при её использовании указать её часть. Их так собственно и используют - "кусочно".

На мой взгляд, было бы интереснее напротив - заставить бежать от фонарика. Или от света вообще, в том числе от костра. В этом случае батарейки (которые могут закончиться) приобретают новый животрепещущий смысл =) Или можно было бы сделать пару красивых миссий, когда надо защититься от толпы ночных монстров. Ну, допустим, сопроводить туристов, застаёт ночь (проматываем время). Надо разжечь костёр и отстреливаться от толпы кровососов.

Думаю, что в этом-то и главная проблема. Анимация завязана на скелет, а он у Сидора наверняка несовместим с человеческим. Думаю, что Сидора сделали монстром, чтобы научить сидеть на стуле. Сталкеры похоже сильно завязаны на логику перемещения и не могут никак взаимодействовать с окружением (в том числе и сложно научить их сидеть на чём-либо). Вот кстати, забавная картинка. Ну не монстр ли?

Нескромно напомню о своей программе "STALKER Icon Editor". Можно не только определять координаты, но и редактировать некоторые иконки. Живёт в этой ветке Добавлено через 11 мин.: Рассуждая логически расчёт попадания в сферу требует вычисления трёх разниц, трёх квадратов и корня. А попадание в параллелепипед требует просто шести сравнений (т.е. по сути вычитаний). Чисто вычислительно по идее второе будет быстрее. Но опять же попадание в сферу можно оптимизировать, если заранее вычислить и хранить квадрат радиуса (корень не нужен). С другой стороны всё это такие копейки с учётом скорости современных FPU.

Есть такая функция level.map_add_object_spot_ser(se_obj.id, map_spot_name, desc) В этой функции аргумент map_spot_name - это значок, как раз и описанный в этом файле (и включённых в него директивами #include). Структура файла XML мне видится довольно очевидной. Например, значок для задания по защите лагеря имеет имя "defend_lager_location" сначала идет эта часть. Здесь упоминаются собственно описатели значков для карты и миникарты ("defend_lager_spot" и "defend_lager_spot_mini") а также по всей видимости вид курсора при наведении на эти значки "quest_pointer". <defend_lager_location> <level_map spot="defend_lager_spot" pointer="quest_pointer"/> <mini_map spot="defend_lager_spot_mini" pointer="quest_pointer"/> </defend_lager_location> далее по отдельности описываются сами значки: для карты <defend_lager_spot x="0" y="0" width="32" height="32" stretch="1" alignment="c" xform_anim="map_spot_new_xform" xform_anim_cyclic="0"> <texture>ui_mapQuest_camp_defend</texture> </defend_lager_spot> В теге defend_lager_spot очевидно указаны видимые размеры текстуры и (возможно) точка привязки к значку. В данном случае в разделе <texture>...</texture> указана уже готовая именованная текстура ui_mapQuest_camp_defend. Она описана в файле ui_common.xml для миникарты <defend_lager_spot_mini x="0" y="0" width="11" height="11" stretch="1" alignment="c" xform_anim="map_spot_new_xform" xform_anim_cyclic="0"> <texture>ui_sm_mapQuest_camp_defend</texture> <texture_below r="0" g="255" b="0">ui_mini_sn_spot_below</texture_below> <texture_above r="0" g="255" b="0">ui_mini_sn_spot_above</texture_above> </defend_lager_spot_mini> Что здесь означают параметры texture_below и texture_above не знаю. Кроме указания именованной текстуры можно и прямо здесь описать текстуру прямой ссылкой на файл текстуры и координатами фрагмента. Так сделано например для значка anomaly_zone_mini_spot. <anomaly_zone_mini_spot x="0" y="0" width="16" height="16" alignment="c" stretch="1"> <texture x="1" y="202" width="31" height="30" r="255" g="100" b="100">ui\ui_mp_icon_kill</texture> </anomaly_zone_mini_spot> Здесь идёт ссылка на файл gamedata\textures\ui\ui_mp_icon_kill.dds . Из неё берётся фрагмент с координатами (1, 202) и размерами (31, 30)

С таким именем не нашёл. В этом каталоге есть другая act_stalker_corp.dds. вот она Есть вообще-то замечательный распаковщик, автор которого Don Reba, который позволяет распаковывать выбранные файлы по одному Лежит здесь называется Database Extractor 2.0

Так всё таки есть ID =) Я собственно поискал таким образом объекты и не нашел ни кроватей ни матрасов. Может модели и сохранились в архивах, но скорее всего как физические объекты они были вырезаны и остались только как элементы декора. Детектировать их вряд ли получится. Проще явно расставить рестрикторы там, где визуально лежат матрасы, и потом на них ориентироваться. Хотя я конечно могу и ошибаться.

А как можно перебрать такие объекты?

Могу ещё добавить, что на возможность убрать предмет в онлайн/оффлайн влияют функции can_switch_offline и can_switch_online, которые являются методами всех классов, унаследованных от cse_alife_object. Эти методы можно перегрузить, что и сделано для некоторых классов (в частности для сталкеров и монстров). Если эти функции возвращают false, то соответствующее действие не получится.