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

[*Shoker* 322]

> Возможно ли как-то отследить этот самый арт или аномалию скриптово?

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

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

Откуда то вызови раз такое:

 

    for i=1, 65535 do
        local sobj = alife():object(i)
        if sobj and sobj:name() ==  "af_gravi22016" then
            level.map_add_object_spot_ser(i, "red_location", sobj:name())
        end
    end

 

И тогда тот глючный артефакт выделится на карте красной меткой, и тебе останется лишь удалить\перенести породившую его аномалию в другое место, чтобы избежать подобных глюков. Ну или вообще отключи у новых аномалий в конфиге спавн артефактов, вроде как такой метод я видел в ОГСМ на ТЧ, где дин. аномалии без артефактов ( а я ещё гадал для чего это было сделано )

 

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

 

По идее (могу ошибаться) если у объекта неправильный вертекс (Invalid vertex for object ), то такая функция obj.level_vertex_id (для клиентского онлаин объекта) или sobj.m_level_vertex_id (для серверного) будет возвращать число 65XXX (забываю последние цифры всегда) В данном случае думаю можно поставить проверку в скрипты, в которых находятся колбеки, вызываемые в момент перехода объекта в онлайн и там проверять это значение, и в случае если оно равно 65XXX, то удалять\делать с ним что то ещё. По поводу точного значения 65xxx спроси у кого нибудь.

 

Но вообще самый правильный вариант - это зарание предотвращать такие ситуации.

 

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

[*Shoker* 322]

Да, про ID я как то не подумал, но насчёт удаления вроде всё верно сказал. Сам на ЧН сталкивался с такой ошибкой, когда арт был заспавнен за границей, вылета не будет пока артефакт не попадёт в онлайн. Если аномалия уже зародила артефакт и он пока в оффлаине (игрок далеко от него), то тогда есть шанс его удалить, иначе же если арт зарождается сразу рядом с игроком, то тут конечно ...

В моём случае арт уже был, тут тоже если арт уже есть (был заспавнен аномалией в оффлаине) и имя кривого артефакта при save\load стабильно, значит вполне...

 

И спасибо, что напомнил о том, что случайное имя объекта строится из секция + ID

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

[*Shoker* 322]

KD87

А что происходит с аномалиями, заспавнеными скриптами? Я честно всегда думал, что артефакты рэндомно из центра аномалии падают.

 

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

Кто нибудь может подсказать самый простой способ сделать такое - есть НПС, надо, чтобы когда ГГ атаковал его, тот удалялся и заменялся на кого то. Всё бы ничего, но тут же по идее проблема - в момент хита, если рядом будут другие нпс той же группировки, они станут враждебные для ГГ, так вот - как проще всего сделать так, чтобы не портилась репутация при атаке такого НПС игроком?

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

[*Shoker* 322]

Здоровье можно поменять через db.actor.health но тут такая загвоздка

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

Допустим здоровье игрока 0.2 процента, ты пишешь db.actor.health = 0.5 но здоровье ГГ становится 0.2 + 0.5 = 0.7

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

[*Shoker* 322]

Верно, причём проверку что меньше\больше 0\1 делать не надо.

Игра сама всё сделает.

Также не забывай что при смерти объекта, здоровье ставится -1

Кстати это работает со всеми остальными объектами.

 

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

Можете рассказать, какие ньюансы есть с удалением аномалий через release() во время игры?

Мне надо создавать и удалять через некоторое время аномалии. Раньше у меня из за простого удаления часто ломались сохранения. Игра ЧН, аномалии в рестрикторы для НПС не добавляю.

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

[*Shoker* 322]

PavelSnork

Пока без понятия. Как в начале игры не знаю, но во время самой игры все параметры работают прекрасно.

Говорю с уверенностью, т.к сам с этим параметром последние дни работал

[*Shoker* 322]

ХЕМУЛЬ36RUS

До ЗП, у игры небыло колбека на использование вещи (self.object:set_callback(callback.use_object, nil))

