Zagolski

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

UPD. Странно, что я этой важной информации здесь на форуме не нашел, как вычислять координаты текстуры худа для формата 16:9. (может плохо смотрел?) Заработал следующий рецепт: берем базовую текстуру 1024х1024 в формате .dds и сжимаем ее в редакторе по горизонтали до 768 (размер получается 768х1024), а затем вставляем полученную сжатую блямбу в опять квадрат 1024х1024. Вот из этого результата затем уже и считаем координаты для формата 16:9 стандартным способом. А вообще может какая формула имеется, чтобы с редактором не заморачиваться?

Скажите, а при рассчете координат на текстуре для широкоэкранника, какие манипуляции с файлом текстуры нужно проводить? Просто растянуть ее в редакторе по горизонтали? Или можно какими математическими действиями обойтись, без затрагивания редактора? Потребовалось худ поменять, но столкнулся с рассчетом координат для 16:9.

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

Тут возникла необходимость использовать в ЗП ф-цию main_input_receiver. В ЗП ее нету, точнее в движке она есть, лишь поменяла название на TopInputReceiver() и убрана из экспорта. Я ее экспортировал и заюзал, все в порядке. Хочу уточнить для спокойствия, кто-то делал подобное, косяков потом никаких не вылезет?

Вот именно это и останавливает от применения схемы с приклеенным оружием. Но тем не менее она имеет право на жизнь.

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

Как я понял, никто не знает. Ну и ладно. Я с этим разобрался, только опять не понял, где конкретно. В одном из stalker_...cpp файлов, то ли stalker_combat_planner.cpp, то ли в stalker_combat_actions.cpp. Точно проверять - перекомпиляцией заниматься не охота. До этого я переделывал инициализацию слотов на ЗП формат, так вот в нескольких этих файлах старая схема их получения осталась. Из-за этого оружие не выпадало из рук, а оставалсь прилепленным. Но в будущем, если подобное выпадение лута кто захочет сделать - копайте там.

Из-за низкого качества SSAO.

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

Да уж, чего на свете не бывает... Но боржоми пить все равно уже поздно, теперь как-то выкарабкиваться из этой ситуации нужно. Для этого мне хоть примерно нужно знать, в каком месте копать. Что-то где-то в каком-то из alife...cpp я намудрил, кажется. А вообще давно подобная идея была - сделать невыпадаемые стволы в руках мобов после их смерти, чтобы стрясти с ГГ жирка.

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

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

Я тут продолжаю копаться с инвентарем у мутантов в ЗП, о проблеме писал чуть выше. Так пока и не разобрался с ошибками по xr_delete. Но кое-что нарыл под дебаггером. Скорее всего виной всему bool переменные m_deadbody_can_take и m_deadbody_closed. Эти свойства добавлены только в ЗП классу CSE_ALifeTraderAbstract, т.е. есть у людей и мутантов. Не совсем понятно для чего они предназначены, в скриптах не используются, есть упоминание в CInventoryOwner в виде пары связанных с ними функций, которые тоже нигде не используются... Но однозначно это связано как раз с инвентарем и обыском (видимо поэтому в ЗП инвентарь у мутантов и убрали). Есть у кого идеи на этот счет?

Этот файл в ЧН/ЗП перенесен в папку xrServerEntities.

Ну вот сюда и добавляй через запятую: Дальше там наверняка потребуется еще что-то корректировать. А может быть и нет, судя по реализации достаточно только к перечислению добавить новые. Размер файлов может заметно отличаться от способа сборки и от включенных оптимизаций.

В ЗП построение слотов заметно отличается от ТЧ/ЧН, как и сама реализация UI. Тот способ и близко не подойдет. Сначала добавь их в перечисление в inventory_space.h, а затем придется возиться в UI. Файлы там другие: UIActorMenu.cpp, UIActorMenuInventory.cpp. Конкретнее может кто другой подскажет.

Кто-нибудь провал добавлять в ЗП мутатнтам инвентарь? Я в тупик зашел, два дня с проблемой вожусь. Делаю вроде все правильно, т.е. наследую соответствующий класс в CBaseMonster и все что с ним связано. В игре все работает как надо, инвентарь у мутантов есть и функционирует как положено, но при переходе любого мутанта в оффлайн (в т.ч. и при загрузке сохранки) дает ошибку в функции xr_delete в IGame_ObjectPool::destroy, т.е. при удалении его. В чем проблема никак не могу разобраться... Кто-то может подскажет, в чем тут дело? Кажется, что проблема на самом деле глубже. Ведь не зря в ЗП у мутантов инвентарь убрали. Видимо косяки с ним были, что не исправить...

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

Да, действительно, тесселяция элементарно шейдером назначается. Используется model_pn. Испробовал на докторе из ТЧ. Изначально он почти квадратный, т.е. слишком низкополгональный, но после применения шейдера стал весь кругленький, как высокополигональный. Отличная штука тесселяция, однако. Интересно, а на статике уровней будет работать (дома, деревья)? По идее тоже должно. Если будет, то подобным образом можно билодовские локации "округлить".

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

Это значит использовался х64 движок ЗП. В нем без ограничений. Спасибо камраду abramcumner. То есть с моделью в редакторе ничего мудрить не нужно по поводу тесселяции? Тогда шикарно. Буду пробовать. Хотя я слышал, что в самой модели нужно указывать - тут использовать тесселяцию, тут не использовать.

Кстати, а вот по поводу тесселяции. На ЧН моделях неписей она не работает, не говоря уж от ТЧ-шных, только на моделях ЗП. Но оно и понятно, ведь в самой модели нужно назначать использование тесселяции. Так вот, сложное ли это дело или пустяковое? Я-то в моделировании не разбираюсь особо, интересно узнать. И можно ли тесселяцию использовать не только на моделях НПС, но и на оружии, скажем. В ЗП на стволах тесселяция похоже не используется. Раз движок усовершенствуется, то возможно когда-то будет подключен R4, так что по-любому встанет вопрос о том, как на ТЧ-шных моделях заставить работать тесселяцию. Можно уже и сейчас начать обсужение.

Сегодня мало кто использует х32 системы на ПК, как мне кажется. А х64 может использовать у х32 процесса максимум 4 гига, и то программа должна быть для этого оптимизирована. А так обычно что-то около 2 Гб или около того. В ТЧ движке так и происходит, а в ЗП они могли полноценную поддержку 4 Гб сделать. Но как я говорил, мне не удалось это проверить. А хотелось бы знать. Мне вообще дх10/11 в движке понравился тем, что загрузка текстур происходит в видеопамять, тем самым разгружая оперативную. А в модах обычно много всяких текстур, причем тяжелых. В том же НЛС обычно всегда в районе 2 гигов на процессе висело, сейчас стало 1.1-1.2.

В смысле, сам процесс Engine.exe ел 8 гигов оперативы? Такого быть не может на 32-битном движке. На ТЧ максимум 2.2 было, а дальше вылет по нехватке памяти. На ЗП не знаю, может и 4 кушает, но никак не выше. Сложно проверить, потому как на дх10/11 все текстуры хранятся в видеопамяти, при этом оперативную выше 1.2 Гбайт процесс не ест.