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

[Artos 99]

*Shoker*, бред указывать некие значения из распечатки некоего непроиндексированного массива без указания 'ключ-значение'

Вот в таком виде:

Print_Table: NetP(wpn_fn20005833):
addon_flags = [0]
ammo_current = [90]
ammo_elapsed = [30]
ammo_type = [0]
condition = [1]
custom_data = [<<zero_string>>]
direct_control = [1]
distance = [0]
gvid = [61]
lvid = [41939]
object_flags = [-65]
spawn_story_id = [-1]
story_id = [-1]
visual_flags = [0]
visual_name = [weapons\fn2000\wpn_fn2000_new]
weapon_state = [0]
updaddon_flags = [0]
updammo_elapsed = [97]
updammo_type = [0]
updcondition = [0]
updcurrent_fire_mode = [0]
updnum_items = [0]
updph_angular_vel.1 = [0]
updph_angular_vel.2 = [255]
updph_angular_vel.3 = [0]
updph_linear_vel.1 = [30]
updph_linear_vel.2 = [0]
updph_linear_vel.3 = [0]
updph_position.<userdata>.x = [1060765.25]
updph_position.<userdata>.y = [-3.7059476161288e-022]
updph_position.<userdata>.z = [5.4318117588277e-037]
updph_position = [vec(x=1060765.250:y=-0.000:z=0.000)]
updph_rotation.1 = [195]
updph_rotation.2 = [0]
updph_rotation.3 = [0]
updph_rotation.4 = [255]
updweapon_flags = [0]
updweapon_state = [0]
updweapon_zoom = [0]

- хоть что-то можно и понять и далее разбираться.

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

[*Shoker* 322]

--/ cse_alife_object
local function Parse_Packet_cse_alife_object(tT,oPs)
(1.6):gvid=[135]
(1.25):distance=[0]
(1.22):direct_control=[1]
(1.4):lvid=[48111]
(0.4):object_flags=[-65]
(1.17):custom_data=[]
(1.23):story_id=[-1]
(0.6):spawn_story_id=[-1]

--/ cse_visual
local function Parse_Packet_cse_visual(tT,oPs)
(1.19):visual_name=[dynamics\weapons\wpn_fn2000\wpn_fn2000]
(0.5):visual_flags=[0]

--/ cse_alife_item
function Parse_Packet_cse_alife_item(tT,oPs,oPu)
(0.2):condition=[0.99999958276749]
(0.8):upgrade_count=[0]
(1.16):updnum_items=[0] --UPD--
(0.1):updph_position=[<userdata>] --UPD--
(1.11):upditem__unk1=[<userdata>] --UPD--
(1.8):upditem__unk2=[<userdata>] --UPD--
(0.12):updph_rotation --UPD--
(1.0):a=[3.7459390200166e-017]
(1.1):d=[0]
(1.2):c=[0]
(1.3):b=[8.6880504788139e-044]
(0.0):updph_angular_vel=[<userdata>] --UPD--
(0.7):updph_linear_vel=[<userdata>] --UPD--
(0.3):updph_unknown=[0] --UPD--

--/ cse_alife_item_weapon_magazined_w_gl 
function Parse_Packet_cse_alife_item_weapon_w_gl(tT,oPs,oPu)
(1.7):ammo_current=[90]
(1.14):ammo_elapsed=[30] 
(1.15):weapon_state=[5]
(1.5):addon_flags=[0]
(1.24):ammo_type=[0]
(0.9):item_weapon__unk1=[0]

(0.10):updgrenade_mode=[76] --UPD-- VVV
(1.13):updcondition=[82]
(0.11):updweapon_flags=[123]
(1.12):updammo_elapsed=[3]
(1.9):updaddon_flags=[0]
(1.21):updammo_type=[0]
(1.20):updweapon_state=[0]
(1.10):updweapon_zoom=[0]
(1.18):updcurrent_fire_mode=[0]
------------

 

Проверял на updweapon_state, updweapon_zoom и updcurrent_fire_mode, ни один не менялся ни при смене патронов, ни при зуме и прочем.

Тоже с остальными upd-параметрами. Начинаются боятся, что это всего-навсего GSC-овский рудимент, аля (1.7):ammo_current=[90], и грош цена этим данным

 

 

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

[KD87 718]

*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

[ziStam 1]

Уж простите за нубский вопрос, но как сделать в зп чтобы можно было со всеми нпс разговаривать? Или может какая правка есть? Буду ооочень благодарен

[Artos 99]

*Shoker*, вдогонку к сообщению KD87:

Это подправленный модуль работы с нет-пакетами:

m_net_utils_111013-2

 

По подсказке KD87 (огромное ему спасибо!), проверил 'лишний хвост' для оружия ... и подправил условие чтения.

