(22.07.2023 18:10)AnT Wrote: [ -> ]А возможно ли динамически заменить сразу весь Dwelling.txt на заранее подготовленные Dwelling2.txt / Dwelling3.txt / ... ?
Теоретически можно:
1. Загружаешь в память игры свои тестовики с помощью SN:E
2. Записываешь адрес на загруженный текстовик в 8 адресов памяти с помощью UN:C в нужный тебе момент времени. Естественно, что окно города при этом должно быть закрыто, иначе придётся менять тексты "на лету" в самих структурах диалогов города, что достаточно не просто.
Подскажите, плиз, как узнать имя загружаемого файла в функции !?FU(OnSavegameRead); или функции
!?FU(OnAfterLoadGame); и какая предпочтительнее?
Вообще-то, меня интересует конкретно загрузка с файла BATTLE, чтобы сбрасывать настройки скриптовых боёв.
P.S. Я понимаю что можно это делать в общем !?FU(OnGameEnter); но сбрасываемых настроек много и я боюсь, что у тех, у кого компы слабенькие, будет задержка, которая может бесить
Is there a way to play a .def but flip it horizontally?
For example, I have a def like this:
Here I want to play it like this without creating another def:
I suppose it can be done in heroes 3 as there are some def with direction changes, like the animation of Death Blow (Death Knight's ability)
Most of def frame drawing functions have Mirror (horizontal) support like:
DrawInterfaceDefGroupFrame (
Def: Heroes.PDefItem;
GroupInd, FrameInd, SrcX, SrcY, SrcWidth, SrcHeight: integer;
Buf: pointer;
DstX, DstY, DstW, DstH, ScanlineSize: integer;
DoMirror, UsePaletteSpecialColors: boolean
); stdcall at 0x47B610;
But I don't recall ready to use "play" function with this parameter. Further investigation is necessary.
Berserker, thanks. Another related address is 0x47BE90.
As I see this will take a lot of trials which might not be realistic at the moment. I will just give this up
There can be dirty approach like BM:V command with hook on DrawDefFrame function, replacing DoMirror argument for particular def name, but I would not suggest such approach, unless the feature is a must have.
Archer30, Berserker, 0x47B610 directly calls 0x47BE90 just changing Def* , groupId and frameId args int Frame
So probably it doesn't matter where to hook
Archer30, so why you just gave this up?
daemon_n, because life is short. I decided to put on other tasks so we don't get stopped in progress
I will get back to it when I have more understanding
Looking for some help with changin the sprite of creature depending on days.
The following script works only for the first switching and then the sprite keeps unchanged. I suppose this is because the something's cached. Possible to be improved?
Also, is there a way to change the sprite on the map of a creature by days?
The only way would be tracking LoadDef and Def->Destruct functions in order to find out the location of loaded defs in memory (which game structure), I suppose, with further unloading/reloading. Anyway, it does not seems as reliable solution. Once the object is drawn and not removed, resource counter is kept > 1, resource is not released and SN:R simply cannot redirect anything. SN:R intercepts LoadDef function, changing argument "name". After resource is loaded and stored in memory, nobody can force the game or plugin to use other def. The only exception are png frames, which ignore already loaded DEF frames.
Maybe another redirection mechanism could help. Something redirecting def drawing functions to other def frames on the fly. I didn't implement it yet. In your example 195z.def is not loaded, thus when we redirect 196z.def frame to 195z.def we should load def from archive, draw single frame and release memory, which would be very slow, unless implementing some time-limited cache.
Basically, SN:R is only for masters of memory hacks.
LoadDef loads resource if it was not loaded yet and set it's reference counting to 1. If resource was already loaded by other code, it's reference counter is simply increased by one. When some code does not need resource anymore, it call Dereference method, which decrease reference counter by one. When it reaches zero, the resource is freed.
So image we have some structure like AdvMapObject with Def field = 0. On the first draw call, LoadDef will be called for each such object with particular def name. If we have 10 objects on the map of the same type, the def will have reference counter = 10.
SN:R intercepts calls to LoadDef and changes one def name to another. But if def pointer is already stored in some structure, we cannot force that structure user to use new def. When all objects are removed from map (reference counter decreased until 0 and def is freed), SN:R is able to take effect on the next LoadDef call.
Berserker, I get the idea, thanks!
New question:
Is there any requirement for a position to be inserted with an erm hook?
Daemon_n told me that it is recommended to put a hook only when there are 5 bytes between opcodes, but from what I see three would also do. Is that correct?
An example is that I put a hook at 0075DE2B for getting one of my creatures to have the same chance of Age with Blood Dragon, but daemon said 0075DE31 is safer. I find no difference between these 2 hooks so far.
5 bytes are required in insert "CALL Hook_Bridge instruction" (1 byte for command and 4 bytes for offset). So at least 5 bytes are always overwritten. Erm Hooker plugin relocates overwritten commands to new memory buffer, preserving all of them. But if there are jumps from other code to overwritten bytes, you'll get a crash. Because this external code will jump into the middle of new CALL command and will interpret new bytes as normal commands. So generally it's safe to overwrite group of assembler instructions with at least 5 bytes in length (like PUSH something, ADD something, XOR something, CMP something), not in the end of function and without jumps in the middle of those 5 bytes.
0075DE2B seems to be safe place.
CMP ECX, 9A
6 bytes, comparison between CPU register and constant, changes CPU Flags register
If your hook does not prevent default behavior or changes comparison logics and return address, it's safe.
0075DE31 seems to be less usable:
0075DE31 |. /75 08 JNE SHORT 0075DE3B
0075DE33 |. |B9 54024400 MOV ECX, 00440254
Two commands will be overwritten, I do not see any advantages. Moreover, the first address was the beginning of IF ... ELSE block, while daemon's variant is just in the middle of IF construction. It's easier to control block start logics.