Romz

@DevastaTOR62, У меня такая фигня была, когда я фикс для DX9 накатил, и на DX10 запустил

Странно... А видюха какая? Покажи скрин в таком режиме. Я на r3 играю (в режиме DX10) - всё норм с прицелами. Да и больше не жаловался никто. Под DX9 только, но для них и фикс выложил. А уж 16:9 - это родное разрешение для OWR.

Ты на статике играешь? Желательно бы на динамике, OWR и AtmosFEAR под DX10 расчитаны. Это с оригинала баг, не знаю как победить. Попробуй с ранней сохранки загрузиться, и диалог начать, подойдя к Ною вплотную. Есть такое, пока не нашёл причину.

Новый фикс. Ссылка - прежняя. У меня, в принципе, всё подхватилось и игра пошла дальше. Но тем не менее, см. предупреждение.

Нафига ж ты движок поверх накатил? Это ж вообще отдельная тема, для чистой игры. Архив с Окрошкой полностью самодостаточен. В ридми же не написано, что ещё что-то нужно поверх ставить... Ну, кроме фиксов, понятно... Ну, я думаю, что понятно. Грядёт фикс. Обнаружился внезапный косяк. В своё оправдание могу сказать, что косяк я утянул вместе с исходниками движка у Revolucas aka Alundaio. Который, в свою очередь, утянул, в виде форка, у nitrocaster. Суть его вот в чём. получил вылет в Путепроводе "Припять-1" при попытке открыть ворота. Вернул, как было в оригинале - всё стало открываться. НО... Как это всё повлияет на игру дальше - непонятно. Поэтому, желательно бы, после фикса начать НИ. Сам я только вылез в Припяти. Как только появится доступ на Затон и Янов, всё проверю, и если вылетать не будет больше, выложу фикс. Вот здесь корни сего косяка.

Ну, вообще, работает, но мои не распаковывает. Спотыкается на документах ГГ, которые в UnP_0.8 были добавлены. И, я думаю, ещё много обо что споткнётся. Конфиги распакованные я ему подсовывал - всё равно не видит. Да и фиг с ним.

Надо же, Okroshka пошла гулять по интернетам Новый фикс Ссылка та же.

А как-то отмотать назад можно?

Не, почему же. В свете того, что работает с CTime, может кому-то ещё пригодится.

Попробовал написать так level.change_game_time(-351,0,0) Не взлетело. Время перевелось вперёд на полтора месяца, почему то...

@Kirgudu, Не, ну из приведённых мной кусков кода, может быть, конечно, не очень понятно, что и как, но у меня get_last_*_time возвращает, в секундах, время, прошедшее со времени окончания предыдущего выброса. А get_delta - возвращает текущий промежуток между выбросами. Тоже в секундах. @Kirgudu, С секундами проще. Промежуток между выбросами - максимум четверо суток (игровых). CTime для моих задач, ИМХО, черезмерно.

@abramcumner, А почему складываем время, прошедшее с последнего выброса, с временем между выбросами? И как из этого получилось время до следующего выброса? Ааа, понятно тогда

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

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

Вернусь к этой теме. Сразу добавлю, что у меня ещё 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. Да, теперь выброс вполне может случиться сразу после того, как ГГ проснётся. Надо бы что-то подобное и для пси-выброса теперь замутить. Вот такая конструкция получилась Добавил в psi_storm_manager по аналогии с surge_manager переменную и функции. А эта функция должна выдать оставшееся до выброса или пси-выброса, если он ближе, время в часах и минутах.

@Kirgudu, Ещё внимание обратил на дату. У меня в игре сейчас 11 ноября 2013 года. А ЗП начинается в августе 2012. Хотя реально ГГ в ЗО, мож месяц, от силы... Ладно, фиг с ним, переиграю с сохранки, где ещё не начал экспериментировать со сном... Хотя, прошёл-то я далековато уже по сюжету...

Не знаю, где лучше вопрос задать, здесь, или в ковырянии файлов ЗП. Задам здесь. Возник вопрос. Внезапно обнаружил косяк - в статистике у ГГ написано, что он в ЗО провёл -1 день. Где, интересно, в скриптах это меняется? Косяк связываю с ковыряниями на предмет просыпания ГГ перед выбросами. Ибо был одно время период, когда у меня ГГ спал -10 часов, и т.п. Вот и хочу попробовать вернуть более правильное значение.

@Дормидонт, @DarkSatellite,

@grom, А зайди к Сидоровичу. Дверь откроется? Мож скрипты у тебя слетели?..

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

Не всегда это возможно. Например, первый переход на Янов. Там разговоры вначале. Хотя ГГ уже заспавнился, но UI пока отключен.Прикол, вернулся на предыдущую локу - инфопоршень сбросился! Инфопоршни, что ли, сохраняются для каждой локи отдельно? Переведу-ка я проверку с инфопоршней на se_stor

И снова здравстуйте. Опять за помощью. ЗП. Имеется инфопоршень. Взводится на пропадание индикаторов ХУДа, сбрасывается при их отображении. Ну, должен, по крайней мере. Взвод и сброс инфопоршня прописал, соответственно, в xr_effects, в disable_ui, disable_ui_only и enable_ui. Если находиться на одной локе, то всё работает, как задумано, а вот если перейти на другую с проводником, то инфопоршень "зависает" во взведённом положении. Где ещё производится проверка на включение\отключение ХУДа? Нашёл ещё в _g show_all_ui, добавил туда взведение и сброс инфопоршня. Всё равно, не срабатывает до тех пор, пока не будет использована функция, в которой явно отключается\включается UI. Например, поспать.

Ага. В рамках UnP 0.8 присутствуют мелкие правки, в целом не влияющие на сюжет.

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

Ну это не моя функция, а @Vergas