Для оружия с подствольниками оставил закомментированной возможность проверки, что нет-пакет (UPDATE) прочитан до конца, так что можно самому перепроверить.

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

[*Shoker* 322]

KD87

Спасибо за ответ

Вселяешь надежду

 

Но с чего ты определил, что ошибка именно в updnum_items=[0]?

В ACDC.pl он записан как type => 'h8', но чтения h8 не нашёл, а потому остаётся только u8, который в данный момент и используется...

(Всё, уже разобрался)

 

И спасибо за подробную информацию о q8\q16, эти данные были получены с помощью IDA?

И будет ли тогда критично пытаться прочитать upd:condition как u8? По идее вылета не будет, но и значение выйдет не правильное.

 

 

Artos

!, щас протестирую...

 

ziStam

ИЗучай конец скрипт xr_meet.script

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

[Artos 99]

*Shoker*: аля (1.7):ammo_current=[90], и грош цена этим данным

Загляни в конфиг своего ФН'а и посмотри сам что у тебя там ... Уверен, что именно ammo_current = 90 и стоИт. Так что: что написал - то и получай. ;-)

[*Shoker* 322]

Не, ну это да, только смысл тогда в этом, по сути просто сохранённые данные из конфигов, да ещё и не имеющие особого смысла.

Кстати с новой версией возвращает nil-ы, т.к updnum_items = 0 и эти данные просто не читаются ...

Кажется я понял в чём дело, updnum_items же вроде тока к физике относится, а у тебя дальше проверка на то что он больше 0 и на параметры класса оружия\фонарика и ещё пары. Щас гляну... Да, терь что то выводится, правда щас разберусь ещё что именно, но значения меняются...

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

[Artos 99]

*Shoker*, это данных просто НЕТ, поэтому и не читаются. Чувствуешь разницу? Пакет закончился - далее 'мусор не читается (в отличии от раннего ...)'

Не, ну это да, только смысл тогда в этом, по сути просто сохранённые данные из конфигов, да ещё и не имеющие особого смысла.

Не уподобляйся мартышке из басни дедушки Крылова (про очки) ... ;-)

То, что причитано было при спавне и запомнено в нет пакет - может как раз и изменяться! Ну а имеет это особое значение иль нет - для этого нужно и знать, что это за параметр и зависимости от него, и как его использовать для некоего смысла.

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

[KD87 718]

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

 

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

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

[*Shoker* 322]

Всё, теперь работает, Artos, зачем у тебя в скрипте это:

    if oPu and tT.updnum_items > 0 then
        tT.updgrenade_mode      = oPu:r_u8() --/#+#
        tT.updcondition         = oPu:r_u8()

 

Зачем tT.updnum_items, ведь он относится к физической части объекта и к cse_alife_inventory_item

Из за этого параметры ниже чтения updnum_items стабильно возвращают nil-ы

 

После того, как я убрал проверку у них на updnum_items, стали выводится значения, и похоже корректные, по крайнем

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

 

И по поводу updconditon, это таки состояние оружия. Так при 100% состоянии оружия, оно мне вывело 256, это 2 в 8 степени.

И соответственно с уменьшением состояния оружия оно опускалось вплоть до нуля.

 

KD87, спс., щас проверю, отпишусь.

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

[KD87 718]

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

[Malandrinus 615]

KD87,

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

Нету

[Artos 99]

KD87, спасибо за информацию и правки.

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

 

*Shoker*: Зачем tT.updnum_items, ведь он относится к физической части объекта и к cse_alife_inventory_item

Не забывай, что в игре классы чаще всего наследуют предыдущие. Оружие - инвентарный предмет (в первую очередь), вот и присущи ему параметры родительского класса.

Иной вопрос, а в конкретном случае в нет-пакете зависят ли от предыдущих ппараметров последующие ... С этим предстоит поразбираться.

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

[*Shoker* 322]

KD87

Твой вариант странноват, не вылетает, но работает не верно, в upd возвращает преимущественно 0, и ещё иногда 1 в updnum_items (при вкл. гранатомёте) и 2 в updgrenade_mode когда стрельба не из гранатомёта идёт.

 

Также у тебя не нашёл чтения tT.updph_rotation, хотя в записи он всегда записывается.

Щас ещё кое что попробую, скажу потом.

 

> Не забывай, что в игре классы чаще всего наследуют предыдущие. Оружие - инвентарный предмет (в первую очередь), вот и присущи ему параметры родительского класса.

 

Не тут верно, но updnum_items относится ж тока к инвентарной части нет пакета оружия, зачем из за него блокировать чтение части с параметрами оружия?

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

[KD87 718]

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

[*Shoker* 322]

Ну хотя бы потому что updcondition в твоём варианте тоже ноль возвращает

