Zagolski

Нормалек. Качество не ахти, но для сталка пойдет. Правда, обозначенный выше алгоритм трассировки активно пропускает мелкие объекты, такие как провода, листва и пр. Да и не только мелкие. Хотя и достаточно быстр. Но все равно 6 итераций - мало, лучше хотя бы с десяток. Марш луча лучше делать в скринспейсе, т.е. по пикселям, а не в мировых или видовых координатах. Нормаль для воды можно не переводить в пространство касательных и не делать лишних умножений матриц, потому как вода всегда расположена горизонтально.

Тут с перекомпиляцией ТЧ лок засада. Все тч-шные локи со сглаживанием ТЧ, а при перекомпиле в СДК 0.7 им применяется сглаживание ЗП и модели корявит. Если в xrLC отключить сглаживание ключом -nosmg (что все и делают), то результат более-менее, но не идеален. Так что тут нужно перед компилем прогонять все модели локации и переназначать им всем сглаживание на ЗП. Это если грамотно делать с качественным результатом. Но неизвестно, делали ли это разработчики CoP пака локаций, или сразу с ключом -nosmg компилили. Никто не в курсе?

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

Я уже давно в разочаровании от игростроя, последние 10 лет выходит 99% шлака. Но в случае со Сталкер 2 у меня теплится 50% надежды, что будет что-то путное. Главное, чтобы беседке не продались, а то произойдет хана.

Вряд ли кто найдется. Тут со своего голова болит, а уж чужим и подавно никто заниматься не станет.

Господа, прошу помощи. Нужно отскалировать модель худа рук ЗП в большую сторону, ну то есть сделать руки крупнее. И вместе с анимацией, чтобы хваты расширились. Это вообще возможно мне сделать средствами майи или макса и малой кровью или не стоит браться? Сами модели и скелет нормально скалируются, но анимация все сбивает обратно (позиции костей). В итоге получается, что руки как бы и стали больше, но хваты остались прежние. А нужно чтоб и хваты увеличились, то есть нужно провести и скалирование анимации в том числе.

Неужели остались еще мазохисты писать table.geth вместо короткого #

Ну то есть работает без всяких изобретений костылей? Мне это и нужно было знать, спасибо.

Все это в планах только после выхода ХСМ, не ранее чем через полгода он выйдет. Задумки более масштабные, но основа - да, комбинирование двух движков.

Может они у тебя где-то за спиной болтаются?

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

Вернусь опять к вопросу по правке анимации в максе. Как там править, если при загрузке анимки (у меня оружие) частично убиваются средние ключи? Неужели никто не в курсе, проблема-то по идее распространенная. Для понятности приведу пример. У оружия такая анимация: около начала затвор поднят вверх, где он и остается почти до конца, а в конце анимации резко опускается вниз. Так вот с этими убитыми в середине ключами (когда анимку .skl загружаешь на модель стандартным скриптовым импортером) затвор начинает плавно с самого начала поворачиваться сверху вниз. А этого происходить не должно, он должен резко опускаться в самом конце анимки, а все остальное время находиться вверху. Там не все ключи убиваются, примерно половина по всей длине, но из-за этого вся анимация портится. В майе подобного не происходит, но я в ней работать не мастак.

Кто-нибудь может сказать, в ЗП возможно с помощью стандартной ф-ции перемещать вещи из ящика в ящик? Ну той, что от непися к неписю, на вскидку не помню ее точное название. В ЗП ящики на ALife переделаны, возможно на них будет работать. Кто-то пользовался в ЗП перемещением для ящиков?

По реализации отложенного взрывателя, спор о воровстве идеи которого возник чуть ранее. Предъявить можно только в том случае, если был украден код (в данном случае если из проекта KRodin перетащили бы код в PP). А если все то же самое сделали, но иначе реализовали, этот случай воровством не считается и ничьи права не нарушили.

На динамике не из-за бампов картинка мультяшно-пластмассовая, а из-за отложенного рендера. На статике используется форвард рендер, поэтому картинка там натуральнее. С подключенными к статике бампами все выглядит куда лучше, чем на динамике.

Нет, нельзя. Только правкой движка. Причем даже в этом случае придется попотеть.

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

Как я понял, dsh спрашивал про мой репозиторий или типа того. А так да, вон morrey тоже сделал рендеры. Но у него есть много того, чего не нужно для ТЧ. Например, отдельные руки и многие другие примочки из ЧН/ЗП, даже UI вроде он из ЗП перетащил. По сути наполовину переделал двиг ТЧ в двиг ЧН/ЗП. А к этому всему ведь еще требуется и перекомпил локаций и замена моделей, замена всей оружейки и прочее. Кто будет для своего мода на ТЧ всей этой перестройкой заниматься, ради чего? В общем, если нужен практически чистый двиг ТЧ, но с новымии рендерами, то советую юзать сорцы простой ЛА. Там правда только R3, но и он многого стоит. А туда можно легко и R4 прикрутить, так как база рандера уже на зп-шную переделана.

Нету никакого репозитория. Смотрите сорцы ЛА, в них все есть. Только будет проще сразу взять их исходники и на них делать свое. Иначе придется переделывать свое примерно до уровня ЛА.

Это все элементарно делается поиском по имени объекта, никаких story_id для этого городить не нужно. Правда, это касается объектов заспавненных аллспавном. В ТЧ даже ф-ция для этого есть: alife():object("name") В любом случае присваивание story_id нет-пакетом, когда он вступает в силу только при перезагрузке - не очень корректный метод, наверное, даже больше косячный.

А зачем заспавненному неписю вообще устанавливать story_id, зачем он ему нужен? Вроде даже при перезапуске игры.

У тебя ничего не выйдет, там все сложно. Не для простого ума. Нужно полностью переделывать рендеры и вдобавок еще половину движка.

Не вирус ли это случаем?

Как ты там собрался что-то исправлять? Ф-ции play_hud_animation не существует, о чем говорит вылет, да и не было никогда.

Никак ты их не подключишь, это невозможно. Только внедрением через исходники движка.