Твоя функция просто не вызывается. Все модеры в ТЧ/ЧН используют колбек на потерю предмета из инвентаря и проверяют, что он был удалён (какбэ использован) Думаю в солянке его стоит искать в amk.script

 

Tris

power

Всё остальное можешь глянуть в скрипте lua_help.script

 

 

 

[*Shoker* 322]

Во первых - откуда тут знают что ты изменял в коде?

Во вторых - удалять надо не болт а то что приводит к его появлению. Помимо болта там гитар и прочего нету случаем?

[*Shoker* 322]

speczadanie

Ты лучше расскажи, что ты сделал такого, отчего у тебя стал спавнится болт. А колбек на юзанье персонажа в игре есть, в xr_motivator.script, это

function motivator_binder:use_callback(obj, who)

Как раз там можешь вставить удаление болтов из трупа в момент юзанья трупа игроком, также можно ещё через death_manager.script это сделать, но это лишь в случаи что болт спавнится ещё когда НПС жив а не в момент его смерти.

 

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

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

[*Shoker* 322]

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

 

Функция могла не сработать по двум причинам:

1) Ты сам её отключил каким то образом.

2) И что более вероятно - у тебя в каком то из скриптов происходит ошибка, из за которой игра не вылетает но "ломается", может перестать идти апдейт, или выборочно что то перестанет работать. Это плохой глюк, т.к причину придётся искать в своих последних действиях, после которого случился этот глюк.

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

В дальнейшем велика вероятность порчи сохранений и прочего.

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

[*Shoker* 322]

Кто может подсказать где можно взять готовый алгоритм, определяющий выстрел из оружия? Ведь наверняка такой имеется.

Суть в том, что надо определить, что из оружия сделали выстрел. В частности нужно отследить каждый выстрел из автомата.

 

У меня сейчас идея - отслеживать кол-во патронов в магазине, но тут остаётся проблема с тем, что надо отследить момент ручной разрядки оружия. Когда патронов много, это можно сделать, сравнивая сколько было патронов в предидущем выстреле и сколько в этом, тоесть допустим если в выстреле 1 было 27 патронов, а в "выстреле" 2 их уже 0, значит сделали разрядку оружия. Но тут возникает затык, когда патрон остаётся всего 1 и игрок делает разрядку, т.к отследить, вручную ли был разряжен магазин или игрок сделал выстрел я пока не представляю как, кроме как одновременно следить ещё за кол-ом патронов в рюкзаке.

[*Shoker* 322]

Artos

Спасибо! Колбек и впрям ведь вызываться должен.

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

[*Shoker* 322]

Игра ругается на скрипт zone_mgr, на его 42 строку, в частности на переменную bounding_box, она должна содержать значение, но оно пустое.

Где то не до конца совместил. Сравнивай файлы через WinMerge или ТоталКомандер.

 

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

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

Возможно ли создать аналогичную вещь скриптово, и ложить туда определённые "элементы", содержащие картинку и какую то доп. информацию.

Если да, то есть ли где рабочий пример?

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

[*Shoker* 322]

XЕМУЛЬ36RUS

Way используют только двигающиеся аномалии, аля файрболы, которые летают по указанному пути. (Такой есть в ТЧ, в х-16, и их много в ЗП)

[*Shoker* 322]

Artos

В ЗП это именно аномалии (ZS_TORRD, zone_fireball), да и в ТЧ ж ведь они тоже наносят урон (там класс Z_TORRID).

В СДК для ЗП для этого класса даже отдельная строка под указание пути.

 

Ну и чтобы не захломлять "Справочник"

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

Указать read - позицию? В принципе верно, приму на заметку, хотя существенного падения скорости я не заметил.

 

> Параметр 'updgrenade_mode', о котором ты срашиваешь, никуда не делся с 2008 года

Я вызывал с разбором UPDATE_ пакета, но этот параметр возвращал nil

