Вис691

Всем привет! Прошёл очередной год, а, значит, пришло время очередного отчёта. Сегодня хотел бы поднять две темы, лишь косвенно связанные с Каньоном. Кстати, забавно вышло. В прошлый раз писал, что защитился и вновь поступил. А сейчас выходит так, что скоро вновь защищаться буду. Ну да ладно, сейчас не об этом. Начнём, пожалуй, с темы поста. Ребята, делайте бекапы. Терять прогресс, и делать что-то заново - невероятно больно. Первый раз у меня случился, когда я решил закинуть обновление от товарищей по команде. А так как у нас всё идёт архивом, я благополучно перезаписал свои наработки старой версией файла. И это было очень неприятно, т.к. это был файл интерфейса. А править эти .xml файлы - то ещё удовольствие. Пришлось вспоминать, что я там наваял, и делать заново. Я даже не уверен, что ничего не забыл. Состояние такое, будто я разобрал что-то, затем собрал заново, а у меня остались лишние детали. Но вроде работает, так что не всё так печально. Второй раз случился, когда я переставлял винду. Старая была явно чем-то заражена, поэтому я, не раздумывая, снёс абсолютно всё, что было на дисках. Естественно, перед этим я сохранил самую ценную инфу. Стоит ли говорить, что про моды на Fallout я забыл? Благо в этот раз потери были не такие большие - только плагин. Да и в том лишь диалоги, которые имеются в виде Word-овского документа. Так что это восстановить было несложно. Но муторно, не люблю монотонную работу . И собственно встаёт вопрос - а как бекапить? Очевидно, надо на какой-то внешний ресурс. Создавать git-репозиторий не хочется, звучит как оверкилл. С другой стороны, всякие .xml файлы там бы хорошо зашли, ибо можно будет отследить все изменения и историю. Может какой-нибудь onedrive? Но тут всю директорию с модами пихать не вариант, слишком тяжёлая. Значит, нужен механизм синхронизации... Не знаю, в общем! Если есть какие-то практики - пишите, очень интересно! Не хочу наступать на грабли в третий раз. Переходим ко второй теме. Ребята, идите в ногу со временем. NVSE до сих пор развивается, не стесняйтесь переходить на новые фичи, ибо они зачастую сделаны лучше, чем оригинал. Я сейчас даже не говорю про лямбда-выражения и прочие продвинутые штуки. Возьму самый банальный пример. Стандартный set .. to и let из NVSE. Мало того, что возможностей у последней функции куда больше, так ещё и читаемость повышается в разы. Вот вам пример: set MyVeryLongNamedQuest.SomeVariable to MyVeryLongNamedQuest.SomeVariable + 1 let MyVeryLongNamedQuest.SomeVariable += 1 Строка получилась в 2 раза короче! А с выходом xNVSE 6.1.0 можно даже так: MyVeryLongNamedQuest.SomeVariable += 1 Если вам в скрипте потребуются строки или массивы, от let никуда не уйти. Так используйте эту функцию везде. Более того, ещё один огромный плюс, указанный в вики: Если возникает ошибка (во время игры), то в консоль будет выведено сообщение, содержащее мод и скрипт, в котором возникла ошибка! Это очень круто, ибо помогает ловить ошибки, которые set просто молча игнорирует. В общем, не стесняйтесь развиваться вместе с NVSE. Может, однажды найдёте что-то, что давно искали. Однако я ни в коем случае не призываю бежать и переписывать старый, уже проверенный код. В этом может быть резон только, если удастся его оптимизировать и снизить нагрузку с игры. В остальных случаях - двигайтесь дальше. Всем спасибо за внимание и с Наступающим!

Очень сильно сожЕлею, что люди не смогут полноценно насладиться качественным переводом.

Могу только предположить, что MenuMode надо на GameMode поменять. Мне кажется, что сразу после нажатия на кнопку, мессаджбокс закрывается, и код обработки срабатывает только тогда, когда ты обратно какой-то мессаджбокс открываешь. Upd: по поводу глобальных переменных. Зашёл в Gameplay->Globals...->ПКМ в поле с переменными->New и создал переменную aaaTestGlobal. Затем создал тестовый скрипт: scn aaaTestScript begin GameMode if aaaTestGlobal == 0 let aaaTestGlobal := 1 endif end Всё сохранилось без проблем.

Я бы наверно глобальную завёл, если квеста нет и он не нужен. Если какой-то квест уже есть со скриптом, то можно и там переменную завести. Так чтобы он кричал постоянно, а не только при входе в триггер (единожды), по идее, надо поменять на OnTrigger.

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

А у тебя между if и endif ничего нет. Команды-то надо внутрь заносить, а не после) if RGLstreetCrier2REF.GetDead == 0 if RGLstreetCrier2REF.IsTalking == 0 if RGLstreetCrier2REF.IsInCombat == 0 if RGLvar == 0 RGLstreetCrier2REF.Say RGLstcr0 set RGLvar to 1 endif if RGLvar == 1 RGLstreetCrier2REF.Say RGLstcr1 set RGLvar to 2 endif ... endif endif endif Но такой вариант тоже неправильный. Смотри, как будет идти скрипт. Считаем, что внешние 3 условия выполняются. Переменная 0? Да, она изначально 0, значит выполняем 2 команды внутри. Одна из команд переводит переменную в 1. Следующее условие - переменная 1? Да, мы её только что на 1 поставили. И вновь код внутри выполнится. И т.д. Т.е. он как бы за 1 проход активирует все реплики, а это неверно. В таком случае надо изучить, что конструкция if-endif может расширяться до if-elseif-endif. Взгляни вот на такой вариант: if RGLvar == 0 RGLstreetCrier2REF.Say RGLstcr0 set RGLvar to 1 elseif RGLvar == 1 RGLstreetCrier2REF.Say RGLstcr1 set RGLvar to 2 ... endif При таком подходе, у нас не много if-endif конструкций, а всего одна. Скрипт при проходе будет искать первое условие, которое выполнится. Как только он его найдёт, он выполнит команды внутри, и выйдет из конструкции (даже если дальнейшие условия тоже выполнялись бы). При такой схеме мы за 1 проход активируем всего одну реплику. P.S. Я обратил внимание, что среди внешних условий есть RGLstreetCrier2REF.IsTalking == 0, поэтому теперь вновь верю, что этот скрипт должен работать)

