Скриптование

[KD87 723]

Disord, он не про то. Чтобы правильно пропарсить список текстур, нужен образец. Формат вывода level cdc я знаю, а тулзу от Xiani неизвестно, где взять. По поводу различия - level cdc еще и билды тащит, а так вроде одинаковые. Изменено 13 Июля 2011 пользователем KD87

[KD87 723]

дядяСаша, секцию спавна покажи. Только под спойлер загони.

[KD87 723]

OZ1, попробуй name и section_name сделать разными.

[KD87 723]

Ulman, что ж вы курите-то такое. story_id хранится в signed __int32, туда такое число просто не поместится. Я не берусь предсказать, во что переведет такое значение acdc.

OZ1, попробуй поставить любой story_id, желательно в промежутке 10000-65535.

Изменено 18 Июля 2011 пользователем KD87

[KD87 723]

Ulman, это называется "использовать недокументированные возможности". В один прекрасный день аукнется. Известно же уже тысячу лет, что может быть 65535 объектов - ну так в чем проблема выбрать сид в промежутке от 0 до 65535?

дядяСаша, в bind_stalker.script в колбек on_item_take() засунуть что-то вроде такого:

    if not has_alife_info("bla_bla") and
        db.actor:object("item_222") then
        db.actor:give_info_portion("bla_bla") 
    end

Ну и инфопоршень зарегистрировать в infoportions.xml

Изменено 19 Июля 2011 пользователем KD87

[KD87 723]

дядяСаша, on_use - это как бы колбек на использование. Про него - речи не было. Была речь про поднятие. Поднятие != использование . Это раз. В апдейт писать подобные проверки не проще - будет страдать быстродействие, так как апдейт вызывается постоянно (с периодом вплоть до 40 мс), колбек on_item_take() - только при поднятии предмета. Это два. Ну и, наконец, прежде, чем спрашивать, неплохо бы разобраться с предметом вопроса. Например - посмотреть, как делают разработчики в таких случаях. Ответ порвет шаблон - с помощью on_item_take() . Только саму проверку они пишут не в самом bind_stalker, а выносят в сторонние скрипты для удобства, как раз потому, что проверок много.

[KD87 723]

Kirag, мопед не мой © Я просто выдернул кусок скрипта у пысов.

malandrinus, Kirag, вы не проверяли, работает ли accuracy() из game_object?

[KD87 723]

*Shoker*, get_monster_hit_info() работает только для объектов, наследующих от CBaseMonster - а это только монстры. Если ковырять - то memory_hit_objects() - он для объектов, наследующих от CCustomMonster, то есть для сталкеров должно работать. Только это все равно не поможет. Этот метод (по крайней мере, в движке) возвращает вектор объектов MemorySpace::CHitObject, а у этих объектов нет никаких полей, которые содержат подобные данные. Да и не добраться до них.

 

Добавлено через 6 мин.:

Ulman, уже ответили, что там оружие берется с помощью active_item(). Как это может помочь-то?

Изменено 27 Июля 2011 пользователем KD87

[KD87 723]

Ulman, *Shoker*, все нормально отработает. В конце концов, никто не мешает поставить свои вызовы printf в нужных точках. Недостаток тут в другом - flush работает очень медленно, так что если переборщить с количеством printf, можно записи лога ждать очень долго. Проверено на себе.

[KD87 723]

Насколько я понимаю, дело тут не в аномалии. Каждой аномалии (кроме torrid- аномалий) соответствует некоторое количество мест спавна артефактов. Таких мест обычно 32, задается параметром artefact_spawn_count. Сами места прописаны во втором чанке all.spawn (файлик section2.bin при распаковке), в формате: x, y, z, lvid, distance. Какие места принадлежат конкретной аномалии - показывает параметр artefact_position_offset.

Камрад Капрал Хикс пишет, что он добавлял аномалии на новые локации пака SMP. Эти локации подключались к паку чистыми, без спавна, значит, фактически для них не прописаны эти самые места спавна артефактов или прописаны по минимуму (не знаю точно, как их высчитывает xrAI). При спавне новых аномалий и впоследствии рождения артефакта ему приписывается точка спавна другой локации (уверен, что Капрал Хикс не правил параметры, взяв секцию аномалии с другой локи). Гейм-вертекса в конфиге точки спавна нет, поэтому движок пытается заспавнить арт по координатам, но - незадача - на текущей локации lvid не соответствует координатам. Если у объекта, который спавнится (тут артефакт) в object_flags стоит флажок flUsedAI_Locations, то такое несоответствие приводит к вылету.

Изменено 30 Сентября 2011 пользователем KD87

[KD87 723]

*Shoker*, с аномалиями, заспавненными скриптом происходит то же самое, только места спавна артефактов берутся с первой (по порядку спавна) аномалии первой локации (по порядку вертексов). Могу ошибаться, такой вывод сделал только потому, что не нашел в движке инициализации artefact_position_offset. А вот artefact_spawn_count по умолчанию 32, как и в спавне обычно. Еще хочу заметить, что никакого рождения артефакта не будет, если в конфиге аномалии min_artefact_count = 0 и max_artefact_count = 0. Изменено 30 Сентября 2011 пользователем KD87

[KD87 723]

