качать отсюда

Здесь представлена функция дли установки и получения силы 16 вторичных навыков на уровнях none, basic, advanced, expert.
Синтаксис:
Сначала проверяется 5ый параметр. Если он меньше нуля, то идет чтение(запись) переменной с плавающей запятой. Иначе идет чтение(запись) 3его параметра.
Вот тестовый пример работы функции:


Еще примеры:





Вот и сама функция


Замечания:
1) Нужно учитывать, что часть навыков хранится в типе integer, а часть в float. В integer хранятся следующие навыки: leadership, luck, mysticism, scouting, estates.
2) Для некоторых навыков позволены отрицательные значения. Например для интеллекта в одном из примеров устанавливается -0,5.
3) Не забывайте, что функция работает только под ТЕ по следующей причине: "В WOG 3.58f запрещена запись с помощью !!UN:C в область памяти, отвечающей за вторичные скиллы".
4) Описание работы конвертеров: Конвертер из действительного числа в его машинное целочисленное представление записывает по адресу переменной e1 значение и считывает оттуда с помощью !!UN:C его машинное представление. Конвертер из машинного целочисленного представления в действительное число записывает с помощью !!UN:C по адресу переменной e1 машинное представление и копирует переменную e1 в переменную ex2, где x2(<0) - выделенный пользователем индекс для получения значения.

Если будет работать, будет здорово. Не помешала бы.

Обновление.
Теперь можно не только устанавливать значения навыков, но и получать их. Смотрите первый пост.

Почему ты думаешь, что запрещена запись через !!UN:C в область вторичных навыков?

У меня не получилось
Я пробовал

Обновил ссылку.
Сделал возможность устанавливать и получать значения для уровня развития навыков None.
Добавил примеров в первый пост.

Обновление. Упростил конвертер из машинного представления в действительное число.

там, где по 4 строчки для каждого навыка расписано по-моему пожно упростить в одну

там условия разные...

нет, напр. первую четверку как:
!!UN&x1=9:C6547864+x2*4/4/x3;

Добавлено ([mergetime]1182948642[/mergetime]):
там закономерность есть

ERM‐интерпретатор не поймет.

Я бы сделал так (хотя, если бы я это писал, я бы, во‑первых, сделал одну и ту же функцию и для чтения, и для записи, во‑вторых, возвращал бы значение в x3, а не vx3):
Функция умеет работать только с 16‑ю навыками, но это нигде не сказано. Непорядок.

1) Насколько я знаю, считается дурным тоном объединять методы Set и Get в один.
2) Согласен с тем, что нужно возвращать в x3. Исправлю.
3) Посмотрю, насколько большой выигрыш по скорости получается при использовании сокращения.

Сказано в названии темы (change some SS values). Но, согласен, в посте нужно продублировать.

Возможно, но, во‑первых, я не согласен  — почему нет? Во‑вторых, можно сделать разный синтаксис, как у меня:В‑третьих, это разумно, так как сэкономит целую функцию, а сейчас в ERM номера — какие бы то ни было — нарасхват.

Согласен с Чёртосом. Комментарий (ложка дегтя в бочке мёда):

3) Посмотрю, насколько большой выигрыш по скорости получается при использовании сокращения.

Не посмотришь Никак.

Почему?
Запускаешь цикл до 1000000 (10000000 или сколько нужно) и засекаешь время на одной функции, потом на другой. По отношению времени смотришь, какой алгоритм работает быстрее. Я таким методом сравнивал несколько алгоритмов сортировки, которые за Nlog2N. Запускал их на 10000000 чисел. Один работал 70 секунд, другой 140 секунд, третий тоже 140 секунд. (Это было еще на старом компе, поэтому так долго.) Как говорится время хороший свидетель скорости.

Ну в лоб всё можно. Только комп работает с разной нагрузкой (смотря какие приложения запущены) + если ты запустишь такой цикл, то ЕРМ надолго заснёт. читать (НАДОЛГО). Ну и время ты как, вручную замерять будешь?

З.Ы Жаль, что воговцы свои алгоритмы не оптимизировали и время не проверяли.

Заметка по ЕРМ: выгоднее писать макросы (то есть которые будут текстом вставляться в код), чем вызывать функцию. Значительный выигрышь времени. Не надо анализировать, обнулять переменные, резервировать место + (ещё внутренняя кухня) ЕРМ.

Время как-нибудь уж померю Была бы проблема.
Насчет макросов. Они страшно глючат. Медленный и безглючный код лучше быстрого и нерабочего. Благо для большинства скриптов есть большой запас по скорости.

