Вис691

Ну и до кучи реальный пример из ГК. В моей азартной игре всё зависит от чисел, выпавших на двух кубиках. Проблема в том, что кубики иногда на ребре останавливаются, и нужно их перекидывать. Решил подобные моменты разбавить сообщениями в углу. А-ля советы, анекдоты и прочее (их содержание ещё не придумал). В общем насоздавал сообщений, закинул их в форм лист. По логике, всё, что мне нужно, - при каждом броске брать и выводить следующее сообщение из листа. Как это выглядело бы с компилятором из ГЕККа (опущу объяснение математики и некоторых переменных): let iSize := ListGetCount BHCDCrapsMsgsList ; узнал размер листа, т.е. точное количество сообщений в нём let iNth := iCounter % iSize ; выбрал нужный номер из него let rMsg := ListGetNthForm BHCDCrapsMsgsList, iNth ; наконец вытащил сообщение с номером iNth showMessage rMsg ; показал его С компилятором NVSE это всё можно записать так: let rMsg := ListGetNthForm BHCDCrapsMsgsList, (iCounter % (ListGetCount BHCDCrapsMsgsList)) showMessage rMsg ; вполне вероятно можно и в одну строку всё запихнуть, но у меня не вышло Мало того, что это на пару строк короче, так я ещё и не завожу какие-то второстепенные переменные для хранения промежуточных данных. И всё, что нужно сделать, чтобы этот код скомпилировался - вместо begin GameMode написать begin _GameMode Не знаю, как со стороны обычного юзера, а меня с позиции скриптера это очень впечатлило.

Ну если совсем кратко, то это просто другой компилятор для скриптов. Позволяет использовать некоторые конструкции, которые нельзя использовать со стандартным. Там очень неплохо на примерах показано различие, поэтому если есть хоть малейшее понимание программирования, то должно быть понятно, что и как. Если же понимания нет, то предлагаю следующий абстрактный пример. Представим, что у нас есть контейнер с ящиками. В них может лежать всё, что угодно - числа, строки, даже другие контейнеры с ящиками. Мы знаем, что в каждом ящике лежит именно какое-то число. А компилятор ГЕККа этого не знает. Поэтому когда мы ему скармливаем содержимое ящика, он ругается: "Я не знаю, что там такое! Я жду на вход число, а вдруг ты мне подкинул строку? Не буду компилироваться!" А этот NVSE'овский компилятор говорит: "Хм, ну раз он мне даёт содержимое ящика, то он уверен, что это число. Скомпилируюсь без проблем. Любые ошибки будут на его совести." Как-то так.

Наткнулся тут на очень интересную страничку https://geckwiki.com/index.php/Script_Compiler_Override Надо будет поэкспериментировать.

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

Вторая попытка перенести интересный пост в мой блог, чтобы он не потерялся. Напоминаю, что подобные записи могут иногда здесь появляться. Убрал окошко цитаты, чтобы читалось удобнее. ====================================== Возвращаясь к самому первому посту в этой теме, наткнулся на интересную фразу: Конкретно, конечно, имею в виду пометку про переменные типа 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 разрядов-"лампочек". Собственно, пожалуй, это всё, что я хотел сегодня рассказать. Хотелось бы почитать ваше мнение - достаточно ли понятно я всё рассказал, может вопросы какие остались? Придумали/знаете другой способ для зажигания конкретно одной лампочки? Поделитесь им, не стесняйтесь. Да и насколько интересно это было читать? А то, может, я время от времени буду подобными интересными моментами делиться. Или наоборот не буду, если вам не понравилось. Источник: Школа Скриптинга

Скорее как компактный вариант управления огромным числом состояний. Правда, конкретно мне нужны были лишь 18. Но да, от ненужных if-elseif мы избавились)

Возвращаясь к самому первому посту в этой теме, наткнулся на интересную фразу: Конкретно, конечно, имею в виду пометку про переменные типа 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 разрядов-"лампочек". Собственно, пожалуй, это всё, что я хотел сегодня рассказать. Хотелось бы почитать ваше мнение - достаточно ли понятно я всё рассказал, может вопросы какие остались? Придумали/знаете другой способ для зажигания конкретно одной лампочки? Поделитесь им, не стесняйтесь. Да и насколько интересно это было читать? А то, может, я время от времени буду подобными интересными моментами делиться. Или наоборот не буду, если вам не понравилось.

