Malandrinus

операция mad(pos, dir, dist) - это комбинация pos + dir*dist При умножении единичного вектора скорости на 5 получается вектор, длина которого 5, а направление совпадает со старым вектором скорости. Он добавляется к позиции. Это разве не то, что надо? Вот только вопрос, что будет, если скорость будет нулевая. Полагаю, это стоит проверять отдельно

вроде так, с небольшой поправкой (я там ранее сам недопонял) newpos:mad(obj:position(),obj:get_helicopter():GetCurrVelocityVec():normalize(), 5) Надо ещё было привести вектор скорости к единичному.

Не очень понятен вопрос. Есть такое значение в пакете, это вектор. При чтении из пакета читаешь: local dir = paket:r_vec3() потом при упаковке обратно записываешь, что тебе надо dir:set(<нужное мне направление>) paket:w_vec3(dir) Как-то так...

А нет там у тебя заначки с большим числом патронов? Такие фризы возникают, когда такая заначка переходит в онлайн. вроде бы так local newpos = vector() newpos:mad(pos, dir, dist) -- pos,dir - векторы, dist - может быть число и вектор, в данном случае число

А если так? device().cam_dir

Попробовал поубивать неписей kill-ом. Ствол улетает по любому. Не помню уже где это было, но просто врезался в зрительную память момент, когда непись от выстрела ГГ улетел, а на его месте возник ствол, причём выше, чем его непись держал и при этом перпендикулярно взгляду ГГ (а до этого был направлен на него, т.е. был параллелен взгляду). ЗЫ Я окончательно запутался, договорились мы или нет. Впрочем, не так уж это и важно. ragdoll физика в сталкере не настолько проработана. Кое-какой реализм обеспечивает и ладно. Стоит ли ломать копья на эту тему?

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

Я добавил level_changer, доспавнил его функцией create(<номер>) и ничего мне за это не было =) Если кому это надо, то добавлю вот что. Я делал тестовый объект на кордоне, и сначала попробовал добавить секцию в файл для кордона. Выяснил, сколько всего объектов, сделал секцию с номером, на один большим... У меня заспавнился не тот. Начал выяснять, откуда он взялся, и понял, что это последний объект из последнего уровня (ящик какой-то). Тогда я просто добавил новый объект в конец последнего уровня, и все получилось. Мораль, номер объекта из all.spawn - это просто его номер в порядке компиляции. Зачем acdc разбирает объекты по уровням, не знаю. Но на мой взгляд, после этого они перетасованы. Если каждый раз начинать игру заново, то это и без разницы. Но если мы хотим использовать пересобранный all.spawn не начиная игру заново, то видимо acdc не годится.

когда смотришь на объект, то на нём подсвечивается его имя.

Monnoroch, а объект подсвечивается, как оружие, или нет?

Monnoroch, смысл моих слов был "невозможно оставить оружие в руках неписей при том, что его там и не было" В чём я не прав?

Несколько уточнений: Файл all.spawn можно дописывать, добавляя туда дополнительные точки переходов. Вопреки распространённому мнению, новую игру при этом начинать не надо. Вроде как это метод, обратный name. Т.е. по имени точки возвращает её номер. Это такие же конструкторы, как и patrol с одним только именем пути. Просто у них ещё есть дополнительные аргументы. И, как мне думается, за само движение отвечает класс entity_action, которому передаётся объект класса move, у которого patrol - это аргумент. Короче, копать и копать ещё, но начало неплохое. Там глядишь, и разберёмся, как свои скриптовые схемы ваять.

Если честно, не понял, что именно из сказанного мной неправда.

Не знаю. У entity_action один из возможных аргументов - это object, а у него при создании указывается аргументом MonsterSpace::EObjectAction. А в этом перечислении есть fire1, fire2, reload, reload1, reload2 и т.п. Есть также у game_object метод set_item с похожим набором параметров. Но это всё похоже низкоуровневые функции, использовать их по-отдельности видимо нельзя. А как перевести непись в состояние "стрелять по кому-то" с реальной стрельбой, как следствие (а не внешней имитацией) - до сих пор не разобрался. Невозможно. Обсуждалось ещё на офф. форуме. Главная проблема, что у непися и нет никакого оружия в руках. Всё, что видно - это анимация, партиклы и пр. При смерти непися ствол просто выкидывается из инвентаря. Это даже видно, что тушка валится на землю, а рядом возникает в воздухе оружие.

И всё-таки смысл этого фактора - отношение игрового к реальному времени. Так и надо говорить. И вообще, этот фактор меняли все, кому не лень (в одном АМК несколько раз). Уж и не помнит никто, что там фактор был 10.

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

Есть проблемы при использовании SIE? Какого рода? Мне просто сложно представить, поэтому и спрашиваю. Минимальная прописка предмета в игре - это создание его секции. Для этого надо либо вписать его секцию в существующий конфиг, либо вписать новый конфиг иклюдом. Если это инвентарный предмет, то надо вписать его иконку на свободное место и соответствующим образом подправить параметры в секции предмета. Кроме этого само-собой надо добавить модели и её текстуры. Кроме того, если это предмет для покупки, надо вписать его торговцам. К балансу это имеет косвенное отношение. кроме того, если это ствол, надо вписать его в ранги оружия. Опять-же, меня интересует техническая сторона вопроса, а не баланс и пр. фигня. Что ещё забыл? Вот это всё, на мой взгляд, и есть предмет для автоматизации. Как видим, иконка здесь - не самая большая проблема. Автоматизировать только установку иконок? Хотелось бы понять, а в чём собственно проблема при использовании того-же SIE в его нынешнем виде.

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