Real Wolf, это, видимо, assert() так работает. Перепиши abort() в _g.script, добавив туда exit().

[KD87 723]

Лёха_тц, на скрине ничего не разобрать. Что там у тебя на той строчке в ini_file? Хотя, это, скорее всего, в методе new, а значит, ты наделал синтаксических ошибок в файлах. Скажешь, что на той строчке - смогу сказать, в чем именно напортачил.

Disord, при адаптации стирай все ненулевые upd:num_items, которые найдешь. Проблема в них.

[KD87 723]

*Shoker*, это не рудимент, это неправильно распаковываешь нет-пакет. Видно же по rotation, что значения идут кривые, где-то соскочил с правильного порядка чтения (я даже скажу где - на upd:num_items).

Также по q8 - ты прав, upd:condition действительно хранится в q8. Что такое q8:

Функции r_float_qX предназначены для чтения float-значений, хранящихся с очень малой точностью.

Прообраз из движка: void NET_Packet::r_float_qX(NET_Packet *this, float *A, float min, float max)

что делает: читает один (q8) или два (q16) байта как unsigned __int8 или unsigned __int16 соответвенно, после чего значение переводится в некое подобие float следующим образом:

 

*A = (val / max_container) * (max - min)) + min; (для простоты опускаю преобразования типов)

 

Значения параметров для финалки ТЧ:

max_container - максимальное значение, помещающееся в контейнер (255 для восьмибитного, 65535 для шестадцатибитного)

max, min - минимальное и максимальное значения float, хранимого в этом контейнере:

для q8 min = -1.0, max = 1.0

для q16 min = -32.0, max = 32.0

 

r_float_q8 в движке используется для чтения кватерниона, векторов angular_velocity и linear_velocity в M_UPDATE объектов, наследующих от CSE_AlifeInventoryItem.

r_float_q16, кажется, используется только для чтения некоторых параметров ключей в anm. В старых билдах как q16 хранили еще здоровье и уровень радиации, только параметры были другими.

Изменено 13 Октября 2011 пользователем KD87

[KD87 723]

Artos, ты немножко избыточно поправил в пакетах оружия, а вот в cse_alife_item, напротив, недостаточно. Вот, попробуйте это: http://narod.ru/disk/28326681001/m_net_utils.script.html

 

Кстати, а битовый сдвиг в сталкерском lua есть?

Изменено 13 Октября 2011 пользователем KD87

[KD87 723]

*Shoker*, из того, что я написал про q8 выше, оно переводится в нормальный float так: float = (q8/255)*2 -1. Подставь свое значение, получишь как раз примерно 1. Кстати, а почему 256? Разве не должен выдавать 255, он же 8 бит читает? Изменено 13 Октября 2011 пользователем KD87

[KD87 723]

Artos, условия действуют в пределах части пакета, относящегося к текущему классу. Ты уже поставил условие в cse_alife_item, все, оружие-то его пакет наследует, а что там оружие своего добавляет, это уже пакета cse_alife_item не касается. Если подробней, оно все читается так: UPDATE_Read::CSE_AlifeInventoryItem читает свою часть, передает остаток в UPDATE_Read::CSE_AlifeItem, у его своих параметров нет, он отдает пакет дальше в UPDATE_Read::CSE_AlifeWeapon, потом в UPDATE_Read::CSE_AlifeWeaponMagazined. Каждый читает свой кусочек и дальше дает читать другим. Единственное исключение - UPDATE_Read::CSE_AlifeWeaponMagazined_W_Gl (не помню точно, как этот класс в движке называется). Он почему-то читается самым первым у оружия, а дальше вступает UPDATE_Read::CSE_AlifeInventoryItem.

 

Добавлено через 4 мин.:

*Shoker*, я, конечно, извиняюсь, но такого параметра, как rotation у оружия вовсе нет Ты может путаешь с кватернионом, так это не совсем то. Хотя, конечно, кватернион характеризует вращение. А насчет апдейт-параметров - так они у оружия почти всегда и ноль. Ну кроме, может, позиции. С чего ты взял, что неверно?

Изменено 13 Октября 2011 пользователем KD87

[KD87 723]

Artos, upd:grenade_mode читается перед апдейт-пакетом cse_alife_item. Тогда num_items будет ненулевой и все нормально прочитается.

[KD87 723]

7.9, верно, mass из cse_alife_object_physic - это не то. Это вроде как масса, определяющая обработку физ-движком, более того, ее можно получить не из нет-пакета, а просто с помощью mass() - метода CScriptGameObject. А инвентарной массы в нет-пакетах нет.

Artos, логика чтения last_spawn_time такая (во всех трех частях):

    local flag = packet:r_u8()
    if flag == 1 then
        self.last_spawn_time = utils.r_CTime(packet)
    end

Для 'se_' классов берите код из соответствующих методов se скриптов.

Изменено 15 Октября 2011 пользователем KD87

[KD87 723]

Artos, удачное решение. Но можно было просто добавить своих переменных. Смотри, например, zenobian mod - там сделан свой скриптовый класс аномальных полей (вроде на классе аномалии) и соответствующим образом поправлен acdc, чтобы при паковке добавлялись новые параметры. Вот еще одно решение