Kirgudu

@Romz, зависит от того, что происходит раньше (вот тут не помню), первый апдейт или исполнение логики (UI при заходе на Янов отключается в ней). Если первое - вполне можно не заморачиваться, а однократно сбрасывать инфопорцию при каждой загрузке. Можно даже не на апдейт сброс повесить, а, например, на спавн актора.

@Romz, ты можешь его сбрасывать при первом апдейте, ведь сразу после загрузки никакой диалог (в том числе проводника) ещё не открыт.

Навеяно помощью @Romz по прикручиванию se_stor к ЗП, результатом чего стал его объединённый комплект скриптов. Он всем хорош, однако, во-первых, предназначен только для ЗП, а во-вторых, предлагает подключение, например, m_timers даже в том случае, если таймеры не нужны, а нужно только универсальное хранилище. Здесь я хочу выложить немного другой комплект модулей @Artos'a, содержащий не все модули сразу, а каждый модуль по отдельности. При этом: реализована полная совместимость модулей между собой (можно интегрировать их в мод в любых необходимых сочетаниях); подключение и работа всех модулей протестированы во всех частях игры; для модуля универсального хранилища (se_stor) добавлено 3 разных примера подключения - для ТЧ, ЧН и ЗП соответственно. Примеры эти 100% рабочие, не требуют никакой доработки напильником. Достаточно в нужных местах добавить/закомментировать указанные куски кода. модуль se_stor доработан так, что теперь он позволяет не только сохранять в чанках те внешние модули, у которых есть публичные методы save/load, но и указывать кастомные названия соответствующих методов. Таким образом, теперь можно больше данных, сохраняемых в оригинале в нет-пакете главного героя, перенести в универсальное хранилище. В добавленных примерах подключения это отражено. Состав: lua_helper - различные часто употребляемые и/или полезные функции которые могут использоваться модмейкерами. m_netpk - интерфейс чтения/записи net-пакетов. m_timers - менеджер универсальных таймеров. se_stor - универсальное хранилище данных произвольного размера. lua_helper - https://yadi.sk/d/1_J1HVZsu7Jgy, обновлено 08.02.2025 m_netpk - https://yadi.sk/d/GtYsSbjnxqdtp, обновлено 08.02.2025 se_stor - https://yadi.sk/d/a38PlQdju7Jhr, обновлено 10.08.2016 m_timers - https://yadi.sk/d/FWJkTnAMu7Jhg, обновлено 08.02.2025 Общий комплект + скрипт для тестирования - https://yadi.sk/d/p69RQkBMu7JgR, обновлено 08.02.2025

@ed_rez, исчерпывающе, спасибо. Регулировок до сих пор не было, так что есть шанс; в ближайшие выходные займусь и отпишу по результату. Не «климат-контроль» часом? Наши компании, занимающиеся установкой окон, продвигают это решение как продвинутое. http://www.fabrikaokon.ru/img/smartbox10.jpg- вот пример (не реклама!).

Уважаемые знатоки стеклопакетов! @ed_rez, наверное, мой вопрос к тебе, но если ещё кто-нибудь сможет подсказать, буду рад. В одной из комнат в квартире есть довольно широкая оконная створка (в оригинале там было 2 узеньких, но когда устанавливали пластиковые окна, решили объединить для большего светопропускания). Створка получилась довольно тяжёлая, и за прошедшие 10 с лишним лет механизм малость разболтался (о чём нас предупреждали монтажники, когда устанавливали окна). Сейчас, например, в режиме мягкого проветривания (когда ручка повёрнута на угол 45 градусов от вертикали/горизонтали) щель между створкой и рамой такая, что сквозит так, как если бы окно было полностью открыто. Да и в полностью закрытом состоянии тоже не прилегает плотно, есть ощутимый подсос воздуха, чего раньше не было. Что можно сделать, где подкрутить (а такая возможность, нам говорили, есть), чтобы подтянуть механизм? Стеклопакет двухкамерный, профиль, если мне не изменяет память, KBE. И, кстати. Всем, кто давал мне советы по электрике, огромное спасибо, @ed_rez в особенности. Всё получилось, уже 2 недели живём без самопроизвольных отключений.

@Romz, да, Lua регистр различает. Смотря для чего сам Vergas её писал. А тебе да, можно сделать всё намного проще, по крайней мере в рамках заданного вопроса. Думаю, окончательное решение должно быть уже понятно.

