изменить силу тяжести? Например, чтобы все персонажи выше прыгали и медленнее падали.
Силу тяжести - средствами модов нельзя. Это вклинивание даже не в фолаутское ядро и даже не в Gamebryo, это надо править параметры Havok, который тут совсем уж внутренняя матрёшка...
Про именно прыжки: в дофолаутские времена, когда тут был такой навык - акробатика - от этого навыка, в частности, зависела прыгучесть персонажей (движок про это помнит, но там всё намертво позатыкали). А начиная с одного из обновлений игры (кажется, в 1.5 уже было сделано) авторы рассердились на моддеров, которые повадились увеличивать прыгучесть правкой доступных параметров (в результате игроки начали запрыгивать за пределы игрового мира - в ту же Мегатонну через забор скакать) - и воткнули ограничение на прыжки, так что попытка слишком высоко и далеко прыгнуть теперь грубо пресекается посреди полёта... То есть даже если бы удалось как-то переубедить Havok, там ещё и вот такое бревно в колёса.
Я немного поковырялся с моддингом и увидел, что светильники в игре это вовсе не светильники, это активаторы или статики, а свет исходит от маркеров похожих на лампочки. Можно ли их как-то сделать сбиваемыми, например как пожарные огнетушители в игре?
Можно сделать, чтобы фонари твоего мода гасли при расстреливании - достаточно привязать объект света к объекту фонаря, и они будут исчезать одновременно (при желании взамен может появиться третий объект - разбитый в хлам фонарь). Но сделать мод, который изменит существующие светильники, не получится - абажур не знает, кто у него лампа, и потому погасить её при взрыве не сможет.
абсолютно непонятно почему перки присвоенные к напарникам перестают работать после перезагрузки игры
Элементы игры можно поделить на две категории. Первая обеспечивает механику игрового мира в целом - навмеши, баллистика, конструкция диалогов, влияние перелома ноги на скорость перемещения и т.п. Вторая - элементы не глобальные, а предназначенные решать какую-то одну очень локальную задачу. Как функция изменения базовой цены предмета ради продажи стилей интерьера, как entry point имени парализующей ладони, как добавление взрыву способности создавать предметы ради тесла-пушки...
Первая категория протестирована и отполирована очень тщательно. До такой степени, что целые глобальные подсистемы отключались, если не удавалось их универсально вылизать до идеала (например, заклинивание оружия при стрельбе). Вторую категорию тестировали и дотачивали только в той мере, которая нужна для работоспособности в том самом единственном месте, где элемент использован. К чему я клоню, очевидно: эти перки-с-секретной-единичкой гарантированно работают только там и так, где и как их использовали авторы...
imod FadeToWhiteAndBackISFX playSound QSTFadeToWhiteB
imod это сокращение от ApplyImageSpaceModifier. Можно из оригинальных модификаторов взять кроме процитированного FadeToWhiteISFX [IMAD:0002ECC6], FadeInFromWhiteISFX [IMAD:00039563] или собственно темнящий FadeToBlackISFX [IMAD:000269C4]... Ну, понятно в общем куда копать.
подскажите, пожалуйста, какие текстуры (точнее их путь) или настройки в НифСкопе отвечают за оттенок кожи: мне, к примеру, очень бесят разноцветные лица афро-американцев. Хотелось бы подправить.
Во всём, что касается кожи, участие модели (то есть НифСкопа например) начинается и заканчивается на включении SHADER_SKIN в BSShaderPPLightingProperty - текстуры и прочие подкраски берутся из свойств расы и поверх того отделываются текстурами-подкрасками персонажа. Также следует знать про bLoadFaceGenHeadEGTFiles в главном INI игры и про багофичу движка, который правильно раскрашивает кожу только у NPC, созданных модулями ESM... Подробности вроде бы все есть в КАРТОТЕКЕ.
Как мне сделать так, чтобы каждый раз при покупке количество патронов было разное, например, один день 50 патронов, потом, после обновления ассортимента через несколько дней, 60 патронов и так далее. Чтобы значение количества было в определенном интервале.
Создаёшь Leveled item, вписываешь в список только один предмет - патрон в количестве одной штуки - ставишь флажок Calculate for each item in count, ставишь Chance none в 50%. Получился "полупатрон" - объект, который с равном шансом или патрон, или ничего. Кладёшь в торговый инвентарь, скажем, 50 нормальных патронов и 50 "полупатронов". При генерации соответствующей зоны получится случайным образом от 50 до 100 патронов.
Собственно, мой вопрос. Взялся править прически в моде, которые сейчас не работают.
Я бы сказал, что вопрос слегка чересчур расплывчатый. Цитата, что ты там приводил, относится к обсуждению эффекта "визуальной дырявости" причёсок - это то, что тебя беспокоит, или нет? Поясни, что именно не так. Желательно указать, откуда происходят проблемные причёски - возможно (немаловероятно), что где-то уже есть работающий отлаженный вариант ровно тех же косичек.
мне нужно увеличить броню у всех роботов на пустоши (в том числе и роботов добавляемых модами). Или на крайний случай увеличить здоровье... Есть ли такая возможность?
При наличии FOSE это был бы сравнительно простой мод. Один базовый эффект, один актор-эффект, один квест и один скрипт квесту. Сканер квеста отлавливает всех роботов в окрестности (поскольку участвуют роботы из неизвестных модов, как-то их модифицировать можно только таким путём - и именно поэтому нужен FOSE, стандартными средствами нельзя искать объекты) и развешивает по ним эффект, который хоть броню им увеличивает, хоть жизнь... Итого мод из четырёх объектов, маленький и несложный. Могу сделать, скажи только, что именно повышать роботам и на какую величину.
Изменение репутации для пользователя Ipatow
IpatowOffline
Сообщение №1179
| Тема: ВОПРОСЫ по моддингу
написано: 14 августа 2014, 22:28
| Отредактировано: Ipatow - 14 августа 2014, 22:31
Ipatow, прически из этого мода. Editor ID: CoolHair56, FO3idkrrr03, FO3idkrrr04 Всего 3 штуки.
Гмм... Мод - Muscle Girl Project by zomb_killer and Tigersan... Надо думать, резонно было бы брать всё из Muscle Girl Project - NV by zomb_killer and Tigersan, оно на четыре года лучше проработано... Причёски, как я понимаю, произошли из того дополнительного файла "Complete Hair Collection" размером полтораста метров... Ну, во-первых, эти три причёски очень давно известны, и мало кто не импортировал их из обливиона (или воровал у соседей). То есть их можно взять чуть ли не из любого причёсочного пакета, авторы бодибилдерши просто поленились привязать свой мод к причёсочному пакету (у игрока же диск резиновый, что ему полтораста метров того же самого?).
Дальше. Ты так и не сказал, в чём именно у тебя наблюдается проблема. Гадать не буду, но дам информацию общего характера. Дело в том, что у портированных в фолауты из обливиона причёсок (неважно, откуда они пришли туда - из Sims, как эти три, или ещё откуда) есть одна общая ахиллесова коленка. В обливионе причёска имела только одну форму - при надевании шляпы персонаж начисто лысел. В фолауте же у причёсок две формы: Hat и NoHat - и в зависимости от наличия шляпы отображается одна из двух веток модели. Как поступили торопливые импортёры? Вторую форму они схватили от какой-нибудь стандартной фолаутской причёски и вклеили как свою. И в NifScope всё выглядело отлично, но незаметно подкрался.. гмм.. назовём его ляпсус. Шляпную форму причёски они схватили вместе с её текстурой. Но дело в том, что фолаут ни капельки не интересуется текстурами, прописанными в модели причёски - вместо того, что прописано там, в игре используется та текстура, которая указана в объекте причёски в esm/esp - причём текстура там одна (то есть текстурный пакет - одноимённые _d, _n, _hl), и эта текстура используется для отрисовки обоих вариантов модели. Легко понять, что на одну из двух подмоделей чужая текстура ляжет сикось-накось. Внезапные дырки странной формы, размазанные по прядям бантики (особенно когда взята текстура от Ren со всеми ленточками-стразами) - часть ожидаемых эффектов. Скажу, как такое лечил я (я тоже грешен портированием причёсок из обливиона): склеивал текстуры для обеих подмоделей в один файл, подправлял развёртку, чтобы каждая из подмоделей использовала свою четверть этого файла, и вот этот файл-коллаж назначал и повсюду в модели, и объекту esm/esp. В результате игра корректно показывает причёску хоть в шляпе, хоть без шляпы.
Дальше. Это уже просто в порядке брюзжания. Как может заметить особенно внимательный игрок, оригинальные причёски фолаутов не длиннее, чем до плечей. Почему? Потому, что волосы в фолауте изготовлены из древесины твёрдых пород, они не эластичнее кувалды. Будь причёска длиннее, при лёгком повороте головы вправо-влево все эти длинные пряди врезались бы в плечи и всё прочее. Это безвредно, но некрасиво. Если ещё учесть, что головы иногда отрываются... Бывает, найдёшь такую улетевшую за забор голову, а она там приземлилась книзу темечком и целится своей длиннющей несгибаемой косичкой в зенит - наверное, готовится отражать инопланетное вторжение... На мой взгляд, любая длинноволосость в фолаутах пригодна либо для изготовления скриншотов, на которых всегда можно придать персонажу позу, в которой деревянность волос не бросается в глаза, либо для статуй в самой игре, поскольку статуи тоже замерли в фиксированной позе. На сколько-нибудь подвижных человеках длинные волосы - совсем не так красиво, как можно подумать, глядя в NifScope...
Я, конечно, понимаю, по каким причинам разные авторы скриптов избегают показывать свои скрипты... Но ты не поверишь, носколько легче увидеть ошибку в предъявленном скрипте, чем в спрятанном.
команды просто перестали выполняться, хотя все условия соблюдены
Не помню, хорошо ли дело в TTW обстоит со скрипт экстендером... Его функция отладочной печати при поиске жуков бывает очень кстати. Какие именно команды перестали выполняться? Все? Что говорит GetQuestRunning про квест? Что показывает ShowQuestVars про него же? Все эти дувансы перевернулись с нулей в единицы или так и остались нулями? Скрипт не выглядит так, чтобы совсем ничего не работало; поясни, какую именно неработоспособность ты видишь и как ты её видишь.
Может ли блок с книгами как-то мешать нормальной работе всего скрипта?
Вообще - да. Если какая-то из функций скрипта взрывается, движок немедленно прекращает работу этого скрипта. Всё, что расположено в скрипте после точки взрыва, обработано не будет; предшествовавшие команды в том цикле, в котором скрипт взорвался, отработают - но следующие циклы не наступят. Поскольку фрагмент про dooncePlmines стоит после книжек, а фрагмент про EquipItems нуждается в сторонних подталкиваниях (это ведь кто-то со стороны выставляет триггерной переменной единицу и инициализирует REF-ы) и на первом обороте скрипта, надо думать, отрабатывает вхолостую - если книжный фрагмент убивает скрипт с первого подхода, то названные два фрагмента никогда не отработают. Правда, ты говоришь, что книжный фрагмент работает прекрасно... Прекрасно работающий блок не может мешать работе скрипта.
Calling By Base Form (B): Syntax Example: FunctionName someParameters objectID:ref Examples: ; get the form at index 2 (3rd item) of the Alcholic Drinks form list ref form set form to ListGetNthForm AlchohlicDrinks 2
Most Fallout scripting functions use this calling convention, where all information is passed into the function as a parameter. These parameters can be base forms, integers, floats, form lists or references. Base forms can either be passed in using the Editor Name directly, or the base form could be put into a reference variable first. In some documentation you will see the term ObjectID rather than Base Form - these terms are mostly interchangeable.
можно ли использовать их (эти функции) для расширения функционала ShowMessage?
Можно, разрешаю!
Конечно, индекс это целое число, и float для него не самый удачный тип числа, а из списка вынимается FormID, который тоже нежелательно присваивать переменной типа float - но сама идея вполне работоспособная, FormID в списках могут храниться любого вида и происхождения (например, мне помнится случай, когда конструктивно использовался список ворлдспейсов).
все же знают, что если не взорвать Мегатонну, то и люкса в Тенпенни-Тауер не видать. Решил я сделать мод, позволяющий ...
Я когда-то тоже делал мод для башни, хотя другого рода - я отменял резню, если Мегатонна не взорвана... На две квартиры разом я не замахивался. Там надо к чертям все механизмы переделывать, скрипты переписывать, и цепочка зависимостей похлеще чем в той конструкции в магазинчике на Жюри-стрит, аукается в неожиданных местах и порой даже бьётся лбом о непреодолимые препятствия в движке игры. Твои правки затронули только небольшую часть всех этих перекрёстных зависимостей, далеко не две трети А если кроме необходимого ещё начать править всё, что там сделано криво (вроде того, что "мини-больничка", снимая радиацию, почему-то снимает не столько, сколько есть - казалось бы, чего уж проще - а ровно миллион, приводя к временно отрицательной радиоактивности и графическим глюкам в некоторых модах), то проще вовсе повеситься. Я не говорю, что ты напрасно всё это затеял - я говорю, что оно сложнее и геморройнее, чем кажется поначалу
Изменение репутации для пользователя Ipatow
IpatowOffline
Сообщение №1187
| Тема: Помощь по G.E.C.K.
написано: 26 августа 2014, 15:36
| Отредактировано: Ipatow - 26 августа 2014, 15:40
Открыть свой плагин в FO3Edit и в заголовке убрать ненужный мастер.
Уточню... Штатный вариант удаления неиспользуемого мастера в FO3edit - встать курсором в левой панели на имя модуля, правая мышка, Clean Masters. Вычёркивание строки из списка мастеров в заголовке - важный и нужный приём при проведении сложных хирургических операций над модулем, но то, что этот способ не исполняет дополнительных действий для обеспечения корректности ссылок, и плюс, поскольку хирург может провести корректировки так, как этого хочется ему, и минус, поскольку вся забота о корректности мода возлагается на хирурга.
Штатный способ удаления ненужного мастера при помощи GECK - в окне выбора модулей для загрузки (ещё ничего не загружая) встать курсором на имя модуля в левой панели, затем в правой панели встать курсором на имя ненужного мастера этого модуля и нажать кнопку Del. Внимание! Мастер будет вычеркнут в момент нажатия кнопки, никакие подтверждения не запрашиваются, никакие бэкапы не делаются. Объекты, ссылающиеся на вычеркнутый мастер, при этом остаются в модуле, и будут из него удалены только после того, как модуль действительно загружен в GECK и сохранён.
Почему у меня в разделе иконок для сообщений какая то неадекватная фигня?
Потому что у тебя среди объектов Miscellaneous -> Menu Icon нет ничего нестандартного. Напихаешь туда чего-то другого - будет показываться и что-то другое.
можно ли эффектом воздействовать на объекты? Допустим я хочу чтоб EMP уничтожал терминалы, пробовал добавить скриптовый эффект, но понял что при проверке на наличие объектов в поле взрыва неодушевленные вещи просто не учитываются. Есть какое то решение?
И да и нет.
Стандартный эффект EMP прописан как повреждение здоровья (плюс визуальная игра шейдером) у попавших под воздействие Creature типа Robot - и естественно, ни на кого, кроме существ типа робот, этот эффект не подействует.
Неодушевлённые предметы вполне могут получать урон - от взрывов, ударов, выстрелов - брось гранату в скопление автомобилей, и тебе понравится! Однако имеются два момента. Во-первых, этот неодушевлённый объект должен быть прописан как разрушаемый (включена и заполнена форма Destruction Data). Во-вторых, все эти разрушаемые объекты не имеют сопротивления урону - ни абстрактно-броневого Damage Resist, ни специфических резистов.
Резюмируя. Если переделать (сделать заново) и сам EMP (вероятно, придётся скриптовать взрыв - и там есть какие-то не очень мне понятные тонкости со скриптованными взрывами, недавно про них где-то рядом писали.. что-то относительно взрывов, шар которых не касается земли.. при большом радиусе шара, вероятно, проблемы не будет), и сами терминалы - можно добиться того, чтобы EMP терминалы уничтожал.
скрипт никак не хочет срабатывать, если в радиус emp не попадает хотя бы одна живая сущность. Обходного пути нет?
Ну как не быть.. Делаем взрыв, который в точке взрыва размещает невидимый объект-активатор. На этот активатор вешаем скрипт, который ищет вокруг все терминалы, проверяет расстояние до них и соответственно вырубает или не трогает, по окончании поиска самоликвидируется. Этакая тесла-пушка с дополнительными бантиками.
Я немного баловался с этими функциями, делал что-то вроде системы обнаружения для отслеживания объектов - активаторов, дверей, контейнеров, неписей, оружия и пр (вешал на них через скрипт шейдерные эффекты). Вроде все нормально работало, но использовать для серьезной игры не стал.
Оно отлично работает, я считай что фанатик их использования - и я про это и писал Darwinian, когда говорил "скрипт, который ищет вокруг все терминалы". Главное не перегружать цикл поиска медленными функциями (как чудовищный пример - Player.MoveTo с подгрузкой новых ячеек в цикле положит систему на пол), а при аккуратном использовании оно работает без сучка и задоринки. Ну, и эти функции по существу единственный способ подружить свой мод с другими заранее неизвестными модами, а это на мой взгляд архикритично...
Много чего можно поставить вместо. Кое-что могло бы даже сравниться по объёму функциональности с этими двумя (нет, Аманда хотя барышня и занятная, столько багажа с собой в игру не притаскивает, безоговорочно ниже рангом спутница)... Но здесь-то бодаются фанаты этих двоих, и про остальных лучше не надо, схлопочешь и от эмифилов, и от брисолюбов
Проверил, повторение не разрешено. А Как вообще правильно менять АИ пакеты?
Про повторение вопрос был в связи с тем, что это известный случай, в котором результат GetStage неопределённый... А вот руками самому проверить, что там за величина? В тот момент, когда должно в диалоге проверяться условие, открыть консоль и посмотреть, какое там значение наблюдается.
Менять пакеты по условиям - основной и естественный способ управления пакетами. Единственная альтернатива - сиюминутное временное подключение одного пакета - ориентирована на использование скриптами сложных алгоритмов.
При использовании пакетов есть некоторые неочевидные моменты. Проверка "а не пора ли поменять пакет" без специальных событий происходит не особенно часто - с интервалом секунд в десять. Событие тут это, например, явное завершение пакета - скажем, пакет был Travel и исполнитель достиг цели похода: текущего пакета больше нет, и новый выбирается немедленно. Состояние боя блокирует периодическую переоценку пакетов - то есть, скажем, не следует ожидать, что сам собой включится пакет с условием IsInCombat (допустим, план был - вообще SandBox, а в бою Guard на сейф - увы, весь бой бедолага будет сандбоксить). Загрузка зоны (фасттравел или просто ГГ в дверь вошёл) вызывает переоценку пакетов только для ограниченного набора текущих пакетов. Например, NPC с пакетом Follow мгновенно среагирует на выход ГГ в дверь - а NPC с пакетом Eat не заметит, что кто-то ушёл. Принудительная переоценка при помощи EvaluatePackage (evp) иногда оказывается недостаточной, может потребоваться ResetAI, но эта функция бывает и чрезмерной...
в пакетах в частности Follow, есть окошко в котором можно выбрать CombatStyle. Так что, во время выполнения пакета будет использоваться выбранный CS или я чего-то не понимаю?
Я не помню, чтобы я использовал или проверял эту функциональность, но и по описанию, и по встречавшимся мне примерам (моддеры задают значение этого поля - наверное, не для юмора) выглядит так. Приоритетнее ли это, чем SetCombatStyle? Мне кажется, что да.
какая настройка в сеттинге отвечает за скорость передвижения игрока в состоянии прицеливания (если она конечно вообще есть)?
Есть настройка про оружие не в руках (в кобуре/рюкзаке) - fMoveNoWeaponMult. Когда топор в руках - ты уже явно в кого-то метишь, поэтому специально про прицеливание нет параметра...
в оригинале везде стоит DEFAULT, причем без вариантов... Так вот что это за DEFAULT такой, где можно посмотреть как он реально выглядит? В списке CS его вроде как нет...
Когда написано DAFAULT - это поле даже не пустое/нулевое, в объекте пакета самого поля нет. И стиль во время действия пакета будет активен тот, что прописан в базовом объекте моба или назначен при помощи SetCombatStyle.
Мы Вконтакте
