RayTwitty

Решил добавить в SA давний прикол с псевдоотражениями в зеркалах. Когда-то показывал еще в PZ. Тут не Parallax Corrected Cubemap, поэтому с определенных ракурсов можно будет заметить некоторую неправильность отражения, но в целом это выглядит лучше, чем какое-то мыльное отражение панорамы Складов (на р1). За шейдер респектуем @Scavenger, я лишь отснял кубмапы для обоих рендеров и внедрил их для отдельного объекта-зеркала))

Кажись вспомнил еще одну причину, по которой свет фонариков ведет себя странно - консольная команда ai_use_torch_dynamic_lights. После ее включения НПС не смогут включить фонарь. Но это пол беды. Если НПС уже включили фонари, то их позиция не будет обновляться. В итоге свет останется там, где он был до выключения командой. Я эту дичь вообще у себя из движка выпилил, допотопные оптимизации. P.S. Насколько тред актуален хз, но для справки может кому пригодится.

Не совсем понял, скелеты рук отличаются от чего? Вроде связка оружие + руки должны нормально объединяться в один скелет, по крайней мере вручную это делается в 3д редакторе. Тоже самое с анимациями, набор анимаций одинаковый, в скелет добавляются новые кости и двигаются они согласно анимациям из второй модели.

Немного разобрался с установкой опций. 1) При старте движка (когда появляется лого), производится поиск "user.ltx" (или если указан ключ -ltx, тогда указанный файл) 2) Построчно выполняются настройки из этого файла 3) В оригинальном файле user.ltx вверху прописана команда unbindall, которая обнуляет все настройки клавиш и применяет настройки из default_controls.ltx в конфигах, таким образом если какие-то не указаны, то они добавятся 4) Аналогичным образом применяется пресет настроек графики, команда _preset в начале user.ltx. Выполняется один из файлов rspec_minimum.ltx, rspec_low.ltx, rspec_default.ltx, rspec_high.ltx, rspec_extreme.ltx 4) Далее устанавливаются настройки из user.ltx (поэтому они не слетают) Причем, видимо по ошибке, GSC два раза загружают "user.ltx" и при этом отдельно выполняют unbindall. В чем тут может быть проблема? В том, что последний аргумент всегда за настройками в user.ltx, который может остаться у юзера от чистой игры или предыдущих модов. В итоге настройки успешно перекроют пресет графики. Поэтому была придумана штука, которая каждый раз устанавливает настройки мода принудительно. Однако, устанавливает только те, которых нет в опциях. Это я все к чему, избавиться от fsgame.ltx и user.ltx в файлах мода в принципе возможно, но вот с параметрами, которые есть в опциях надо что-то придумать. Бегло посмотрел, это затронет r2_mblur (размытие в движении), r2_sun_details (тени от травы) и cam_inert. Размытие и тени по умолчанию у всех выключены, а раскачка камеры аццкая. В идеале, при первом запуске мода, но уже _после_ загрузки user.ltx устанавливать эти параметры на нужные. Вопрос только в том, как определить, что запуск был первый. Есть пару идей на этот счет, попробую потом.

Каким образом тогда это работает в стиме, если верить постам выше, каталог с юзер файлами лежит рядом с игрой в _appdata_? Полагаю, самым простым решением будет вовсе убрать fsgame.ltx из комплекта установки. В итоге будет использоваться тот, который установлен (и по идее рабочий) у юзера. P.S. Хотя не все так просто, в комплекте еще идет user.ltx, именно для него и изменялся путь до юзер файлов. Посмотрю, что в нем изменено и можно ли будет от него отказаться. По идее, все изменения этого файла должны быть в пресетах графики, а некоторые вообще автоустанавливаться при каждой загрузке игры. user.ltx - это идет еще с ранних версий мода, когда я не знал о пресетах и не написал приблуду с принудительной установкой некоторых параметров.

