[SoC] Ковыряемся в файлах

[Dennis_Chikin 3 661]

Так а чей мод-то ?

[Dennis_Chikin 3 661]

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

[Dennis_Chikin 3 661]

Ну вообще-то парент есть у любого предмета. В том числе и у wpn_colt191128437. Даже если его id == 65535.

И проверяется он в куче разных мест. А также - меняется.

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

 

Искать: где находится сам предмет или его владелец в момент вылета, и кто именно что именно пытается с ними сделать. Ну или с актором.

Изменено 14 Мая 2015 пользователем Dennis_Chikin

[Dennis_Chikin 3 661]

"use = {=dialogs_SP_dist(3.0) -darklab_gromov_end} self, true"

А это вообще что должно означать, и кто это должен сделать ?

 

И вообще оно без этого-то хоть работает ?

 

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

Изменено 3 Июня 2015 пользователем Dennis_Chikin

[Dennis_Chikin 3 661]

В чем угодно.  "Настоящий покойник должен дрыгать ногами и кричать: - У-ууу !!!" © Братец Кролик.

То есть, вот буквально так.

 

 

В "оригинале" многие трупы ведут весьма бурную жизнь: актора разглядывают пристально всеми 3-мя глазами, пытаются куда-нибудь пойти, рассказывают анекдоты и т.д.

 

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

 

Но поскольку он - труп - то лежит на месте. Но его бурной жизни это не мешает. Особенно, если неписю изначально прописано много всякой логики.

 

А еще в ем могут быть всякие предметы, которые весьма активно апдейтятся.

 

Ну и, наконец, может быть особо одаренная моделька.

[Dennis_Chikin 3 661]

Для очистки совести я бы попробовал еще с другого ракурса подойти. А то был прецедент. Когда один гений графики и моделирования ухитрился на свалке всадить эффекты аж в трех местах, так, что глядя с другого конца под нужным углом, даже при полностью закрытом рельефом "эффекте", fps падал с 90-100+ до 5, да еще и карте крышу сносило в итоге так, что деревья в "шведскую стенку" размазывало.

[Dennis_Chikin 3 661]

А проще сразу вызывать удаление предмета у актора. Без указания участников.

[Dennis_Chikin 3 661]

Таки смотрим xr_camper.script - не оно ?

[Dennis_Chikin 3 661]

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

[Dennis_Chikin 3 661]

а вылеты по e_parent, e_entity вообще как-то

Первое - вроде как можно отключать безболезненно. Я затрудняюсь представить себе ситуацию, в которой может что-то поломаться.

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

 

2 _Val_: ты прекрасно знаешь, что проверять координаты ни кто не будет. Из принципа. Их не для того в олспавн запихивают, чтобы потом там еще что-то проверять.

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

Изменено 21 Июля 2015 пользователем Dennis_Chikin

[Dennis_Chikin 3 661]

alex5773, для начала, я бы отключил rx_*.script, если они используются. То есть, ВСЕ их вызовы.

Во-вторых, если вылет воспроизводится постоянно на одном и том же месте - значит искать, что где происходит при достижении этого места. Особенно - что вообще за объекты с указанными id, и что конкретно где именно пытаются с ними сделать.

 

Обычно, узнать - что это - вполне достаточно для понимания ситуации.

 

И, да, не надо больше ТАКИЕ выяснения в той теме.

[Dennis_Chikin 3 661]

Ну, я не Чип и Дейл, и даже не справочное бюро. Как нашел время - так и ответил.

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

 

Такая вот судьба у смеси чего попало с чем-нибудь еще.

[Dennis_Chikin 3 661]

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

[Dennis_Chikin 3 661]

У свежезаспавненного монстра очевидно нет ни каких эксклюзивов. Соотвественно, они ни где не запоминаются.

Изменено 2 Августа 2015 пользователем Dennis_Chikin

[Dennis_Chikin 3 661]

Онлайновые и офлайновые.

Изменено 16 Августа 2015 пользователем Dennis_Chikin

[Dennis_Chikin 3 661]

obj.m_story_id есть только у серверного объекта.

У game - :story_id()

 

Соотвественно, rank() и character_rank()

 

Ну lua_help.script же - он для кого лежит ?

[Dennis_Chikin 3 661]

а Lua я никогда толком не изучал.

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

 

И, кстати, вопрос обсуждался не так давно несколько раз: данные онлайн объектов не сохраняются.

Или руками делать запись в custom_data, или в серверный объект.

[Dennis_Chikin 3 661]

alife():create( 15228 ) - такого барахла тонким слоем по полусотне скриптов. Почему, собственно, владеющий олспавном соли - диктует всем, на каких задних цырлах на какую высоту подпрыгивать, ага.

[Dennis_Chikin 3 661]

"Я проверил все скрипты"

 

Да ну ?

amk_mod.script:

if amk.load_variable("amk_13",0)==0 then

-- pri_space_restrictor_0011

local obj = alife():story_object(830)

if obj then

alife():release(obj)

alife():create(10776)

end

ну и т.д.

 

sak.script, *_dialog.script и т.д.

Изменено 19 Августа 2015 пользователем Dennis_Chikin

[Dennis_Chikin 3 661]

Про ammo_sections:

 

Поиск дает dunin_ammo.script, repair_check.script, restriction_stock.script, rx_wmgr.script.

То есть, один файл из amk, и 3 навески на него.

Что они с ним делают ? Правильно, проверяют секцию. По тому что в class_registrator не прописан класс для ammo.

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

 

Аналогично с quest_items.

 

То есть, замена обращения к таблице на чтение из конфига - это не есть решение. Но в принципе, ни одна из этих проверок на самом деле ни в одном скрипте не нужна. И даже если у нас есть проблема с clsid(), то коль скоро в наличии имеется еще пачка скриптов, использующих таблицы зависимости патронов и оружия - строить эту таблицу при запуске (вот таки да, читая конфиг), и брать из нее.