@Romz, у тебя есть все необходимые инструменты, ты же сам недавно подключал модули Артоса. В lua_helper есть метод (импортированный в публичное пространство) Get_PastSeconds. Получаешь им кол-во секунд, прошедшее со времени последнего выброса: local past_seconds = Get_PastSeconds(surge_manager.get_last_surge_time()) Затем из дельты между выбросами (которая тоже в секундах) вычитаешь полученное значение и превращаешь в часы и минуты простой арифметикой. Upd: единственное - твоя добавленная функция surge_manager.get_last_surge_time() должна возвращать объект типа CTime, то есть то, что в оригинальном surge_manager хранится в свойстве self.last_surge_time. Upd2: если интересно, как то же самое можно сделать без lua_helper, то вот: local past_seconds = game.get_game_time():diffSec(surge_manager.get_last_surge_time())

@Nazgool, зачем ждать запроса? Кому-то может пригодиться позже, а своевременно выложить пример возможности не будет. Лучше сейчас, это полезно.

Это касалось старой версии OGSM. Если бы что-то подобное надо было делать сейчас - об этом написали б в инструкции и шапке темы.

Romz, конечно. Сохранять и там и там избыточно. Labus, получить имя объекта. Карлан, согласен. (пишу с телефона, заметки и проч. недоступны)

Что странно, никаких предпосылок к этому я не вижу. Имя чанка никак не участвует в формировании технологического нет-пакета (только как ключ таблицы), а ошибка в логе говорит о том, что вместо нет-пакета во временную таблицу было записано значение типа boolean. Чего быть не может, судя по коду se_stor. Ну да ладно.

Ты свои 5 копеек вставишь или ограничишься выкриком «браво/позор» постфактум? Этот триллер был бы ещё более качественным, если б у меня была возможность покрутить скрипт (в игре! а не краем глаза в паузах основной работы) самому. Но отпуск только на следующей неделе, а пока единственное, на что хватает времени - это мельком глядеть код и давать наводки. Вполне возможно, где-то я по этим причинам ошибся, написал неправильно.

Ну так это se_actor, там свои данные пишутся. Сейчас тебя больше должно интересовать всё, что касается сохранения в bind_stalker, а там, как я смотрю, порядок. «SAVE DIF» показывает объём записанных за одно действие данных, а «set save marker» - результирующий объём нет-пакета. Вроде всё сходится. Единственное, что слегка настораживает: c:\gam\s-cop\se_stor:(165):save_storehouse:key[xr_statistic],type_key[string],type_chunk[boolean]~not saved:<Warning!> Я бы на твоём месте глянул, что пишется в этом модуле и почему se_stor выдаёт это предупреждение. Не факт, что что-то критичное, но удостовериться в этом надо.

