Не надо делать апдейты с периодом 0.001 с, это мало того, что бессмысленно, так еще и очень вредно.
1)Все твои скриптовые ресурсы будут заняты ненужной проверкой здоровья актера. 2) Даже простая проверка здоровья вряд ли сможет выполняться с такой высокой частотой (1000 Гц).
Если ты не уверен, что апдейт с периодом ниже 0.1 тебе ЖИЗНЕННО необходим, и это точно нужно для правильной работы кода, то никогда не опускайся ниже 0.1 с.
Изменение репутации для пользователя Multigone
MultigoneOffline
Сообщение №1052
| Тема: Вопросы по скриптам Papyrus
написано: 5 ноября 2022, 22:35
| Отредактировано: Multigone - 6 ноября 2022, 16:15
1) ставишь базовую простую задачу (основу); 2) реализуешь ее в коде, проверяешь его работу; 3) если все хорошо, расширяешь в коде функционал и возможности основы, учитываешь разнообразные условия ее работы, если это необходимо.
Так вот, если основа работает хорошо и нет необходимости что-то менять, то менять / добавлять ничего и не нужно.
По поводу реализации большого числа проверок. Там вообще ничего сложного, нужно просто знать, что... * порядок выполнения кода всегда сверху вниз (исключая цикл WHILE) до конца события или функции; * порядок операторов IF ELSEIF ELSE ENDIF должен соблюдаться (назовем это элементарным блоком проверок); * в промежутки ПОД каждым оператором можно поставить любое количество действий или других блоков проверок, или не ставить ничего; * оператор ELSEIF может повторяться несколько раз подряд (IF ELSEIF ELSEIF ELSEIF ELSE ENDIF). Он служит для проверки условия, если проверка вышестоящего оператора этого блока не выполнена (под проверкой подразумевается одно или несколько условий, связанных логическими операторами && или ||); * в блоке проверок, первая выполненная проверка допускает к действиям, написанным под этим оператором. Остальные проверки этого блока не осуществляются вообще;
* оператор ELSE автоматически выполняется, если ни один вышестоящий оператор не прошел свою проверку.
* После того, как все действия внутри "успешного" оператора завершены, машина переходит к действиям, следующим за ENDIF этого блока проверок.
* операторы ELSEIF ELSE необязательны, и их можно не включать в блок;
* если несколько условий связаны логическим И (&&), то проверка проводится до первого НЕВЫПОЛНЕННОГО условия, а остальные не проверяются вовсе. Например, А > 0 && В() < 3, где В() - функция, результатом своей работы возвращающая число; и если А не выполняется, то функция В() запускаться НЕ БУДЕТ, чтобы сравнить свой результат < 3;
* если несколько условий связаны логическим ИЛИ (||), то проверка проводится до первого ВЫПОЛНЕННОГО условия, а остальные не проверяются вовсе (в вышеописанной манере);
* из этого следует, что в цепочке условий && на первое место выгодно ставить условия, вероятнее всего НЕ выполняющиеся, и для || - условия, выполняющиеся вероятнее всего. Кроме случаев, когда требуется гарантированно выполнить некоторую возвращаемую функцию прямо в условии, тогда ее ставят на первое место.
В целом, в скриптописании нужно обращать внимание на следующие вещи: - функции и переменные могут изменять работу нижестоящих условий, событий и функций; - функции могут заставлять срабатывать события (например, экипирование предмета в тот же момент вызовет событие "OnObjectEquipped"); - независимые события могут срабатывать одновременно, и, если в них используется одна и та же переменная, менять ее значение непредсказуемо (требуется делать защиту). То же самое может происходить, если одно и то же событие (например, событие при нажатии игроком опред. клавиши) выполняет свой код медленнее, чем оно вызывается (игрок может очень быстро нажимать клавишу); - перед проверкой в игре нужно умозрительно проверять срабатывание блоков условий, подставляя стартовые значения переменных, 0, 1 (в зависимости от конкретного назначения переменной); - нужно пользоваться messagebox для отладки блоков условий (и вообще, чтобы понимать, как работает код); - и, самое главное, нужно курить базисы википедии, понимать взаимодействие скриптов, магических эффектов и прочих форм, проводить внутриигровые опыты, тестировать код при различных игровых условиях, и вообще, проводить за этим делом много времени (я не думаю, что это лучшее времяпрепровождение).
ScriptName _TESTNEW2 Extends Actor ; на актера, нужен тест
ObjectReference Property pxMarkerRef Auto ; референс любого объекта (напр., хМаркера), в какой точке актер должен быть включен. Не заполнять, если это не требуется.
Float fEnableTime = 21.0 ; время включения, часов, (fEnableTime + fRandomDispersion) < 24.0, (fEnableTime - fRandomDispersion) > (fDisableTime + fRandomDispersion) Float fDisableTime = 6.0 ; время отключения, часов, (fDisableTime - fRandomDispersion) >= 0.0 Float fRandomDispersion = 1.0 ; случайное отклонение (в плюс или минус) от времени включения или отключения, часов, fRandomDispersion >= 0.0
Например, в Скайриме простая замена ванильных моделей тела на СВВЕ отразится и на игроке, и на др. актерах. Чтобы актер использовал к.-л. особенную модель, в СК нужно указывать ее отдельно от общей. Чтобы игрок использовал к.-л. особенную модель, нужно прибегать к скриптам. Думаю, в F4 то же самое.
Hommyak, если переменная скрипта имеет такое же название и тип, как и EditorID формы, существующей в этом плагине или связанных с ним мастер-файлах, то она может автозаполняться кнопкой Auto-fill. В противном случае, нужно указывать ее значение вручную.
Попробуй сейчас, я подредактировал.
Изменение репутации для пользователя Multigone
MultigoneOffline
Сообщение №1057
| Тема: Вопросы по скриптам Papyrus
написано: 14 ноября 2022, 17:20
| Отредактировано: Multigone - 14 ноября 2022, 17:20
Hommyak, там была, кхм, проблемка с перепутанными переменными, из-за чего апдейт работал непрерывно (а должен 2 раза в сутки). Сейчас вроде все на месте, по крайней мере, актер исчезает и появляется, когда нужно. Можно поставить ему флаг "изначально отключен", чтобы при первом посещении локации, если он сразу виден после ее загрузки, он не мозолил глаза 3 секунды перед тем, как исчезнуть (днем).
В скрипт можно добавить эффектов / шейдеров исчезновения (это уже по вкусу).
Если актер сам уходит в др. локацию, то могут наблюдаться проблемы. Чтобы исключить это, эвенты должны выглядеть так (вместо 5 будет 2):
Скрипт будет потенциально стабильней, но апдейт 2 раза в сутки будет выполняться независимо от того, где находится игрок (а в первом случае апдейт отключается, пока ячейка, в которой находится актер, отсоединена).
Hommyak, если закомментировать одну строку вот так (без кавычек) " ; EvaluatePackage()", поскольку эта команда применяется только к актерам, то скрипт можно вешать на большинство форм, которые могут иметь ObjectReference (т.е. формы, которые могут быть представлены в игре в виде предметов или др. объектов). Для этого шапка скрипта должна расширять референсы "Extends ObjectReference".
Сам скрипт не представляет из себя какой-либо ценности, кроме формулы расчета времени, через которое требуется производить новый апдейт. Поскольку апдейт производится 2 раза в сутки (72 минуты реального времени при ванильном TimeScale = 20), и объем расчетов там ничтожный, считаться тяжелым скриптом, нагружающим систему, он никак не может. Для примера, относительно тяжелым скриптом может считаться объем мат. расчетов размером со страницу текста, выполняемый с апдейтом 0.15 с.
Скрипт влияет только на включение или отключение определенного объекта (актера). Конфликты (или ошибки) могут возникнуть только в случае, если актер отключается во время его взаимодействия с др. объектами (использование фурнитуры, диалоги и т.д.), а это для норм. работы этих объектов не предполагается. Такие вещи можно предусматривать либо в скрипте, либо ограничением возможностей актера.
События являются неотъемлемой частью любого скрипта (по крайней мере, большинства из них). Конфликты могут возникать тогда, когда работа одного скрипта не предполагает вмешательства в процесс со стороны других скриптов, оперирующих тем же объектом.
Hommyak, не совсем так. Есть квест MS06Start, в нем алиас MS06StartIntroTriggerAlias, заполненный референсом (RefEditorID) MS06StartIntroTrigger. Это референс триггера, находящегося в ячейке SolitudeBluePalace. Вышеуказанный скрипт MS06AliasSetStageTriggerPlus прикреплен к этому реф. алиасу, а не к триггеру (фактически, он не имеет прямого отношения к конкретно этому референсу, вместо этого он имеет прямое отношение к любому референсу, которым будет заполнен данный алиас).
Исходя из описания скрипта, "MS06 specific Alias based Setstage Trigger that that verifies MS05 is not in a range of stages before setting the stage", т.е. "триггер проверяет, что текущая стадия др. квеста (MS05) не находится в заданном диапазоне, перед тем, как перевести стадию владеющего этим алиасом квеста (GetOwningQuest()) на заданную.
; это копия скрипта, связанная с работой алиаса MS06StartIntroTriggerAlias (расширяет эту конкретную форму, т.е. этот скрипт является не только алиасом MS06StartIntroTriggerAlias, но и чем-то большим, чем именно, определяется кодом скрипта). Если этот же скрипт прикрепить к др. алиасам, у них будут свои копии этого скрипта, никак друг с другом не связанные, и работающие параллельно и независимо. Все переменные, объявляемые внутри скрипта, принадлежат только конкретной копии скрипта, и в разных копиях одного и того же скрипта они могут иметь разные значения, обусловленные работой их кода.
; сам алиас (любой) является ссылкой на референс (или форму), с возможностью производить над ней определенные действия
; вверху объявляются переменные, им присваивается какое-то начальное значение прямо в тексте скрипта, либо в его Property.
; если значение не присвоено, то начальным значением автоматически является 0, 0.0, "", none (для Int, float, string и любых других форм соответственно).
; Для алиаса MS06StartIntroTriggerAlias, переменные заполнены в Property скрипта (ПКМ на прикрепленном скрипте), и их можно там же посмотреть и изменить.
auto STATE waitingForPlayer ; состояние скрипта с произвольным именем состояния "waitingForPlayer", в котором может быть выполнено событие onTriggerEnter ; auto означает, что в это состояние скрипт переводится сразу при инициализации EVENT onTriggerEnter(objectReference triggerRef) ; событие, срабатывающее в момент попадания любого objectReference внутрь триггера (если какой-либо скрипт с этим событием прикреплен к референсу триггера или к алиасу, заполненному референсом триггера), с присвоением референсу попавшего в него объекта (для целей данного события) произвольного имени triggerRef
; иными словами, при срабатывании onTriggerEnter создается переменная с типом objectReference и именем triggerRef, которой присваивается значение попавшего в триггер референса. Эта переменная существует до конца кода этого события. В процессе выполнения кода этого события ей можно, как и любой другой переменной, присвоить новое значение (если требуется). Если одновременно срабатывают несколько копий события (см. ниже), то для каждой копии создается своя копия переменной triggerRef.
; пока скрипт остается в состоянии waitingForPlayer, для КАЖДОГО попавшего в триггер референса срабатывает это событие, независимо от того, сколько одновременно референсов попало в триггер, попали ли они одновременно или каждый в свое время, выполнился ли код предыдущей копии события, или нет.
; если скрипт прикреплен не к триггеру, то это событие не будет срабатывать никогда.
if triggerRef == getPlayer() ; если попавший объект == референс, возвращаемый функцией game.getPlayer() (т.е. игрок) ; поскольку скриптовый объект game импортирован в данный скрипт (вверху есть import game), то вместо game.getPlayer() можно писать getPlayer() ; импортирование означает, что все функции импортируемого скриптового объекта находятся как будто бы в этом скрипте, и к ним не нужно обращаться, каждый раз указывая название этого скриптового объекта перед названием функции.
; если условие не выполняется (попавший референс не является игроком), то ничего не произойдет (за endif код завершается), скрипт останется в этом состоянии
if MS05.GetCurrentStageID() < MS05DoNotStartRangeLowestStage || MS05.GetCurrentStageID() > MS05DoNotStartRangeHighestStage
; MS05 - переменная этого скрипта с типом квест и произвольным именем MS05 (имя совпадает с EditorID квеста MS05, чтобы было удобно заполнять Property кнопкой Авто).
; если (значение MS05, т.е. указанный в Property квест).(имеет № текущей стадии) < значения переменной с произвольным именем MS05DoNotStartRangeLowestStage (типа int, т.е. целочисленная, ее начальное значение указано в Property этого скрипта), или квест MS05 имеет № текущей стадии > значения MS05DoNotStartRangeHighestStage if !MQ302.isrunning() ; если квест MQ302 не запущен (! означает логическое "не") GetOwningQuest().setStage(MS06StageToSet)
; функция GetOwningQuest(), примененная к конкретному алиасу, возвращает ID квеста, владеющего тем алиасом
; функция применена к Self, что означает, что функция применяется к ЭТОЙ копии скрипта, т.е. к алиасу MS06StartIntroTriggerAlias
; результат Self.GetOwningQuest() возвращает ID квеста, владеющего данным алиасом
; Self в большинстве случаев можно не писать
; вместо Self можно, к примеру, указать другой алиас (т.е. заполненную переменную с типом Alias или ReferenceAlias), чтобы узнать ID владеющего им квеста ; перевести квест, ID которого возвращает функция GetOwningQuest, в стадию с №, равным значению переменной MS06StageToSet (заполняется в Property этого скрипта) gotoState("hasBeenTriggered") ; перевести скрипт в состояние с произвольным именем hasBeenTriggered endif endif endif endEVENT endSTATE
STATE hasBeenTriggered ; состояние, в котором нет событий и функций
; состояния являются взаимоисключающими
; состояния определяют, код каких именно "версий" одних и тех же событий и фунций (или наборов событий и функций) будет выполняться при их вызове (к примеру, onTriggerEnter)
; в данном случае при вызове onTriggerEnter не произойдет ничего (событие отсутствует в наборе этого состояния), несмотря на то, что триггер это событие будет посылать (при попадании в него любого референса, как и прежде, поскольку триггер данным скриптом не отключается / перемещается, хотя этот триггер может выполнять и др. задачи в др. квестах и т.д., кто знает, я его дальше не ковырял).
; скрипт будет находиться в этом состоянии, пока не будет переведен в другое командой gotoState. Поскольку в этом состоянии таковой команды нет, это можно сделать только извне. Подробнее о состояниях можно почитать на СК-вики по поиску STATE или на последних 30 страницах этой темы (+-). endSTATE
ScriptName _TESTNEW2 Extends ObjectReference ; на референс - источник звука ; проигрывает случайные звуки из массива, 2 звука подряд не повторяются (звуки редактируются в разделе СК Sound Descriptor) ; настройка форм Sound Descriptor для использования - Looping: None, количество звукофайлов в списке отдельного Sound Descriptor не ограничено
Sound[] Property apxMySoundArray Auto ; вручную в Property скрипта заполняется массив со звуками (не менее 2 шт.), которые требуется проигрывать в случайном порядке Int iLastPos ; вспомогат. переменная (№ позиции предыдущего звука)
EVENT OnUpdate() Int iC = iLastPos WHILE iC == iLastPos iC = Utility.RandomInt(0, apxMySoundArray.Length - 1) ENDWHILE iLastPos = iC apxMySoundArray[iC].PlayAndWait(Self) RegisterForSingleUpdate(2.0) ; пауза между концом предыдущего звука и началом следующего, сек ENDEVENT
ScriptName _TESTNEW2 Extends ObjectReference ; на референс - источник звука ; проигрывает случайные звуки из форм-листа, 2 звука подряд не повторяются ; форм-лист упрощает заполнение Property в некоторых случаях
FormList Property MyFList Auto ; указать форм-лист со звуками (не менее 2 шт.), которые требуется проигрывать в случайном порядке
Int iLastPos ; вспомогат. переменная (№ позиции предыдущего звука)
EVENT OnUpdate() Int iC = iLastPos WHILE iC == iLastPos iC = Utility.RandomInt(0, MyFList.GetSize() - 1) ENDWHILE iLastPos = iC ((MyFList.GetAt(iC)) AS Sound).PlayAndWait(Self) RegisterForSingleUpdate(2.0) ; пауза между концом предыдущего звука и началом следующего, сек ENDEVENT
Нарада, вот осн. страница SKSE. Там же можно просмотреть инструкцию. При использовании от модмейкера требуется: для компиляции своих скриптов, SKSE функции которых он использует - иметь в папке Scripts/Source .psc скриптов SKSE. Для использования мода от пользователя требуется: иметь SKSE установленным.
valambar, у кинжала ключ. слово, проверяемое в перке dunMossMotherPerk, в котором устанавливается шанс крит. урона для этого кинжала. Перк у игрока есть изначально.
Этот кинжал имеет средний урон (с учетом крит.) +25% (6.25 ед.) от его базового значения (5 ед.). Простой двемерский кинжал имеет базовый урон 7 ед., т.е. уже больше.
Hommyak, а чего-там сложного-то? Ну, хорошо, давай прямо пройдемся по заданным тобой вопросам.
"В Синем дворце на лестнице перед троном есть триггер. На нем находится вот такой скрипт:"
Скрипт находится на алиасе, а не триггере. Это другое. Пока алиас заполнен триггером, скрипт алиаса будет принимать события, посылаемые триггером.
"Из написанного я понял, что триггер - в режиме ожидания, пока игрок в него не зайдет. Зайдя в него, игрок может активировать квест MS06, если квест MS05 находится на стадии не ниже и не выше указанных параметров (MS05.GetCurrentStageID()). И если при всем этом уже запущен квест MQ302 уже активирован, то установить квест MS06 в такую-то стадию. "
Триггер активен - ловит объекты, попадающие в него, и посылает скриптам (прикрепленным к нему непосредственно, либо к таким алиасам) событие об этом. Если объектом является игрок, и квест MS05 находится на стадии меньше 150 или выше 200, и квест MQ302 запущен, то перевести квест MS06 на указанную стадию, а скрипт - в неактивное состояние. Если условия не выполняются, то ничего не делать, и быть активным дальше.
"Стоит ли использовать такие скрипты с подобными "кросс-ссылками", вместо установления условий Condition внутри других квестов?"
Фактически, многие квесты управляются извне при наступлении подходящих условий. Тут посчитали, что такими условиями являются приход игрока в точку местности при определенных состояниях других квестов. Возможно, необходимость в запуске квеста - просто способ поддержать сюжетную связь между несколькими взаимосвязанными квестами без нарушения логичности.
"Правильно ли я понял (по тексту скрипта), что данный триггер не вписывается в квест Алиасом, а стоит индивидуально, аля "глобальный игрок", а не "внутриквестовый"?"
Объекты в мире могут быть размещены заранее (в СК), или созданы (заспавнены) скриптом или алиасом в процессе игры (возможно, есть и др. пути). Насчет триггеров как объектов - вроде бы, их можно только размещать в СК. Далее, при запуске квеста, этим триггером заполняется соотв. алиас.
"Как правильно понять на какую стадию квеста тут идет ссылка? Или тут говорится что стадии квеста вооообще включаться могут - GetOwningQuest().setStage(MS06StageToSet) "
В СК, в окне добавления скрипта к объекту, щелкнуть по нему мышью, нажать ПКМ - появится меню управления Property скрипта, где можно посмотреть или изменить стартовые значения переменных, использующихся в скрипте.
"Является ли эта строка "универсалом" для триггеров (активирующих квесты или их стадии), чтобы после активации "выключать или удалять" эти триггеры - gotoState("hasBeenTriggered")? Если в скрипте триггера (OnTriggerEnter) нет подобных функций, он будет работать один раз или постоянно один и тот же квест запускать?"
С триггером ничего не происходит - он будет так же посылать событие при попадании в него объектов. Перевод состояния происходит только для этой копии скрипта алиаса. В состоянии, где нет событий, скрипт не будет получать событие onTriggerEnter, и, следовательно, делать что-то. Вместо перевода скрипта в неактивное состояние можно, к примеру:
* очистить алиас;
* отключить триггер (Disable) (не уверен);
* переместить триггер в неигровую локацию (операции с триггером повлияют на все объекты, где он используется);
* в скрипте предусмотреть переменную bool, которая используется таким образом:
Bool bActivated = false
EVENT onTriggerEnter() IF (основные условия) == true IF bActivated == false bActivated = true (команды) ENDIF ENDIF ENDEVENT
Я почему спрашиваю, у меня были такие симптомы, причем по разным причинам и в разное время - перегрев видеокарты, умирающий БП, периодически отваливающийся ЖД. Не конкретно в Скайриме, но вообще. С диском, к примеру, работа игры будет зависеть от того, где она установлена - если на компе несколько ЖД, проблемный диск не является системным, и игры установлены на разные диски, понятное дело, проблемы будут не у всех игр. И пропадающий звук - это может быть признаком того, что игра, (частично) загруженная в оперативку и в память видеокарты, не может считать с ЖД звуковые данные. И зависаний намертво из-за модов (LE) не было никогда. Я бы проверил монитор событий в первую очередь.
BodySlide and Outfit Studio - зато я использовал, хехе, правда в Скайриме. Довольно мощная вещь в плане настройки тела и одежды. Outfit Studio требует определенного умения, нужно курить гайды. Некоторая проблема СВВЕ , благодаря широкой настройке телосложения, заключается в том, что, если создать какой-либо уникальный пресет, который значительно отличается от стандартной фигуры, то по большей части придется пользоваться только той одеждой, которая поддерживает Outfit Studio, иначе одежда под другую фигуру будет заметно бросаться в глаза.
зачарование "Хождение по воде" благополучно изучается и появляется в списке... но неприменимо ни к чему
В конструкторе зачарования (ENCH) в строке Worn Restrictions нужно указать форм-лист с ключевыми словами, любое из которых должно быть у предметов, допустимых для этого зачарования.
Мы Вконтакте
