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

[Artos 99]

*Shoker*, не путай людей. 'аля файрболы' (в х-16) - это считай партиклы, а не какие не аномалии. Точнее, это space_restrictor'ы, для которых работает схема 'sr_particle'. От аномалий - тут только собственно партиклы. Изменено 12 Октября 2011 пользователем Artos

[Artos 99]

*Shoker*

Помня, что твоя идея была в 'износе от выстрелов', то ... вполне достаточно было бы вопользоваться:

а) В 'se_item.script' для классов оружия добавить функции чтения нет-пакетов и там брать нужные параметры с конца пакета. Учитывая, что апдейт и не част и не редок - для обсчета выстрелов этого вполне достаточно. И не требуется загружать апдейт актора.

б) Где удобно выполнять мониторинг наличия активного оружия в руках ГГ и именно это оружие (ID) мониторить в 'se_item.script'.

в) Отсекать перезарядки и пр. по их коллбэкам.

Все это в сумме и даст небольшую нагрузку на ресурсы и достаточную точность для твоего износа.

 

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

Что по твоему должен означать упомянутый тобою 'updcondition', учитывая что для всех предметов имеется 'condition'? Ведь именно второй тебе то и нужен.

 

Если ты читаешь и используешь только общие параметры для оружия - то неважно какой пакет ты читаешь Get_Data_Weapon иль иной. А вот если тебе нужны эксклюзивные для класса параметры или ты еще и изменяешь пакет - то использовать нужно ТОЛЬКО соответствующий классу объекта метод.

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

[Artos 99]

*Shoker*

По сути, нет-пакет объекта состоит из двух частей, которые считываются/записываются двумя разными методами.

Упрощенно, это две части одно таблицы, каждая из которых может читаться/изменяться своим методом по отдельности.

Разделение на STATE и UPDATE довольно условное и ясно может быть только самим разрабам.

Опять же упрощенно, STATE - это основные параметры объекта, которые он имеет в настоящий момент. UPDATE - дополнительные параметры и те которые объект должен получить/установить/достичь ... (например, на следующем апдейте). Тут очень много вариаций и нюансов.

STATE - никак НЕ стабильные значения, как ты трактуешь. Опять же условно: это те параметры статус (state) которых определен на настоящий момент.

 

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

Как определять класс? Странный вопрос для тебя ... Открой тот же 'class_registrator.script' и смотри куда какое оружие относится.

Вот это добавлено в новую версию модуля нет-пакетов:

function Get_Data_AnyWeapon(soObj,bFull) --/ серверный объект на входе
  local iCid = soObj:clsid()
  if iCid == wpn_knife_s then
    return Get_Data_Weapon(soObj,bFull) --/>
  elseif iCid == wpn_ak74_s or wpn_groza_s then
    return Get_Data_WeaponGL(soObj,bFull) --/>
  elseif iCid == wpn_shotgun_s or iCid == wpn_bm16_s or iCid == wpn_rg6_s then
    return Get_Data_WeaponShotgun(soObj,bFull) --/>
  else
    return Get_Data_WeaponMagazined(soObj,bFull) --/>
  end
end
function Set_Data_AnyWeapon(tT,soObj,bFull) --/ таблица параметров и серверный объект на входе
  local iCid = soObj:clsid()
  if iCid == wpn_knife_s then
    return Set_Data_Weapon(tT,soObj,bFull) --/>
  elseif iCid == wpn_ak74_s or wpn_groza_s then
    return Set_Data_WeaponGL(tT,soObj,bFull) --/>
  elseif iCid == wpn_shotgun_s or iCid == wpn_bm16_s or iCid == wpn_rg6_s then
    return Set_Data_WeaponShotgun(tT,soObj,bFull) --/>
  else
    return Set_Data_WeaponMagazined(tT,soObj,bFull) --/>
  end
end

 

 

Я уже тебе говорил ранее, что является критерием выстрела чтобы отсечь факт разрядки/перезарадки. Коллбэк на появление у ГГ нового патрона/пачки - это и есть не выстрел, а раз(переза)рядка.

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

[Artos 99]

Darkscape, задавая вопросы стОит все же вдумываться в то, что пишешь ...

 

1. Как спавнить объекты через all.spawn - читаем многочисленные туторы (см. ссылки в шапке).

Спавн объектов в all.spawn идет по именам, т.е. имена заспавненных объектов эксклюзивны (по крайней мере для конкретной локации). Зная имя объекта в all.spawn - по имени находишь объект в игре и удаляешь его.

Инфопоршнем ничто не удаляется, это всего лишь некая информация (порция), используемая неким образом в игре. Для удаления объектов используется один единственный всем известный метод (reliase), применяемый к удаляемому серверному объекту.

 

2. Переведи на русский ...

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

[Artos 99]

Darkscape

