Wake of Gods Forum | Форум Во Имя Богов

Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174

Archer30, I never faced such a bug. Rechecked - everything is saved and restored.

Strange, for some reasons I received more than one report about this. Just checked and yea it worked quite well

Let they send you savegames. Only scripts can reset such settings, WoG engine works well.

Quote:[-] Исправлен черный фон в меню «Авторы».

Ура, спасибо огромное!!! Бегу обновляться Yes

Raistlin, то есть только это послужило причиной обновить ERA 96-copy

(13.04.2021 05:04)Berserker Wrote: [ -> ][+] Добавлена новая команда ERM VR:B. Она преобразует любое число в логическое значение (1 или 0). Любое ненулевое значение становится 1.

Пример:

Эм, Берс, а можно какой-нить другой пример, оправдывающий существование VR:B?
А то (hasGold)=(TRUE) вместо (goldAmount)>0 звучит неубедительно. И к тому же еще и возможные отрицательные значения золота не учитывает.

Скажем так, в коде на разных языках программирования приходится много раз конвертировать числовое значение в булево. Мне на ЕРМ тоже приходилось. Далее это булево значение использовать в проверках. Смысл: есть хоть какие-то флаги установлены или «не пустое», «не 0» или «не ошибка».

На ЕРМ без оператора приведения типов это делается так:

И короче никак. Если разрешены отрицательные значения, то hasSomething писать нельзя, конечно же.

Установка булевой переменной в (TRUE), если флаг присутствует. Сами логические переменные упрощают написание и понимание кода. Без них смысл проверок необходимо комментировать. В хорошем коде не нужно комментировать каждую строку. Логическое значение можно передать функциям, ожидающих только TRUE/FALSE в качестве определённого аргумента.

Berserker, я, наверняка, занудствую, но это все равно попахивает натягиванием известной птицы на глобус.
Имхо,
!!VR(undeadPresent:y):S(monFlags) &(MON_FLAG_UNDEAD) B;
от
!!VR(undeadPresent:y):S(monFlags) &(MON_FLAG_UNDEAD);
ничем принципиально не отличается.
Один хрен, результат складывается в int-переменную, которая и далее обрабатывается также как int. И читабильности кода это ни убавляет, ни добавляет - константы TRUE и FALSE можно интерпретировать и как 1/0 и как !0/0 - без типа BOOLEAN всё это только привычки/установки в голове кодера. А при попытке загнать результат во флаг, понадобится доп. строка кода.

Лучше бы запилил как во многих языках (и как для флагов в ERM) условия без знаков сравнения, т.е.

!!IF&(undeadPresent):M^Кажется, тут кто-то не совсем живой...^;
вместо
!!IF&(undeadPresent)=(TRUE):M^Кажется, тут кто-то не совсем живой...^;
или
!!IF&(undeadPresent)>0:M^Кажется, тут кто-то не совсем живой...^;

Хотя это всё тоже сахар, количество которого в последнее время в ERM+Framework и так стремится к (JOPA_SLIPNETSA).

Algor, условия без сравнения уже есть. Трактуются как проверка f-флага. Кривая штука.

Не выведет ничего. Условие в ветке OR вообще не проверяется.
Но за идею ещё раз спасибо, посмотрю.

Не соглашусь. Если не привести значение к boolean, то везде, где ожидается boolean, и проверка не вида <>(FALSE), а =(TRUE), всплывут баги.
Более того, я ещё и boolean как 1 в математических выражениях использую. Зная, что это 0/1. Умножаю или вычитаю. Не должно логическое значение хранить 31733 ни в ЕРМ, ни в любом другом ЯП.

C++, PHP (bool)
Javascript Boolean(value)
Pascal: boolean(value)
ERM 2: VR:B

ЕРМ 2 нуждается в следующих правках:

Code:

-) Условия вида 500<>(someVar:y) должны вычисляться как результат сравнения, а не просто f[500]

-) Условия вида &(var1:y)/(var2:y) должны вычисляться как (var1)<>0/(var2)<>0

-) Условия вида &(text:z) должны вычислять как (text)<>^^

(15.04.2021 17:57)Berserker Wrote: [ -> ]Более того, я ещё и boolean как 1 в математических выражениях использую. Зная, что это 0/1. Умножаю или вычитаю.

Грязный извращенец Moral

Впрочем, спишем это на "привычки/установки в голове кодера".
Думаю, можно закрыть этот вопрос. Особенно, если внесёшь обозначенные правки

Algor, готово. Заодно стало возможным использовать любое число пробельных символов между аргументами и операторами.

Hi Berserker, is there an OnAfterBattleReplay event, or is it only from ERA changelog?

Quote:[*] Fixed non-working "OnBeforeBattleReplay" and "OnAfterBattleReplay events". Newest "BattleReplay" plugin by igrik is required.

If it's not valid, then the auto-complete of sublime needs to be updated. 102

Thank you very much, my friend. I will add a fix soon.
https://dropmefiles.com/3ZB2O

(16.04.2021 05:42)Berserker Wrote: [ -> ]Algor, готово. Заодно стало возможным использовать любое число пробельных символов между аргументами и операторами.

хм, надо бы мне реже появляться и чаще нудеть