Ну тогда предложи решение? Обратиться с петицией в офис Valve, чтобы они по умолчанию не указывали директорию Steam в защищенных папках?)) P.S. По крайней мере с такой формулировкой в ридми всегда можно отклонять багрепорты, в которых есть упоминание Program Files. А в логе почти всегда указывается путь))

В том, что папка Program Files защищена от записи Win-службой UAC. В этом случае нужно отключить UAC либо не ставить сталкер в защищенные папки, такие как Program Files (а стим по дефолту туда и устанавливается). Проще поступить как @macron, который в своих релизах запрещает установку в Program Files в принципе.

Stern-13 тогда в чем разница? Было _appdata_ стало userdata. Или в _appdata_ там права есть на перезапись из коробки?

Тогда для стима надо менять строчку в fsgame.ltx $app_data_root$ = true| false| $fs_root$| userdata\ где указывать папку сохранений вне Program Files. По дефолту сохранки сталкера были вроде где-то в документах. Это настолько давно было, что я уже и не помню где. Скиньте файл fsgame.ltx от оригинала 6 патча и от WW-стима, хоть посмотрю что там менялось. Можно сделать папку незащищенной, выдать себе права доступа и прочее. Но как по мне, получать на каждый чих предупреждение винды о том, можно ли копировать мой файл на мой же компьютер это не тараканы, это клиника) Может в корпоративном секторе оно от чего-то защитит или если комп в руках домохозяйки, но если голова на плечах это все не нужно. P.S. На самом деле тред про Program Files - это такой древний баян, я даже помню во время первой Нар. солянки на АМК форуме это обсуждалось. С тех пор уже прошло почти 15 лет и мне казалось вопрос давно закрыт.

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

Уже писали про подобный вылет - вроде дело было, что ставят на стим версию и умудряются при этом дойти аж до бара.

Возможно в CUI_Camera::ZoomExtents, после bb.getsphere(C,R) попробовать модифицировать R примерно как я предлагал. Это правда общий компонент для всех редакторов, так что после правки надо будет проверить на логику использования в АЕ, РЕ и в SE(?). И еще в идеале посмотреть, не используется ли CUI_Camera::ZoomExtents где-то кроме этой кнопки, чтобы ничего не поломать. P.S. Если Zoom Extents Selected перемещает камеру к выделенному объекту, то смысл кнопки Zoom Extent не понятен. В LE при нажатии на нее камера улетает в космос.

Да, посмотрел, в чистом моде и РМА такого нет. Дополнено 9 минуты спустя Я вообще сейчас обнаружил, что эти статьи почему-то не выдаются актору. Это в чистом СА правда, но и тут должно быть такое же поведение. А проблем с заголовками не должно быть, эти названия есть в текстовиках. Проверил у себя - отображаются нормально. Но у меня чистый мод. upd. По появлению статей - похоже какой-то баг движка. Загрузил сейв в конце игры, там были все статьи, загружаю сейв в начале игры - те же статьи в ПДА. Видимо список не очищается при сейвлоадах. Если перезагрузить игру, то нормально все выдается и отображается.

А должны? Пистолеты все 2х1 клетки идут.

У меня вообще такого нет "истории о выбросе", в разделе "Местный фольклор" 20 статей, в разделе "История зоны" 4 статьи, вроде ошибок никаких нет.

А что за вылет? При каком переносе?

Ты бы хоть написал, как исправил. Может кто-то столкнется. Сам не раз сталкивался с вопросами, гуглил похожие посты, находил, в итоге автор пишет ниже "я исправил проблему, всем спасибо" //_-

Yara я так понимаю, основные изменения компилятора геометрии - это появление новых опций (ключей), сами алгоритмы, оптимизация и прочее не проводилось? Спрашиваю это все к чему, во многих кастомных компиляторах можно поймать странные ошибки освещения такого рода на обоих рендерах: https://ap-pro.ru/forums/topic/3341-universalnye-kompilyatory-urovney-h64/?do=findComment&comment=232962 В первых компиляторах от K.D. довольно сильно косячила статика. Поэтому использую все новые компиляторы с настороженностью. Дополнено 19 минуты спустя Я бы сделал, если размер шейпа выделяемого объекта больше 10 (?) метров, то для функции выделения принимаем его за 10. Ну вроде ... if (radius > 10) radius = 10 ... Смысла нет улетать за два километра, если шейп большой. Рестрикторов тоже касается.

