Far calls in overlay

[Asfex]

I don't understand. Are you saying those 7 bytes are being used for something? I only used 2 for the new entry, there are 5 left.

Those 6 bytes is not used by something except adresses to point to overlay-segment inside the overlay. feel safe. But. Can you form a dif file to implement it in the other mod?

[I like Serena]

When we start moving far calls and/or function boundaries around, combining different binary diffs/patches to the same segment becomes indeed impossible.
Up till now fixes were always very localized, maintaining the existing framework of far calls and jumps.
Then again, ideally we come up with a diff/patch mechanism that can handle it.
It would be very nice if we can pick which fixes we want in or out and just merge them together.

Let's see... what does a typical fix look like...

As far as I've been doing stuff, it's optimizing some code to make space, and then add/change some code.
Typically all of that is in 1 specific function, carefully keeping far calls and jumps in the same place.
As long as no other fix touches the same function, that can be merged together with any other fix.

Alternatively, a fix can consist of changing some data (in the data segment, directly in the code, or in an LBX file).
That can easily collide with another fix that touches the same data.
That's basically what I ran into when trying to merge Insecticide with another mod.
On a binary level it's pretty difficult to figure out what is what if enough changes have been made.

[I like Serena]

Aaaaaand it works!!!!!!!!!!!!!!!!!

Nice!

To add an entry I used some of those empty 0 bytes at the end (guess they are to make segments multiples of 16 bytes) and had to increase the relsize value in the stub by 2 to actually read the new entry.

I'm worried what "nenteries" might be, though. There were exactly 7 of those 0 bytes there and "nenetries" happens to be a 7. Maybe a coincidence but what if it isn't? (I tried changing it to 5 but it crashes the game so it most likely isn't the number of zero bytes, but I'm still worried.)

Not sure what you mean.
stub119 (corresponding to ovr119) has a 'relsize' of 70h, which I think means 70h bytes of relocation entries - it fits exactly, excluding the 00 entries, and excluding the 'cb' prefix.
And stub119 has an 'nentries' of 3, which means there are 3 far functions in ovr119.

[Seravy]

Aaaaaand it works!!!!!!!!!!!!!!!!!

Nice!

To add an entry I used some of those empty 0 bytes at the end (guess they are to make segments multiples of 16 bytes) and had to increase the relsize value in the stub by 2 to actually read the new entry.

I'm worried what "nenteries" might be, though. There were exactly 7 of those 0 bytes there and "nenetries" happens to be a 7. Maybe a coincidence but what if it isn't? (I tried changing it to 5 but it crashes the game so it most likely isn't the number of zero bytes, but I'm still worried.)

Not sure what you mean.
stub119 (corresponding to ovr119) has a 'relsize' of 70h, which I think means 70h bytes of relocation entries - it fits exactly, excluding the 00 entries, and excluding the 'cb' prefix.
And stub119 has an 'nentries' of 3, which means there are 3 far functions in ovr119.

All of the change was in stub/ovr60, the "EndTurnButton" procedure. Ovr119 is one of the procedures called by the button one, happens in the middle of the progress but as the bug is caused by not calling the save at the very end (or beginning but end had more space) it had to be moved from there. All I did in ovr119 was to make it jump over the now unnecessary old call, and I added the call in ovr60. Ovr119's relocations are unchanged, I just skip the call with a jmp.

Attached a diff file (you need fileset.exe from my mod to apply it).
It contains all the changes I made today, which, according to my log is

-Autosave now happens at the beginning of the new turn instead of in the middle of the end turn process.
-War Bears now costs 55 to summon and 1 to maintain.
-Werewolves now cost 125 to create and 2 to maintain.
-AI wizards will not try casting Spell of Return if their skill is below 25 instead of below 40. This should make it somewhat less likely for one AI to premanently eliminate another at start.

It's plain text, you can cut out unwanted changes easily.
The format is 3 lines for every changed byte, in the order of address,source,destination.
Fileset does apply the change even if it does not match the source value but it gives you a text warning for each byte not matching.

Keeping things compatible is indeed difficult. In most cases it works like you describe, but sometimes I need to use space that was freed up by removed spells (for example Word of Recall's AI space is used to adjust priority for like 10 other combat spells in the mod).
Some, more difficult changes actually require making space at 3-5 different (near) locations, and using near jumps or calls to merge that space into one (like adding the "turns : display").
I'm not planning to use far calls to make space unless it's a last resort (due to the nature of overlays this wouldn't work well inside loops and such I think anyway), but it's nice to have such last resort.

I plan to separate all changes that can be separated and release them as txt files when making that raid150 patch, but first I want to at the very least play like 10-20 games after the last changes made to see everything works safely.