Лидеры

Анимация косячит. С Хитманской норм. KillerBuffaloRealoadFix.7z Не уверен, что стоит скидывать RA-Wasteland.json из моего архива, ибо версия его может отличатся, у меня не из обновы. Так же нужно пройтись по всем .json, открыть блокнотом, вбить в поисковике Johnsonn_CaravanShotgun и сменить первое слово на Hit, сохранить.

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

Большое спасибо! Подшил. Во вложении правленные актуальные json'ы, где фигурировал Johnsonn_CaravanShotgun. RA-MoreGear.json RA-Wasteland.json FalloutNV.json RA-CHAOTIC SUN.json RA-Factions.json RA-ModernGear.json

Предположу, что это связано с забагованными пакетами, как в том случае, где твари телепортировались в Гудспрингс. RA-Quests-NPCPackage-fix.esp Поправил пакеты для нескольких npc из этого мода, но если впредь этот же баг обнаружится, то надо сообщить об этом)

Спасибо! Подшил. Это которая? Анабель в этом квесте должна вроде у своей хибары тусоваться. UPD: поменял ей цвет волос.

Поменял труп второго. Оставляю пока, т.к. будут подшиваться апдейты ADAM.

Во время перезарядки или смены типа боеприпаса с этим оружием, если присесть или привстать на CTRL, происходит баг с застыванием оружия в определенном положении, как указанно на скриншоте. Модуль RA-Wastelands, ID - 2303117C

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

Это да) Самому нравится.

Так, почистил пару реплик с этой переменной. Вот это тоже удаляю: [INFO:300460D1] ('<тяжелое дыхание>' in GRUP Topic Children of DogmeatGoHome "DogmeatGoHome" [DIAL:30A460D0] for Followers "Quest to Handle Followers" [QUST:000371D1]) Фух, вроде всё подшил. Ненужное выпилил. Офигенная работа! Это столько древних конфликтов между модулями сразу починилось, столько лишних оверрайдов убралось.)

Только такую ошибку увидел: if player.getitemcount LloydsPlasmaPistol == 1 && && PlayerGotThePistol == 0 Сделано) Диалоги не будут доступны, поэтому сперва надо смотреть, есть ли диалоги с этими npc после конца квеста (привязаны ли они к квесту). В целом некритично, так как там всего две проверки будут раз в 5 секунд: if eval GetStage FloydQuest > 0 && GetQuestCompleted FloydQuest == 0 Меня всегда смущала чувиха с идиотским цветом волос, которая стоит у входа в Ривет-Сити) FloydQuest-fix.esp

