Takirell

В данном случае - да, это невозможно прикрутить, но есть пример наркомании иного плана) Скриптовый эффект доппельгангера (квест на ДО, в Роще отражений), содержит в себе блок OnActivate, который, хоть и кроется писюнами со стороны компилятора CSE, но в игре то прекрасно работает)00) Хотя не должен. Как и не должен работать ванильный скрипт "RavenCamoranScript", в котором переменные объявляются прямо в блоках, а не в декларации оных - вначале скрипта.

Хмм... зайдите в Мои документы\My Games\Oblivion, найдите там Oblivion.ini и откройте его через блокнот (NotePad ++). В открытом документе поищите опцию "bUseRefractionShader" и поставьте значение "1", если оно у Вас иное. Сохраните изменения и проверьте работу эффекта у того кричера.

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

Шейдер-паки, сами по себе, неразборные. Есть речь идет о тех, что лежат в Data\Shaders. Можно установить куда-нить ванильную Облу и оттуда перетянуть оригинальные шейдеры, с заменой. Правда, вряд ли это что изменит, т.к любой OR, насколько я понял, меняет освещение откуда-то из движка через сеттинги (как это делал Оскуро, правда, через GS'ы внутри плагина). А что не так с шейдерами ORC? Если их не включать, то ничего работать и не будет. Ну да, картинка чуть другой становится, но это не из-за шейдер-паков. Вообще, Вам с таким вопросом стоило бы обратиться к автору ORC, он отвечает на вопросы, обычно.

Ну... ничего не мешает Вам попробовать задать НПС другие показатели и проверить, как НПС будет себя вести.

Если мне не изменяет память, то отрицательное значение предмета в инвентаре у НПС, будет постоянно удалять указанный итем из его сумки, даже если актер его подберет. Либо, как я еще где-то слышал, это позволит сделать предмет, в сумке у НПС, бесконечным (но это вряд ли).

А потом он ее слил)0))

Эта стадия у Вас будет обновляться постоянно. Нужно условие-ограничитель, типа вот так: Short sOnce Begin GameMode if (sOnce == 0) setstage NameQuest 1 Set sOnce to 1 Return Endif End

Имеете ввиду - режим камеры? Если да, то поможет OBSE-функция "IsThirdPerson". Она используется, как правило, в условии типа: if (IsThirdPerson > 0) ;Режим от третьего лица Else ;Режим от первого лица Endif

Самое примитивное, что приходит на ум, это функция SetActorAlpha, которая устанавливает прозрачность актера. 1 - полностью видимый, 0 - невидимый. Значение с плавающей точкой, может быть и 0.1, например. При этом, НПС все равно будут замечать персонажа так, словно он полностью видимый.

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

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

@jpsmith, Не то, чтобы затея совсем уж неосуществима, но это будет довольно сложно сделать + это, скорее всего, скажется на совместимости с другими модами. Придется перелопатить добрую часть механик Врат. Ко всему прочему, еще сперва нужно разобраться во всем этом :D 

Жаль, что когда я начал только осваивать все это ремесло, у меня не было кого-то вроде себя нынешнего :D   Ну, в общем, вроде как даже что-то получилось. Мод получился не шибко сложный, если понимаете синтаксис и в целом более-менее ориентируетесь в скриптинге, механика работы должна быть понятна. По идеи, должно работать не только в случае, если бьет игрок, но и когда атакуют другие НПС. Пробуйте) SkeletonWeakness.7z

Заданный Вами вопрос достаточно интересный, да и к тому же, я сам хотел сделать подобную систему для себя. Тут теперь есть мотивация, почему бы и нет? Зачастую лучше самому все сделать и объяснить на готовом, чем пытаться донести тупо словами. Раз уж мы тут задумали такой мод, то мне нужные точные данные... на сколько уязвимы будут скелеты к дробящему оружию, а также на сколько резистивны к стрелам. Все вот в этом духе) Концепт ясен, но ТЗ нет)

Я же сказал, что придется использовать 2 хандлера - этот и OnHealthDamage.   Вот я тоже о ней подумал. Можно проверять по имени актера, а можно и по пути меша.   Действительно бред, поскольку запускать хандлеры и вешать подобного рода блоки в скриптовый эффект - онанизм планетарного уровня. Игра ловит клин после таких приколов и скрипт-профайлер вообще виснет наглухо, переставая выполнять какие-либо скрипты.   Я, считай, за 10+ лет практики, многие извращения видел в скриптинге, но такое... впервые) Не мудрите и просто дайте мне время, я подумаю и попробую сделать отдельный esp-файл, как в прошлый раз.

OnHitWith, как и OnHit - ванильные блоки из игры, посему их хавает компилятор без проблем, если Вы вешаете скрипт с этим блоком на актера. А OnHealthDamage - уже новый блок, который работает ИСКЛЮЧИТЕЛЬНО как хандлер и никак иначе. Посему компилятор плюется ошибками при попытке впихнуть невпихуемое.   Да, в одной функции их не собрать, но в игру можно запускать хоть сразу 100 хандлеров, втч. и одного типа, но чтобы у них были разные исполняемые функции. Проблема в том, что от 100 таких обработчиков игре стремительно поплохеет, но от парочки наших - вряд ли. Просто я не хотел бы плодить лишние хандлеры там, где можно обойтись без них. Но тут, похоже, не тот случай... Похоже, чтобы ловить удары оружием, все же придется вводить еще один хандлер OnHitWith, в нем уже выдавать цели токен, который будет находится в сумке у НПС порядка 3-5 кадров, затем удаляться автоматически. По идеи, за этот момент, пока токен у НПС, OnHealthDamage должен будет успеть среагировать на наличие отметки у НПС и выполнить все необходимые рассчеты. Ну, в теории, оно, вроде бы как, должно и работать. Осталось только решить - как мы будем определять нежить и конкретные их типы?) Вариантов тут тоже несколько)

@jpsmith, OnHitWith - вещь, в принципе. Вроде как в новых версиях OBSE его поправили, но я не проверял. На счет OnHealthDamage... чессказать, я тоже пока не имею мыслей, как отфильтровать урон непосредственно от стрел, с уроном от дробящего оружия все +\- понятно.   Ну, сперва нужно написать саму функцию, которая и будет что-то у нас делать в этом типе хандлера: scn TestDamageFunction Float fDamage ​Ref rAttacker Ref rTarget Begin Function {fDamage, rAttacker} ;Определяем цель, по которой приходит урон Let rTarget := GetSelf ;Ограничиваем срабатывание хандлера в случае несоответствия некоторых условий (их всегда можно дописать при необходимости) if (IsFormValid rTarget == 0) || (IsFormValid rAttacker== 0) || (fDamage <= 0) Return Endif ;Получаем абсолютную величину урона Let fDamage := Abs fDamage PrintToConsole "Актер *%n* был атакован актером *%n* и получил *%g* ед. урона!" rTarget rAttacker fDamage Return End Теперь, чтобы эта функция работала, ее нужно зарегистрировать в игре. Как правило, все Event-хандлеры принято запускать при загрузке сейва единожды из квеста\токена или любого другого гейм-мода: Begin GameMode if (GetGameLoaded) || (GetGameRestarted) SetEventHandler "OnHealthDamage" TestDamageFunction Return Endif End В принципе, это все. Имею ввиду, что хандлер зарегистрирован и должен выплевывать в консоль текст, который мы писали, используя функцию PrintToConsole. Теперь уже нужно правильно писать саму функцию)