Понятно, но прямого отношения к той фиче он не имеет. Насколько я понимаю, это общий множитель мягкости для всех теней вообще, в том числе от искусственных источников света. Хорошо, тогда что называется для закрепления. Требуется скомпилить наземный уровень ТЧ без новых фич из ЗП (кастомного сглаживания и тесселяции), но при этом качественными текстурами лайтмап (RGBA) и сохранением маленьких полигонов. В этом случае, при использовании компилятора входящего в комплект поставки, заданная команда должна выглядеть так: @start bins\compiler_smg\xrLC.exe -nosmg -skip_aht_tess -skip_optimize -f level_name ? P.S. "В левел_эдиторе исправлен баг с выделением статичных звуков / групп (через zoom extent select)" У меня по прежнему саунд сорсы при нажатии на эту кнопку выделяются неправильно - камера улетает за два километра. Не знаю, что конкретно тут поправили, но я ожидал что камера не будет учитывать радиус звука (который в 99% случаев оставляют на дефолте - 300 метров), а будет подлетать к центру, где он расположен.

"Для LE сделано сохранение групп сглаживания при билде карты. Чтобы получить норм. сглаживание, нужно использовать объекты с типом сглаживания ЧН / ЗП (задаётся в плагине для майки при экспорте), иначе будут проблемы с освещением полигонов (или использовать ключ -nosmg, чтобы включить ТЧ-вариант)." Я просто изначально подумал, читая ченжлог, что ключ -nosmg надо прописывать для СДК, а не для компилятора. Тогда вопрос снимается. При экспорте объектов со сглаживанием из LE, дефолтный (старый) компилятор просто проигнорит кастомное сглаживание и сделает как указано в настройках сцены. Собственно как и было всегда. А при использовании новых компиляторов нужно заюзать ключ -nosmg, если у нас старые модели без сглаживания. Если не прав, поправьте. Насколько я понял, они к этому отношение не имеют, а эффект мягких теней достигается только одним параметром дисперсии? Значит флаг lmap_rgba указывать не нужно и формат включен по умолчанию? Я так понимаю, это тоже функция нового компилятора (из ЗП?). При использовании старых компиляторов флажок будет просто проигнорирован?.. P.S. Лучше один раз спросить, чем десять раз скомпилить

