New Map Utils For Dom2 - Now Available

[Saber Cherry]

I dislike writing (and especially reading) C, but I'd be willing to help with non-coded aspects. So if you need tests run to find out what a unit ability does, I'd be interested in helping.

Do you think there is any possiblity of altering dice rolls, like changing 2d6oe (open ended) to 2*(2d6oe)+(1d2)? Or more simple things like number of spell effects / spell damage?

[The_Paladin]

Saber Cherry said:
I dislike writing (and especially reading) C, but I'd be willing to help with non-coded aspects. So if you need tests run to find out what a unit ability does, I'd be interested in helping.

Do you think there is any possiblity of altering dice rolls, like changing 2d6oe (open ended) to 2*(2d6oe)+(1d2)? Or more simple things like number of spell effects / spell damage?

Dislike C!?!?!? Is that even possible ?

I'm not certain about the dice rolls though my impression is that it would be a code segment change. Since dice rolls are likely generated all over the place it would be extremely difficult to change.

I imagine several elements of magic sites and magic spells that you mention are alterable. At this point I have mapped only the units and unit magic assignment structures however. The sites and spells look to have relatively simple structures but only looking at them in more detail will tell.

I have sent you a PM to give you the info on what's been mapped so far.

[The_Paladin]

Project Update

It has been an incredibly busy week of work on this project for me. As I know I will be returning to a regular work schedule soon I wanted to get as much done as possible.

I will not delve into all the details but in summary I have mapped essentially 90% of the interesting portions (the portions I am interested in for this mod) of the Dom2.exe. The following items I know how to modify directly now. This is not a complete list - just a summary off the top of my head:

Nations
-------
- Cold Preference
- Recruitable units
- Starting magic sites

Dominions / Themes
------------------
- Design cost
- Scale requirements (no more turmoil for S&A will soon be possible - if you want at least)
- Recruitable units
- Starting Sites
- Restricting nations to specific themes

Units
-----
- All stats
- Some special attributes
- Some additional commands
- Armors and Weapons

(Basic) Armor
-------------
- Pretty much everything

(Basic) Weapons
---------------
- All stats
- Special attributes
- Associated animations / fx
- The special 'Damage Type' field! Should prove interesting but no more details at this point.

Magic Items
-----------
- Construction level
- Path costs
- Extra spell
- Combat spell
- some additional attributes

Magic Sites
-----------
- Gem Incomes
- Type, Level, and Frequency
- Some additional attributes

I haven't bothered with spells (yet) for the reason that it seems many of these items share a list of well over 200+ attribute / fx types that can be assigned. The spells make extensive use of this list and until I have a better idea what more of them do, mapping the spells would prove pointless. Additionally when more of this list is mapped, I will likely be able to modify all the additional attributes of the units, weapons, armor, etc, etc.

At present I am working on a GUI to allow others to implement these mods (partly also because if I have to look at one more piece of hexcode in the next few days I'm going to explode ).

All right - that's it.

[Endoperez]

Will it be possible to edit descriptions? That is my biggest gripe with the official modding tools.

All of this looks very good. And if you manage to make some kind of a GUI for it, it will help people to make more mods faster and much more easily. Great work! Keep it up!

[The_Paladin]

In the initial version I'm working on now I'm not going to include the ability to edit descriptions but in future versions it may be possible.

The issue with unit descriptions is basically that within they are often stored in variable length string buffers (this is probably due to both the complier and intentional development) which essentially means the new strings / descriptions have to be the exact same length as the old ones in order to function properly - either that or alter the entire string structure which then means that every reference to the old strings has to be updated which is rather difficult when hex-editing.

This issue can be worked around - possibly by expanding the data segment... but I hesitate to do that as it would make porting this change to other non-windows OS's very difficult.

I believe however many of the types of descriptions should be easy to alter and I will look into that after I have more of the GUI coded.

[Cainehill]

If, as I believe, we're talking C-style strings in C++, then the new description shouldn't need to be the exact same length - merely the same length or shorter; the null termination of the shorter description should cause all to be well. Not nearly as complicated as if we were talking Pascal style strings, or the C++ <string> class.

[The_Paladin]

Yes I believe you are correct Cainehill. I would be willing to bet that they are simple C strings and therefore shorter lengths may be ok. The reason I say may is that some of the strings are stored as:

"String 1" + '\0' + "String 2" + '\0' + ...

and the problem here is that if, say, we change it as follows:

"New 1" + '\0' + '\0' + '\0' + '\0' + "String 2" + '\0'

Thus we have changed string 1 and maintained the starting address of both strings. However if they are stored in a tightly packed method. The code reads the strings by reading the chars up until the first null character then assumes the next character is the beginning of the next string, instead of reading just two strings it will now read, "New 1", 3 null length strings, then "String 2". I know that Windows stores its string resources in this fashion and variable parameter functions like printf and scanf use strings like this as well.

I'm not sure this is how they do read the strings but I'm hoping you are correct which will make the modification easier.

The other issue is that the optimizing complier has embedded DWORD alignment of the strings. That means that, say, if a null-terminator of a string ends on a non-4 byte boundary it will pad it up to the next boundary. That means the CPU no longer need worry about the last two address bits when incrementing between strings. It also means that any would be hacker has to maintain this padding. Not terribly complicated mind you but still a nuisance. The fact that this padding exists though indicates, at least partly, that the tightly packed method I described above is likely not used or else this padding would disrupt it as well.

On a better note the descriptions themselves seem to be stored in large fixed length strings so that should be quite easy to manipulate... the names of items on the other hand are stored in this other manor. I believe if you look at the modding manual - any description / name that can be changed with it will have a fixed length string and any that cannot be changed will be stored variable length. I suspect this is why the limits of modding are the way they are.

Anyway sorry for rambling Cainehill - you just made me start thinking about the subject and I'm thinking out loud .

[PDF]

Bah, we could spare some headaches if the shortened description were padded with blanks (/20), isn't it ?

[The_Paladin]

Indeed! I never thought of that but it may indeed be an option . If we pad both sides of the name strings with relatively the same number of spaces they will remain centered on the screen in the descriptions and yet also remain the same size.

[Endoperez]

I quess the spell and item descriptions are also stored the same way, and can be changed to be editable shortly after monster descriptions?

And why, exactly, do the monster descriptions have to be editable by your program when that is doable in mods? It seems I forgot to mention that I was mainly interested in editing the descriptions of spells and items.