Kirgudu

Да не проверка это, не ищи там глубокого смысла. Цитата вырвана из контекста; речь идёт всего лишь о том, что имея id, можно получить сам объект.

@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. Что в ней, не таблица ли? Полностью согласен! Но мы ж тут знания стараемся повышать. Я потому и написал специально: "одну переменную", да ещё и "с числовым значением". Разве что жирным и подчёркнутым не выделил. Умный человек вычленит для себя важное, а глупому и модули с движком не помогут.

@_Sk8_AsTeR_, условную одну переменную, не занимающую много места (а числовое значение именно такое), вполне можно сохранять в pstor актора без огорода с дополнительными модулями или новыми движками - см. штатные xr_logic.pstor_store и xr_logic.pstor_retrieve и их применение в оригинале. Вот с таблицами, длинными строками или множественными переменными - другое дело, в этом случае уже стоит последовать совету @Zander_driver.

Не так. Таблица в Lua - объект, доступ к которому осуществляется именно по ссылке (указателю). Ещё раз, почитай. Посмотри внимательнее код. Как раз не внутри функции, а за её пределами, поскольку tt - это указатель на таблицу, являющуюся подтаблицей объекта, объявленного в модуле глобально. То есть твои изменения, сделанные функцией, сохраняются и после выхода из неё, и могут использоваться затем другими функциями/модулями. А вот у тебя переменная s имеет тип "значение", объявлена уже внутри функции func(), существует только в пределах этой функции и не сохраняется после её выполнения. При повторном выполнении она создаётся заново со значением nil, что ведёт к повторному выводу в консоль.

@DMT, функция не обязана что-то возвращать, чтобы проделать какую-либо работу. Вот здесь local tt = t_data[npc:id()] из массива менеджеров торговли (не знаю, из какого мода взят код, но это именно переделанный относительно оригинала trade_manager) читается экземпляр, соответствующий конкретному NPC. Далее происходит изменение свойств этого экземпляра (списков покупки/продажи) в зависимости от условий. При этом массив менеджеров торговли наполняется другой функцией (trade_init или её аналог), а результаты изменений, сделанных внутри функции update, доступны также и за её пределами. Для общего понимания рекомендую почитать, что такое ссылочные типы данных и типы значений (reference type и value type).

@Zander_driver, насчёт фломастеров полностью согласен - кому как удобнее, тем более если скриптёр понимает, что именно делает. На мой взгляд, переопределить при замене (гипотетической) модуля четыре глобальные функции в одном месте проще, чем выискивать по всем скриптам вызовы внутренних функций модуля. Выше, кстати, есть опечатка: должно быть "se_stor.get(key, default)" Вызовы глобальных функций будут выглядеть так: SetVar(key, value) -- установить значение переменной GetVar(key, default_value) -- получить значение переменной (default_value - значение по умолчанию для переменных типа таблица) DelVar(key) -- удалить переменную HasVar(key) -- проверить наличие переменной в хранилище Для всех частей игры работает одинаково.

Тебе какого рода примерчик-то нужен? В сборочном цехе смотрел? Там всё максимально подробно расписано - и автором, и я от себя добавил, даны примеры подключения для всех частей игры и даже подготовлены скрипты для оригиналов. А использование... что может быть банальней трёх добавленных глобальных функций SetVar, GetVar и DelVar, тоже описанных? Ведь работа модуля и сводится как раз к сохранению, чтению и удалению переменных.

@Murarius, давай меняться. Я к тебе, ты ко мне... Может высплюсь.

А, ну тогда сдублируйте div с классом "scroll-top-wrapper", дав ему класс "scroll-bottom-wrapper", расположите на расстоянии 62px от нижнего края (свойство bottom в новом классе), внутри элементу i сразу дайте класс "rotated", а в обработке глобального события "scroll" добавьте скрытие элемента с новым классом, если страница отмотана в самый низ (уже не нужна) или в самый верх (не нужна, так как её функции выполняет старая кнопка). И будет вот так везде, кроме низа и верха:

@Keeper,

@Баба ЯГА, полегче, полегче. Красным цветом и прописными буквами пиши в другом месте. Надо разжевать и в рот положить, да? Извини, не по адресу обратился. Предпочитаю дать пищу для самостоятельных размышлений, хотя бы минимальных. Например, модифицировать функцию так, чтобы сразу искала единственный гейм-вертекс, находящийся на минимальном расстоянии от твоих координат, а не все вертексы в радиусе 9 метров.