Так как я с закрытыми глазами помочь смогу?) Ну давай подумаем. Надо решить, когда будет срабатывать блок, правильно? Если у нас Gamemode, то этот блок будет срабатывать всегда, когда мы "в игре" (не в меню или ещё где-то). Получается, что переменная в каждый новый проход скрипта будет 0. Как-то нехорошо. Если у нас OnTrigger, то срабатывание будет происходить всегда, когда мы внутри триггера. Т.е. опять в каждый новый проход (пока мы внутри триггера) переменная будет обнуляться. Наверно, тоже не очень хорошо. Как же быть? А всё очень просто. По умолчанию, когда ты пишешь "short RGLvar" переменная принимает значение 0. И это происходит ровно один раз. После этого ты можешь менять переменную как хочешь, она в 0 автоматически не сбросится. Поэтому всё, что нужно - убрать "set RGLvar to 0". Ничего сложного нет. На каждый if ты в конце ставишь endif. Я думаю, если ты посчитаешь, сколько у тебя if-ов и endif-ов, то заметишь, почему скрипт не сохраняется. Это называется добросовестный автор или нет. Сдвиг строк вправо делается для повышения читаемости кода. На работу скрипта никак не влияет. Когда их двигать? Не знаю даже как это правильно объяснить. Вот есть у тебя смысловые блоки begin-end, if-endif, также бывают циклы различные. В общем, всё, где ты ставишь какое-то условие. Вот для того, чтобы было понятно, что выполняется, когда условие проходит, это сдвигают вправо. Например: if (условие1) команда1 команда2 else команда3 команда4 endif команда5 Если посмотреть, то сразу становится понятно, что команды 1 и 2 выполняются. если условие1 срабатывает. Команды 3 и 4 выполняются, если условие не срабатывает. И команда5 выполняется всегда, т.к. она идёт после if-endif. Если вдруг нужно больше уровней вложенности, то не проблема: if (условие1) if (условие2) команда1 endif команда2 endif Тут команда1 выполняется, только если и условие1, и условие2 выполняются. Команда2 выполняется только если условие1 выполняется, на условие2 ей всё равно, она вне этого блока. Кстати, обрати внимание, что if и endif на одном уровне визуально находятся, если правильно сдвиги делать. Это опять же позволяет проверить, а не забыл ли ты что-то. Тут не "==", а "to". "==" используется для сравнения, а "to" для присвоения нового значения. Я, кстати, только сейчас задумался о потенциальной проблеме. По-хорошему надо подождать. пока НПС закончит свою последнюю реплику. Хмм, возможно подход через скрипт не будет работать. А как устроены другие зазывалы?

Не знаю, как работают Link From/To, поэтому я бы всю логику перенёс в скрипт. Завёл бы переменную-счётчик, которую увеличивал бы после каждой реплики, а после последней сбрасывал бы её в 0.

Если не ошибаюсь, наличие перка у НПС проверяется. Для ГГ вроде с Subject на Target поменять

По первым 2ум не подскажу, а вот с именем есть несколько вариантов. Сразу предупреждаю. что сам не тестировал. Получить имя любого рефа можно через LNGetName, т.е. имя игрока должно быть player.LNGetName. Дальше уже надо смотреть, что тебе нужно. Если варианты замены имени у рефа и у базового объекта. Для рефа вроде походит LNSetName, для базового объекта SetName и SetActorFullNameAlt. Если надо расписать подробнее - пиши.

Вот по идее она должна быть там, где сообщение вызывается, т.е.: Begin OnActivate if IsActionRef player == 1 If NVDLC03DialogueHQBuddies.bBuddiesTalk == 1 setTalkingActivatorActor BioReactorNPC activate else set bAwaitingInput to 1 ShowMessage BioReactorNoTalk endif endif End. А смысл у неё простой - сказать, мол, вот мы вам менюшку вывели, ждём, что же вы выберете. Это чтобы не крутить целиком блок в MenuMode 1001 постоянно, когда он активен.

Один Endif забыл: scn BioReactorScript Begin OnActivate if IsActionRef player == 1 If NVDLC03DialogueHQBuddies.bBuddiesTalk == 1 setTalkingActivatorActor BioReactorNPC activate else ShowMessage NVDLC03HQBuddiesNoTalkMSG endif endif End

Это не камень, это скорее призыв к тому, чтобы на это обратили внимание. Текст я читаю всегда, ибо иногда встречаются очепятки и пропущенные/лишние знаки препинания. Но вот на глаз определить тире или дефис передо мной (а Word оставляет и то, и то) не всегда получается. Да и про многоточия тоже иногда забывается. Ситуация реально неприятная выходит. Вроде и вычитываешь, и в игре пересматриваешь, но всё равно иногда проскакивают "пропуски". На днях, например, нашёл несколько тире в правилах крэпса, которые в игре уже не первый год лежат... Всё же проще избежать эту проблему изначально, мне кажется.