Появилось несколько вопросов по проекту. 1) На каком-то этапе разработка пошла в отдельную ветку - SMG. Для чего это было сделано и в чем отличие от первоначальной задумки? Для понимания идеи. Могу предположить, SMG - Smooth GroupS. Если эта ветка стала основной, может избавиться от приписки в названиях редакторов? 2) Если я не ошибаюсь, прообразом проекта был СДК от YURSHAT. В нем было совсем немного правок, однако была зачем-то сделана правка на тему сохранения thm, подробности: https://www.gameru.net/forum/index.php?s=&showtopic=59990&view=findpost&p=1534581 Из-за чего возникала путаница и приходилось дополнительно заниматься ресурсами для работы с новым СДК. В текущем проекте этот момент не менялся? В ченжлоге есть несколько изменений на эту тему, поэтому уточняю. 3) Судя по изменениям, в СДК переделан механизм сглаживания на манер ЗП? Теперь, чтобы корректно сбилдить уровень с ТЧ моделями и получить результат, как в оригинальном СДК нужно прописывать ключ -nosmg для LE? А почему бы не пойти от противного и не сохранить по умолчанию оригинальное поведение, а уже поддержку групп сглаживания включать отдельно? Я бы вообще сделал в опциях сцены флажок "Use model smooth" рядом со "Normal smooth angle", а не отдельным ключом. По умолчанию "Use model smooth" выключен (тем самым сохраняя поведение ТЧ), при включении приоритетом используются группы из модели, если их нет, то фиксированный угол из следующего параметра. 4) "обработка сглаживания при конвертации в OGF (как в ЗП)" - можно поподробнее? Изменен формат моделей на выходе? ТЧ движок будет корректно отображать? 5) "Отключение оптимизации скелетных мешей (AE)" - речь о флажке HQ Geometry? Как я понял, он теперь включен всегда и самого флажка в АЕ нету? 5.1) https://ap-pro.ru/forums/topic/3577-object-editor-v395/ Кстати вот тут пишут, что HQ Geometry в ЗП был не совсем HQ и по прежнему что-то оптимизировал. 6) "LE при построении уровня (Compile->Build) не удаляет маленькие полигоны" это как я понимаю мой фикс инвалид фейсов? Где-то видел более улучшенную версию фикса, возможно в репо "борща". 7) "В настройки сцены добавлены параметры, которые были в старых сдк" это из того треда на ГМ, где обсуждалось размытие теней на статике? Что-то вроде запекаемого аналога Percentage-Closer Soft Shadows? 7.1) В последнем апдейте эта фича с тенями убрана или я неправильно понял? У меня в LE я их не наблюдаю. "Убраны новые (старые) параметры в настройках сцены: Hemisphere energy coeff и Jitter distortion" Почему? 8) "В шейдеры компиляции, добавлен флаг Tessellate" в описании не указано, для чего это нужно. Если не использовать эту фичу и оставить оригинальное поведение, нужно ли что-то менять в ресурсах СДК? 9) Прошелся по списку старых фиксов отсюда https://www.gameru.net/forum/index.php?showtopic=46774 Вроде бы все есть, только уточню - правки компилятора геометрии "xrLC: Фикс вылета при инвалид фейсах + качественные лайтмапы" перенесены из репо abramcumner с ключами (соответственно) - skip_inv_face и lmap_rgba? Второй ключ не указан в xrLC_help.txt. ---------------------------------- Из того, что еще бы хотелось: Кубические env_mod. Сферой очень неудобно и коряво заполнять прямоугольные помещения. Правка уже готова, вот исходники: 1) https://bitbucket.org/stalker/xray-csky_borscht_sdk/commits/a7ef26b9f2a713c8b890fd8f002222283f723433 2) https://bitbucket.org/stalker/xray-csky_borscht_sdk/commits/472ee56b8f26533d891fe576f9d13065daee505d 3) вроде тоже сюда https://bitbucket.org/stalker/xray-csky_borscht_sdk/commits/62bcd5ff7a7159cb0c873e991eef09046371eeb9 как я понял переделали куб в параллелепипед, правда только для движка. На первый взгляд непонятно, где это можно применить, разве что под крышей какой-нибудь. 4) правка выделения шейпа env_mod https://bitbucket.org/stalker/xray-csky_borscht_sdk/commits/15e41760f222177c44ac6f35fab763e791338413 Искал по коммитам "env", может еще какие правки вносились, мной незамеченные. А также кнопки видимости типов объектов из ЗП СДК. К примеру хотим скрыть все Spawn Element, сейчас надо нажимать Visibility -> Hide All. В ЗП это делается одной кнопкой (с текстурой глаза) слева от типа элемента. P.S. Изменения за 11.09.2022 никак не отражены в репозитории, однако есть в релизах.

Вполне реально без правок движка. Получить позицию объектов в мире можно, направление камеры тоже. Работаешь с координатами, считаешь углы и рисуешь как тебе надо.