Взял сейчас вариант Artos-а ( архив 11013-2, последний), поудалял везде проверку на tT.updnum_items, кроме cse_alife_item.

 

В итоге:

        packet.updnum_items = 0
        packet.updgrenade_mode = 0
        packet.updcondition = 255
        packet.updweapon_flags = 1
        packet.updammo_elapsed = 21 --\\ Не совсем совпадает с действительностью
        packet.updaddon_flags = 0
        packet.updammo_type = 0
        packet.updweapon_state = 5
        packet.updweapon_zoom = 0
        packet.updcurrent_fire_mode = 2

 

 

 

        packet.updnum_items = 1
        packet.updgrenade_mode = 76
        packet.updcondition = 82
        packet.updweapon_flags = 124
        packet.updammo_elapsed = 3
        packet.updaddon_flags = 0
        packet.updammo_type = 0
        packet.updweapon_state = 0
        packet.updweapon_zoom = 0
        packet.updcurrent_fire_mode = 0

 

Так что непонятки, похоже всё же при updnum_items > 0 что то не так считывается. Ежели он равен 0, то всё идёт корректно.

Но если оставить проверки Artos-а, то при обычной стрельбе всегда будет возвращать nil. А если взять твой вариант там кажется некорректно идёт,

но я завтра если что перепроверю.

 

 

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

[RvP 1]

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

есть во многих библиотеках для lua, можно подключить. Например чтото отсюда

http://lua-users.org/wiki/BitwiseOperators

[Artos 99]

KD87

Поправил различные нюансы в читалке нет-пакетов ... со всем оружием боле-менее понятно, но с оружием класса 'cse_alife_item_weapon_magazined_w_gl' - непонятки.

Проверяю на SHoC v1.0006

Заспавнил "Грозу" и считал ее нет-пакет. Параметр 'upd:num_items' оказался равным 0 и соответствено пропущены остальные 'upd' для 'cse_alife_item'. Но(!) update-пакет оказался недосчитанным на 16 байт.

Принудительно их изъял (r_u8), и вот что получил:

Print_Table: NetPacket(wpn_groza):
--/ cse_alife_object
gvid           = [61]
distance       = [0]
direct_control = [1]
lvid           = [41939]
custom_data    = [<<zero_string>>]
object_flags   = [-65]
story_id       = [-1]
spawn_story_id = [-1]
--/ cse_visual
visual_flags   = [0]
visual_name    = [weapons\groza\wpn_groza]
--/ cse_alife_item
condition      = [1]
--/ cse_alife_item_weapon
ammo_current   = [90]
ammo_elapsed   = [30]
weapon_state   = [0]
addon_flags    = [0]
ammo_type      = [0]

--/ cse_alife_item (left=27)
upd:num_items = [0]
--/ ??? (left=26) <- принудительное считывание (r_u8)
upd:chunk.01 = [195]
upd:chunk.02 = [124]
upd:chunk.03 =   [1]
upd:chunk.04 =  [83]
upd:chunk.05 = [195]
upd:chunk.06 =   [2]
upd:chunk.07 = [224]
upd:chunk.08 = [155]
upd:chunk.09 = [193]
upd:chunk.10 = [213]
upd:chunk.11 = [184]
upd:chunk.12 =  [12]
upd:chunk.13 = [195]
upd:chunk.14 =   [0]
upd:chunk.15 =   [0]
upd:chunk.16 = [255]
--/ cse_alife_item_weapon_magazined_w_gl (left=10)
upd:grenade_mode = [0]
--/ cse_alife_item_weapon (left=9)
upd:condition    = [255]
upd:weapon_flags = [0]
upd:ammo_elapsed = [30]
upd:addon_flags  = [0]
upd:ammo_type    = [0]
upd:weapon_state = [0]
upd:weapon_zoom  = [102]
--/ cse_alife_item_weapon_magazined (left=1)
upd:current_fire_mode = [0]
--/ done (left=0)

Ну ни как не возьму в тоолк, откуда взялись эти 16 байт? Чем и когда они должны считываться.

В опущеных 'upd' из 'cse_alife_item' (по причине upd:num_items = 0), по любому только 4х3 + 4 + 3 + 3 байтов, т.е. 16 можно набрать только если считывать 'upd:ph_position' (4x3) и 'upd:quaternion' (4) - но это вроде как в ACDC отсекается строкою:

return if ($_[0]->{'upd:num_items'} == 0);

да и для координат значения явно некорректны (upd:ph_position => x=556143935488.000:y=-0.000:z=0.000).

Где может быть загвоздка/недоработка?

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

[abramcumner 1 141]

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

Неверно. Для updcondition диапазон от 0.0f до 1.0f. Ну и формула соответственно q8 / 255