Я про другие макросы, скоро узнаешь

Ждемс.
Только мне кажется, что не все так просто. Я думаю, что время работы скрипта зависит еще и от его длины. А использование макросов вместо функций ведет к удлинению скрипта

Нет, нет, и ещё раз нет Причина: ЕРМ-парсер не преобразует исходник в байт кода каждый раз заного интерпритирует команду. То есть если в функции даже одна команда, а выполняется функция 200 раз, то всё равно выгодне написать эти 200 раз текстом.

Berserker очень прав.
Время вызова функции ~ 0,5ms
Время выполнения одного сравнения < 0,001ms
Однако, время загрузки в память на старте карты 1ой строчки скрипта ~ 0,2ms
Вывод1:
У Чертоса функция работает быстрее. В ней меньше сравнений и она занимает меньше места, т. е. быстрее грузится на старте.
Вывод2:
Лучше использовать функции по минимуму.
Вывод3:
Можно предположить ситуацию, когда стоит использовать функции, чтобы сократить время загрузки карты на старте.

Ждем макросов!!!

Обновил функцию. Встроил конвертеры. Добавил проверку входных параметров на валидность.
Спасибо Chortos-2 за замечания и предложения

Макросы - первая задача после евмы. Завтра выложу прогу с хэлпом для откладки в Wog3.58 и для ехешника ТЕ (всё в одной, выбор будет //З.Ы Также и Реквизит, знать бы версию экзешника)

Я знаю, насколько глупы бывают ошибки ЕРМ и насколько рутинна откладка. Приходится пихать везде !!IF:M^%V600 %V601 %V602^;....
Расталвять их по всем местам, заного менять, проверять другие... и каждый раз с перезапуском карты. Труд программера не ценится. Это ещё что, хуже когда присылают сейв с багом, который повторить больше не может (происходит раз в пол года), или который только в данном сейве. Тут нет возможности перезагрузки. Я было начал писать функцию для получения и изменения переменных ЕРМ прямо через ЕРМ (н помню как называется, в скриптах выкладывал), но это не то. Что даёт ERM VARS MEMORY EDITOR (EVMA):

1) Удобный и красочный диалог с программой через консоль.
2) Максимально простой интерфейс, одна клавиша определяет команду, остаётся только ввести значения.
3) Встроенная сводка команд
4) Масимальная защита от "уничтожения" игры. Вы можете вводить кривые числа, не те индексы, выходить за рамки ЕРМ переменных, оставлять пустые места, пихать во флаги цифры, отличные от 0 и 1 (в особом режиме), в общем издеваться как хотите. Прога укажет на каждую ошибку и выполнит операцию ТОЛЬКО при идеальном синтаксисе.
5) Поддерживаемые переменные: V, F (флаги), Z (строки), W (переменные героев, герой выбирается особой командой). Разумеется только глобальные поддерживаются, можно было и локальные, но это более рутинно, а я не могу тратить на прогу больше 2-3 дней.

6) Консоль на 1000 строк. Поддерживаемые команды:
//Очистить консоль, показать список команд, выход.

P.S Всё на русском языке.

//Получить значение переменной ЕРМ или нескольких. Если кол-во не указано, то по умоччанию одной, в противном случае до максимума. То есть v1 1000 после команды выведет все v переменные.

//Выбор героя (это понятно, так как w-переменные привязаны к определённому герою)

//Установить значение переменной. Поддерживаются массовые установки:
v1 1 2 3 4 5 6 7 8 9 10
установит переменные v1..v10 данными значениями. Если одно из значений некорректно, установка прервётся и покажется ошибка (которая не мешает, вы такие будете видеть часто).

Строки устанавливаются по одной и автоматом ковертятся в ansi-кодировку (как оказалось, в консоле кодировка доса и ваш ввод был бы непонятен ЕРМ и ЕРМ-строки отображались бы криво).

//Заполнить серию переменных указанным значением.
Так, где так армия защитника, ага, к примеру в v9000..v9015

v9000 16 0
Всё, нет армии (заполнили нулями).

Строки тоже массово устанавливаются и вся рутина (строки в ерм 0-конечные, а в паскале юзаю string) пользователю не видна и не нужна. Если нужно забить что-то пустыми строка, то используется '#0'