Компиляция из чего?

SergoniuS, Слушаю предложения, какие конкретно команды обвешивать хоткеями и какими. Делать на всё подряд утомительно.

Stalker Hartman, баян =)

Это не метод, а глобальная функция в модуле _G function distance_between(obj1, obj2) return obj1:position():distance_to(obj2:position()) end

Не уверен, что блокнот всё остальное кроме той строки оставил в том же виде, как было. Он же воспринимает весь файл как текст и не факт, что при сохранении сохраняет в том же виде произвольный набор байтов. Надо использовать hex-редактор. Сгодится любой, какой найдёшь.

Я как раз закончил предварительный разбор некоторой инфы по внутренним потрохам игры. Итак. Основной источник информации - билд 2945, в котором разрабы оставили вместе с библиотеками движка ещё и файлы с отладочной информацией. Это файлы *.pdb В этих файлах содержится информация, необходимая для отладки: прототипы классов и функций, перечисления и имена локальных переменных и констант. Также в этом файле содержится привязка кода к строкам исходного текста (но не сами исходники, не надейтесь=) Я откопал утилитку, которая делает дамп всего содержимого файла pdb. Дамп для xrGame.dll вышел немаленьким - 250 Мб первостатейного мусора. Немного почистил (регулярные выражения - великая вещь) получилось 12 Мб. Выделил список экспортированных классов, выделил список всех перечислений. Теперь по крайней мере можно в этом что-то осмысленно искать. Можно точно сказать, какой тип возвращает функция или метод, что принимает, что возвращает (и возвращает ли), точный состав перечислений (тем более, что именно под этими именами они упоминаются в lua_help.script). Можно сказать, можно ли создавать в Lua свой класс на основе данного, или он для этого не предназначен. Не обольщайтесь, это конечно дополнительная информация, но в конечном итоге не намного больше, чем собственно в lua_help.script Держите в общем: Исходный дамп В архиве 3.8 Мб, распакованный 250 Мб. Море шлака. Зато это всё, что было. Очищенное от основного мусора В архиве 514 Кб, распакованный 12 Мб. Все классы и перечисления должны были остаться, удалил основной мусор, затрудняющий восприятие и поиск. Что-то могло попасть под раздачу (из-за автоматизации процесса) Только перечисления В архиве 27 Кб, распакованный 182 Кб. Ясно из названия. Включает все, а не только использованные в скриптах перечисления. Только экспортированные классы В архиве 51 Кб, распакованный 925 Кб. Попытался оставить полные определения только тех классов, которые входят в список экспортированных. Опять же, что-то могло попасть под раздачу и пропасть (см. исходный файл) Все перечисленные файлы содержат множество дублирующих записей. Это связано с тем, что в файле pdb запись включается столько раз, сколько она упоминается по коду. Пытался с этим бороться, но безуспешно. С другой стороны, больше не меньше =) Наконец, список экспортированных классов Это достаточно объективная информация. Позволяет узнать не только какие классы экспортированы, но и можно ли от класса наследовать в Lua. В двух вариантах: один содержит исходные определения luabind, а второй немного почищен для большего удобства.

Это вот такое перечисление (суть набор именованных констант) языка C++: enum MonsterSpace::EScriptMonsterMoveAction { eMA_WalkFwd, eMA_WalkBkwd, eMA_Run, eMA_Drag, eMA_Jump, eMA_Steal, }; Ему соответствуют константы, определённые в том-же классе move: move.walk_fwd move.walk_bkwd move.run_fwd move.drag move.jump move.steal Про третий аргумент знаю только, что он имеет тип float Не так. Это просто значок указателя на объект. Здесь должен заметить, что все описания из lua_help.script имеют характер неточный и до крайности условный. Они не соответствуют никакому языку, ни C++ ни Lua. Там часто упоминаются внутренние типы данных, как в примере выше, остаются хвосты от исходной структуры экспортированных классов, как с этими указателями. Зато по#ерены типы возвращаемых значений (и вообще наличие возвращаемого значения), а типы данных чисел сведены к единственному number, что лишает это описание существенной части информации. Что касается звёздочек. Сперва небольшой ликбез по Lua. В этом языке есть встроенные типы данных: nil, строки, числа, логические, таблицы, функции, потоки. Эти типы данных описаны в самом стандарте языка. Кроме этих есть ещё т.н. пользовательский тип данных. Физически этот тип данных всегда представляет собой указатель. На что он там указывает, дело второе. Выражение type(obj) для переменных пользовательского типа всегда возвращает строку "userdata". Все объекты, экспортированные из движка, как раз и представляют собой такие объекты. Безотносительно Lua, с точки зрения языка C++ объект (например vector, хотя внутри он называется не так) может передаваться в функцию по ссылке void fun(_vector3<float>&); // _vector3<float> - это как раз и есть внутреннее имя класса, который экспортирован в Lua как vector или по указателю void fun(_vector3<float>*); технически это одно и тоже, поскольку в обоих случаях передаётся адрес объекта. А сточки зрения Lua вообще нет разницы, запишете ли вы описание функции так: fun(vector*) так: fun(vector&) или так: fun(vector) Поскольку vector - это по любому пользовательский объект (указатель, помните?), и по любому в Lua передаётся как 4 байта. Так что если увидите звёздочку или амперсанд, то относитесь к этому проще.