@Romz, скорее всего, даные self.weather_manager у тебя сейчас не сохраняются. И вот почему. Методы ext_save/load вызываются из публичных (добавляемых комплектом se_stor) bind_stalker.save/load, которые, в свою очередь, должны вызываться при сохранении тех самых чанков. Но сейчас ты оставил в таблице tPkChunks, судя по всему, только sr_psy_antenna. ИМХО, для описанного тобой выше частного случая всё должно выглядеть так: bind_stalker.script function actor_binder:ext_save(pk) self.weather_manager:save(pk) end function actor_binder:ext_load(pk) self.weather_manager:load(pk) endтам же обязательно должно быть сделано (как и сказано в инструкции) это: --[[ --/#x# отключено! function actor_init (npc) --npc:bind_object(actor_binder(npc)) end --]] --/ ----------------------------------------------------------------- --/#+# организуем внешний доступ к биндеру актора: --/ ----------------------------------------------------------------- function actor_init(npc) _G.g_bind_actor = this.actor_binder(npc) npc:bind_object(g_bind_actor) end function save(...) _G.g_bind_actor:ext_save(...) end function load(...) _G.g_bind_actor:ext_load(...) end se_stor.script local tPkChunks = {} --/ таблица нет-пакетов с чанками внешних модулей (option for SIMBION mod) if iSSVer < 8 then --/ for SHoC -- ... для ЗП можно оставить без изменений elseif iSSVer < 12 then --/ for CS -- ... для ЗП можно оставить без изменений else --/ for CoP tPkChunks["bind_actor" ] = { file = "bind_stalker" } --/ ext_save/load в bind_stalker.script tPkChunks["psy_antenna" ] = { file = "sr_psy_antenna" } --/ зоны пси-излучения endСобственно, ext_save/load были сделаны как раз для того, чтобы данные внешних модулей, у которых отсутствуют публичные save/load, но есть класс с этими методами, инициализируемый в биндере актора, с минимальными изменениями перенести из нет-пакета актора в чанки.Почему у тебя вырос объём данных, записываемых в нет-пакет актора, сказать не могу, тут надо смотреть, что ты пишешь. Если беспокоит или просто интересно, для анализа организуй сам дополнительный вывод в лог соответствующей информации, это не сложно. Но, в принципе, в случае ЗП объем 8000 байт не страшен, в ЗП и ЧН безопасно записывать в нет-пакет до 16000-16200 байт. Это, кстати, учитывается в механизме se_stor.

А что имеет - добавляем (так как список в примере se_stor неточный). Примерно так. В примере из se_stor такие модули уже указаны в ext_save и ext_load. Надо только актуализировать список согласно реалиям ЗП. Либо - переделать таки эти модули на хранение данных в глобальной таблице хранилища, как я уже расписывал выше. Точнее сейчас сказать не могу, если это требуется - жди неделю.

@Romz, а мы с @abramcumner тебе о чём? Похоже, ты просто не понимаешь разницы между публичной функцией модуля и методом класса в этом модуле. Допустим, есть у нас некий модуль module.script. В нём может быть это: function func() -- do something end и это: class "MyClass" function MyClass:__init() -- do something end function MyClass:func() -- do something end Чтобы вызвать функцию func из другого модуля в первом варианте, достаточно написать: module.func() Чтобы сделать то же самое во втором варианте, потребуется больше действий: local my_class = module.MyClass() --/ тут получили экземпляр класса my_class:func() --/ и только тут дёрнули метод se_stor умеет вызывать только публичные функции, как описано в варианте 1. Да! Но их там нет, так как save и load в этом модуле существуют только в контексте класса.

@abramcumner, об этом я уже писал здесь. @Romz, если подождёшь несколько дней, ориентировочно со вторника по пятницу на следующей неделе я постараюсь подготовить рабочий пример встраивания в чистый ЗП. В модуле level_weathers нет публичных функций save и load. Ну нету! Есть save и load, описанные только как методы класса WeatherManager. se_stor же ни о каких классах в подключаемых для сохранения модулях не знает. Поэтому тупо пользоваться примером из se_stor нельзя. Подробнее смотри по ссылке выше.

Честно говоря, я тоже других переопределений prinf (кроме как в комментируемой тобой строчке) не нашёл, не могу без предметного теста сказать, откуда берётся эта ошибка. Да пусть у тебя в его модулях выводится через консоль, какая разница? На самом деле, после отладки вывод в лог вообще можно убрать.

@Romz, я сейчас с мобильного вошёл, посмотреть не могу. ЕМНИП, при загрузке данные (кроме чанков) читаются в другом месте. Глянь функцию read_tail_packet (как-то так) и откуда она вызывается. Если надо будет, уточню завтра. Что же касается вылета, видать твоя функция printf вовсе не так уж везде доступна. И при удалении, как ты говоришь, "самопальной" скрипту становится нечего вызывать. Посмотрел. Да, так и есть, я правильно запомнил. Во время загрузки данные в глобальную таблицу хранилища читаются функцией read_tail_packet, которая вызывается при регистрации каждого кастомного объекта, используемого для сохранения данных в файле.

@Romz, почему только Артосу? Он дал необходимый инструмент и пояснения, дальше тебе всё доступно, надо только понять принцип. Приведу пример из своей практики.

@Карлан, у меня более старая версия se_stor встроена в мод (платформа ЧН), причём с изменениями, так что выковыривать оттуда будет сложно. @Romz, всё намного проще. Если ты глянешь в se_stor таблицу tPkChunks, то увидишь, что в ней для ЗП перечислены модули, которые Артос предлагал сохранять в чанках. В том числе и level_weathers. А этот модуль у тебя либо отсуствует, либо в нём нет метода save - отсюда и принудительный вылет в функции сохранения чанков. Проверь для начала это. Если судить по ЧН, в модуле level_weathers действительно нет публичного метода save. Там надо сначала получить экземпляр класса, у которого уже этот метод будет. Стандартно этот экземпляр класса сохраняется в экземпляре класса актора. Поэтому level_weathers мы из tPkChunks удаляем, вместо этого возвращаем в actor_binder:save() такую строчку: self.weather_manager:save(packet)Также надо вернуть аналогичную строчку в actor_binder:load() Затем надо проверить остальные модули, которые Artos добавил в чанки для ЗП. sr_psy_antenna и treasure_manager имеют публичные методы save и load (повторяю на всякий случай, пишу для ЧН! ЗП нет в наличии, но там по аналогии), их оставляем в чанках. task_manager в ЧН публичных save и load не имеет - его из чанков убираем, возвращая в actor_binder:save() и actor_binder:load() (если в ЗП по-другому, действовать соответственно). bind_actor - тут Artos для ЧН ошибся, этот модуль называется bind_stalker. Возможно, для ЗП это тоже так. Публичные методы save и load в него ты добавляешь согласно инструкции se_stor. Внутри них дёргаются опять же добавленные ext_save и ext_load, а там - пишутся/читаются данные ещё кое-каких внешних модулей. Записываемые/читаемые в ext_save и ext_load модули надо не тупо взять из примера se_stor (который, как мы знаем, сделан для ТЧ), а сверить с оригинальными save и load ЗП. Надеюсь, понятно расписал. Уверен на 99%, если внести все эти поправки, se_stor заработает. И это стало бы хорошим взносом для всех будущих пользователей хранилища в любых частях игры. Возможно, на следующей неделе у меня самого будет время посидеть и соорудить готовые примеры использования модуля для всех платформ, а не только для ТЧ, как это сделано в оригинальном комплекте. Поправка насчёт weather_manager. Его сохранение/загрузку Artos прописал и в таблицу чанков, и в доп. методы ext_save и ext_load. Это, понятное дело, избыточно (разве только в ЗП в этом модуле есть публичные save и load). Поэтому делаем что-то одно - либо оставляем в ext_save/load и убираем из таблицы чанков, либо убираем и из таблицы и из ext_save/load, но возвращаем в save/load.

@denisshulgin, отгадывать с помощью гугла и иже с ним неинтересно.

В корне неверное решение. Лучше б тогда просто закомментировал по первому варианту. Тут надо понимать, что и для чего было сделано. @Artos написал шаблоны вида '%\%[s|d|f]', чтобы работало такое формирование строки, выводимой в лог: exformat("something %s something else %d something else 2]", param1, param2) То есть берётся исходная строка, в которую в подстановочные места, обозначенные %s, %d или %f, добавляются значения дополнительных аргументов. Строго говоря, артосовский шаблон тоже не совсем верен - как справедливо заметил в кулуарной беседе @Charsi, в нём должно быть экранирование процента процентом же, а не escape-символ. Но, как ни странно, в ТЧ и ЧН шаблон Артоса не приводит к «невидимости» модуля и нормально работает. Ты же добавляешь ещё один символ, который приводит к неправильной работе указанного выше вывода в лог. Функция в твоей редакции просто не найдёт %s и др. и выведет исходную строку в лог как есть, без подстановки аргументов. Правильным вариантом шаблона должен быть именно тот, что приведён выше: '%%...' и без вертикальных чёрточек между символами в квадратных скобках. Например, '%%[sdf]' или '%%'.

Хоть десяток функций друг в друга вкладывай. Тут дело в другом... надо думать. Пока предложение следующее. Вариант 1. Функция fStringExtraFormat (она же exformat в глобальном пространстве _G) используется только для вывода отладочной информации в модуле хранилища. Закомментируй её целиком, также закомментируй: lua_extension: строки 874-876, 929-931 se_stor: строки 47-49 При добавлении из _g_ADD.script не надо добавлять строки 53-67. Всё должно заработать, но без вывода возможной отладочной информации. Вариант 2. Попробуй вместо комментирования всего и вся поменять в шаблонах этой функции %\% на %% (в четырёх местах).

Тогда как рабочий вариант могу посоветовать взять из lua_extension только используемые функции и вставить их куда-то ещё, да хоть в тот же _g.script. Это exformat, table.size и, возможно, что-то ещё, что вызывается в se_stor, а также вызывается уже из этих функций. Конечно, это довольно ёмкая и, вероятно, ненужная исходя из твоих задач работа. Но чисто ради спортивного интереса я бы попробовал и рассказал о результатах здесь - вдруг кому поможет в аналогичной ситуации. Заодно, может быть, при последовательном переносе обнаружится причина, по которой полный модуль не хочет в ЗП грузиться. К сожалению, сам я не смогу этим заняться как минимум неделю, а то и больше.