SkyLoader было current_server_entity_version = 6, поменял на 7 (как в финалке), лог чуть изменился, теперь версия определяется верно (вроде бы) This is a spawn of S.T.A.L.K.E.R. unknown, spawn ver. 118 По крайней мере так же пишет о тех спавнах, которые и раньше распаковывались. Но тем не менее в остальном ошибка не ушла. handling error with smart_terrain, но смарт видимо тут не причем. В свежей версии распаковщика жалуется уже на сталкера. Я для проверки вообще все конфиги заменил на финалковские, не помогло. Даже не знаю, в чем еще может быть беда. P.S. Только я дописываю пост, копирую папку со скриптами в геймдату СДК и у меня все распаковывается. WTF??? У меня вместо всех скриптов было 12 штук всего. _g, класс регистратор и серверные классы объектов. Это конечно вопрос ко мне, как так вышло, но может это какой-то дефолтный набор скриптов из СДК 0.4? P.S2. Насколько же неочевидный косяк, который вылез в третьей программе. А ведь СДК не крашнулся и даже спавн собрался в нем без ошибок.

Столкнулся со странным поведением при экспорте спавна в LE через "Make GAME". Сам экспорт проходит нормально, появляется новый файл level.spawn в папке с уровнем, но этот файл не может распаковать Universal ACDC 1.38. Но, как выяснилось далее, дело не в ACDC. Что я делал: 1) беру любой уровень из чистого ТЧ, к примеру l12u_control_monolith как самый маленький 2) конвертером бардака декомпилирую этот уровень 3) загружаю его в LE, делаю Make GAME 4) беру свежесозданный level.spawn и запускаю acdc_decompile_level.bat (perl universal_acdc.pl -d level.spawn -level) В итоге получаю: log inited: console Universal ACDC v.1.38 opening level.spawn... reading alife objects... handling error with stalker_monolith, template C FATAL ERROR! Function: stkutils::data_packet::error_handler Line: 1548 Description: unhandled exception Лог, который на самом деле ни о чем не говорит. Нахожу старую версию Universal ACDC 1.27, там получаю более информативный лог: Universal ACDC v.1.25 checking version of level.spawn... This is a spawn of S.T.A.L.K.E.R. xrCore build 3120 opening level.spawn... reading alife objects... handling error with smart_terrain FATAL ERROR! Function: stkutils::data_packet::error_handler Line: 385 Expression: Description: unhandled exception На что тут можно обратить внимание - ACDC определяет мой файл как спавн из билда 3120 почему-то о_0 Я подчеркиваю, любой спавн из моего СДК почему-то так определяется, в том числе оригинальные только что декомпиленные уровни. Следовательно, проблема может быть в одном из 3 компонентов - конвертер, Universal ACDC и СДК. 1. Конвертер - я пробовал две версии, старую которая у всех была в свое время и новую из последних релизов на битбакете. В обоих случаях ничего не изменилось. 2. Аналогично с ACDC. Последняя версия 1.38 и 1.27. Разницы нет, только логи чуть разные. Дело явно не в нем. 3. СДК... У меня оригинальный СДК с правками, которые использовали все и всегда, по типу отключения оптимизации и прочего. Но чтобы исключить этот момент, я скачал последнюю версию СДК от Yara с битбакета. Итог - это никак не повлияло, спавн также определяется как 3120. Чтобы железобетонно определить, является ли что-то из перечисленного виновником, я попросил другого человека проделать аналогичные действия на своей машине (компьютере). То есть взять l12u_control_monolith, декомпилить таким же конвертером как у меня и сгенерить level.spawn. После чего он скинул мне свой level.spawn и он благополучно распаковался через Universal ACDC. То есть можно сказать на 100%, что дело не в конвертере и не в ACDC. Дело в СДК (или в том, что он использует). Далее, я у себя в СДК на ранее декомпиленный уровень для проверки добавил на карту один объект (по типу бочки) и сохранил уровень. Измененный файл spawn.part скинул человеку, который его загрузил уже у себя и сгенерил также level.spawn. Как итог - распаковщик его благополучно распаковал. То есть получается, сам уровень сохраняет данные правильно и дело конкретно в функции Make GAME. В связи с этим вопрос к тем, кто ковырял СДК куда больше чем я - может ли функция Make GAME использовать какие-то внешние системные компоненты? Фреймворки и прочее. Я просто не понимаю, почему у нас получается разная версия спавна. Я могу лишь грешить на то, что у меня Win7 64, а у человека 10-ка и у нас в системе разный набор библиотек.