06.02.2012, 23:51
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
07.02.2012, 12:53
Стандартом шел с железом 

07.02.2012, 13:02
всем привет
Поздравляю, хоть и с опозданием, МоРа с выходом его проекта - наконец-то - надеюсь все остались довольны и играют в эту игру с удовольствием
Поздравляю, хоть и с опозданием, МоРа с выходом его проекта - наконец-то - надеюсь все остались довольны и играют в эту игру с удовольствием
08.02.2012, 10:08
Спасибо.
1. Герои ИИ «ведут» постоянную проверку местности на предмет строительства города. Строит ИИ бесплатно – город автоматом ставится, если найдена подходящая локация. Так что, если карта практически пуста, то она на первом же ходу ИИ загромоздится городами.
2. Размещение рейд-боссов WERD-ом происходит по принципу: прохождение по всем клеткам карты в поисках чистого квадрата 5х5 клеток, если найден – поставить RB в центр. Так что опять же, если карта полупустая, RB будут на ней кишмя кишеть, причём по чёткой схеме.
Кстати, это хороший пример, где ERM потерпел бы фейл и повесил игру минут на 5-10. А так – ничего не заметно. Хотя алгоритм всё же тупой, но ничего лучшего пока придумать не могу.
Избавиться от этих проблем при картостроении в текущей версии довольно просто – не оставлять больших кусков карты пустыми. Размещению RB помешает любой объект. С городом чуть сложнее, так как фундамент может ставиться на всякие кактусы, мандрагоры и прочие декорации, но вокруг него всё проверяется на чистоту – чтобы будущий город можно было безболезненно обойти.
В Ride The Lightning RB и строительство, скорее всего, станут опциями – благо не затрагивают каких-то глобальных принципов и не интегрированы в другие системы.
P.S. Таки серьёзно засел за справку. А то ведь могу забыть вторую половину фишек...
(02.02.2012 17:56)Ivor Wrote: [ -> ]Попробую на досуге нарисовать карту для туториала, в которой были бы отражены фичи из шапкиКстати, о картостроении. Есть два не очень приятных момента, а второй неприятен ещё тем, что в S & D практически неотключаем. Оба они обусловлены тем, что мод создавался для случайных карт, где описанные проблемы не возникают.
1. Герои ИИ «ведут» постоянную проверку местности на предмет строительства города. Строит ИИ бесплатно – город автоматом ставится, если найдена подходящая локация. Так что, если карта практически пуста, то она на первом же ходу ИИ загромоздится городами.
2. Размещение рейд-боссов WERD-ом происходит по принципу: прохождение по всем клеткам карты в поисках чистого квадрата 5х5 клеток, если найден – поставить RB в центр. Так что опять же, если карта полупустая, RB будут на ней кишмя кишеть, причём по чёткой схеме.

