Bes, самим, как обычно. Может быть, я успею добавить пару безпрефиксных в стандартную библиотеку для распространённых IF:Q, IF:M, IF:G.

Berserker, а что по предложенному мной синтаксису? Можно надеяться на подобную унификацию?

Algor, я уже закончил основную работу по движку. Только ещё посмотрю, можно ли переписать интерполяцию переменных в строках для поддержки условных "%XV3". Твой синтаксис требуют расширения движка в части массивов и сложных интерполяций вида %W(hero, blabla). W-переменные устарели и прекрасно заменяются на i^$(hero).offence^.

Да и в целом никакой доп. унификации не требуются, это тот же ЕРМ. Разве что ты предлагаешь префиксный вариант локальных переменных (везде тип переменной указывать вручную) вида x(hero), когда как как обилие префиксов на мой взгляд и опыт создаёт лишнюю нагрузку. + появляется возможность иметь одноимённые разнотипные переменные вида x(hero), y(hero) и использовать переменные без объявления, то есть создавать классические баги-опечатки. !!VRx(hro):S70; !!HEx(hero):K1;

Мой первый вариант с $x...$, @x...@ был префиксовым. Безпрефиксный явно чище. В других ЯП:

int heroId = 200;
GetHero(heroId).mana = 700; вместо GetHero(int heroId).mana = 700;

---

По твоему совету v-ки полностью убрал из локальных и документации. Есть вопрос по интерполяции переменных в строках:
?

Bes, я имел в виду в запланированное для релиза и до перехода к другим задачам время.

Berserker, второй вариант лучше, не надо плодит различные синтаксические конструкции. Если подстановка в строку идет через %, пусть везде и будет %.
Я поэтому и хотел чтобы именованные переменные отличались от неименованных только тем, что вместо номера (имя в скобках).
w-переменные, как и флаги можно вообще изжить. Только надо поправить соответствующие ресиверы, которые их (флаги) используют. Ну и как-то с совместимостью поколдовать, если это вообще возможно без огромного геморроя.

Что до префиксов, то я не слитаю это плохим. Наоборот, строгая типизация - гуд. ОДноименные переменные разных типов - почему нет. Да и префиксы это все-таки классика ERM.

Меню Вог опций.
Ранее опция "Мифрил" включала/отключала опцию "Отображение мифрила" динамически.
Ныне только включает, но отключение "Отображения мифрила" выключает "Мифрил"

Имею ввиду лишь визуальный аспект в меню опций, а не скрипт и т.п.

daemon_n, это как раз тот случай, когда надо эти опции слить в одну и не заморачиваться. Но вопрос в тему WoG Scripts, не в ERA

Algor, так эти опции вшиты в ехе,значит надо их править непосредственно в ERA,имхо
Скрипты то переписать самосабой для проверки,но это пол дела

Bes, с чего бы они вшиты?
Обе в 42 wog - mithril enhancements.erm, ток функционал привязан к разным опциям 36-й и 149-й

Algor, там зависимости захардкожены. Типа включаешь одну опцию, другие автоматом вырубаются, или вообще блокируются.

SyDr, я же и предлагаю в меню вог-опций просто объединить 2 опции в одну, а вторую убрать и ничего друг-друга включать/выключать не будет.

(03.04.2020 17:52)Algor Wrote:  SyDr, я же и предлагаю в меню вог-опций просто объединить 2 опции в одну, а вторую убрать и ничего друг-друга включать/выключать не будет.

Это экзешник надо править или бинарным патчем, больше никак.
Я тоже за, чтобы убрать зависимости.
Вернее, зависимости должны быть настраиваемыми, а не так, как сейчас.

Algor, тогда просто будет свободная опция,которую если кто заюзает,она будет отрубаться,когда отключать мифрил,а тот моддер будет репу часать как так происходит? Я ж потому и говорю,если отказаться от одной опции её надо по хорошему в памяти отлучать от некогда связанной опции

А кто-нибудь сам скрипт глядел? Внутри 4 опции, которые друг друга по кругу включают. Но, как ни странно, не всё из них включают мифрил, и выглядит это странно. Если сам мифрил отключен, он должен отключить все 3 остальные, но так оно не сделано... Жуть

Да блин...
Вот так можно отвязать:

"Мифрил" и "Новая опция" включаются отдельно. Никто никого не отключает. Можно подобным образом развязать и с текущей.
Все это делается в текстовике.