Улучшение ИИ

Согласно декомпилятору, данные в ST(0) далее используются (передаются в функции дальше). Но на самом деле это неправда - не используются они дальше. Так что в целом вы правы - но были бы неправы, если бы декомпилятор был прав )))

ИИ некрит всегда по одному скелету.
Как это исправить?

Цитата:

The problem with casting from floating-point numbers to 32-bit integers stems from the ANSI C standard, which states the conversion should be effected by truncating the fractional portion of the number and retaining the integer result. Because of this, whenever the Microsoft Visual C++ 6.0 compiler encounters an (int) or a (long) cast, it inserts a call to the _ftol C run-time function.

This function modifies the floating-point rounding mode to 'truncate', performs the conversion, and then resets the rounding mode to its original state prior to the cast. This code sequence is a detriment to application performance because modifying the rounding mode requires use of the long-latency FLDCW (Floating Point Load Control Word) instruction.

Так что _ftol() - это плохо

Цитата:

ИИ некрит всегда по одному скелету.
Как это исправить?

Думаю, нужно поставить брейкпоинт на Necromancy_GetPower и посмотреть, в чём там дело. На армию компа тоже можно поставить.

as239 писал(а):

ИИ некрит всегда по одному скелету.
Как это исправить?

RosеKavalier исправлял же. Я тоже правил, на свой манер.

По Роузу (давно присылал, человеческим языком еще было написано):

Код: Выделить всё

void _HH_AI_NecromancyFix(HiHook *h, BYTE *winner, BYTE *loser, _Town_ *town)
{
        CALL_3(void, __thiscall, h->GetDefaultFunc(), winner, loser, town); // call function
        CALL_2(void, __thiscall, 0x424880, loser, 1); // delete army after the fact
}

...

_PI->WriteHiHook(0x426EE0, SPLICE_, EXTENDED_, THISCALL_, _HH_AI_NecromancyFix);
_PI->WriteWord(0x426FE4, 0x07EB); // jmp 0x426FED, doesn't delete loser army


А вот мой "багфикс" для исправления переоценки ИИ опасности крепостного рва:

Код: Выделить всё

int __stdcall AIMoatEstimate(LoHook* h, HookContext* c)
{   
      if(gameVersion >= 2)
         c->edx = c->edx/2;
      else
         c->edx = 0;

   return EXEC_DEFAULT;
}
...
_PI->WriteLoHook(0x4B31D7, AIMoatEstimate);


2Ben80: По фиксу Necromancy всё понятно. Армия удалялась до расчёта поднимаемых существ. А почему оценку (?) опасности крепостного рва делим именно на 2?

AlexSpl писал(а):

2Ben80: По фиксу Necromancy всё понятно. Армия удалялась до расчёта поднимаемых существ. А почему оценку (?) опасности крепостного рва делим именно на 2?

Вопрос уместный. Можно было бы конечно делить на 4 (думаю, ты это имеешь в виду). Но, во-первых, это дань уважения оригиналу (все же мы остаемся к нему ближе). Во-вторых, это все-таки имеет смысл. Скажем, у нас (вернее, у ИИ) в штурмующей армии есть отряд, который имеет ХП в несколько раз больше, чем урон рва, а есть такой, ХП которого едва его превышает. Если у нас будет условие (ХП > Дамаг рва), то может быть ситуация, когда в ров к единственной дырке в стене идет слабый стек, толку от чего не будет никакого. А при условии (ХП / 2 > Дамаг рва) все получится правильно - в ров пойдет сильный стек.

AlexSpl писал(а):

оценку (?) опасности

Это не оценка, да. Это абсолютно строгое условие - монстры идут в ров, только если имеют ХП стека минимум в 4 раза больше, чем дамаг рва. Так в оригинале.

Вот еще маленький-маленький фикс для веса постройки Усилителя черной магии:

Код: Выделить всё

int __stdcall correctAmplifierAIValue(LoHook* h, HookContext* c)
{
   _Hero_* hero = o_GameMgr->GetHero(c->ecx);

   if(hero->_class == 8)
   {
      c->return_address = 0x42B14C;
      return NO_EXEC_DEFAULT;
   }

   return EXEC_DEFAULT;   
}
...
_PI->WriteLoHook(0x42B131, correctAmplifierAIValue);


В оригинале ИИ смотрел только, есть ли у него Некроманты. А про Рыцарей Смерти забыл. То есть получается, если у ИИ-некра герои - только Рыцари Смерти, то Усилитель он строить вообще не будет.

Ben80 писал(а):

Code of RoseKavalier becomes more and more complex. We make just hacking, not complete programming project. Who need
all those "protected", "public" and so on (object properties) ? In hacking all properties are public ))

In principle we could use just C, not C++... Though, to tell the truth I have used sometimes some C++ abilities. For example, passing an array by reference to procedures.

P.S. Thank you for H3API.

I typically cast with DWORD() or (DWORD) but when I really want clarity I will use reinterpret_cast<> or similar.

protected members in H3API are there to reduce clutter by hiding things that are either not necessary or unknown/undefined/mislabeled.

Whenever I want to do an ASM hook, I prefer to write it directly in assembly myself rather than use the convenient-but-not-so-convenient patcher_x86 ASM hook.

Suggestions and additions to H3API are always welcome)

Правильно я понимаю, что если ST(0) не "очищается" в коде, то декомпилятор при вызове далее вложенных функций всегда считает, что он туда передает "лишний" floating-point аргумент ?
Или я невнимательно читаю то, что AlexSpl пишет ?