//Чтение и запись данных по адресу.
Нашли адрес с переменными? 16-ричный редактор неудобен, не поимает формата переменных, тогда идём сюда указываем адрес, тип (типы сллегка другие) и кол-во просматриваемых. Ой-ля-ля. Всё в родном виде. Также можно и писать в память в родном иде, числа, байты, строки...Если вы укажите кривой адрес - ничего не прозойдёт, а прога известит о неверном адресе (или защищённой от чтения/записи) области.

//Установка одной ЕРМ переменной значения другой. Сюда же входит совместимость w и v переменных. Так что все присваивания (опять таки, можно массовые) вам доступны. Например скопировать w55.w64 в v1..v10 можно за две секунды. Хорошо, но вам нужно скопировать большой объём данных, а там почти везде воговские переменные, не хочется и портить! Тогда...

//Сброс дампа и загрузка переменных из дампа!!!
Сброс дампа: Имя файла: мой_дамп.XXX
Параметры: v1 10000
Всё, все v-переменные благополучно перекочевали в файл, можете юзать память. Также просто и загрузить! Более того, можете снять дамп строк, а загрузить в v-переменные, не знаю, что это вам правда даст

Вывод: таким образом, кинув нужное место банальное !!IF:M^^; вы сможите качественно проанализировать работу скрипта и в каких переменных неверные значения, сможете эксперементировать прямо на ходу, наблюдая реакцию игры и быть в курсе внутренной кухни ЕРМ...

В первом примере используется переменная v1, значение которой нигде не задается.

ERM интерпретатор "разбирает" все триггеры и каждую строку с приемниками. Текст самой строки приемника (не триггера) не разбирается, а интерпретируется каждый раз.
Отсюда следствия:
1. Можно по ходу выполнения править текст приемников (для этого и делалось).
2. Повторной интерпретации триггера не производится, но при вызове триггера (например функции), происходит поиск в списке. Больше триггеров - дольше поиск.
3. Приемники интерпретируются при каждом выполнении. Два приемника в одной строке - меньше памяти (внутренней) используется, скорость не должна зависить. Т.к. поиска приемников нет, то и количество их (вернее строк в скрипте ERM) не влияет на скорость выполнения скриптов.
И последнее 4. При разработке ERM не ставилась задача оптимизации скорости работы скриптов. Ориентация была на разово выполняющиеся скрипты, а не циклы. И количество скриптов, конечно, ушло ДАЛЕКО вперед по сравнению с тем, что предполагалось. :-) Да и сами попробуйте прикрутить скриптовую систему, да еще и оптимизированную к чужому готовому экзешнику...

ZVS, всё это верно Ваш труд поистенне велик, но ИМХО байт-код сразу был бы более оптимальным решением. А теперь о другом. ЕРМ-скрипты уже есть, может просто переписать движок? Хотя работы много, это понятно, но диалоги и так есть, адреса переменных и встроенных функций имеются. Правда это лиш мечты. Была и другая идея: вызывать из произвольного кода библиотек Ваши ресиверы. Это возмоно? Проблема в том, что невозможно совместить быстрый код и вызов какой-небудь внутриигровой функции, которая в ЕРМ занимает пару символов. Та же: !!IF:M^^;

Это возможно. Опять - интерфейсные соглашения и внешняя DLL. Так работает, например генаратор случ. карт для Г4. Утилита грузит DLL Генератора, передает указатель на интерфейс, DLL "просит" разместить объекты и утилита размещает.

Можно даже проще.
Допустим Вы напишите универсальную функцию ЕРМ, которая выполняет один ресивер и возвращает управление. Тогда внешней DLL понадобится только адрес данной функции ну и параметр типа pchar. Функция возвращает булевкий аргумент.

Добавлено ([mergetime]1184086885[/mergetime]):
И ещё, команда по вызову DLL ещё как нужна. Пока мне приходится вообще рутинным процессом всё это делать (только при загрузке, правда). Дело в том, что если я вызываю
VreateRemoteThread с адресом LoadLibrary (сперва зарезервировав место под имя библиотеки), то библиотека загружается и всё вроде ОК, только адреса сдвинуты, а эти адреса и так с боем у Detective Story ищутся. Хуже всего то, что раз на раз не приходится.

Это хорошо. Но некоторые ресиверы подразумевают callback триггеры (тот же таймер, например). Думаю, что в минимальном варианте можно и такой функцией обойтись, но если уж делать, так делать. Предлагаю и это по почте обсудить.

В таком случае завтра придёт письмо. Рад, что не погибло желание продолжить работу над Героями. Честно говоря, я считал уже, что ВоГ 3.59 мало что светит.