Tom's eating dongs, Tom's eating dongs, Tom's eating dongs xdd

Добро пожаловать в мою регулярную рубрику блогов, где я рассказываю, что нового произошло за последнее время и как это выглядит со стороны разработки. Для новых читателей и для тех, кто забыл, напомню, что блоги выходят с завидной постоянностью - 2 раза в год, по двум главным праздникам: в Новый Год и в мой День Рождения Сегодняшний же "выпуск" немного задержался, но не верю, что кто-то его вообще ждал. В последней записи мы говорили о нуар квесте, который я разрабатываю. Сегодня мы вновь поговорим о нём. Как только я передал диалоги для персонажей другому члену команды, Пахе007, у меня буквально развязались руки. Мало того, что я доработал некоторые аспекты самой азартной игры (сделал анти-чит систему, добавил мелкие полезные функции, пофиксил некоторые баги и т.д.), так я успел поработать и над блокнотом детектива. Начальный рабочий вариант содержал в себе 2400+ строчек кода и ужасно пролагивал секунд на 5 при его открытии. Страшно подумать, сколько бы он лагал у людей с большИм количеством модов. Поэтому сразу же после очередного коллективного апдейта, я начал переписывать концепцию блокнота. Получилось неплохо - количество строк сократилось почти в 2 раза. Пролаг же, к сожалению, остался, но теперь он не такой большой (около полутора секунд). Посмотрим, может удастся и ещё что-нибудь вырезать. Кстати, это было сделано в прямом эфире - любой желающий мог посмотреть на процесс и столкнуться с некоторыми небольшими спойлерами Буду ли ещё стримить разработку, я не знаю, но если кому будет интересно - пишите в комментарии, найду способ вас предупредить заранее. Откуда же такой громкий заголовок у этой записи. Дело в том, что мы решили выпустить первую версию мода. Уверен, что она будет не последней, скорее что-то типа открытой бетки. Что, стало интересно? Не спешите радоваться - пускай мы и обговорили потенциальную дату выхода, я её называть не буду. Почему? Да чтобы не давать ложных обещаний. Чтобы потом не извиняться, если что-то пойдёт не так. Все мы люди, и у всех нас возникают проблемы. Могу заверить, что команда прикладывает все усилия в разработку. Для некоторых из нас этот мод является последней работой в сеттинге Фоллаута, а возможно и в моддинге в целом. На этом эта краткая запись подошла к концу. Если у кого-то есть вопросы - не стесняйтесь задавать их в комментариях. Встретимся где-то в районе Нового Года. Надеюсь, что к этому моменту дата выхода будет более чёткой, и я смогу ей поделиться (если мы не анонсируем её раньше).

Ох, что же так сложно-то. Нет там скрипта. Никакого. Вообще. Не от скрипта появляется стелс-поле. И даже стелс-бои не от скриптов работают. StealthBoyStopCombatScript просто выводит игрока из боя при активации стелс-поля.

Зачем, если есть броня, которая работает практически так, как надо?

Так я же так и сказал

Ну, собственно, я посмотрел, что там и как. Вот результат: на китайской броне нет скрипта. И на шлеме нет. Скрипты здесь вообще не понадобятся. Но идея начать поиски с китайской брони - очень здравая. Так и поступите и попытайтесь выяснить, что же тогда даёт стелс-поле, если не скрипт. Только убедитесь, что нужную китайскую броню смотрите, из Анкориджа. А то лично у меня там ещё 2 были, и у них поля нет. Будут вопросы - пишите.

Ну, учитывая, что вы обратись именно в школу скриптинга, а не в эту тему, то придётся всё же разбираться самому. Т.к. я в Сталкер и уж тем более в моды на него не играл, хотелось бы более подробное описание. Я так понимаю, нужен Селс-Режим пока костюм на ГГ. Всегда ли он нужен? Или есть условия выхода из него? Хотя смотреться наверно странно будет, но всё же. Жду подробностей, а я пока скрипт брони посмотрю. P.S. Если вдруг желания делать самому не будет вообще, то советую всё же переместиться в тему, которую я указал. Хотя пока что я ничего сложного не вижу. А если что, думаю, единственный ученик, Old Vault Boy, поможет при необходимости

Честно говоря, я бы даже сказал, что хороших задумок очень много, но вот только: 1) Не всё реализуемо 2) Не на всё хватает времени Однако, надеюсь, что в итоге это всё будет стоить того.