Kirgudu

@Norman Eisenherz, news_manager.send_tip(act, table.concat(pk_dump, "\n")) И кстати, это опять изобретение велосипеда повторение уже имеющегося инструмента. В m_netpk есть функция pk:dumpDesc(), как раз предназначенная для вывода всех свойств нет-пакета. Почему бы не использовать её?

@abramcumner, я пробовал сегодня - см. выше. Не сработало. Делал, ессно, как надо: с добавкой в биндере и колбэком.

Вероятно, это действительно так. Я поэкспериментировал по-своему - с разными частями нет-пакета (включая абстрактную), со спавном и без, с выбрасыванием из инвентаря и без, с переключениями онлайн-оффлайн и без - тот же результат. Признаться, я рассчитывал на другое. Судя по всему, классические способы тут не помогут, либо что-то проходит мимо внимания.

local file = io.open() / file:write() / file:close() - для ЧН/ЗП. Для ТЧ я такого способа не знаю. В любом случае сохранение на лету скорее всего не даст автоматического подключения к ресурсам, а сохранение с целью последующего чтения при запуске игры равносильно формированию нужного конфига заранее. Но соглашусь с @Zander_driver. Совершенно непонятны цели данных усилий. Если для самообразования - это похвально, вот только начинать (и продолжать) тогда нужно с того, что страницей раньше написал @dsh: чтения этой и соседних (справочник, общие вопросы) тем от начала и до конца. В противном случае лучше таки обратить своё внимание на доработанные движки или модули Артоса. Ведь они и вправду "из коробки" обеспечат то, что ты пытаешься сделать.

@Zander_driver, не всем можется и, главное, хочется ковыряться в движке. @Norman Eisenherz, функция create_ini_file создаёт объект в памяти, к которому можно применять все методы этого класса, такие как ini:line_count(), ini:r_bool() и др. Но это не значит, что этот объект автоматически подключён в качестве игрового ресурса аналогично инклюдам в system.ltx.

@Norman Eisenherz, Что я сделал? Взял готовый модуль из https://www.amk-team.ru/forum/topic/13216-sborochnyy-ceh/?do=findComment&comment=971137, пробежал глазами скрипт на предмет того, где именно в нет-пакете лежат флаги фонарика согласно его классу - up_props, значит в update части нет-пакета, вспомнил по приложенной инструкции, как именно читать только update часть, и как в результатах она будет называться, накидал базовый скрипт для чтения текущего флага и сравнения его с флагом включения. Естественно, ещё и модуль подключить надо, но на это есть исчерпывающие сведения в посте по вышеприведённой ссылке, как инструкция Артоса, так и дополнения к ней. На всё потребовалось не больше 10 минут. Куда меньше, чем глубокое изучение трёх с половиной килострок кода. Не изобретай велосипед - его уже вылизали со всех сторон за эти годы.

Во! Я ж чувствовал, что есть что-то значительно проще, только не получилось вспомнить. Ну и ладно, зато поупражнялся.

@Norman Eisenherz, коллбэк on_trade(item, sell_mode, cost) вызывается для каждого предмета перед тем, как он передан новому владельцу. При этом сначала пачкой обрабатываются все предметы, которые актор продаёт (при наличии), а затем все предметы, которые актор покупает. Направление передачи предмета отображается при срабатывании коллбэка в параметре sell_mode так: sell_mode = true - предмет у актора, parent_id предмета равен id актора, после коллбэка передаётся НПС. sell_mode = false - предмет у НПС, parent_id предмета равен id НПС, после коллбэка передаётся актору. Таким образом, если есть хотя бы один покупаемый у НПС предмет, id НПС определить достаточно просто: берём item, когда sell_mode = false, его item:parent() будет равен id НПС. Но что делать, если покупаемых предметов в этот раз нет, а есть только продаваемые? На момент продажи их владелец - актор, и он нам не подходит. Вот тут как раз может прийти на помощь обсуждавшийся выше метод level.add_callback. А именно: запоминаем в какой-нибудь переменной сам предмет (item), устанавливаем признак того, что надо проверить предмет попозже, запускаем коллбэк, при срабатывании которого во время следующего апдейта опять же возьмём id родителя, которым будет уже не актор, а НПС. Примерно так: Разумеется, это лишь набросок, который надо доводить до ума. Как соединить всё это в единое, универсальное и для покупки, и для продажи, и для того и другого одновременно - это поле для самостоятельных исследований. Ну и не исключаю, конечно, что есть гораздо более простой вариант решения.

@Winsor, всё так. До сих пор ни разу не пытался копаться в движке, однако в данном случае самому стало интересно. Скачал и развернул у себя проект версии 1.0006, немного поискал. Собственно, тут всё видно. Ну а для скриптёра резюме будет простым: можно сколько угодно использовать level.add_call(f1,f2) в скриптах без необходимости принудительно удалять коллбэки, лишь бы функция f1 рано или поздно вернула true.

И всё-таки позволю себе усомниться в данном утверждении. Проведём маленький эксперимент: Ремарка: эксперимент проведён в ЧН, так как у меня нет сейчас установленных Теней. Может быть, конечно, разрабы что-то доработали во второй части, не исключаю. В противном случае либо метод remove_call не является обязательным для прерывания действия коллбэка, либо неявно вызывается где-то в движке после запуска второй функции.

@Norman Eisenherz, начать можно с того, что первая функция (в твоём случае check) должна вернуть true, чтобы была запущена вторая функция. Ты же возвращаешь db.actor... Поведение коллбэка предсказать в таких условиях не возьмусь; хорошо ещё, что вылета не было. Ну и второе: я привык считать (может, конечно, и ошибаюсь), что когда первая функция вернула true, запускается вторая функция, а коллбэк отключается. Если это действительно так, однократность сообщения полностью укладывается в такое поведение, ведь инфопорция также выдаётся один раз, и повторно назначить коллбэк некому.

@UltimatePower, ответил в личке.

@_Sk8_AsTeR_, либо они, либо искажение/потеря каких-либо данных после загрузки. (Второе, как я уже писал, не всегда заметно сразу! Поэтому контроль и ещё раз контроль записи чего-либо куда-либо.) Например, в одном из модов для ЧН это приводило к тому, что инвентарь какого-либо НПС начинал содержать абсолютно невразумительный набор предметов, а при взаимодействии с этим НПС (с целью, скажем, торговли) следовал вылет. Поройся в поиске, тут хватает нужных сведений.

Печальные примеры есть у каждого мододела, кто более-менее глубоко погружался в правки скриптов. Моё мнение: если делаешь фигню, но не замечаешь и не исправляешь её, вероятность очень высокая. Особенно плохо, когда последствия вылезают не сразу, вот как сейчас, а где-нибудь на другой локации и спустя несколько часов игры - в таких случаях причину диагностировать бывает очень трудно. А конкретику для данного случая тебе только двигоправы скажут. Отдельно хочу ещё раз - в дополнение со своей стороны - указать на то, что написал @Zander_driver. Всё это тут не раз объяснялось, но лишний раз повторить не помешает.

Вот если б было написано "bank" - тогда да, то же самое по синтаксису. А так здесь используется некая переменная bank. Что в ней, не таблица ли? Полностью согласен! Но мы ж тут знания стараемся повышать. Я потому и написал специально: "одну переменную", да ещё и "с числовым значением". Разве что жирным и подчёркнутым не выделил. Умный человек вычленит для себя важное, а глупому и модули с движком не помогут.