Во-первых, следует уточнять версию игры при подобных вопросах, реализация которых различна в ТЧ и ЧН/ЗП.

Во вторых, ... судя по твоей неосведомленности про 'reliase' 'release', вероятно ты замахиваешься на вопрос, которы пока не 'по зубам'. Может стОит пока не вот так сразу кастрировать КПК, а понемногу приблизиться к пониманию что и как?

 

Краткий ответ:

Вызов интерфейса КПК сопровождается выдачей тех или иных инфопоршней (в ТЧ - одни, в ЧН/ЗП - несколько иначе).

Отследив коллбэк на появление такого инфопоршня можно принудительно 'гасить' окно КПК и вызывать свой скрипт/функцию.

Все это довольно корявенько, т.к. мелькание окна КПК все же будет чуток заметным.

Рузумнее, как дал совет 7.9, отключить в биндере клавиш использование кнопок для КПК ...

 

Scarabay, и чем же не катит освоббождение клавиши от КПК? Тут нет кашперских, чтобы читать ваши мысли/возражения.

Ну а заюзать то можно слот бинокля, выправляя конфиги оружия под этот слот, но ИМХО это уже для садомазохистов ...

Болтовый слот врядли удастся задействовать, все же это движковая фича.

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

[Artos 99]

Darkscape, сорри, очепятался: reliase -> release, но сути моего ответа не меняет.

 

 

 

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

*Shoker*, мне непонятно, какое значение и для чего ты ожидаешь от 'updgrenade_mode' для FN?

Если у него штатный подствольник - вообще для чего читать этот параметр?

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

 

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

Scarabay, функционал по проверке патронов различным оружием и его наличие/отсутствие у НПС (иль актора) можно найти например в 'amk_offline_alife.script'. Там при продаже проверяется имеющееся оружие, наличие к нему патронов и 'беспатронное' иль 'нелучшее' - продается.

[Artos 99]

*Shoker*, держи последний:

m_net_utils_111013

Примечание: Не советую что-то менять/переставлять. Модуль достаточно автономен и универсален, чтобы работать в любом моде (при разумном использовании).

 

По остальному чуть позже отвечу ...

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

[Artos 99]

*Shoker*, ты полез туда, где нужны уверенные знания, а не погадалки.

r_u8() - это метод чтения одного байта (как есть)

r_s8() - чтения одного байта с учетом знака (число со знаком)

r_float() - чтение 4-х байт (число с плавающей точкой)

 

q8,h8, ... типы значений однобайтового числа, а не указание на используемый метод чтения/записи.

 

*Shoker*: ведь condition число как раз с плавающей запятой

Уже ранее обращал твое внимание на недопустимость перемешивать все в кучу!

Параметр 'condition' для всех предметов читается как: tT.condition = oPs:r_float(). Чем тебе это не нравится или что смущает?

 

И ты так и не ответил, что же такое в твоем понимании однобайтовые(!) параметры 'upd:condition' и 'upd:grenade_mode' и каковы же значения для них ты ожидаешь?

 

Пытаться читать вместо одного байта четыре - даже самым "правильным" методом глупо и кроме ошибок или зависание ничего не принесет.

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

[Artos 99]

*Shoker*, конечно же метод проб и ошибок никто не отменял, но ... что можно сказать о таком пробовальщике, который заведомо знает что перед ним грабли и, наступая на них, задается вопросом: "А отчего у меня на лбу каждый раз как наступаю на грабли - шишка?"

Нет-пакет объекта строго упорядоченная последовательность байт, формат(методы) чтение/запись которых строго фиксированы!

Попытка считать иным методом или иное кол-во байт - ошибка. Попытка записать иным методом или иное кол-во байт - фатальный еррор.

Хочется пробовать - никто не возражает, но не пость о своих 'шишках' сообщения в топик. Ответ всегда будет един - не наступай на грабли!

 

Конечно названия параметров о чем то говорят, но ... следует иметь ввиду что:

- их истинное значение знает только тот, кто их придумал, т.е. разработчики. Мы же можем только предполагать.

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

- давать функционально значимое наименование - правило хорошего тона в программировании, но ... и нередко лень приводит к появлению 'bla_bla_bla' и сложно выразить одно-дву-сложно функционал. Нередко в наименовании фигурирует то, что имеет некое отношение, а не конкретное определение.

- и т.д.

Так что читая, все же не возводи прочитанное в 'истину', и тем более не делай выводов о сути из названия. Нередко обертка не соответствует сути.

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

