Romz 142 Опубликовано 8 Октября 2015 (изменено) Похоже, ты просто не понимаешь разницы между публичной функцией модуля и методом класса в этом модуле Ну есть такое... Я думал, они равнозначно вызываются... Теперь понятно. В treasure_manager и task_manager тогда тоже нет публичных save и load. Но зато в них присутствуют такие функции, как get_чтототам_manager, через которые их save и load в bind_stalker и вызываются... И в level_weathers тоже такая есть Поправка насчёт weather_manager. Его сохранение/загрузку Artos прописал и в таблицу чанков, и в доп. методы ext_save и ext_load. Это, понятное дело, избыточно (разве только в ЗП в этом модуле есть публичные save и load). Поэтому делаем что-то одно - либо оставляем в ext_save/load и убираем из таблицы чанков, либо убираем и из таблицы и из ext_save/load, но возвращаем в save/load. То есть, всё, что не имеет публичных вызовов save и load убираем из чанков.А если есть необходимость хранить их отдельно, переносим их вызовы save и load из actor_binder:save и actor_binder:load в ext_save и ext_load. Я правильно понял? Изменено 8 Октября 2015 пользователем Romz Шаман - СисАдмин Всяко-разно: для ЧН Поделиться этим сообщением Ссылка на сообщение
Romz 142 Опубликовано 8 Октября 2015 (изменено) Либо - переделать таки эти модули на хранение данных в глобальной таблице хранилища, как я уже расписывал выше. Точнее сейчас сказать не могу, если это требуется - жди неделю. Подожду, конечно. А пока попробую сделать, как выше написал. Собственно, похоже, что save и load в явном виде осталось только в sr_psy_antenna, xr_sound и xr_statistic, остальное - исключительно через классы... Тогда имеет смысл, наверное, через se_stor сохранять только то, что нужно сохранять в модах. А от оригинала - оставить, как было, раз оно и так нормально сохраняется. Ну или наоборот, повыносить часть секций сохранений в se_stor, чтоб они уже с гарантией не загрузились на чистой игре. Проверил, пока только с sr_psy_antenna в чанках и self.weather_manager в ext_save/load. НИ началась нормально. Игра сохранилась и загрузилась без проблем, вроде. Именные сохранения тоже. Единственное, set load marker: перевалил за 8000, это размер сохранения он считает, как я понял, по поводу чего он и начал ругаться, что, мол проблемное сохранение. Хотя, собственно размер сохранения и не увеличился. Изменено 8 Октября 2015 пользователем Romz 1 Шаман - СисАдмин Всяко-разно: для ЧН Поделиться этим сообщением Ссылка на сообщение
Romz 142 Опубликовано 9 Октября 2015 (изменено) @Kirgudu, Так и сделал. Только в таблицу чанков добавил tPkChunks["xr_statistic"] = { file = "xr_statistic" } --/ статистикаНе знаю зачем. Чтоб было и для эксперимента. Плюс, переношу вот эти вызовы. --[[ release_body_manager.get_release_body_manager():save(packet) -- AtmosFear if atmosfear then self.atmosfear:save(packet) self.psi_storm_manager:save(packet) self.fallout_manager:save(packet) end -- End AtmosFear self.surge_manager:save(packet) -- treasure_manager.get_treasure_manager():save(packet) -- task_manager.get_task_manager():save(packet) -----------------------------makdm_start----------------------------- if art_sp_mgr then art_sp_mgr.get_art_spawner_manager():save( packet ) end ]] -----------------------------makdm_end------------------------------- Пока, с целью эксперимента, чтобы проверить, что можно безболезненно вынести во внешние сохранения. Почему у тебя вырос объём данных, записываемых в нет-пакет актора, сказать не могу, тут надо смотреть, что ты пишешь. Если беспокоит или просто интересно, для анализа организуй сам дополнительный вывод в лог соответствующей информации, это не сложно. Но, в принципе, в случае ЗП объем 8000 байт не страшен, в ЗП и ЧН безопасно записывать в нет-пакет до 16000-16200 байт. Это, кстати, учитывается в механизме se_stor.Сам объём не вырос, судя по всему. Там, похоже, просто номер метки сохранения увеличывается, скачком и единомоментно. Вот пример лога ... c:\gam\s-cop\se_stor:(298):read_tail_packet:chunk_key=[xr_statistic],chunk_size=[715]:(717) c:\gam\s-cop\se_stor:(298):read_tail_packet:chunk_key=[psy_antenna],chunk_size=[3]:(5) c:\gam\s-cop\se_stor:(298):read_tail_packet:chunk_key=[bind_actor],chunk_size=[80]:(82) c:\gam\s-cop\se_stor:(315):~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ c:\gam\s-cop\se_stor:(316):Load Storehouse: size(1)=[856], keys=[1] :BuildSav=[-1] c:\gam\s-cop\se_stor:(317):~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * Game 0 is successfully loaded from file 'c:\users\public\documents\stalker-cop\savedgames\0.scop' (3.088s) * phase time: 3041 ms * phase cmem: 448435 K _se_actor: set save marker: 8795 _se_actor: SAVE DIF: 1 _se_level_changer: set save marker: 268 _se_level_changer: SAVE DIF: 26 _se_level_changer: set save marker: 273 _se_level_changer: SAVE DIF: 26 ... ... * [Loading IB] 760575 indices, 1485 Kb * phase time: 1282 ms * phase cmem: 552458 K * phase time: 170 ms * phase cmem: 561488 K * [DETAILS] VertexConsts(256), Batch(61) * [DETAILS] 10126 v(20), 5368 p * [DETAILS] Batch(61), VB(197K), IB(31K) * phase time: 71 ms * phase cmem: 561549 K * Loading HOM: c:\gam\s-cop\gamedata\levels\zaton\level.hom * phase time: 1763 ms * phase cmem: 562359 K * phase time: 24 ms * phase cmem: 562359 K * phase time: 21 ms * phase cmem: 562359 K * t-report - base: 2125, 1050208 K * t-report - lmap: 16, 16386 K _se_actor: set save marker: 8795 _se_actor: SAVE DIF: 1 _se_level_changer: set save marker: 268 _se_level_changer: SAVE DIF: 26 _se_level_changer: set save marker: 273 _se_level_changer: SAVE DIF: 26 ... ... * [win32]: free[1977620 K], reserved[84592 K], committed[2132028 K] * [ D3D ]: textures[1141354 K] * [x-ray]: process heap[628826 K], game lua[25658 K], render[7655 K] * [x-ray]: economy: strings[28744 K], smem[319117 K] * [win32]: free[1978452 K], reserved[84920 K], committed[2130868 K] * [ D3D ]: textures[1142378 K] * [x-ray]: process heap[628585 K], game lua[25766 K], render[7656 K] * [x-ray]: economy: strings[28744 K], smem[319117 K] _actor_binder: set save marker: 126 _Crelease_body: set save marker: 404 _Crelease_body: SAVE DIF: 4 _AtmosFear: set save marker: 410 _AtmosFear: SAVE DIF: 217 _PsiStorm: set save marker: 629 _PsiStorm: SAVE DIF: 14 _Fallout: set save marker: 645 _Fallout: SAVE DIF: 18 _SurgeHide: set save marker: 665 _SurgeHide: SAVE DIF: 14 _sr_psy_antenna: set save marker: 681 _sr_psy_antenna: SAVE DIF: 1 _sound_actor_save: set save marker: 685 _sound_actor_save: SAVE DIF: 3102 _CTreasureManager: set save marker: 4508 _CTreasureManager: SAVE DIF: 3582 _CRandomTask: set save marker: 8093 _CGeneralTask: set save marker: 8115 _CGeneralTask: SAVE DIF: 64 _CGeneralTask: set save marker: 8203 _CGeneralTask: SAVE DIF: 68 _CGeneralTask: set save marker: 8295 _CGeneralTask: SAVE DIF: 68 _CGeneralTask: set save marker: 8386 _CGeneralTask: SAVE DIF: 66 _CGeneralTask: set save marker: 8474 _CGeneralTask: SAVE DIF: 64 _CRandomTask: SAVE DIF: 447 _AS_manager: set save marker: 8546 _AS_manager: SAVE DIF: 8 c:\gam\s-cop\bind_stalker:(701):bind_stalker:save:size=[8430] c:\gam\s-cop\se_stor:(117):save_storehouse:size=[0/nil]>) _sr_psy_antenna: set save marker: 2 _sr_psy_antenna: SAVE DIF: 1 _WeatherManager: set save marker: 2 _WeatherManager: SAVE DIF: 78 c:\gam\s-cop\se_stor:(165):save_storehouse:key[xr_statistic],type_key[string],type_chunk[boolean]~not saved:<Warning!> c:\gam\s-cop\se_stor:(159):save_storehouse:chunk_name=[psy_antenna],chunk_size=[3],len=[19]=>[19] c:\gam\s-cop\se_stor:(159):save_storehouse:chunk_name=[bind_actor],chunk_size=[80],len=[95]=>[114] c:\gam\s-cop\se_stor:(237):~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ c:\gam\s-cop\se_stor:(238):Save Storehouse: size(1)=[125], keys=[1] : BuildSav=[-1] c:\gam\s-cop\se_stor:(239):~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ _actor_binder: SAVE DIF: 8430 WARNING! may be this is problem save point _anomaly_zone_binder: set save marker: 242 _anomaly_zone_binder: SAVE DIF: 34 _anomaly_zone_binder: set save marker: 284 ... DIF изменяется в небольшом диапазоне, а вот save_marker сразу скачком. А сам размер сохранения, физический, практически не изменился... Изменено 9 Октября 2015 пользователем Romz Шаман - СисАдмин Всяко-разно: для ЧН Поделиться этим сообщением Ссылка на сообщение
Romz 142 Опубликовано 9 Октября 2015 (изменено) Я бы на твоём месте глянул, что пишется в этом модуле и почему se_stor выдаёт это предупреждение. Собственно, function save(package) package:w_u16(actor_statistic.surges) package:w_u16(actor_statistic.completed_quests) package:w_u32(actor_statistic.killed_monsters) package:w_u32(actor_statistic.killed_stalkers) package:w_u16(actor_statistic.founded_secrets) package:w_u16(actor_statistic.artefacts_founded) package:w_u32(actor_statistic.best_monster_rank) package:w_stringZ(tostring(actor_statistic.best_monster)) package:w_stringZ(tostring(actor_statistic.favorite_weapon_sect)) local i = 0 for k,v in pairs(weapons_table) do i = i + 1 end package:w_u8(i) for k,v in pairs(weapons_table) do package:w_stringZ(tostring(k)) package:w_float(v) end i = 0 for k,v in pairs(artefacts_table) do i = i + 1 end package:w_u8(i) for k,v in pairs(artefacts_table) do package:w_stringZ(tostring(k)) package:w_bool(v) end i = 0 for k,v in pairs(taken_artefacts) do i = i + 1 end package:w_u8(i) for k,v in pairs(taken_artefacts) do package:w_u32(k) end end function load(package) actor_statistic = {} actor_statistic.surges = package:r_u16() actor_statistic.completed_quests = package:r_u16() actor_statistic.killed_monsters = package:r_u32() actor_statistic.killed_stalkers = package:r_u32() actor_statistic.founded_secrets = package:r_u16() actor_statistic.artefacts_founded = package:r_u16() actor_statistic.best_monster_rank = package:r_u32() local str = package:r_stringZ() if(str~="nil") then actor_statistic.best_monster = str end str = package:r_stringZ() if(str~="nil") then actor_statistic.favorite_weapon_sect = str end weapons_table = {} local n = package:r_u8() for i = 1,n do local k = package:r_stringZ() local v = package:r_float() weapons_table[k] = v end artefacts_table = {} n = package:r_u8() for i = 1,n do log("n "..tostring(n)) local k = package:r_stringZ() local v = package:r_bool() artefacts_table[k] = v end taken_artefacts = {} n = package:r_u8() for i = 1,n do local k = package:r_u32() taken_artefacts[k] = k end end Кстати, в нём нет классов. А именно это предупреждение в se_stor выдаётся, если не проходит условие if type(key) == 'string' and key ~= "" and type(ch_pk) == 'userdata' and type(ch_pk.r_eof) == 'function' then ... ... else to_log("save_storehouse:key[%s],type_key[%s],type_chunk[%s]~not saved:<%s>", key, type(key), type(ch_pk), "Warning!") --/#~# а там, как видно, тип чанка, почему-то, получился boolean Кстати, может быть из-за совпадения имени чанка с именем файла. Сейчас переименовал вот так tPkChunks["xr_stat" ] = { file = "xr_statistic" } --/ статистика и, как результат c:\gam\s-cop\se_stor:(159):save_storehouse:chunk_name=[xr_stat],chunk_size=[709],len=[721]=>[721] c:\gam\s-cop\se_stor:(159):save_storehouse:chunk_name=[psy_antenna],chunk_size=[3],len=[19]=>[740] c:\gam\s-cop\se_stor:(159):save_storehouse:chunk_name=[bind_actor],chunk_size=[80],len=[95]=>[835] c:\gam\s-cop\se_stor:(237):~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ c:\gam\s-cop\se_stor:(238):Save Storehouse: size(1)=[845], keys=[1] : BuildSav=[-1] c:\gam\s-cop\se_stor:(239):~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ _actor_binder: SAVE DIF: 8457 WARNING! may be this is problem save point Изменено 9 Октября 2015 пользователем Romz Шаман - СисАдмин Всяко-разно: для ЧН Поделиться этим сообщением Ссылка на сообщение
Romz 142 Опубликовано 9 Октября 2015 (изменено) Вроде, взлетело. Вот так выглядит у меня сейчас else --/ for CoP tPkChunks["psy_antenna" ] = { file = "sr_psy_antenna" } --/ зоны пси-излучения tPkChunks["xr_stat" ] = { file = "xr_statistic" } --/ статистика tPkChunks["bind_actor" ] = { file = "bind_stalker" } --/ ... end и вот такой self.weather_manager:save(packet) release_body_manager.get_release_body_manager():save(packet) -- AtmosFear if atmosfear then self.atmosfear:save(packet) self.psi_storm_manager:save(packet) self.fallout_manager:save(packet) end -- End AtmosFear self.surge_manager:save(packet) xr_sound.actor_save(packet) treasure_manager.get_treasure_manager():save(packet) task_manager.get_task_manager():save(packet) -----------------------------makdm_start----------------------------- if art_sp_mgr then art_sp_mgr.get_art_spawner_manager():save( packet ) end -----------------------------makdm_end------------------------------- То есть, присутствуют и вызовы из оригинала, и вызовы из модов. Всё загружается и сохраняется. Скрипты вроде не слетели. Да, и set_save_marker перестал ругаться на размер сохранения. Изменено 9 Октября 2015 пользователем Romz 1 Шаман - СисАдмин Всяко-разно: для ЧН Поделиться этим сообщением Ссылка на сообщение
Romz 142 Опубликовано 9 Октября 2015 (изменено) По результатам прикручивания se_stor к ЗП, получился комплект скриптов и инструкций se_stor от 09.09.2013, lua_helper и lua_extension от 29.09.2013, для чистой ЗП, с учётом минимального вмешательства в игру (т.е. без изменения методов сохранения данных в модулях, кроме bind_actor) Скорее всего, на ЧН тоже подойдёт, с минимальными изменениями. Стоит ли выкладывать, и если да, то куда лучше? Изменено 9 Октября 2015 пользователем Romz 1 Шаман - СисАдмин Всяко-разно: для ЧН Поделиться этим сообщением Ссылка на сообщение
Romz 142 Опубликовано 9 Октября 2015 Возник вопрос. Коль скоро sr_psy_antenna и xr_statistic у меня схраняются/загружаются через чанки, может их тоже стоит убрать из стандартного actor_binder:save/load? Шаман - СисАдмин Всяко-разно: для ЧН Поделиться этим сообщением Ссылка на сообщение
Romz 142 Опубликовано 11 Октября 2015 @Kirgudu, Понял, архив поправлю и перезалью тогда. Шаман - СисАдмин Всяко-разно: для ЧН Поделиться этим сообщением Ссылка на сообщение
Romz 142 Опубликовано 13 Октября 2015 (изменено) Блин, туплю опять... local levels_list = {} ... ... local new_level_name = string.lower(level.name()) levels_list = GetVar("levelname") if table.find(levels_list, new_level_name) ~= true then start_quick_timer(2*60, ssbs(true)) if levels_list == nil then levels_list = levels_list{new_level_name} else table.insert(levels_list, new_level_name) end DelVar("levelname") SetVar("levelname", levels_list) end Что хочу получить: Взять таблицу из "levelname" - работает Если в ней нет имени текущей локации, то Запустить таймер на 2 игровые минуты - работает Если таблица пустая, создать её и положить в неё,как первый элемент, имя локации - не взлетает Если не пустая, то добавить к имеющимся элементам новый с именем локации - работает Записать в "levelname" новую таблицу - работает Подскажите, а? Изменено 13 Октября 2015 пользователем Romz Шаман - СисАдмин Всяко-разно: для ЧН Поделиться этим сообщением Ссылка на сообщение
Romz 142 Опубликовано 13 Октября 2015 почему у тебя проверка на пустоту таблицы это сравнением с nil? Пустая таблица это вполне себе живая переменная, nil'ом не являетсяПотому что в начале игры "levelname" не существует. (см. конструкцию) Далее не вполне внятная для меня конструкция levels_list = levels_list{new_level_name}. Это как вообще? Можетlevels_list = {new_level_name}? А вот в этом и затык. Щас попробую сделать, как ты написал.Говорю же - туплю... И поиск не даёт ничего... Пол-дня вокруг этого момента кружу... Шаман - СисАдмин Всяко-разно: для ЧН Поделиться этим сообщением Ссылка на сообщение
Romz 142 Опубликовано 13 Октября 2015 Из кода видно только то, что значению levels_list присваивается результат функции GetVar. Что и как она должна возвращать я не знаю.Ну я не стал весь скрипт копипастить, только проблемный фрагмент. А то, что она может быть nil, вроде и так понятно. Если переменная может быть nil, тогда несколько вариантов и один из адекватных - передавать в функцию GetVar вторым аргументом дефолтовое значениеНе всегда, т.к. игра может начаться с другой локи. у тебя эта проверка сработает один раз за всю игру, Само собой. Но имеем зато универсальность скрипта.В любом случае, твой совет про Может levels_list = {new_level_name}?Помог, спасибо! Без всяких заморочек с поиском, проверками на пустоту и прочими мною нелюбимыми действиями.Задачу я сформулировал тут. Самое простое решение - сохранять имена локаций в таблицу при первом их посещении после выброса. А в выброс - табличку обнулять. Шаман - СисАдмин Всяко-разно: для ЧН Поделиться этим сообщением Ссылка на сообщение
Romz 142 Опубликовано 23 Октября 2015 Нужна помощь. ЗП Имеется выброс. Он случается раз в 2 - 4 дня. Из игры я могу получить дату и время, когда был последний выброс, например, 20 апреля в 13 часов 20 минут. Могу получить промежуток между выбросами, в секундах. Могу получить текущие дату и время, например 21 апреля 11 часов 48 минут. Нужно рассчитать оставшееся до следующего выброса время, в часах и минутах (т.е. до выброса осталось Н часов и м минут) Имеется у меня функция, но она бред выдаёт. Конкретно, отрицательные значения часов и минут. К тому же, не учитывается, что выброс мог произойти в прошлом месяце (т.е. например, выброс был 28 апреля, а сейчас 1 мая) local delta_all = surge_manager.get_delta() local d,h,m = surge_manager.get_last_surge_time() --текущее время local d_t = vergas_lib.return_time(3) local h_t = vergas_lib.return_time(4) local m_t = vergas_lib.return_time(5) --считаю время (сек) прошедшее с последнего выброса local delta_d = 0 local delta_h = 0 if d == d_t then --выброс был в этот же день --считаю прошедшие часы delta_h = h_t - h else --выброс был накануне delta_h = 24 - h + h_t end --считаю прошедшие минуты local delta_m = math.abs(m - m_t) --перевожу все в игровые секунды local delta = delta_all - delta_h*3600 - delta_m*60 local delta_ost = math.fmod(delta,3600) local delta_h = (delta - delta_ost)/3600 delta = math.fmod(delta_ost,60) local delta_m = (delta_ost - delta)/60 return delta_h, delta_m local delta_all = surge_manager.get_delta() local d,h,m = surge_manager.get_last_surge_time() --текущее время local d_t = VS_surge_news.return_time(3) local h_t = VS_surge_news.return_time(4) local m_t = VS_surge_news.return_time(5) local delta_d = 0 local delta_h = 0 local delta_m = 0 --считаю время (сек) прошедшее с последнего выброса delta_d = d_t - d --считаю прошедшие часы if d == d_t then --выброс был в этот же день delta_h = h_t - h else --выброс был накануне delta_h = 24 - h + h_t end --считаю прошедшие минуты delta_m = math.abs(m - m_t) --перевожу все в игровые секунды local delta = delta_all - delta_d*86400 - delta_h*3600 - delta_m*60 local delta_ost = math.fmod(delta,3600) local delta_h = math.abs((delta - delta_ost)/3600) delta = math.fmod(delta_ost,60) local delta_m = math.abs((delta_ost - delta)/60) return delta_h, delta_m Но всё равно не взлетает... Шаман - СисАдмин Всяко-разно: для ЧН Поделиться этим сообщением Ссылка на сообщение
Romz 142 Опубликовано 23 Октября 2015 единственное - твоя добавленная функция surge_manager.get_last_surge_time() должна возвращать объект типа CTime,Ну это не моя функция, а @Vergas function get_last_surge_time() local Y, M, D, h, m, s, ms = 0, 0, 0, 0, 0, 0, 0 local g_s_m = get_surge_manager() Y, M, D, h, m, s, ms = g_s_m.last_surge_time:get(Y, M, D, h, m, s, ms) return D, h, m end То есть, можно было гораздо проще всё сделать... Просто, для информации и личного развитияА что, в ЛУА регистр названия переменной играет роль?То есть "M" и "m" будут разные переменные? Шаман - СисАдмин Всяко-разно: для ЧН Поделиться этим сообщением Ссылка на сообщение
Romz 142 Опубликовано 23 Октября 2015 Да я, собственно, переделываю скрипт Vergas-a, который должен будить ГГ перед выбросом. У него это реализовано таким образом, что при вызове функции сна проверяется, сколько времени осталось до следующего выброса, и если меньше, чем ГГ собрался поспать, то устанавливается время сна равное оставшемуся до выброса времени, в часах. Но у него это сделано под оригинальный выброс, а у меня в сборке Атмосфир прикручен, и период выброса стоит раз в 2-4 дня. Причём, у меня такое ощущение, что промежуток между выбросами тоже может динамически меняться в некоторых пределах. Потому что если проматывать время, часто спать, то можно ловить выбросы на каждом сне, чего быть не должно. Шаман - СисАдмин Всяко-разно: для ЧН Поделиться этим сообщением Ссылка на сообщение
Romz 142 Опубликовано 27 Октября 2015 И снова здравстуйте. Опять за помощью. ЗП. Имеется инфопоршень. Взводится на пропадание индикаторов ХУДа, сбрасывается при их отображении. Ну, должен, по крайней мере. Взвод и сброс инфопоршня прописал, соответственно, в xr_effects, в disable_ui, disable_ui_only и enable_ui. Если находиться на одной локе, то всё работает, как задумано, а вот если перейти на другую с проводником, то инфопоршень "зависает" во взведённом положении. Где ещё производится проверка на включение\отключение ХУДа? Нашёл ещё в _g show_all_ui, добавил туда взведение и сброс инфопоршня. Всё равно, не срабатывает до тех пор, пока не будет использована функция, в которой явно отключается\включается UI. Например, поспать. Шаман - СисАдмин Всяко-разно: для ЧН Поделиться этим сообщением Ссылка на сообщение
Romz 142 Опубликовано 27 Октября 2015 сразу после загрузки никакой диалог (в том числе проводника) ещё не открыт.Не всегда это возможно. Например, первый переход на Янов. Там разговоры вначале. Хотя ГГ уже заспавнился, но UI пока отключен.Прикол, вернулся на предыдущую локу - инфопоршень сбросился! Инфопоршни, что ли, сохраняются для каждой локи отдельно? Переведу-ка я проверку с инфопоршней на se_stor Шаман - СисАдмин Всяко-разно: для ЧН Поделиться этим сообщением Ссылка на сообщение
Romz 142 Опубликовано 27 Октября 2015 @Kirgudu, В принципе, да. В скрипте, где этот инфопоршень проверяется, помимо него ещё проверки есть, так что, думаю, не критично будет. Рекомендую, кстати, глянуть доработанный se_stor, который я выложил вчера в «сборочном цехе».Да, я видел уже, и себе уволок. 1 Шаман - СисАдмин Всяко-разно: для ЧН Поделиться этим сообщением Ссылка на сообщение
Romz 142 Опубликовано 28 Октября 2015 Да я, собственно, переделываю скрипт Vergas-a, который должен будить ГГ перед выбросом.Вернусь к этой теме. Сразу добавлю, что у меня ещё AtmosFear 3 прикручен. В процессе тестирования получившейся функции выяснилось, что промежуток между выбросами может динамически меняться, почему-то. Этот самый промежуток вычисляется и хранится в surge_manager в переменной self._delta.А вычисляется он в функцях CSurgeManager:initialize, CSurgeManager:new_surge_time, CSurgeManager:update плюс ещё сохраняется и считывается из сохранения. В CSurgeManager:initialize и CSurgeManager:new_surge_time Всё понятно и прозрачно. А вот в CSurgeManager:update есть интересный кусок, назначение которого я не очень хорошо понимаю. if(self.time_forwarded) then local diff = math.abs(self._delta - g_time:diffSec(self.last_surge_time)) if(diff<3600) then self._delta = 3*3600+g_time:diffSec(self.last_surge_time) end self.time_forwarded = false end Этот код, в точно таком же виде, есть и в оригинале ЗП, только там ещё и вывод в лог кой какой инфы идёт. То есть, если время время переводится и до выброса остаётся меньше часа, то промежуток между выбросами устанавливается равным 3 часа + прошедшее с последнего выброса время... Зачем??? В общем, обошёл этот момент, путём закомменчивания в ui_sleep_dialog в функции dream_callback строчки surge_manager.get_surge_manager().time_forwarded = true. Да, теперь выброс вполне может случиться сразу после того, как ГГ проснётся. Надо бы что-то подобное и для пси-выброса теперь замутить. Вот такая конструкция получилась function dream_calculation() local delta_surge = surge_manager.get_delta() local past_seconds_su = surge_manager.get_last_surge_time() local delta_su = delta_surge - past_seconds_su local delta_psi_storm = psi_storm_manager.get_delta() local past_seconds_ps = psi_storm_manager.get_last_psi_storm_time() local delta_ps = delta_psi_storm - past_seconds_ps if delta_ps < delta_su then local delta = delta_ps else local delta = delta_su end local delta_h = math.floor(delta/3600) local delta_m = math.floor(math.fmod(delta,3600)/60) return delta_h, delta_m end Добавил в psi_storm_manager по аналогии с surge_manager переменную и функции. А эта функция должна выдать оставшееся до выброса или пси-выброса, если он ближе, время в часах и минутах. 1 Шаман - СисАдмин Всяко-разно: для ЧН Поделиться этим сообщением Ссылка на сообщение
Romz 142 Опубликовано 28 Октября 2015 я правильно понимаю, что здесь ты вычисляешь время, оставшееся до ближайшего из двух типов выброса?Совершенно верно. лучше не дёргать 2 раза подряд один и тот же менеджер, а вычислять соотв. дельту прямо в нёмНу если написать таким образом, как у тебя, то да, весьма наглядно.А вот math.modf, он разве не целую и десятичную часть возвращает? Потому что десятичная часть - это же миллисекунды, вроде. И тогда их на 3600 умножать надо, чтоб минуты получились. Мож ошибаюсь, конечно. Математика - не мой конёк совершенно... Шаман - СисАдмин Всяко-разно: для ЧН Поделиться этим сообщением Ссылка на сообщение
Romz 142 Опубликовано 28 Октября 2015 (изменено) get_last_surge_time Не, я переписал функцию, она время в секундах возвращает. странная функция dream_calculation. Ну это функция от @Vergas-а. Я её и переписываю, в меру своих познаний. Возвращает целую и дробную части, но уже после деления на 3600 А, точно. Торможу Изменено 28 Октября 2015 пользователем Romz Шаман - СисАдмин Всяко-разно: для ЧН Поделиться этим сообщением Ссылка на сообщение