Перейти к контенту

Скриптование


Svoboда

Рекомендуемые сообщения

Похоже, ты просто не понимаешь разницы между публичной функцией модуля и методом класса в этом модуле

Ну есть такое... Я думал, они равнозначно вызываются... Теперь понятно.

В 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.

Я правильно понял?

Изменено пользователем Romz

Шаман - СисАдмин

Всяко-разно: для ЧН

Поделиться этим сообщением


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

Подожду, конечно. А пока попробую сделать, как выше написал.

Собственно, похоже, что 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, это размер сохранения он считает, как я понял, по поводу чего он и начал ругаться, что, мол проблемное сохранение. Хотя, собственно размер сохранения и не увеличился.

Изменено пользователем Romz
  • Нравится 1

Шаман - СисАдмин

Всяко-разно: для ЧН

Поделиться этим сообщением


Ссылка на сообщение

@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 сразу скачком. А сам размер сохранения, физический, практически не изменился...

Изменено пользователем Romz

Шаман - СисАдмин

Всяко-разно: для ЧН

Поделиться этим сообщением


Ссылка на сообщение

Я бы на твоём месте глянул, что пишется в этом модуле и почему 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
Изменено пользователем Romz

Шаман - СисАдмин

Всяко-разно: для ЧН

Поделиться этим сообщением


Ссылка на сообщение

Вроде, взлетело.

Вот так выглядит у меня сейчас

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 перестал ругаться на размер сохранения.

Изменено пользователем Romz
  • Нравится 1

Шаман - СисАдмин

Всяко-разно: для ЧН

Поделиться этим сообщением


Ссылка на сообщение

По результатам прикручивания se_stor к ЗП, получился комплект скриптов и инструкций se_stor от 09.09.2013, lua_helper и lua_extension от 29.09.2013, для чистой ЗП, с учётом минимального вмешательства в игру (т.е. без изменения методов сохранения данных в модулях, кроме bind_actor)

Скорее всего, на ЧН тоже подойдёт, с минимальными изменениями.

Стоит ли выкладывать, и если да, то куда лучше?

Изменено пользователем Romz
  • Спасибо 1

Шаман - СисАдмин

Всяко-разно: для ЧН

Поделиться этим сообщением


Ссылка на сообщение

Возник вопрос.

Коль скоро sr_psy_antenna и xr_statistic у меня схраняются/загружаются через чанки, может их тоже стоит убрать из стандартного actor_binder:save/load?

Шаман - СисАдмин

Всяко-разно: для ЧН

Поделиться этим сообщением


Ссылка на сообщение

@Kirgudu, Понял, архив поправлю и перезалью тогда.

Шаман - СисАдмин

Всяко-разно: для ЧН

Поделиться этим сообщением


Ссылка на сообщение

Блин, туплю опять... :(

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" новую таблицу - работает

 

Подскажите, а?

Изменено пользователем Romz

Шаман - СисАдмин

Всяко-разно: для ЧН

Поделиться этим сообщением


Ссылка на сообщение

 

 

почему у тебя проверка на пустоту таблицы это сравнением с nil? Пустая таблица это вполне себе живая переменная, nil'ом не является
Потому что в начале игры "levelname" не существует. (см. конструкцию)

 

Далее не вполне внятная для меня конструкция levels_list = levels_list{new_level_name}. Это как вообще? Можетlevels_list = {new_level_name}?
А вот в этом и затык. Щас попробую сделать, как ты написал.

Говорю же - туплю... И поиск не даёт ничего... Пол-дня вокруг этого момента кружу...

Шаман - СисАдмин

Всяко-разно: для ЧН

Поделиться этим сообщением


Ссылка на сообщение

 

 

Из кода видно только то, что значению levels_list присваивается результат функции GetVar. Что и как она должна возвращать я не знаю.
Ну я не стал весь скрипт копипастить, только проблемный фрагмент. А то, что она может быть nil, вроде и так понятно.

 

Если переменная может быть nil, тогда несколько вариантов и один из адекватных - передавать в функцию GetVar вторым аргументом дефолтовое значение
Не всегда, т.к. игра может начаться с другой локи.

 

у тебя эта проверка сработает один раз за всю игру,
Само собой. Но имеем зато универсальность скрипта.

В любом случае, твой совет про

 

Может levels_list = {new_level_name}?
Помог, спасибо! :)

Без всяких заморочек с поиском, проверками на пустоту и прочими мною нелюбимыми действиями.

Задачу я сформулировал тут. Самое простое решение - сохранять имена локаций в таблицу при первом их посещении после выброса. А в выброс - табличку обнулять.

Шаман - СисАдмин

Всяко-разно: для ЧН

Поделиться этим сообщением