[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

[Artos 99]

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

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

m_net_utils_111013-2

 

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

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

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

[Artos 99]

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

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

[Artos 99]

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

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

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

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

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

[Artos 99]

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

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

 

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

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

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

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

[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

[Artos 99]

KD87

Вау! Оторвать бы кое-что тому, кто так извратился со структурой пакета ...

Спасибо огромадное! Все встало на свои места. Теперь осталось чуток подправить читалку нет-пакетов ...

 

P.S. Для *Shoker*-а: Проверяй с исправленным вариантом (на SHoC проверено):

m_net_utils_111014

 

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

[Artos 99]

FLUDMAN, по идее 'криминала' у тебя вроде нет, должны респавниться.

1. Убери из секции респавнера строку 'conditions = 100', она излишня.

2. Строка idle_spawn = 5,5 задает периодичность в 5,5 секунд, а не минут. Наверное стОит увеличить.

3. Самому спавнить не нужно, твой респавнер должен каждый запуск игры спавнить по две собаки и далее по тайм-ауту ... по 2 штуке ... пока их 'в живых' не будет 8 штук. Погибнут - опять доспавнит.

Если не так - оригинальный ли у тебя 'se_respawn.script' или со сторонними правками?

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

[Artos 99]

*Shoker*

Модуль нет-пакетов все же пишется не как универсальный для 'всего и вся', а в привязке и к конкретному моду и учитывая его применение с головою, а не методом тыка ...

1. Все пакеты для объектов можно получать конкртеным вызовом именно той функциии, которая предназначена для данного класса. То, что начал вводить в модуль обобщенные вызовы, которые сами по классу объекта выбирают соответствующие методы чтения/записи - это пока и а 'разработке' и предназначено в первую очередь для 'only Simbion'. Если модмейкеру не хочется каждый раз самому в кодах предварительно определять класс объекта, а хочет воспользоваться 'общим' вызовом - то и должен озаботиться портированием к 'себе' соответствующих доп.функций.

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

Так что, считаю более правильным - дана основа и некоторые бонусы. Хочешь воспользоваться бонусами - потрудись под них подстроиться.

 

2. Параметр 'updskeleton_flags' остался с давних времен и он рудиментарен. Спасибо за подсказку - вычистил.

 

3. Действительно с utils.w_CTime для ЧН/ЗП упустил сей нюанс, что может возвоащать не юзердату а нолик иль ничего. Ранее просто считывал как 'остаток' (кстати этот вариант остался и достточно раскомментировать).

Подправил сей момент под ЧН/ЗП, но пока не протестировал ... Если есть желание/полтребность - могу выложить подправленный вариант.

 

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

[Artos 99]

KD87

Логика то одинакова, но ... нюансы имеются.

а) В SHoC (ТЧ) метод utils.r_CTime(packet) всегда(!) вернет объект таймера, а вот в CS/SCoP (ЧН/ЗП) уже возвратить может и 'nil' и '0'. А вот метод utils.w_CTime(packet,oTimer) во всех версиях игры должен принять не число, а именно объект или 'nil', что упустил некоторое время назад и теперь подправил.

б) В моде Simbion, например, байт flag хранит уже не только в 1-ом бите факт наличия self.last_spawn_time, но еще и в других битах иные обнобитные значения/флаги (статус аномалии, в часности). Т.о. условие 'flag == 1' недостаточно и использовано более узкое: bit_and(flag,1) == 1, что совместимо и с исходными кодами игры. Сделал так, чтобы убрать 'мусор' из кастомдаты, что реализовано в АМК-моде.

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

[Artos 99]

KD87, вариант из Zenobian-mod конечно же смотрел в свое время и даже на каком-то этапе в сборке Симбиона присутствовали оба варианта (AMK+Zen). Однако в процессе работы над кодами принял решение идти оптимальным (на мой взгляд) путем.

Уже и сами разрабы для неписей использовали однобайтовые флаги для расширения (битовые флаги работ для сталкеров), и в том же АМК были добавлены доп. однобитовые флаги для монстров (офф/онлайна) и для сталкеров (состояние ранености).

Добавлять новые переменные и править ACDC в то время было и затруднительно и совместимость страдала ...

Выбранный вариант не зависит ни от версии ACDC, ни требует новых классов, и ресурсов сторонних (доп.байтов в пакетах) не потребляет. :-)

Это же решение позволило упаковать/разгрузить сохранки для таск-менеджера и для диалог-менеджера при сохранении совместимости с предыдущими сэйвами.

 

===

Вот, кстати в тему и топика и по следам модуля нет-пакетов, возник вопрос, который сейчас сам перепроверить не могу на ЧН/ЗП:

В utils.script (ЧН/ЗП) имеется функция 'w_CTime', в которой упоминается переменная 'CTime':

if (CTime == nil) or (t ~= CTime_0) then

- но если она (CTime) НЕ определена нигде выше/ранее - ведь и будет постоянно тождественна 'nil' и все последующие времена будут постоянно перезаписываться, т.е. до условия 't ~= CTime_0' никогда не будет доходить проверка.

Или что-то я упускаю или ... в кодах явный ляп?

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