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

Kirgudu

Жители
  • Число публикаций

    1 566
  • Регистрация

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

  • Дней в топе

    23
  • AMKoin

    12,002 [Подарить AMKoin]

Kirgudu последний раз побеждал 2 Июня

Kirgudu - автор самых популярных публикаций!

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

1 077

9 подписчиков

О Kirgudu

  • День рождения 12.03.1974

Контакты

  • Сайт
    http://www.voinitsa.ru

Недавние посетители профиля

7 914 просмотров профиля
  1. Kirgudu

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

    "Справочник", функция level.remove_call.
  2. Эти функции не подходят для использования в качестве завершающих в квесте, а вот как раз для диалога они прекрасно подходят, поскольку именно в диалоге движок формирует и передаёт в вызываемую функцию параметры first_speaker и second_speaker. Соответственно, вызывать функцию chern_joe_hand_gave необходимо из диалога при нужном ответе, указав ссылку на неё в элементе <action>. Возможно, инфопорцию chern_joe_hand_gave тоже следует выдавать из диалога.
  3. Функция dialogs.relocate_item_section_from_actor, куда транслируются параметры из функции dialog_drda.chern_joe_hand_gave, требует на входе передачи первого и второго собеседников. Но указываемая в свойстве квеста <function_complete> функция вызывается совсем не с этими параметрами (ведь там нет диалога), а с такими: (task, objective), где task - идентификатор квеста, а objective - число, предположительно показывающее статус задания. Вот и выходит, что в переменную second_speaker вместо второго собеседника попадает число 1,0 (см. лог), а в переменную first_speaker - id квеста вместо ожидаемого первого собеседника. Да, и в ванильном ТЧ функций relocate_item_section_from_actor, relocate_item_section_to_actor и who_is_npc нет, ты их брал откуда-то ещё, например из ЧН (где они как раз присутствуют).
  4. Метод ненаучного тыка в действии. А всего-то надо было внимательно прочесть, что написано на своём же собственном скриншоте ошибки.
  5. Kirgudu

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

    А мне вот эта строчка очень любопытна. Можно сказать, что второй параметр в функции-коллбэке не нужен, но не это главное. Что-то я даже затрудняюсь сказать, что будет с глобальной кеширующей актора переменной db.actor, если её использовать в качестве выходного параметра. Обнулится со всеми вытекающими? Или будет создана локальная одноимённая переменная, не влияющая на глобальную, поскольку существует только внутри этой функции? В любом случае делать так не стоит.
  6. Как ни крути, а придётся согласиться и сегодня. Ведь этим способом по-прежнему можно менять предмет в слоте. А методы в "нормальных" движках - всего лишь добавленная альтернатива, но не безусловная замена.
  7. Совершенно верно. Это фикс замены визуала на дефолтный от Артоса и Шокера.
  8. Kirgudu

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

    Скорее решение наоборот. Не отсеивание ненужного с избыточными проверками "а то ли это", а адресная обработка нового параметра, который, разумеется, будет добавлен только там, где нужно. Впрочем, условия для этой "нужности" достаточно специфические, почти разовые, так что решил сделать по-другому - и ладно. @monk в Final Stroke вообще пошёл третьим путём: сократил расстояние (чтоб Левша не орал издалека) и убрал субтитры (за ненужностью, ибо лицом к лицу). Подходов может быть много, главное чтобы выбранный способ удовлетворял автора.
  9. Kirgudu

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

    Возможно. В xr_meet.init_meet(npc, ini, section, st, scheme) добавить новый параметр для идентификатора кастомного сообщения, указав в соотв. блоках как дефолтное значение "nil", так и парсинг строки из конфига. В xr_meet.action_meet_wait:execute() при ненулевом значении прочитанного выше параметра добавить вывод сообщения параллельно со звуком и с учётом его условий. Оригинальное сообщение при этом отвязать от звука, а в секцию логики [meet@1] добавить строку с новым параметром. Это, конечно, не действия только с логикой, как, вероятно, хотелось, зато универсальное решение, которым можно будет воспользоваться и в других случаях.
  10. Kirgudu

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

    @Norman Eisenherz могу предположить только одно. В той же функции check_task немного выше есть условие if self.state == "counter_attack", в котором выдаётся ровно то же самое сообщение. Раз break и отсечка по флагу не срабатывает, единственное, что приходит в голову - это что последовательно срабатывает выдача сообщений из разных частей условия, с действующей контратакой и без оной. Рекомендую расставить флаги и логирование в обеих частях и проверить. Если я прав, дальше надо будет подумать, почему сначала запускается контратака, потом (видимо) практически сразу отменяется. Могу ошибиться, но на ранних этапах работы над OGSM CS 1.8 (народный патч) что-то такое мы встречали... но в последнее время это уже не проявлялось. Точно уже не помню, давно это было.
  11. Чтобы обезопасить себя от теоретически возможных ошибок, но при этом сохранить значения таймаутов хотя бы для находящихся в онлайне торговцев, можно записать переинициализацию таблицы примерно так: --' if trade_manager[npc:id()] == nil then -- trade_manager[npc:id()] = {} -- вместо этой строки пишем нижеследующую trade_manager[npc:id()] = trade_manager[npc:id()] and { update_time = trade_manager[npc:id()].update_time, resuply_time = trade_manager[npc:id()].resuply_time } or {} --' end
  12. @SWEAW, пример приведён верно, но это, конечно, только один из возможных вариантов. Обычно, если хотят посмотреть, что происходит с переменной, то смотрят её значение (читай логируют) непосредственно до изменения и сразу после, перед сравнением (if) с другой переменной и перед любым использованием. Это если брать по максимуму. Естественно, если такое логирование будет в update функции, файл лога забьётся однотипными строками, но это не страшно. А вообще, хочешь заниматься этим - экспериментируй, мы все делаем это в той или иной степени.
  13. @SWEAW просто мало активных специалистов по ЗП осталось, вот сюда никто и не заглядывает, а кто заглядывает - мало пишет. Попробую сузить тебе задачу вдвое. trade_manager вообще не обновляет список продаваемых товаров. Всё, что он делает - это раз в какое-то время вычитывает из конфигурации текущий тип списка товаров, примерно такого вида: current_buy_supplies = supplies_generic, а потом методом npc:buy_supplies() передаёт его движку. Внутри движка и происходит взвешивание вероятностей появления того или иного объекта в продаже и составление конечного списка. Могу ошибаться, конечно, но это то, как я сейчас сумел наискосок понять написанное в менеджере торговли и других связанных с этим скриптах. И если прав, то без модификации движка смену после загрузки из сейва списка торгуемых предметов не побороть. Что же касается вывода в лог, добавь себе в _g.script в самом его конце что-то такое: local console to_log = function(fmt,...) if not console then console = get_console() end console:execute("load ~:"..string.format(fmt,...)) end -- пример записи (в любом скрипте) local st = "test" to_log("Message: %s", st) -- где %s - место подстановки значения твоей строковой (числовой, булевой) переменной Пример использования также приведён. После чего смотри, чему у тебя при торговле становятся равны всякие tt.update_time, tt.resuply_time и иже с ними и думай, почему не срабатывает то, что ты делаешь. Да, и соглашусь с @abramcumner, без логов сразу понять, что происходит, можно только в редких случаях. Поэтому прежде чем что-то под себя править, научись логировать.
  14. Эммм... "с учётом вложенных папок" пойдёт? ) Если не ошибаюсь, user.ltx сохраняется в "$app_data_root$".
  15. Первый параметр - рекурсия включена/выключена (для операций с массивом файлов, например, чтением их списка в папке), второй - уведомление (движка) об изменениях включено/выключено. Где и в каких сценариях используется второй параметр, сказать не могу, не изучал.

AMK-Team.ru

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