Перейти к контенту

IG-2007

Проверенные
  • Число публикаций

    19
  • Регистрация

  • Последнее посещение

  • AMKoin

    0 [Подарить AMKoin]

Баланс оценок

0

1 подписчик

  1. frags Мне нравиться, что вы сделали этот мод. Такая система рангов очень интересна, просто исходная реализация немного хромает, да ещё NLC добавляет ряд проблем. Вот я и написал об этом... Извиняюсь, я не знал что есть какие-то особые КПК. Значит другой 'косяк' будет, квестовые КПК вроде как и не КПК получаются и в статистике не участвуют. Вроде в NLC есть квест на N-дцать КПК неужели они все квестовые? ID ровно 16 бит, причём 0 и FFFF (-1) зарезервированы. Дело в том, что арт не помещается в контейнер, а удаляется. В контейнер прописывается информация о том, что там лежит такой-то арт. При выкладывании арта из контейнера осуществляется спавн нового артефакта, id при этом уже другой. С артефактами возможно вылезет и более неприятная вещь, связанная с повторным использованием ID уже удалённых артов для вновь создаваемых.
  2. Ну, для КПК можно переделать удаление на запоминание айдишников, как у артов. Правда чем дальше играть, тем больше вероятность вылета из-за переполнения актёрского хранилища переменных. Кстати, автор может переделать функции сохранения и загрузки массивов этих айдишников с 32 бит на 16, уменьшев этим расход памяти в два раза. Что касается контейнера, то тут сложней. Можно попытаться написать скрипт, который будет удалять id и единичку из статистики артов при помещении их в контейнер.
  3. Adrenalin Пару рангов начинаются не с 0: 1) денежный ранг зависит от колличество денег у ГГ, 2) ещё один ранг зависит от игрового ранга Ещё можно сразу получить артефактный ранг, если в инвентаре есть три и более артов. Этот мод плохо совместим с NLC: 1) мод удаляет найденные КПК, 2) статистику артефактов можно увеличить поместив арт в контейнер и достав его от туда.
  4. IG-2007

    ARENA EXTENSION MOD ver. 0.3.2 for AMK 1.4.1

    max71 Сколько тестил на полной динамике в оригинале почти никогда не тормозила, только иногда в момент спавна участников боя. kwendy Это появляется в логе при удалении после боя трупов с арены, игра при этом вроде не вылетает и не портится.
  5. IG-2007

    AI pack FINAL

    Если ничего не путаю... В соответствии костюму неписю прописывается visual. visual - это строка, которая содержит путь к файлу модели. Найдите этот файл, откройте его чем-нибудь (например, FAR-ом). Увидите абра-кадабру, но это нормально, т.к. файл бинарный. Теперь пролистайте содержимое файла к концу, там увидите (если увидите) текстовы строки, одна из которых - это название ltx-файла с резистами. Из этого файла будут соответствующие ссылки, в том числе и на immunities.ltx.
  6. IG-2007

    Banderos_add_for_AMK_MOD

    local sobj = alife():object("имя_объекта_нужного_рестрикта_из_all.spawn") alife():release(sobj, true) Примерно так... Самый простой способ - уберите их. Это именные смарты с единственной работой, посторонние npc сюда попадать не должны, только те, у кого прописаны данные смарты. Накой эти предикаты здесь вообще нужны - не понятно. Второй вариант, меняйте функцию предиката, например так: function wt_predicate_g(npc_info, gulag) -- guard if string.find(npc_info.name, gulag.name) ~= nil then return true elseif <своё_условие> then return true end return false end PS: замучили меня совсем... попробую всё сделать сам, как будет результат отпишусь.
  7. IG-2007

    Banderos_add_for_AMK_MOD

    Всё вроде правильно. Рестрикт, если уж очень мешает, можно удалить скриптом (release) В именах должна быть ещё цифорка после watchtower. А как вы собрались присваивать им имена? Насколько мне известно этого уже через net_packet-ы от АМК не сделать. Сделать такое можно только через all.spawn или изврат с перепаковкой cse_abstract. Хотя в вашем случае будет достаточно сменить название секции спавна, т.к. полностью задавать имя не требуется. Идея рестриктор "пускает" в области вышек только неписей с определённым именем не правильная. Рестрикт пускает тех у кого он прописан. Прописывается он тем, кто назначается на работу часовых в гулаге. В гулаг попадают только те, кто в кастом дате имеет соответствующую запись со смартом и прошёл проверку предикатов (если вы её оставили), а вот проверку может пройти только тот чьи имена содержат val_watchtowerN. Вывод такой: если хотите использовать гулаг, то либо вы настраиваете персонажей под текущие предикаты, либо настраиваете предикаты как вам удобно. Если спавн снайперов будет разовый, то можно сделать ещё так. Пропишите родным снайперам в кастом дату в секцию [spawn] (точно уже не помню, может в какую другую) условие спавна. Например, наличие некого инфопоршина. Снайперы будут созданы при старте игры, но сидеть в офлайне до той поры пока этот инфопоршин не появится. А появиться он должен в тот момент, когда вы сочтёте нужным, например, после некого диалога. Так себе вариант: (1) требует начала новой игры, (2) возможно, точно не знаю, что АМК офлайн-алайф их укокошит...
  8. IG-2007

    Banderos_add_for_AMK_MOD

    Предикты - это имена функций, сами функции определены парой строчек выше в том же файле скрипта gulag_dark_valley. -- Predicates ------------------------------------------------------------ function wt_predicate_g(npc_info, gulag) -- guard return string.find(npc_info.name, gulag.name) ~= nil end function wt_predicate_s(npc_info, gulag) -- sniper return string.find(npc_info.name, gulag.name) ~= nil and npc_info.is_sniper == true end npc_info - это структура, заполняется в файле "se_smart_terrain.script" в функции se_smart_terrain:fill_npc_info Вот, набросал то, что знаю про гулаги. Всё ИМХО, 100% правильность не гарантирую. Гулаги - это только часть несколько большей темы. Желательно, для начала, взглянуть на всё это в общих чартах. Распределение живности по Зоне. Первое, что делается, выбирается место, где должна обитать живность. В этом месте создаётся smart_terrein - это специальный объект игры. Потом создаётся гулаг (это уже не объект, а скрипты и ltx), в котором для каждой живой души прописывается, что она должна делать в разных ситуациях: сидеть у костра, стоять в дозоре, прятаться под кустом, штурмовать базу и т.д. Затем создаётся сама живность. Тут возможны варианты: либо разовый спавн через all.spawn, либо респавнер, либо и то и другое. Все регулярные скопления живностей (стаи, стоянки сталкеров, заставы) работают по этому принципу. Некоторые скопления могут появляться или пропадать по мере развития сюжета, делается это добавлением специальной строки в кастам дату smart_terrein-а, в которой содержиться условие его существования (наличие или отсутствие сюжетных инфопоршинов). Как правило включение и отключение терейнов производится синхронно с респавнерами, которые генерят подходящих терейну персонажей. Ещё одна особенность использования терейнов заключается в том, что подходящий ему персонаж, где бы он ни был, будет движком игры переведён в нужное место. Т.е. это такой движковый метод перевода персонажей как внутри одной локации, так и между локациями. Причём перемещение будет производиться как в онлайне, так и в офлайне. После того как персонаж дойдет до своего терейна, движок его оставляет в покое, теперь им начинают управлять скрипты гулага, соответственно только в онлайне. Теперь о гулагах. Гулаги используются в игре повсеместно, как для регулярных скоплений живности, так и для разовых скриптовых сцен. Когда существо зачисляется в гулаг, ему назначается некая работа. Работа - это текстовая последовательность секций, каждая секция служит для задания схемы поверения. Принцип такой же, как и при прописывании последовательности напрямую в кастом дату существа. Отличие, помоему, лишь в задание путей. Если в прямой записи название пути читается схемами как есть, то в случае гулага к названию пути прибавляется название гулага. Более конкретную информацию по различным схемам и их настройкам можно посмотреть в оффициальном документе: Настройка логики (часть 1) Там же есть немного и о гулагах. Помимо задания последовательности, при назначении работ работнику могут быть добавлены особые способности: рестрикты, не переводимость в офлайн... Эти способности задаются в параметрах работы. Есть в гулагах возможность синхронного перевода работников с одной работы на другую. Для этого используется статус гулага и в параметрах работ указывается для каких статусов она подходит. Используя такой механизм, можно сделать смену активности в зависимости от времени суток (день/ночь), можно сделать зависимость от численности (рейды, как только все участники прибывают в гулаг) и т.д. Гулаги бывают двух видов: обычные (general) и... не обычные. Обычные гулаги сделать проще, т.к. создание списка работ происходит автоматически по заданному в "gulag_general.script" шаблону. Чтобы такой гулаг заработал достаточно сделать терейн, указать для него тип general_lager (для людей) или general_lair (для мутантов). После этого нужно в all.spawn прописать несколько путей с предопределёнными именами: gname.."_kamp_"..1, gname.."_kamp_"..2, ... - если нужно, что бы были посиделки, gname.."_sleep_"..1, gname.."_sleep_"..2, ... - если нужно, что бы были спящие, и т.д. (полный список можно составить анализируя "gulag_general.script") gname - это название гулага (или терейна) Нужно ещё прописать предусловия для приёма в такой гулаг, это делается в файле misc\general_lager.ltx или misc\general_lair.ltx. В качестве предусловий выступает ранг персонажей. Группировка тоже является предусловием, но задаётся она в настройках терейна, там же задаётся и максимальная вместимость. Необычные гулаги используются везде, где шаблонных возможностей недостаточно. Например, требуются более сложные работы, проигрывание анимаций, дополнительные условия для приёма и т.д. Для таких гулагов создаётся терейн с типом, отличным от обычного. После этого нужно внести необходимые изменения в скрипт гулагов для нужного уровня или можно добавить свой. Например, для Темной Долины изменения нужно делать в скрипте gulag_dark_valley.script. Все работы прописываются вручную, есть возможность прописать работы непосредственно в скрипте или прописать в ltx и подгрузить из него. PS: banderos, извиняюсь что так много и не совсем в тему.
  9. IG-2007

    Banderos_add_for_AMK_MOD

    predicate - это просто функция, которая участвует в проверке и распределении работ гулага для приходящих в него неписей. Назначение вроде можно примерно понять по вызовам функций и комментариям разработчиков (xr_gulag.script + smart_terrain.script). Основная задача отправлять конкретных неписей на конкретные работы. Кстати, мысля появилась пока писАл ответ. Не перепутают ли снайперы, если совсем убрать predicate, свои вышки? Возможно этот predicate придётся оставить, но немного переделать...
  10. IG-2007

    Banderos_add_for_AMK_MOD

    banderos Отпишусь тут. Вроде всё как надо. Вот только аналогичный снайпер в all.spawn имеет такие параметры: name = val_watchtower1_bandit_sniper position = -49.6784553527832,11.208517074585,8.38117504119873 game_vertex_id = 819 level_vertex_id = 116044 хотя, это не очень важно, если позиция не та, то дойдёт ножками до нужной. Можно не убирать. Работа для снайперов не назначится как с этой строкой, так и без неё. При добавлении этой работы, проверяется наличие путей для снайперов в all.spawn, а путей этих там нет. Пути прописаны только для первой работы - для часовых. Точно не знаю, но думаю, что начинать новую игру не надо. Да, правда тут возможна некоторая путаница, т.к. я не доконца понимаю весь этот механизм: у npc два поля для рестриктов base_out_restrictors и base_in_restrictors (?рестрикты, внитри/снаружи которых можно ходить?), может нужно было прописать название рестрикта в другое поле? Рестрикты в данном случае - это область пространства, ограничевающая перемещение. Зачем это нужно? точно не знаю, может для того, чтобы случайные неписи не ходили в этом месте. Вот один из рестриктов, для первой вышки: [2303] ; cse_abstract properties section_name = space_restrictor name = val_watchtower1_restr position = -49.0167427062988,7.3995189666748,8.30681037902832 direction = 0,0,0 ; cse_alife_object properties game_vertex_id = 811 distance = 0 level_vertex_id = 316473 object_flags = 0xffffff3e ; cse_shape properties shapes = shape0 shape0:type = box shape0:axis_x = 5.8149995803833,0,0 shape0:axis_y = 0,16.1853523254395,0 shape0:axis_z = 0,0,5.8149995803833 shape0:offset = 0,0,0 ; cse_alife_space_restrictor properties restrictor_type = 2 Собственно - это некий box, который закрывает собой всю или почти всю вышку. Npc, у которого нет разрешения ходить в этом рестрикте, не сможет подняться на вышку. Похоже у вас это и происходит. Прописать рестрикт npc можно: 1) в all.spawn. Помоему, так делается для тех неписей, у которых нет терейна. Например, военные часовые на вышках Агропрома. [1455] ... name = agr_tower3_soldier ... custom_data = <<END ... [smart_terrains] none=true END ... [b]base_out_restrictors = agr_space_restrictor_tower3[/b] 2) можно попробывать сделать через net_packet, если нет клиентского объекта (то что я предлагал) 3) в работах гулага. Так делается много где, например, для ваших снайперов: -- добавляем должность t = { section = "logic@" .. idstr, idle = 0, prior = 1, state = {0}, squad = squad, group = groups[1], position_threshold = 10, in_rest = "", [b]out_rest = gname .. "_restr"[/b] } table.insert(sj, t) 4) если есть клиентский объект, то можно вызвать функцию npc:add_restrictions(in_restr, out_restr). Таким способом kstn в ArenaExtensionMod привязывал неписей и монстров к арене. Только вот отловить момент появления нужного клиентского объекта бывает проблематично. Либо нужно переписывать функцию net_spawn для нужного binder-а, либо делать свой binder. Есть ещё такая особенность, глобальные схемы поведение, вроде реакции на выброс, первым делом отключают неписям все идиотские ограничения (комментарий Red75), т.е. прописанные для них рестрикты. Восстанавливаются ли эти рестрикты потом - не знаю, но раз вы говорите, что снайперы на Агропроме возвращаются на вышки, то наверное восстанавливаются.
  11. IG-2007

    Мысли ...

    Бывают моменты, при которых структуры (колличество) данных net_packet-а для одного и того же объекта могут различаться. Помню сделал функцию для парсинга - всё работало с вновь создоваемым объектом, но стоило воткнуть её в движковый вызов при загрузке уровня - начались глюки. Возможно какие-то другие конфликты. А как проверяли то, сравнивали с acdc, раскомментаривали логи тейлов? Любые: партиклы, модели, all.spawn... Я не знаю точно, как они все обрабатываются, думаю вы тоже. Значит исключаем. Напишу подробней, что нашёл в том сейве: 1) сейв был битый изначально. Проявлялось это в том, что после его загрузки нельзя было выгрузить уровень, происходил вылет в винду с ошибкой функции memmove из Си-шной библиотеки msvcrt71.dll. Но, не смотря на это, всё игралось и тестилось. 2) вылеты происходили из-за того, что в bind_monster.hit_callback self.object становился равен nil 3) вылеты происходили с 100% вероятностью при уничтожении плотей только из огнемёта 4) при отключении партиклов горения, вылеты не происходили (100% вероятность) 5) сделал печать в лог self.object из hit_callback и увидел следующее: каждому второму вылету, предшествовало порчение self.object уже в предыдущих колбеках. Иногда object менял свой тип с объекта на структуру, иногда оставался объектом, но терял функцию name(), иногда не терял, но name() возвращала nil или явный мусор - длинные или короткие строки из повторяющихся символов или вообще не буквы и цифры, а прочие символы таблицы. 6) сделал вывод: порчение памяти, а не просто переопределение скриптом self.object 7) в скриптах партиклов копался, но ничего криминального не нашёл
  12. IG-2007

    Мысли ...

    Перефразирую: возможно, что чем больше разных объектов в локации, тем больше шансов словить такую ситуацию. Некоторые 'памятиёмкие' вещи могут не являтся причиной вылета, я лишь работать катализатором. У меня, например, огнемёт (партиклы горения на монстрах) весьма способствовал вылетам.
  13. IG-2007

    Мысли ...

    Скачивал несколько сейвов, на которых якобы вылазят ошибки (bind_monster и xr_kamp). Почти нигде ошибок у меня так и не вылезло. Но один сейв (милитари, штук 15 плотей, 3 кобанчика, 1 гигант) всё таки дал вылет с bind_monster. Пару дней пытался найти ошибку, но... Очень похоже, что портится память, в которой расположены данные игры. В результате вылет происходит далеко не сразу, а лишь при обращении к этой порченной памяти, да и то если порча оказалась критичной. Если после порченния данных удастся сделать сейв, то и сейв становится испорченным. Пожалуй это самая неприятная ошибка, что могла закрасться в код. Думаю, что большая часть странных ошибок, которые упоминались в ныне закрытой теме, это просто различные эффекты этой порчи памяти. Что является причиной - не знаю. Сам по себе язык LUA на такое вроде не способен. Могу лишь предположить варианты, проверить которые весьма не просто: 1) Ошибка где-то при работе с net_packet. 2) Ошибка где-то в структуре одного из бинарных файлов мода. 3) Ошибка в каком-то конфиге, задающем параметры для работы движка. 4) Что-то ещё

AMK-Team.ru

×
×
  • Создать...