Кстати, это хороший пример, где ERM потерпел бы фейл и повесил игру минут на 5-10. А так – ничего не заметно. Хотя алгоритм всё же тупой, но ничего лучшего пока придумать не могу.
Избавиться от этих проблем при картостроении в текущей версии довольно просто – не оставлять больших кусков карты пустыми. Размещению RB помешает любой объект. С городом чуть сложнее, так как фундамент может ставиться на всякие кактусы, мандрагоры и прочие декорации, но вокруг него всё проверяется на чистоту – чтобы будущий город можно было безболезненно обойти.
В Ride The Lightning RB и строительство, скорее всего, станут опциями – благо не затрагивают каких-то глобальных принципов и не интегрированы в другие системы.
P.S. Таки серьёзно засел за справку. А то ведь могу забыть вторую половину фишек...
08.02.2012, 11:04
1. Учту
2. А, вот почему в игре у меня RB сгенерировался на единственной дороге, ведущей из моего замка! Обойти его, конечно, можно было, но очень неудобно.
2. А, вот почему в игре у меня RB сгенерировался на единственной дороге, ведущей из моего замка! Обойти его, конечно, можно было, но очень неудобно.
14.02.2012, 18:26
Два вопроса - о настоящем и будущем.
1. RB - они вообще какие? Я им раздал параметры от балды, а должны они были быть страшными, но всё-таки победимыми. Может, они слишком слабые или наоборот - имба?
2. Стоит ли выносить Дуалит на панель ресурсов?
А ещё: Iv говорит, что у него не сохраняются имена игроков во внешнем файле при мультиплеере. У меня ОК. Есть такая проблема?
1. RB - они вообще какие? Я им раздал параметры от балды, а должны они были быть страшными, но всё-таки победимыми. Может, они слишком слабые или наоборот - имба?
2. Стоит ли выносить Дуалит на панель ресурсов?
А ещё: Iv говорит, что у него не сохраняются имена игроков во внешнем файле при мультиплеере. У меня ОК. Есть такая проблема?
14.02.2012, 19:34
Так ты решил его оставить? Тогда уж и что-то кроме строительства городов нужно с ним делать.
19.02.2012, 10:43
Ну это само собой.
Глючная подсказка по ПКМ кнопки "Купить всех" заменена на эту:

8-ой слот - Портал вызова.
Вообще, по традиции, все геройские диалоги покупки показывают цену, а не остаток. Но в данном случае, как и с кнопкой "Улучшить всех", я считаю, что такой подход был бы неправилен. Игрока всегда по сути интересует не цена, а то, что находится с нею в прямой зависимости - количество богатства после покупки. И если суммы типа 1000 одного лишь золота не напрягают, то варьирующиеся цены, состоящие из нескольких ресурсов, порой заставляют игрока юзать калькулятор. Так не лучше ли, если код сам всё посчитает?
Глючная подсказка по ПКМ кнопки "Купить всех" заменена на эту:

8-ой слот - Портал вызова.
Вообще, по традиции, все геройские диалоги покупки показывают цену, а не остаток. Но в данном случае, как и с кнопкой "Улучшить всех", я считаю, что такой подход был бы неправилен. Игрока всегда по сути интересует не цена, а то, что находится с нею в прямой зависимости - количество богатства после покупки. И если суммы типа 1000 одного лишь золота не напрягают, то варьирующиеся цены, состоящие из нескольких ресурсов, порой заставляют игрока юзать калькулятор. Так не лучше ли, если код сам всё посчитает?
19.02.2012, 18:24
А патч на анимацию далеко в планах, или лучше забыть про такую возможность?
20.02.2012, 08:02
packa, эк ты настырный. 
Ладно, попробую. Хотя откровенно не понимаю, чем эта анимация не нравится - глаза устают куда меньше. В обычных Героях, даже с HD, даже пять минут не могу находиться после того, как опробовал это. Спасибо monster`y.

Ладно, попробую. Хотя откровенно не понимаю, чем эта анимация не нравится - глаза устают куда меньше. В обычных Героях, даже с HD, даже пять минут не могу находиться после того, как опробовал это. Спасибо monster`y.
20.02.2012, 10:25
За время, прошедшее с Нового Года, WERD достаточна оформилась и теперь у меня есть о ней чёткое представление. Написал что-то вроде краткой статьи о ней - вдруг кто-то захочет сделать нечто подобное, только на высокоуровневом языке.Пример кода, реализующего то, что изображено на скрине выше. Блоки, расположенные в разных файлах, отделены коммент-символами.
Spoiler (Click to View)
Система WERD (Without ERM Relating Dynamic) – альтернативная платформа для модостроения в Героях III, чьё использование возможно только в моде Master of Puppets (MoP). Для сторонних мододелов может представлять лишь теоретический интерес в области низкоуровневого программирования.
Аббревиатура WERD изначально является анаграммой имени Drew, так как автор платформы страдает ДБГМ и СПГС.
Основу WERD составляет MoP.exe и собственно Werd.dll, написанная на flat assembler-е (fasm) – свободно распространяемом компиляторе языка ассемблера, чьим автором является Tomasz Grysztar.
Упор WERD сделан на скорость и компактность с сохранением достаточной читаемости исходного кода.
Сутью замены ERM является всего один хук, открывающий WERD доступ ко всем ERM-триггерам. По получении номера вызываемого триггера происходит быстрое сканирование (repne scasd) в таблице номеров триггеров. Если найденный триггер соответствует вызванному – вызывается функция, чей адрес расположен в другой таблице (WERD-триггеры) на том же смещении относительно базового адреса блока данных. Таким образом, каждому ERM-триггеру соответствует всего одна процедура.
Исходя из сказанного выше, нетрудно догадаться, что можно дополнительно регулировать скорость вызова отдельных триггерных процедур, просто поставив их в начало таблицы. В первую очередь это – ведение мышью, передвижение героя, клики и прочие очень часто вызываемые триггеры. Впрочем, даже при списке в тысячу триггеров этот процесс не может заметно замедлиться.
Благодаря нужному макросу, две таблицы в исходниках представляют собой одну, что исключает возможность запутаться, какой триггер какой процедуре соответствует.
Удаление или закомментирование триггера в таблице автоматически исключает его из списка компиляции, так как одной из особенностей fasm-а является то, что он не компилирует «мёртвый код» - процедуры, которые нигде не вызываются и даже не присутствуют в виде бинарных данных.
В исходниках каждый триггер начинается в файле \WERD\Begin\Название_триггера.inc объявлением процедуры и заканчивается в файле \WERD\End\Название_триггера.inc её завершением. В первом файле триггер получает данные и кладёт их в свои локальные переменные. В последнем файле могут находиться некоторые специфические данные триггера (особые функции, свитчи и пр.), но чаще всего там просто завершение процедуры.
Так как хук, реализующий WERD-триггеры, сохраняет в стеке регистры процессора, то эти регистры нет нужды пересохранять при вызове триггерной процедуры. WERD-триггер по сути – автономное образование, влияющее на последующий за ним код только через вложенные в него вызовы функций или через глобальные переменные.
Каждому триггеру соответствует файл с листингом include-ов – файлов с кодом, который присоединяется к триггеру в процессе компиляции. Листинг начинается с файла из папки Begin и заканчивается файлом из папки End. Файлы с триггерной «начинкой» находятся в папках, структурированных по игровым элементам.
Файлы с архитектурой триггеров также собраны в список include-ов в файле Werd.inc, определяющем порядок их положения в коде.
Естественным дополнением к этой системе являются описания игровых структур, константы, переменные, строки и различного рода макросы.
Главной достопримечательностью WERD является её нарастающая коллекция переходников к игровым функциям. Если специфические функции WERD расположены в самой библиотеке, то практически весь доступ к игровым процедурам осуществляется через короткую конструкцию push %Адрес функции%; ret. Остальная работа по оптимизации уже проделана в MoP.exe, как то:
1. Неудобные вог-процедуры с си-соглашением получают stdcall-ные переходники к ним.
2. Функции с постоянными параметрами (вроде ecx = [постоянный адрес]) обрезаются в переходнике по этим параметрам.
3. Частая последовательность вызова одних и тех же процедур для такого же постоянного действия (вроде инициализации DL-диалога) оборачивается в одну функцию с минимальным количеством параметров.
4. Короткие, но важные функции (вроде получения адреса структуры какого-либо игрового объекта или некой математической операции над массивами данных), тоже прописаны в exe.
Описанный подход неоднозначен. С одной стороны, именно эта особенность, главным образом, делает WERD несовместимой с другим exe, а с другой – обуславливает свободу в пределах данного мода. Сам список переходников обёрнут макросом в таблицу, которая служит и самим кодом, и наглядной документацией к нему (параметры вызова подробно комментируются). Это делает Werd.dll чрезвычайно компактной и нетребовательной. Кроме того: таблица переходников может быть экспортирована целиком в другую длл, если таковая появится в моде, и займёт в ней ничтожное пространство.
WERD поддерживает все необходимые соглашения вызова процедур – stdcall, ccall, pascal, thiscall, fastcall и стандартный вызов API-процедур – invoke.
Большинство констант, функций, структур, переменных и даже самих source-файлов в WERD имеет русские названия. Причём эти названия обычно очень длинные и подробные. Ассемблер вообще к этому приучает…
WERD – очень разветвлённая система. На настоящий момент её исходники состоят из 55 папок с более тремястами файлов при весе самой готовой библиотеки всего чуть более 20 Кб.
За месяц, прошедший с выхода версии мода Seek & Destroy, система WERD поглотила более 1000 строк ERM-кода в различных участках скрипта, при этом едва увеличив свой объём вдвое.
Аббревиатура WERD изначально является анаграммой имени Drew, так как автор платформы страдает ДБГМ и СПГС.
Основу WERD составляет MoP.exe и собственно Werd.dll, написанная на flat assembler-е (fasm) – свободно распространяемом компиляторе языка ассемблера, чьим автором является Tomasz Grysztar.
Упор WERD сделан на скорость и компактность с сохранением достаточной читаемости исходного кода.
Сутью замены ERM является всего один хук, открывающий WERD доступ ко всем ERM-триггерам. По получении номера вызываемого триггера происходит быстрое сканирование (repne scasd) в таблице номеров триггеров. Если найденный триггер соответствует вызванному – вызывается функция, чей адрес расположен в другой таблице (WERD-триггеры) на том же смещении относительно базового адреса блока данных. Таким образом, каждому ERM-триггеру соответствует всего одна процедура.
Исходя из сказанного выше, нетрудно догадаться, что можно дополнительно регулировать скорость вызова отдельных триггерных процедур, просто поставив их в начало таблицы. В первую очередь это – ведение мышью, передвижение героя, клики и прочие очень часто вызываемые триггеры. Впрочем, даже при списке в тысячу триггеров этот процесс не может заметно замедлиться.
Благодаря нужному макросу, две таблицы в исходниках представляют собой одну, что исключает возможность запутаться, какой триггер какой процедуре соответствует.
Удаление или закомментирование триггера в таблице автоматически исключает его из списка компиляции, так как одной из особенностей fasm-а является то, что он не компилирует «мёртвый код» - процедуры, которые нигде не вызываются и даже не присутствуют в виде бинарных данных.
В исходниках каждый триггер начинается в файле \WERD\Begin\Название_триггера.inc объявлением процедуры и заканчивается в файле \WERD\End\Название_триггера.inc её завершением. В первом файле триггер получает данные и кладёт их в свои локальные переменные. В последнем файле могут находиться некоторые специфические данные триггера (особые функции, свитчи и пр.), но чаще всего там просто завершение процедуры.
Так как хук, реализующий WERD-триггеры, сохраняет в стеке регистры процессора, то эти регистры нет нужды пересохранять при вызове триггерной процедуры. WERD-триггер по сути – автономное образование, влияющее на последующий за ним код только через вложенные в него вызовы функций или через глобальные переменные.
Каждому триггеру соответствует файл с листингом include-ов – файлов с кодом, который присоединяется к триггеру в процессе компиляции. Листинг начинается с файла из папки Begin и заканчивается файлом из папки End. Файлы с триггерной «начинкой» находятся в папках, структурированных по игровым элементам.
Файлы с архитектурой триггеров также собраны в список include-ов в файле Werd.inc, определяющем порядок их положения в коде.
Естественным дополнением к этой системе являются описания игровых структур, константы, переменные, строки и различного рода макросы.
Главной достопримечательностью WERD является её нарастающая коллекция переходников к игровым функциям. Если специфические функции WERD расположены в самой библиотеке, то практически весь доступ к игровым процедурам осуществляется через короткую конструкцию push %Адрес функции%; ret. Остальная работа по оптимизации уже проделана в MoP.exe, как то:
1. Неудобные вог-процедуры с си-соглашением получают stdcall-ные переходники к ним.
2. Функции с постоянными параметрами (вроде ecx = [постоянный адрес]) обрезаются в переходнике по этим параметрам.
3. Частая последовательность вызова одних и тех же процедур для такого же постоянного действия (вроде инициализации DL-диалога) оборачивается в одну функцию с минимальным количеством параметров.
4. Короткие, но важные функции (вроде получения адреса структуры какого-либо игрового объекта или некой математической операции над массивами данных), тоже прописаны в exe.
Описанный подход неоднозначен. С одной стороны, именно эта особенность, главным образом, делает WERD несовместимой с другим exe, а с другой – обуславливает свободу в пределах данного мода. Сам список переходников обёрнут макросом в таблицу, которая служит и самим кодом, и наглядной документацией к нему (параметры вызова подробно комментируются). Это делает Werd.dll чрезвычайно компактной и нетребовательной. Кроме того: таблица переходников может быть экспортирована целиком в другую длл, если таковая появится в моде, и займёт в ней ничтожное пространство.
WERD поддерживает все необходимые соглашения вызова процедур – stdcall, ccall, pascal, thiscall, fastcall и стандартный вызов API-процедур – invoke.
Большинство констант, функций, структур, переменных и даже самих source-файлов в WERD имеет русские названия. Причём эти названия обычно очень длинные и подробные. Ассемблер вообще к этому приучает…
WERD – очень разветвлённая система. На настоящий момент её исходники состоят из 55 папок с более тремястами файлов при весе самой готовой библиотеки всего чуть более 20 Кб.
За месяц, прошедший с выхода версии мода Seek & Destroy, система WERD поглотила более 1000 строк ERM-кода в различных участках скрипта, при этом едва увеличив свой объём вдвое.
Spoiler (Click to View)
Code:
; Правый клик на карте приключений
include 'WERD\Begin\Правый клик на карте приключений.inc'
.if signed Активный_герой > -1
include 'WERD\Переименование героя и города\Клик в окне статуса - переименование героя.inc'
include 'WERD\XL-портреты\Выбор в окне статуса.ASM'
include 'WERD\Показ бонусов Морали и Удачи героя при кликах в окне статуса\Показ бонусов Морали и Удачи героя при кликах в окне статуса - правый клик.ASM'
.endif
.if signed Активный_город > -1
include 'WERD\Переименование героя и города\Клик в окне статуса - переименование города.inc'
include 'WERD\Покупка существ в городе\Подсказка к кнопке Купить Всех в окне статуса.ASM'
.endif
.if [Тип_объекта_в_кликнутой_клетке] = 20 | [Тип_объекта_в_кликнутой_клетке] = 17
include 'WERD\Улучшенные подсказки по внешним жилищам\Улучшенные подсказки по внешним жилищам.ASM'
include 'WERD\Улучшение поселения\Улучшение поселения.ASM'
.endif
include 'WERD\Сброс артефактов на карту\Подсказка к Мешку по ПКМ.ASM'
include 'WERD\Показ количества Дуалита\Показ количества Дуалита.ASM'
include 'WERD\Объект Древо Жизни\Подсказка по ПКМ.ASM'
include 'WERD\Магистрат\Подсказка по ПКМ.ASM'
include 'WERD\RB\Подсказка по ПКМ.ASM'
include 'WERD\Подсказки к артефактам на карте приключений\Подсказка по ПКМ.ASM'
include 'WERD\End\Правый клик на карте приключений.inc'
; ¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤
.if Область_клика = Окно_статуса_по_городу_!_Иконка_Форта & Подтип_клика = Нажата_правая_кнопка_мыши
stdcall Подсказка_к_кнопке_Купить_Всех, [Структура_активного_города]
ret
.endif
; ¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤
proc Подсказка_к_кнопке_Купить_Всех uses ebx esi edi, TownStr
locals
Ресурсы_игрока dd 7 dup (?)
Тип_существ dd ?
Количество_существ dd ?
Номер_города dd ?
endl
Отмена_стандартной_реакции_клика
mov eax, Структура_текущего_игрока
stdcall Копирование_памяти, addr eax + Структура_игрока.Дерево, addr Ресурсы_игрока, 4*7
mov ebx, [TownStr]
movsx eax, [ebx + Структура_города.Номер_города]
mov [Номер_города], eax
rv esi, stdcall, Инициализация_игрового_диалога, Диалог_подсказки_к_кнопке_Купить_Всех, _Шаблон_диалога_подсказки_к_кнопке_Купить_Всех
stdcall Настройка_элемента_игрового_диалога, esi, 100, 13, Текущий_игрок
ccall Преобразование_текста_с_включёнными_подстроками, Буфер_для_текста, стр 452 MoPSpec, [ebx + Структура_города.Название]
stdcall Настройка_элемента_игрового_диалога, esi, 101, 3, Буфер_для_текста
; Настройка верхних слотов
mov edi, 6
.Цикл_слотов:
fastcall Проверка_доступности_существа_в_городе, [Номер_города], edi
.if word [ERM_Flag_2]
stdcall Настройка_элемента_игрового_диалога, esi, addr edi + 201, 9, mwcrport_def
lea eax, [edi * 2 + ebx + Структура_города.Количество_улучшенных_существ_0]
mov ecx, [Номер_города]
movsx edx, [ebx + Структура_города.Тип]
Умножить edx, 56
Умножить ecx, 504
add ecx, edx
lea edx, [edi * 4 + ecx + Структура_типов_обитателей_для_каждого_города + 28]
.if ~byte [ERM_Flag_3]
sub eax, 14
sub edx, 28
.endif
movsx eax, word [eax]
mov [Количество_существ], eax
m2m dword [edx], [Тип_существ]
stdcall Конвертирование_числа_в_текст, eax, Буфер_для_текста
stdcall Настройка_элемента_игрового_диалога, esi, addr edi + 31, 3, Буфер_для_текста
mov edx, [Тип_существ]
add edx, 2
stdcall Настройка_элемента_игрового_диалога, esi, addr edi + 201, 4, edx
; Настройка нижних слотов
stdcall Вычисление_количества_нанимаемых_монстров, [Тип_существ], [Количество_существ], addr Ресурсы_игрока
.if eax
stdcall Конвертирование_числа_в_текст, eax, Буфер_для_текста
stdcall Настройка_элемента_игрового_диалога, esi, addr edi + 131, 3, Буфер_для_текста
stdcall Настройка_элемента_игрового_диалога, esi, addr edi + 301, 9, mwcrport_def
mov edx, [Тип_существ]
add edx, 2
stdcall Настройка_элемента_игрового_диалога, esi, addr edi + 301, 4, edx
.endif
.endif
dec edi
jge .Цикл_слотов
; Настройка Портала Вызова (верхний слот)
mov eax, Размер_структуры_городских_реликвий
imul eax, [Номер_города]
Проверка_бита [ebx + Структура_города.Биты_строений1], Бит_Портал_Вызова
.if CARRY? & [ebx + Структура_города.Тип] = Темница | [eax + Адрес_структуры_городских_реликвий + Структура_городских_реликвий.Тёмный_Круг_Баа_за_Дерис]
stdcall Настройка_элемента_игрового_диалога, esi, 208, 9, mwcrport_def
mov eax, [ebx + Структура_города.Тип_существа_в_Портале_Вызова]
mov [Тип_существ], eax
add eax, 2
stdcall Настройка_элемента_игрового_диалога, esi, 208, 4, eax
movsx eax, [ebx + Структура_города.Количество_существ_в_Портале_Вызова]
mov [Количество_существ], eax
stdcall Конвертирование_числа_в_текст, eax, Буфер_для_текста
stdcall Настройка_элемента_игрового_диалога, esi, 38, 3, Буфер_для_текста
; Настройка Портала Вызова (нижний слот)
stdcall Вычисление_количества_нанимаемых_монстров, [Тип_существ], [Количество_существ], addr Ресурсы_игрока
.if eax
stdcall Конвертирование_числа_в_текст, eax, Буфер_для_текста
stdcall Настройка_элемента_игрового_диалога, esi, 138, 3, Буфер_для_текста
stdcall Настройка_элемента_игрового_диалога, esi, 308, 9, mwcrport_def
mov edx, [Тип_существ]
add edx, 2
stdcall Настройка_элемента_игрового_диалога, esi, 308, 4, edx
.endif
.endif
mov edi, 6; счётчик ресурсов
.Цикл_ресурсов:
stdcall Конвертирование_числа_в_текст, [edi * 4 + Ресурсы_игрока], Буфер_для_текста
stdcall Настройка_элемента_игрового_диалога, esi, addr edi + 63, 3, Буфер_для_текста
dec edi
jge .Цикл_ресурсов
thiscall Показ_игрового_диалога_Pop_Up, Диалог_подсказки_к_кнопке_Купить_Всех
ret
endp
proc Вычисление_количества_нанимаемых_монстров uses ebx edi, тип, количество, адрес_строки_вычитания_ресурсов
xor edi, edi; счётчик существ, которые могут быть наняты
mov ebx, [тип]
Умножить ebx, Размер_структуры_монстра
lea ebx, [ebx + Адрес_структуры_монстров + Структура_монстра.Цена_в_дереве]
.while signed edi < [количество]
stdcall Сравнение_значений_двух_массивов_двойных_слов, ebx, [адрес_строки_вычитания_ресурсов], 7
test eax, eax
je .недостаточно_ресурсов
inc edi
fastcall Вычитание_массива_из_массива, [адрес_строки_вычитания_ресурсов], ebx, 2, 7
.endw
.недостаточно_ресурсов:
mov eax, edi
ret
endp
20.02.2012, 11:15
(20.02.2012 08:02)MOP Wrote: [ -> ]packa, эк ты настырный.Если делать такой патч, то и с возможностью обратно сделать все как было, а то ведь кому-то может не понравиться стандартная скорость.
Ладно, попробую. Хотя откровенно не понимаю, чем эта анимация не нравится - глаза устают куда меньше. В обычных Героях, даже с HD, даже пять минут не могу находиться после того, как опробовал это. Спасибо monster`y.
20.02.2012, 14:42
Флеш Wrote:Если делать такой патч, то и с возможностью обратно сделать все как было, а то ведь кому-то может не понравиться стандартная скорость.Ну дык пускай тогда не ставят) в чем проблема?)))
Я так думаю что этот патч можно будет поставить в любой момент и на любую версию (ну почти) т.к. касается только анимации - никаких тут багов и тех. заморочек.
МоП Wrote:packa, эк ты настырный.Просто мод понравился, а поиграть не могу - анимация просто заставляет меня закрыть игру =(
МоП Wrote:Хотя откровенно не понимаю, чем эта анимация не нравитсяНу как же? Все красиво, плавно, естественно. С быстрой анимацией - лично у меня убивается вся атмосфера.
Теряется тот шарм, и то очарование за которые я и люблю героев )
20.02.2012, 16:29
Флеш имел ввиду, что патч встроеный.
20.02.2012, 16:58
Кстати, верд же такое позволит сделать, хотя я подразумевал не это, но так даже лучше.
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