Kirgudu

@Murarius, ладно, тогда прошу восстановить справедливость в отдельно взятом случае.

А если юзер не заходил 3 года? Емнип, когда эту цацку только вводили, она была выдана также и таким вот, давно не появлявшимся, что по крайней мере некоторых из них сподвигло дорогу сюда вспомнить. Собственно, из тех семерых, что я заметил, практически все именно такие. Но может оно и не надо, ведь раз не появлялся, то как бы и не на форуме, то есть не укладывается в границы награды..

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

@aka_sektor, ЛС - это ЛС, не занудствуй. Я бы на месте администрации просто проигнорировал твою жалобу, как и заповедано пунктом 7.2 правил форума. Тебе никто не мешает поместить адресата в игнор, если так уж невтерпёж.

А не поломалась ли (была отключена) автовыдавалка десятки часом? Зашёл намедни в тему одного когда-то очень популярного мода и чисто случайно обнаружил сначала одного автора, не получившего лычки за выслугу лет, затем второго, третьего и так далее; в сумме их набралось как минимум семь.

@Expropriator, теоретически all.spawn, конечно, может влиять. Например, для тех же заданий типа "kill_stalker" одним из свойств является свойство parent, указывающее на того, кто может выдать задание. Это story_id определённого персонажа, и если ты удалил его из спавна, задание с таким родителем будет полностью пропущено при инициализации, а значит не будет учтено при составлении массива task_id_by_type[type]. Таким образом, получается, чтобы ты не наталкивался на вылет, описанный выше, необходимо выполнение трёх условий: 1. Конфиг misc\rt_manager.ltx должен содержать как минимум одно задание типа "kill_stalker"; 2. All.spawn должен обеспечивать спавн как минимум одного персонажа со story_id, указанным в конфиге в заданиях типа "kill_stalker", причём этот спавн должен происходить до инициализации менеджера; 3. Вызов любого метода менеджера должен происходить только через получение его экземпляра: ogsm_rt_manager.get_rt_manager():method_name(). Конечно, менеджер можно доработать так, чтобы он был универсальным и стойким к разным условиям. Но на момент активной разработки ОГСМ такой задачи просто не возникало, поэтому имеем то, что имеем. И кстати, если ты действительно убрал весь классический спавн, тогда причина именно в этом согласно трём правилам, описанным выше. А значит, решение, предложенное @Zander_driver, скорее всего будет для тебя панацеей. Куда воткнуть такую проверку, объяснять не нужно? Вроде все тут - люди опытные.

@Expropriator, ну, тут уж только тебе ведомо, что ты там со стартом накуролесил. Впрочем, на правильную инициализацию менеджера заданий это влиять всё равно не должно. Там главное, чтобы вызов любого метода менеджера из другого модуля шёл только через получение синглтона инициализированного экземпляра менеджера, например: ogsm_rt_manager.get_rt_manager():register_target(self)

А я тебе не подойду вместо Kirgudu? Не было там никакой привязки к локациям, насколько я помню. К смартам - да, но не в заданиях типа "kill_stalker". Проверь, что ты не почистил ненароком конфиг misc\rt_manager.ltx При первом после загрузки обращении к менеджеру (например, как раз из se_stalker.on_register()) там считывалось содержимое секции list, затем по каждой строке этой секции читались уже свойства заданий и записывались в массив self.task_info. Далее делался перебор этого массива и в зависимости от значения свойства type добавлялось значение в один из массивов task_id_by_type[type]. Пустым он мог оказаться только в том случае, если из конфига не получено ни одного задания нужного типа.

Вопросы Charsi задавать бесполезно - он уже больше года не интересуется Сталкером и сюда не ходит. Лично я для проверки и локального запуска скриптов пользуюсь как раз его разработки плагином к N++: https://yadi.sk/d/UIMIb8_8vZtMD

Да не проверка это, не ищи там глубокого смысла. Цитата вырвана из контекста; речь идёт всего лишь о том, что имея 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.