*Shoker*

KoRan

Artos, KD87 Огромное спасибо за помощь С последней версией всё прекрасно работает. Никаких сдвигов (ЧН) я не заметил, все параметры отображаются корректно. Теперь попробую переделать колбек на выстрел, чтобы без кейлогера работал. RvP А твоя lua-библиотека с невырезанными функциями работает только в ТЧ? > в правой части должно везде быть по примеру Ещё можно так: if obj_sect == 'medkit' then snd = "interface\\inv_medkit" Добавлено через 7 мин.: И вообще, функцию use_object лучше так переделать, использовать таблицу:

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

Ну хотя бы потому что updcondition в твоём варианте тоже ноль возвращает Взял сейчас вариант Artos-а ( архив 11013-2, последний), поудалял везде проверку на tT.updnum_items, кроме cse_alife_item. В итоге:

KD87 Твой вариант странноват, не вылетает, но работает не верно, в upd возвращает преимущественно 0, и ещё иногда 1 в updnum_items (при вкл. гранатомёте) и 2 в updgrenade_mode когда стрельба не из гранатомёта идёт. Также у тебя не нашёл чтения tT.updph_rotation, хотя в записи он всегда записывается. Щас ещё кое что попробую, скажу потом. > Не забывай, что в игре классы чаще всего наследуют предыдущие. Оружие - инвентарный предмет (в первую очередь), вот и присущи ему параметры родительского класса. Не тут верно, но updnum_items относится ж тока к инвентарной части нет пакета оружия, зачем из за него блокировать чтение части с параметрами оружия?

Всё, теперь работает, 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, спс., щас проверю, отпишусь.

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

KD87 Спасибо за ответ Вселяешь надежду Но с чего ты определил, что ошибка именно в updnum_items=[0]? В ACDC.pl он записан как type => 'h8', но чтения h8 не нашёл, а потому остаётся только u8, который в данный момент и используется... (Всё, уже разобрался) И спасибо за подробную информацию о q8\q16, эти данные были получены с помощью IDA? И будет ли тогда критично пытаться прочитать upd:condition как u8? По идее вылета не будет, но и значение выйдет не правильное. Artos !, щас протестирую... ziStam ИЗучай конец скрипт xr_meet.script

> *Shoker*, ты полез туда, где нужны уверенные знания, а не погадалки. Метод проб и ошибок никто не отменял Попробовать всегда можно, потому и уточнил. > Параметр 'condition' для всех предметов читается как: tT.condition = oPs:r_float(). Чем тебе это не нравится или что смущает? Меня смущает наличие upd:condition, для чего он тогда нужен, и что обозначает? Собственно говоря его я вывожу лишь для того чтобы проверить корректную работу разбора UPDATE_ пакета, и только потому-что оно шло первым-вторым в свойствах upd_пакета оружия, а не чтобы получить текущее состояние оружия. Но если этот параметр обозначает не состояние оружия, то тогда почему имеет такое название, и для чего нужен? > И ты так и не отвтеил, что же в твоем пониманиее такое однобайтовые(!) параметры 'upd:condition' и 'upd:grenade_mode' и каковы же значения для них ты ожидаешь? Названия этим параметрам придумывал не я, а те, кто разбирали нет-пакеты. Ориентируясь по названиям, я ожидаю, что upd:grenade_mode вернёт мне что то, связанное с гранатомётом. Но вместо этого он каждый раз при каждом save\load (как и upd:condition) возвращает разные числа, которые изменяются случайным образом лишь при следующей загрузке, а их значения не имеют никакого смысла . Тут уже я должен задать вопрос, что из этих параметров я могу получить полезное, что мне от них ожидать, и для чего они вообще существуют? Ибо пока у меня выходит лишь бессвязный набор случайных цифр. PS: С новым скриптом ситуация аналогичная, разве что он теперь чаще просто нули возвращает в выводимых мною upd-параметрах. ^^^

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

> *Shoker*, мне непонятно, какое значение и для чего ты ожидаешь от 'updgrenade_mode' для FN? Хм, по моему ещё вчера мы обсуждали возможность отслеживать то, что у оружия в ДАННЫЙ момент включён режим гранатометания. Чего я ожидаю, ну точно не того, что сейчас выходит. Для чего читать? Определение выстрела из оружия, был ли выстрел из гранатомёта или из обычного режима. PS: Можешь выслать последнию версию m_net_packets.script? Зарание спасибо. О updgrenade_mode - http://www.amk-team.ru/forum/index.php?s=&...st&p=634928

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

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 Где я мог ошибиться?

Кстати говоря, всегда интересовало, чем UPDATE_ пакеты отличаются от STATE_ ? Я думал что вроде как UPDATE_ меняется постоянно, а STATE_ имеет стабильные значения. > неправильной трактовке и применения нет-пакетов. Значит для чтения UPDATE_ пакетов всё же нужно использовать соответствующую функцию (Get_Data_WeaponGL, Get_Data_WeaponShotgun...) ? А как примерно определить какую где, если с шотганами ясно, то что насчёт GL и прочих оставшихся? >в) Отсекать перезарядки и пр. по их коллбэкам. Я знаю колбек лишь на то, что в оружии закончились патроны, все остальные вроде надо делать кустарно.

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 и прочие...

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

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

Игра ругается на скрипт zone_mgr, на его 42 строку, в частности на переменную bounding_box, она должна содержать значение, но оно пустое. Где то не до конца совместил. Сравнивай файлы через WinMerge или ТоталКомандер. Добавлено через 38 мин.: Хотел ещё спросить, можно ли скриптово создать объект по типу "окна инвентаря", точнее ту часть, где находятся иконки предметов, и их можно перетаскивать. Возможно ли создать аналогичную вещь скриптово, и ложить туда определённые "элементы", содержащие картинку и какую то доп. информацию. Если да, то есть ли где рабочий пример?

Эх, забыл совсем... в ЗП работать не будет, т.к там вырезали функцию level.main_input_receiver(), а ею я проверяю, что не открыто никакого UI Так что её придётся как то заменить. В принципе она нужна, чтобы сделать защиту от срабатывания колбека на выстрел в момент разрядки оружия в инвенторе. Я уже делал её без использования level.main_input_receiver() (скрипт проверял, что в инвенторе новый предмет появлялся, не важно какой секции, и на 1 апдейт блочил срабатывание колбека на выстрел), там был тока глюк со сменой оружия в инвенторе, если кликнуть двойным шелчком мыши на оружие, т.к менялось оружие и патроны в нём + была нажата левая кнопка мыши, скрипт считал, что это был выстрел. Это можно предотвратить, если сравнивать ещё id текущего и предыдущего оружия, но я этим заниматься уже не буду. Так что в принципе после переделки, на ЗП работать будет тоже, просто чутка более громоздко. С ТЧ-ЧН работать должно. Сам тестировал на ЧН.

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

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

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