Ссылка на сообщение

Нужна помощь. ЗП

Имеется выброс. Он случается раз в 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

 

Но всё равно не взлетает...

Шаман - СисАдмин

Всяко-разно: для ЧН

Поделиться этим сообщением


Ссылка на сообщение

 

 

единственное - твоя добавленная функция 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" будут разные переменные?

 

Шаман - СисАдмин

Всяко-разно: для ЧН

Поделиться этим сообщением


Ссылка на сообщение

Да я, собственно, переделываю скрипт Vergas-a, который должен будить ГГ перед выбросом. У него это реализовано таким образом, что при вызове функции сна проверяется, сколько времени осталось до следующего выброса, и если меньше, чем ГГ собрался поспать, то устанавливается время сна равное оставшемуся до выброса времени, в часах.

Но у него это сделано под оригинальный выброс, а у меня в сборке Атмосфир прикручен, и период выброса стоит раз в 2-4 дня. Причём, у меня такое ощущение, что промежуток между выбросами тоже может динамически меняться в некоторых пределах. Потому что если проматывать время, часто спать, то можно ловить выбросы на каждом сне, чего быть не должно.

Шаман - СисАдмин

Всяко-разно: для ЧН

Поделиться этим сообщением


Ссылка на сообщение

И снова здравстуйте.

Опять за помощью. ЗП.

Имеется инфопоршень. Взводится на пропадание индикаторов ХУДа, сбрасывается при их отображении. Ну, должен, по крайней мере.

Взвод и сброс инфопоршня прописал, соответственно, в xr_effects, в disable_ui, disable_ui_only и enable_ui.

Если находиться на одной локе, то всё работает, как задумано, а вот если перейти на другую с проводником, то инфопоршень "зависает" во взведённом положении.

Где ещё производится проверка на включение\отключение ХУДа?


Нашёл ещё в _g show_all_ui, добавил туда взведение и сброс инфопоршня. Всё равно, не срабатывает до тех пор, пока не будет использована функция, в которой явно отключается\включается UI. Например, поспать.

Шаман - СисАдмин

Всяко-разно: для ЧН

Поделиться этим сообщением


Ссылка на сообщение

 

 

сразу после загрузки никакой диалог (в том числе проводника) ещё не открыт.
Не всегда это возможно. Например, первый переход на Янов. Там разговоры вначале. Хотя ГГ уже заспавнился, но UI пока отключен.

Прикол, вернулся на предыдущую локу - инфопоршень сбросился! Инфопоршни, что ли, сохраняются для каждой локи отдельно?

Переведу-ка я проверку с инфопоршней на se_stor

Шаман - СисАдмин

Всяко-разно: для ЧН

Поделиться этим сообщением


Ссылка на сообщение

@Kirgudu, В принципе, да. В скрипте, где этот инфопоршень проверяется, помимо него ещё проверки есть, так что, думаю, не критично будет.


 

 

Рекомендую, кстати, глянуть доработанный se_stor, который я выложил вчера в «сборочном цехе».
Да, я видел уже, и себе уволок. :)
  • Нравится 1

Шаман - СисАдмин

Всяко-разно: для ЧН

Поделиться этим сообщением


Ссылка на сообщение

 

 

Да я, собственно, переделываю скрипт 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

Шаман - СисАдмин

Всяко-разно: для ЧН

Поделиться этим сообщением


Ссылка на сообщение

 

 

я правильно понимаю, что здесь ты вычисляешь время, оставшееся до ближайшего из двух типов выброса?
Совершенно верно.

 

лучше не дёргать 2 раза подряд один и тот же менеджер, а вычислять соотв. дельту прямо в нём
Ну если написать таким образом, как у тебя, то да, весьма наглядно.

А вот math.modf, он разве не целую и десятичную часть возвращает? Потому что десятичная часть - это же миллисекунды, вроде. И тогда их на 3600 умножать надо, чтоб минуты получились. Мож ошибаюсь, конечно. Математика - не мой конёк совершенно... :)

Шаман - СисАдмин

Всяко-разно: для ЧН

Поделиться этим сообщением


Ссылка на сообщение
get_last_surge_time

Не, я переписал функцию, она время в секундах возвращает.

странная функция dream_calculation.

Ну это функция от @Vergas-а. Я её и переписываю, в меру своих познаний.

Возвращает целую и дробную части, но уже после деления на 3600

А, точно. Торможу :)

Изменено пользователем Romz

Шаман - СисАдмин

Всяко-разно: для ЧН

Поделиться этим сообщением


Ссылка на сообщение
  • Недавно просматривали   0 пользователей

    • Ни один зарегистрированный пользователь не просматривает эту страницу.
×
×
  • Создать...