Как убрать ограничение магазина у оружия в 255? Максимум, который можно выставить в ГЕККЕ или Эдите!
Там, должно быть, один байт под значение. В байт большее число поместиться не может. Тогда превышение возможно только качественное - вида "расход патронов на выстрел: ноль"...
Изменение репутации для пользователя Ipatow
IpatowOffline
Сообщение №1743
| Тема: Бункер модмейкеров
написано: 11 марта 2018, 09:36
| Отредактировано: Ipatow - 11 марта 2018, 09:39
В фолаутах есть вещи, которые сделать легко. Изменить вес фляжки, сдвинуть в сторону плакат на стене. Делается штатными стандартными средствами, часто даже мод не нужен.
Есть вещи, которые сделать невозможно. Заплести волосы в недеревянную косичку, научить неписей экономить патроны. То, что прошито в движок настолько намертво, что может быть изменено только заменой движка, по сути заменой игры на другую.
Между этими категориями широчайший промежуток. Какие-то моменты между "легко" и "невозможно" исполняются штатными средствами, пусть неуклюже (динамические навмеши приходят в голову), большинство доступно только благодаря экстендеру (увидеть собственные ботинки от первого лица например).
Экстендер радикально расширяет инструментарий, порой прямо новые горизонты открывает. Иные сделанные на экстендере моды настолько естественны и удобны, что отказаться распробовав невыносимо...
И всё же... При всей привлекательности экстендера моддерская фантазия настолько часто и повсеместно бьётся локтями об "невозможно", что руки опускаются. Да, конечно, с экстендером доступно множество потешных затейливых возможностей. Однако, объективно глядя, это всё косметика, не затрагивающая суть вещей. Можно нарисовать дураку умное лицо - но нельзя сделать дурака умным. Так, может, и рисовать не стоит?..
У меня даже при наличии указанного файла экзешник не показывается
А как отслеживаются значения, прописанные там? Когда значение есть, его же нужно в каком-то модуле видеть - например, чтобы скопировать к себе для оверрайда. Мебельные маркеры там или мало ли с каким фундаментом захочется поиграться...
Ну а как же! Цивилизация пришла в окончательный упадок, общество стремительно катится в пропасть, будущее совершенно беспросветно. Вон и Цицерон то же самое сказал!!
Изменение репутации для пользователя Ipatow
IpatowOffline
Сообщение №1746
| Тема: Скрипты
написано: 22 марта 2018, 04:51
GetStage XXXX >= 2 AND GetStage XXXX < 3 AND Вот интересно - зачем так сделано? Что можно воткнуть между 2-й и 3-й стадиями? Почему не поставить просто "Стадия равна двум"?
Формально "целое значение больше или равно двум и притом меньше трёх" в точности означает "целое значение равно двум", каково бы ни было происхождение этого целого значения. В то же время разработка движется инкрементально, и кроме релизных в последовательности бывают тестовые версии. Возможно, в какой-то момент там были не двойка и тройка, а двойка и семёрка. Да, в момент смены семёрки на тройку вроде бы идеально совсем выкинуть второе условие, а в первом сменить знак на равенство - но! Если автор предполагает двльнейшую разработку, которая будет ещё не раз нуждаться в отладке, а для отладки там должен быть всё-таки диапазон, а не точная цифра... Тогда лучше держать два условия, чтобы уменшить количество исправлений (и опечаток) при очередном переходе от релиза к бете и обратно. Это только один из вариантов, как и для чего могла образоваться такая конструкция... Конечно, могла быть и совершенно нелепая причина вроде того, что автор по религиозным соображениям не признаёт равенства!
Изменение репутации для пользователя Ipatow
IpatowOffline
Сообщение №1747
| Тема: Скрипты
написано: 22 марта 2018, 07:34
| Отредактировано: Ipatow - 22 марта 2018, 07:36
Никогда не сталкивалась с этим ранее и ни за что бы не подумала, что если в результ-скрипте ОДНОГО квеста объявлена переменная, а в ДРУГОМ квесте в результ-скрипте есть переменная с таким же именем - то это считается одной, общей переменной.
Такое распространяется на все безымянные скрипты - из диалогов, из пакетов, из стадий квестов, из перков... Я не знаю, все ли они считаются частью одного и того же скрипта - вроде бы объектного на мобе, я помню пересечения с ним по именам переменных - но по меньшей мере многие. Даже если на объекте скрипта нет - всё это исправно дописывается к пустому скрипту. Как я понимаю, это фундаментальное свойство скриптового двигателя фолаутов - исполняются только именованные скрипты. В случае со скриптом реплики - когда реплика может произноситься разными персонажами - это должно порой вызывать волшебные происшествия, поскольку в объектных скриптах разных персонажей одинаково могут называться сильно разные по смыслу и даже типу переменные.
есть 2 гуля (бродяга и светящийся), у одного Health = 400, у другого 440. Level у первого 15, у второго 18. Флаги стоят только Walks, Respawn, No Low Level Processing, у обоих одинаковые. А в игре получается, что у светящегося 440 HP (или около того), а у бродяги - превышает 3000.
Мне кажется, описаны не совсем стандартные существа из игры, и параметры указаны приблизительные... А детали там бывают важны. Было бы намного определённее, если бы ты показал что-нибудь наподобие...
(серое это мне было лень отключать лишние моды, к делу не относится) SetConsoleOutputFilename >> 'Ghoul.txt' PlaceAtMe 9FAFB Дикий гуль - бродяга radiation level is 0.00 Дикий гуль - бродяга radiation level is 0.00 PRID FF0012E0 SetUnconscious 1 [GUN] Дикий гуль - бродяга [FF0012E0] got effect GetAVInfo Health GetActorValueInfo: Health on Дикий гуль - бродяга ...Current Value: 80.00 Computed Base: 80.00 ...Base Value components: ......Reference Base Value: 80.00 (creature) ......Derived Value: 0.00 (Ignored) ...Modifiers: Temp: 0.00 Perm: 0.00 Damage: 0.00 PlaceAtMe 1CF7B Светящийся гуль radiation level is 0.00 Светящийся гуль radiation level is 0.00 [GUN] Светящийся гуль [FF0012E4] got effect [GUN] Финн [09000802] change: [00000000] -> Пневматическое ружье [00004323] [GUN] Финн [09000802] shoots Пневматическое ружье [00004323], has 34 ammo and 4 clips [GUN] Финн [09000802] got clip for Пневматическое ружье [00004323]; ammo: 134, spare clips: 3 [Waifs] Алиша [09000801] OnStartCombat, leash 0 [Waifs] Алиша [09000801] leash set, calling SetStage QJ13WaifsQuest 1 [Waifs] SetStage 1 (count 0) PRID FF0012E4 SetUnconscious 1 GetAVInfo Health GetActorValueInfo: Health on Светящийся гуль ...Current Value: 234.88 Computed Base: 240.00 ...Base Value components: ......Reference Base Value: 240.00 (creature) ......Derived Value: 0.00 (Ignored) ...Modifiers: Temp: 0.00 Perm: 0.00 Damage: -5.12 qqq Bye.
Рабочая версия решения твоей загадки - мобы переменного левела начиная с некоторого прекрасного момента жизнь на уровень стали умножать, вот и получаются толстые тысячи.
Успел сделать только такой скрин, ибо после этого команда PlaceAtMe напрочь перестала работать, требуя референс.
Включение журнала в игре вредное, поскольку запускается функция только по короткому имени (SCOF), а в сам лог пишет длинное имя. Для функций с синтаксисом как у PlaceAtMe нужно или явно указывать референс (e.g. Player.PlaceAtMe FormID [number etc.]), или выбирать текущий референс функцией PickRefByID/PRID, или хоть мышкой в какой-то референс ткнуть...
По крайней мере стало видно, что столько жизни это базовое, а не результат ModAV... Но явно ведь умножение сработало. Если невооружённым глазом фраг PC Level Mult не виден, надо искать, кто и когда его включает.
формула получается "Уровень игрока * поле Level Mult * базовое HP кричера"?
Когда у моба переменный уровень, получается "УровеньМоба * БазовоеЗдоровьеМоба", а уровень моба при этом получается вообще-то из уровня ГГ, но с поправкой на Calc Min и Calc Max.
как сделать, чтобы было фиксированно (хотя бы примерно, плюс-минус), скажем у гуля обычного HP игрока * 1,25, у бродяги * 1,5 у светящегося * 2. Или это в принципе невозможно?
Если мы хотим, чтобы у кричи уровень был переменный (мало ли зачем), но количество жизни у её экземпляров было A + (B * уровень), то в качестве номинальной жизни мы дадим криче только B, а основное A выдадим в виде способности с AV-эффектом "плюсжизнь".
то есть берем эффект "плюсжизнь" (какой у него FormID, кстати) и вешаем на кричера с кондишенами, проверяющими уровень игрока, так? Например, уровень > 10 - +200 к базовой жизни, > 20 - +400 к базовой жизни. Значения после плюса варьируются, в зависимости от НР подобных существ в оригинале, т.е. у обычного гуля плюсы будут совсем небольшие, а вот у светящегося - уже намного весомее. Но писать подобные эффекты под всех сильных и страшных по ЛОРу существ в моде (а их там с десяток наберется, а то и больше) - ну такое себе. Поэтому я и спросил, как это реализовать через "процедуру" Level Mult и связанные с ней поля, ибо это в разы проще.
Не особенно важно, какой там у стандартного маг.эффекта повышения здоровья FormID, да их может быть и несколько стандартных. Никто не мешает сделать собственный эффект по образцу всех этих стандартных плюс-что-то и минус-что-то - их на всякий случай куча там прописана ради алхимии (кулинарии, допингов т.п.) и энчантов, даже не все используются. Всё равно способность делать, почему бы и эффект рядом не изготовить. Эффекты с архетипом Actor Value простейшие, а поскольку размер поправки указывается при вписывании эффекта в способность, эффект тебе нужен ровно один.
Стандартная механика игры допускает только один вид переменного здоровья, и оно привязано к переменному уровню существа. Если тебе надо точно привязаться к уровню ГГ - ставишь флаг PC Level Mult, множитель левела устанавливаешь в единицу, не ставишь верхний-нижний предел, и получаешь моба, уровень которого равен уровню ГГ. Номинальное здоровье существ всегда прямо пропорционально их уровню. Если тебя устраивает, что твой гуль при 20 уровне ГГ ровно в два раза толще твоего гуля при ГГ 10 уровня и в 10 раз толше твоего гуля у ГГ 2 уровня, то именно это и делает стандартный механизм.
Я предложил менее радикальный вариант, в котором толщина гуля с уровнем растёт, но не в десятки раз. Если способностью дать гулю, допустим, 400 ОЗ, одновременно прописав номинальное умножающееся здоровье в 5 ОЗ, на первом уровне ГГ это будет гуль толщиной 400+(1*5)=405 ОЗ, на 15 уровне ГГ станет 400+(15*5)=475 ОЗ, на 45 уровне ГГ всё ещё 400+(45*5)=625 ОЗ. То есть рост наблюдается, но сумасшедшие тысячи не образуются. От способности не требуется что-то проверять, она всегда даёт ровно 400.
Если использовать только стандартную механику, но уменьшить множитель уровня, то уровень существа будет отставать от уровня ГГ, и, соответственно, ступенчатое увеличение здоровья будет случаться реже. Скажем, при коэффициенте 0.3 и номинальном здоровье 400 ОЗ существо будет иметь 1200 ОЗ для ГГ 10 уровня (поскольку уровень существа станет 3) и 6000 ОЗ для ГГ 50 уровня (означающем 15 уровень существа). Даже если уровень существа повышается медленно, мне всё равно нелепо, что на 15 уровне оно впятеро толще себя же 3 уровня...
Если к предыдущему примеру кроме уровневого множителя 0.3 добавить пределы - например, минимум 2 и максимум 8 - то сначала здоровье существа будет зафиксировано на 800, пока вычисленный уровень не превысит двойку (это случится на 10 уровне ГГ) и значение не подскочит до 1200 ОЗ, а дальше оно будет ступенчато расти, пока уровень ГГ не достигнет 27 (когда уровень существа упрётся в 8), и с этого момента выше 8 уровня, то есть 3200 ОЗ, существо толстеть не будет. Это, собственно, штатный подход авторов игры, и сумасшедшее утолщение он предотвращает (не давая существам бесконечно повышать уровень), но меня морщит даже разброс толщины всего в два-три раза...
если в качестве минимума и максимума пределов указать, скажем, 1 и 30 при мульте 0,1 и базовом здоровье в 270, как это будет расти и какой уровень HP и уровень кричера будут, когда у ГГ будет уровень 30?
Единица в минимуме эквивалентна отсутствию минимума, меньше первого уровень быть и так не может.
Пределы 1 и 30 означают разницу между минимальной толщиной и максимальной в 30 раз (здоровье существ пропорционально уровню).
Верхний предел уровня в 30 при множителе одна десятая означает, что до максимума существо дорастёт на 300 уровне ГГ. Не уверен, что даже при сорванном ограничителе уровень ГГ можно поднять выше 255... Трёхзначный уровень мне представляется несусветным.
При множителе одна десятая на тридцатом уровне ГГ уровень существа будет 0.1*30=3. На третьем уровне при номинальном здоровье 270 существо будет иметь 3*270=810 ОЗ.
Изменение репутации для пользователя Ipatow
IpatowOffline
Сообщение №1756
| Тема: ВОПРОСЫ по моддингу
написано: 25 марта 2018, 14:52
| Отредактировано: Ipatow - 25 марта 2018, 14:54
спокойно можно выставить пределы 1 и 3 и этого будет достаточно для получения на 30 уровне ГГ уровня здоровья кричера в 810?
Я бы сказал, что спокойно можно убрать к чертям переменный уровень вместе с переменным здоровьем, просто снять галку PC Level Mult и не заморачиваться. Ну плохо сделали беседковцы, когда устроили эту пропорциональность. Редиски. У них же у самих же практически везде используется формула "база плюс уровень с множителем", у тех же басурманов гуманоидов NPC здоровье по такой схеме вычисляется, какого лешего существам навесили ущербную систему?! Лучше отключить её под корень. А если зачем-то всё-таки некоторый рост параметра желателен, то стоит исполнить его с использованием правильной формулы - и я уже писал, как это сделать...
"Как сделать "взрыв" из крышек, при убийстве в голову?
Обвешать всех присутствующих скриптом, который при смерти пациента будет проверять, не ГГ ли IsKiller и не в голову ли GetHitLocation - ну и дальше по результатам...
Создать эффект, при котором игроку будут добавляться крышки при килле непися, и повесить его на этот ствол.
Может быть, я путаю, но как будто эффект оружия срабатывает до того, как наносится урон - то есть эффект выстрела не может знать, что этот выстрел смертельный, потому что в момент эффекта выстрел ещё никого не убил.
Решил сделать в ГЭККе плазменный пистолет, урон которого зависел бы от степени радиоактивного облучения. Можете подсказать, как создавать подобные эффекты для оружия
Если не упираться в именно магические решения, я бы предположил, что проще всего, наверное, как-то так это исполнить:
GRUP Top "PERK" ……PERK - Perk [01000EA6] …………Record Header ………………Signature: PERK ………………Data Size: 348 ………………Record Flags ………………FormID: PERK - Perk [01000EA6] ………………Version Control Info 1: 09 40 00 00 ………………Form Version: 15 ………………Version Control Info 2: 00 00 …………EDID - Editor ID: RadPlasma …………DESC - Description …………DATA - Data ………………Trait: No ………………Min Level: 0 ………………Ranks: 1 ………………Playable: Yes ………………Hidden: Yes …………Effects ………………Effect ……………………PRKE - Header …………………………Type: Entry Point …………………………Rank: 0 …………………………Priority: 0 ……………………DATA - Effect Data …………………………Entry Point ………………………………Entry Point: Calculate Weapon Damage ………………………………Function: Set Value ………………………………Perk Condition Tab Count: 3 ……………………Perk Conditions …………………………Perk Condition ………………………………PRKC - Run On: Perk Owner ………………………………Conditions ……………………………………CTDA - Condition …………………………………………Type: Greater than …………………………………………Comparison Value: 400.000000 …………………………………………Function: GetActorValue …………………………………………Parameter #1: Rad Level …………………………………………Parameter #2: 00 00 00 00 …………………………………………Run On: Subject …………………………………………Reference: 0 ……………………………………CTDA - Condition …………………………………………Type: Less than or equal to …………………………………………Comparison Value: 600.000000 …………………………………………Function: GetActorValue …………………………………………Parameter #1: Rad Level …………………………………………Parameter #2: 00 00 00 00 …………………………………………Run On: Subject …………………………………………Reference: 0 …………………………Perk Condition ………………………………PRKC - Run On: Weapon ………………………………Conditions ……………………………………CTDA - Condition …………………………………………Type: Equal to …………………………………………Comparison Value: 1.000000 …………………………………………Function: GetIsID …………………………………………Parameter #1: WEAP - Weapon [00004343] "Плазменный пистолет" …………………………………………Parameter #2: 00 00 00 00 …………………………………………Run On: Subject …………………………………………Reference: 0 ……………………Entry Point Function Parameters …………………………EPFT - Type: Float …………………………EPFD - Data ………………………………Float: 200.000000 ……………………PRKF - End Marker ………………Effect ……………………PRKE - Header …………………………Type: Entry Point …………………………Rank: 0 …………………………Priority: 0 ……………………DATA - Effect Data …………………………Entry Point ………………………………Entry Point: Calculate Weapon Damage ………………………………Function: Set Value ………………………………Perk Condition Tab Count: 3 ……………………Perk Conditions …………………………Perk Condition ………………………………PRKC - Run On: Perk Owner ………………………………Conditions ……………………………………CTDA - Condition …………………………………………Type: Greater than …………………………………………Comparison Value: 200.000000 …………………………………………Function: GetActorValue …………………………………………Parameter #1: Rad Level …………………………………………Parameter #2: 00 00 00 00 …………………………………………Run On: Subject …………………………………………Reference: 0 ……………………………………CTDA - Condition …………………………………………Type: Less than or equal to …………………………………………Comparison Value: 400.000000 …………………………………………Function: GetActorValue …………………………………………Parameter #1: Rad Level …………………………………………Parameter #2: 00 00 00 00 …………………………………………Run On: Subject …………………………………………Reference: 0 …………………………Perk Condition ………………………………PRKC - Run On: Weapon ………………………………Conditions ……………………………………CTDA - Condition …………………………………………Type: Equal to …………………………………………Comparison Value: 1.000000 …………………………………………Function: GetIsID …………………………………………Parameter #1: WEAP - Weapon [00004343] "Плазменный пистолет" …………………………………………Parameter #2: 00 00 00 00 …………………………………………Run On: Subject …………………………………………Reference: 0 ……………………Entry Point Function Parameters …………………………EPFT - Type: Float …………………………EPFD - Data ………………………………Float: 100.000000 ……………………PRKF - End Marker
Я вообще всю жизнь думал, что это называется RadiationRads, а Rad Level первый раз вижу...Интереснее другое: почему там Set Value и как оно работает. Что, просто устанавливает урон от оружия в руках у ГГ строго 100 либо 200 ед? Почему не множитель, логичнее же? В обеих играх (без дополнений) для такого Entry Point'a используется только Multiply Value.
Почему в дамп оно выдалось как Rad Level не скажу, в списке AV для функции я выбирал (там выбор из существующих, от руки не вписать) именно RadiationRads.
Какую именно операцию с уроном проводить - редактирующий легко видит доступные варианты (опять же, выбор из списка) и может заменить на более соответствующее замыслу. Суть демо-перка в том, что мы можем изменять урон, проверяя какие-то параметры ГГ и параметры его оружия - легко можем, например, удвоить урон всей знергетики для интеллектуалов или уполовинить рукопашный урон у слабаков - при этом оно не требует уникальности оружия (предлагавшийся скриптовый вариант правил все плазменные пистолеты, когда один из них в руках облучённого ГГ).
Понятно, что оригинальный автор вопроса хотел сделать особенный пистолет; он может быть ещё чем-то особенный - стрелять другим цветом или ещё как-то выделяться. Может захотелься иметь таких красивых пистолетиков два или три - для раздачи, например, напарникам. В случае со скриптовым вариантом урон будет прыгать у всех, когда облучается ГГ - но перк затронет только выстрелы, исполняемые ГГ, сколько бы народу ни держало в руках точно такие же стволы.
вот строчка:Player.SetAttackDamage 100 WeapPlasmaPistol Назначается дамаг вроде как плееру, почему тогда дамаг будет пропорционально как у ГГ расти так и у мобов? Я просто до этого понимал, что указывая плеер референс получателем, то именно плеер и получает ? Разве нет?
В документации на скрипт экстендер есть раздел Function Calling Conventions, в котором обсуждаются варианты синтаксиса. Некоторые функции можно использовать только в референс-варианте, пример SomeRef.GetBaseObject. Некоторые функции никакого отношения к референсам не имеют; использование референса может не считаться ошибкой, но, скажем вот тут референс неуместен: SomeRef.IsKeyPressed 33. Для большинства функций можно использовать любой из вариантов; например, допустимо и SomeRef.GetItemValue, и GetItemValue SomeRef. Однако если смешать эти два синтаксиса и написать FirstRef.GetItemValue SecondRef, одно из двух окажется лишним (из которого базового объекта должна браться цена, если они разные?). Я предполагаю, что будет проигнорирован префиксный объект - хотя бы потому, что во многих контекстах этот объект присутствует по умолчанию (в объектных или эффектных скриптах - очевидно), все вызовы функций оказываются с подразумеваемым префиксом.
В твоей строчке SetAttackDamage меняет значение номинального урона в базовом объекте. Не в экземпляре - у экземпляра просто нет такого значения (зато, например, есть "остаток патронов в обойме" - не знаю, умеет ли добираться до этой цифры NVSE, но её можно явно указывать при размещении экземпляра в мире вручную). Именно поэтому изменение затрагивает все экземпляры плазменного пистолета: каждый из них берёт номинальный урон у базы.
Изменение репутации для пользователя Ipatow
IpatowOffline
Сообщение №1762
| Тема: Скрипты
написано: 15 апреля 2018, 13:01
Запускаю GECK с правами администратора через ярлык с припиской в конце " nvse_loader.exe" -editor " не знаю, достаточно этого, или нет.Т.е., в принципе крманда "setgs" должна и в скрипте тоже, не только в консоли? На неё нет каких-то ограничений?
Во-первых, с запуском всё правильно.
Во-вторых, ты отрыл мне глаза на особенности вегасовского экстендера, см. комментарий в конце описания SetGameSetting. Нет ли странностей с использованием консольной функции из скрипта - в данном случае в виде con_SetGameSetting, сказать не могу, но некоторые подобным образом завёрнутые функции игру клинили (они работали, но после них всё оказывалось печёнками наружу). Насколько надёжнее в этом смысле экстендер-плагиновская функция Console - тоже не знаю, но по крайней мере эти варианты компилироваться будут, и их работоспособность можно будет протестировать.
На практике я работал только с FOSE и пользовался только SetNumericGameSetting, которая в скриптах сразу была уместна.
Так как все же решить вопрос, чтобы моя модель брони использовалась только игроком или определенным НПС ...
В модах вида Body By Race обычно встроена и система Armor By Race... Не видел стопроцентно доведённых до ума модов такого направления (и сам не доделал то что начинал), но если не требуется глобальное универсальное решение, под частный случай (небесконечный набор рас/одёжек) можно любой из них подстроить.
если гг афро-американка (мод для женских персонажей), сняла броню с азиатки и надела ее, то тело гг будет выглядеть как у азиатки, если же купила в магазине, то как европеоид.
Я не помню, какие из этих модов как работали, но оно как бы очевидно, что одёжки должны быть "активные". Не обязательно сами, но где-то должен быть скрипт, который проверяет, что на персонаже надето и не надо ли это заменить на то, что соответствует его расе - и при необходимости заменяет. Главная проблема тут - что делать с одёжками, неизвестными моду, а стандартное (известное) само подменится расовым вариантом.
вопрос по поводу текстуры силовой брони t-45d. Дело в том, что изначально в игре на левом наплечнике данной брони присутствует эмблема "Братства Стали", но когда я наношу эту текстуру на броню в Nifskope'е, то эмблема почему-то не отображается, будто ее там быть и не должно. Соответственно, раз я не вижу ее, то и убрать с текстуры тоже не могу. Прошу вас, пожалуйста, объяснить мне, как убрать эту эмблему с текстуры.
Это резонно сделать так же, как снимается в плаща шерифская звезда. То есть отредактировать список Biped Model List соответствующей одёжки, в котором перечислены все элементы, из которых составлена эта броня - и вычеркнуть тот Armor Addon, который не нужен.
Размер базового кричера (который является основой для всех своих копий в мире) меняется в его настройках на второй вкладке Stats. Там в поле атрибутов есть параметр Base Scale. Если нужно поменять размер одного, конкретного, существа - то находишь его реф-копию в локации и в настройках, на первой вкладке 3D Data меняешь параметр Scale.
Возможно, я путаю - с масштабами я сам экспериментировал на гуманоидах - но если логика Gamebryo последовательна, это же должно быть и у существ. Дело в том, что масштаб эталона (базового объекта) и масштаб экземпляра (референса) визуально неотличимы, но работают они немного по-разному. Например, человек или болотник, заходя в воду по пологому склону, в какой-то момент перестаёт идти и начинает плыть - и эта глубина зависит от его базового роста, а не от сиюминутного. Увеличь болотника в сто раз - он всё равно "поплывёт" в речке, которая ему сейчас по щиколотку (плыть будет над водой, естественно). Уменьши человека в сто раз - он будет добросовестно шагать по дну и не испытывать недостатка кислорода, даже если он на глубине в три своих нынешних роста. Этот же трюк будет наблюдаться при протискивании в узкие/низкие двери и т.п. - "эффективный" масштаб будет браться от базового объекта. При этом речь не совсем о коллизии - например, стрелять в плывущего над речкой мегаболотника нужно именно в ту летающую тушку, а не в воду, где по мнению части движка он плавает...
Как невозможно не заметить, глядя на начинку игры, авторы её делали работу довольно неряшливо и неизящно. Идеи были в основном интересные и толковые, но реализация через раз обернулась конфузом... Лютое уважение вызывают обсидианы, которые сумели добавить и изменить заметную часть механики так, что это нагромождение гибких костылей и велосипедов не рухнуло! По существу вопроса - именно iXPRewardKillOpponent ничего не делает, это опечатка. Этого сеттинга вообще не должно было быть - но поскольку тот из авторов, кто отвечал за проверку на определённом этапе, не был уверен, что неправильный параметр никто из коллег не успел использовать, он на всякий случай удалять его не стал, а значение ему дал от iXPRewardKillOpponentAverage. Ближе к финалу разработки, когда код было править уже поздно, но порегулировать сеттинги в последнюю секунду было надо, отвечающий за это автор проигнорировал неправильный сеттинг, но исправленный iXPRewardKillOpponentAverage в ESM положил, из-за чего iXPRewardKillOpponent больше не совпадает ни с кем из законных iXPRewardKillOpponent*. Ну и нестрашно, он всё равно не нужен.
Да, а то, что сеттингам iXPLevelKillCreature* соответствуют iXPRewardKillOpponent*, хотя напрашивались бы iXPRewardKillCreature* - это очередное проявление той неряшливости, вреда от него нет, просто неизящно и может кого-то сбить с толку...
Не совсем. Так же, как интернет в основном творение криворукого микрософта, текстурирование растёт из нвидиа и автодеска. В своём приложении (игре) ты можешь по-своему что-то отсортировать или запаковать - совместить, например, светоотражение с прозрачностью - но когда дойдёт вплотную до реальности, графический процессор ожидает определённого формата, и с тем же форматом работает девелоперский софт. Если хочется альтернативы - это можно, но никуда не деться от постоянного преобразования между своим форматом и тем, который требуется реальному миру. Чем дальше от реальности своя версия, тем больше мощности будет отжираться на нелепые преобразования, тем тормознее будет приложение. Многие авторы предпочитают не добавлять своим продуктам навесных тормозов, обычно хватает и неизбежных...
Мы Вконтакте