UPDATE_ пакет точно разбирался, но например когда я пытался вывести updcondition, он выводил мне стабильно число 102, а после ломки ствола и save\load - 32 ... так что я не уверен, что в моём случае этот пакет был разобран правильно.

 

И ещё, я для ВСЕГО оружия использую функцию по разбору нет пакета Get_Data_Weapon, тоесть и для дробовиков, и для автоматов. Корректно ли это, ведь я заметил у тебя ещё Get_Data_WeaponGL, Get_Data_WeaponShotgun и прочие...

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

[*Shoker* 322]

Кстати говоря, всегда интересовало, чем UPDATE_ пакеты отличаются от STATE_ ?

Я думал что вроде как UPDATE_ меняется постоянно, а STATE_ имеет стабильные значения.

 

> неправильной трактовке и применения нет-пакетов.

Значит для чтения UPDATE_ пакетов всё же нужно использовать соответствующую функцию (Get_Data_WeaponGL, Get_Data_WeaponShotgun...) ?

А как примерно определить какую где, если с шотганами ясно, то что насчёт GL и прочих оставшихся?

 

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

Я знаю колбек лишь на то, что в оружии закончились патроны, все остальные вроде надо делать кустарно.

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

[*Shoker* 322]

Artos

Я видимо не до конца разобрался в чтении UPDATE_ пакетов.

Тестировал на FN2000 в ЧН, класс WP_GROZA, это ("CWeaponGroza", "se_item.se_weapon_magazined_w_gl", "WP_GROZA", "wpn_groza_s")

 

Разбирал пакет так - local p = sm_net_utils.Get_Data_WeaponGL(sobj, true)

 

В итоге:

* p.updgrenade_mode = 238

* p.updcondition = 226

 

Где я мог ошибиться?

[*Shoker* 322]

Scarabay

> можно через скрипт "разбиндить" кнопку открытия ПДА?

Можно, с помощью работы скриптово с консолью, сделать в скриптах вызов такого get_console():execute("unbind active_jobs"), и тогда кнопка PDA будет сброшена. Только учти, что люди, после удаления твоего мода, должны будут вручную занаво установить кнопку открытия ПДА в опциях.

 

ЗЫ: active_jobs - для ЧН, если не работает в ЗП/ТЧ то возможно там по другому называется действие, но маловероятно.

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

[*Shoker* 322]

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

Хм, по моему ещё вчера мы обсуждали возможность отслеживать то, что у оружия в ДАННЫЙ момент включён режим гранатометания.

Чего я ожидаю, ну точно не того, что сейчас выходит.

Для чего читать? Определение выстрела из оружия, был ли выстрел из гранатомёта или из обычного режима.

 

PS: Можешь выслать последнию версию m_net_packets.script?

Зарание спасибо.

 

О updgrenade_mode - http://www.amk-team.ru/forum/index.php?s=&...st&p=634928

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

[*Shoker* 322]

Artos, или любой, кто может ответить:

Хотел ещё кое что уточнить по разбору нет-пакета, вот у тебя в разборе пакета оружия есть такое:

 

    if oPu then
        tT.updgrenade_mode      = oPu:r_u8() --/#+#
        tT.updcondition         = [b]oPu:r_u8()[/b]
                ...

 

Но в ACDC для ЧН:

use constant upd_properties_info => (
    { name => 'upd:condition',    type => '[b]q8[/b]' },        # 0xec
    { name => 'upd:weapon_flags',    type => 'u8' },        # 0x190 (0x1b0)
       ....
);

 

Под q8 я нашёл:

    function w_float_q8(number, number, number);
    function r_float_q8(number&, number, number);

 

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

Но при замене на tT.updcondition = oPu:r_float_q8()

Биндер игрока виснет. Судя по lua_help туда надо передавать и принимать больше параметров (3 number)

Но я сам не могу разобраться.

 

Может это как то влияет на неправильный разбор upd-пакета?

 

 

За скрипт спасибо, проверю с ним, возможно это я что то напортачил.

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