Возвращаясь к самому первому посту в этой теме, наткнулся на интересную фразу: Конкретно, конечно, имею в виду пометку про переменные типа Long. По интересному стечению обстоятельств я таки столкнулся с этим типом. Самое забавное, что пришлось им пользоваться самому. Если вкратце, то нужен был код, позволяющий одну из восемнадцати переменных увеличивать до одного, а остальные семнадцать уменьшать до нуля. Если говорить совсем по-простому, представьте что перед вами 18 лампочек. В любой момент времени гореть может только одна. Пускай горит лампа номер 5. Если вы зажигаете, скажем, лампу номер 12, то 5ая обязана потухнуть. Как это сделать? Ну, из логичных вариантов на ум приходит запоминать, какая лампа горит в данный момент и при зажигании другой тушить её и запоминать новую. К сожалению, переводя это всё в код скрипта, необходимо будет писать 18 проверок а-ля "Если горела лампа номер 1, то потушить её. Иначе если горела лампа номер 2, то потушить её ..." И так далее. Решение рабочее, но учитывая ограничения на количество строк в скрипте, не самое элегантное. А есть и более плохой вариант (который и использовался изначально, когда переменных-"лампочек" было около пяти): не запоминаем вообще ничего, а просто постоянно выключаем все лампы, кроме нужной. Даже если лампа и не горела в данный момент. "Если зажгли лампу номер 1, то потушить лампу номер 2 потушить лампу номер 3 ... иначе если зажгли лампу номер 2, то потушить лампу номер 1 потушить лампу номер 3 ..." Думаю, смысл ясен. Очевидно, что этот вариант совершенно неприемлемый. Однако он имеет место быть, если была бы возможность/необходимость зажигать сразу несколько ламп. Тогда бы прошлый, более компактный вариант, не совсем бы подходил и раздувался бы по количеству строк. "Что же делать?" - подумал я. Хотелось бы иметь всего одну кнопку, по нажатию которой сразу бы выставлялись все 18 состояний ламп. И тут я придумал следующее: в качестве кнопки будем передавать обычное число, скажем, 4. Вы наверное спросите, а как число 4 может изменить состояние всех 18ти лампочек? Всё очень просто - переведите число в двоичную систему, тогда оно будет состоять только из нулей и единиц. Даже если вы про такую только слышали или вообще слышите впервые, то ничего не составит труда разобраться. Это абсолютно такие же числа, которыми мы пользуемся. Как работает наша система? У нас есть 10 цифр 0-9, и, когда мы доходим до следующего после 9ки числа, мы просто добавляем новый разряд и получаем 10. Также и там, только цифр всего 2. Но это всё теория, которую даже знать не надо - есть куча конвертеров в Интернете, где за 5 секунд вы сможете перевести любое число в любую систему. Вернёмся к нашим баранам. Что я там выбрал, 4ку? В двоичной системе это число записывается как 100. "И что же тебе это даёт?" - спросите вы. А всё очень просто, пускай 0 - это лампа выключается, а 1 - включается. Добавлю для наглядности нулей перед нашим числом, чтобы выровнять по по количеству лампочек: 000000000000000100. Соответственно, каждый разряд соответствует своей лампочке. Имея функцию, которая просто приравнивает лампочки к разрядам а-ля "Лампа 1 = 0 (т.е. тушим её) Лампа 2 = 0 ... Лампа 16 = 1 (зажигаем) ..." мы с лёгкостью избавили себя от 18ти проверок (или 18*18 изменений состояний по второму методу) и сократили код до 18 строк. Ну, конечно, их по факту чуть больше, но не в этом смысл. При этом мы можем "зажечь" абсолютно любую комбинацию из этих ламп (хоть мне и нужно было только по одной). Допустим, хочу зажечь 2ую, 7ую и 15ую лампы. Всё, что мне нужно - это записать последовательность 010000100000001000 и перевести это число в привычную нам десятичную систему. Вручную или через конвертер получаем 67592. Передаём это число в функцию ("нажимаем кнопку") и радуемся жизни. Горят ровно те лампы, которые были нужны. А главное - совершенно не надо думать, чтобы "запрограммировать" какую-либо комбинацию. Выписал в строку 18 цифр и перевёл из двоичной систему в десятичную. Удобно, красиво, лаконично на мой взгляд. Проблема лишь в том, что с увеличением количества лампочек, увеличивается и количество комбинаций. 67592 явно больше, чем 32767 (см. цитату - это граница integer'a). Отсюда и применение переменной типа Long. Но он тоже не вечен - максимум в теории мы можем завести 31 лампочку (2147483647 = 1111111111111111111111111111111 (31 символ)). А если работаем конкретно с ГЕККом, то у функции, работающей с разрядами, к сожалению, есть ограничение на примерно 20 разрядов-"лампочек". Собственно, пожалуй, это всё, что я хотел сегодня рассказать. Хотелось бы почитать ваше мнение - достаточно ли понятно я всё рассказал, может вопросы какие остались? Придумали/знаете другой способ для зажигания конкретно одной лампочки? Поделитесь им, не стесняйтесь. Да и насколько интересно это было читать? А то, может, я время от времени буду подобными интересными моментами делиться. Или наоборот не буду, если вам не понравилось.