New Map Utils For Dom2 - Now Available

[The_Paladin]

The main reason I'm attempting to modify descriptions (and other attributes) that are already moddable by the official tools is that I am hoping to make the GUI interface as complete as possible.

Since my program is modifying the EXE directly it would be ideal if everything the user was interested in modding could be done directly in that fashion. If you have to combine an EXE mod with a standard mod to get all the changes you desire, it would essentially mean that every time you used that EXE you would also have to enable the appropriate mods. Its not a huge issue but I think for the sake of having a nice UI and to avoid the nuisance of maintaining multiple different mods to accomplish just one overall mod, I am going to try to make the EXE mods as complete as possible.

So yes I will look into modifying the spell and item descriptions after the UI is complete .

[Endoperez]

Very interesting project.

Have you contacted Illwinter to see if they are going to implement some of the things your program can edit as moddable? I don't think your program will work (without changes) on Dom3, but if your program can write the changes into .dm format of Dom3... And that would also make your program general mod-making tool, so that one could make mod with your tool and have the program write working .dm if modified exe isn't needed.

I'm not sure if this would be much more work to you, but as I think it would be quite a simple addition suggesting it isn't too bad.

[PDF]

The_Paladin said:
The main reason I'm attempting to modify descriptions (and other attributes) that are already moddable by the official tools is that I am hoping to make the GUI interface as complete as possible.

Since my program is modifying the EXE directly it would be ideal if everything the user was interested in modding could be done directly in that fashion. If you have to combine an EXE mod with a standard mod to get all the changes you desire, it would essentially mean that every time you used that EXE you would also have to enable the appropriate mods. Its not a huge issue but I think for the sake of having a nice UI and to avoid the nuisance of maintaining multiple different mods to accomplish just one overall mod, I am going to try to make the EXE mods as complete as possible.

So yes I will look into modifying the spell and item descriptions after the UI is complete .

Hmm I don't agree on the principles : IMHO *everything* that can be modded through standard "data" mod should be left in "mods", and your .exe editing tools should *only* be used for the rest ... For example there's no point in modifying in the exe some unit cost or stats.
A clear frontier between both tools will help everyone get what he wants

[Gandalf Parker]

Personally I tend to avoid any program which modifies the game exe except for ones that come from the developer.

[The_Paladin]

Hmm... it would appear that there is some indecisiveness amongst the community . Hehe... what else is new?

The bit of feedback I did receive on my original tools that were text based indicated that they were very difficult to use for some as they had to learn both the modding commands and my new mod-style commands.

Also they indicated that they would like to have some up-to-date reference information for the units / nations / magic / etc that were altered by the mods as they would have a hard time keeping track of all the changes without such an element. I noticed this as well as I had to keep running the game to see the current state of things.

I actually received no feedback saying that anyone was actually going to use the tools in their present state - though no feedback isn't necessarily a bad thing . So I just went on my own impressions and the feedback I did get.

In order to get rid of the requirement of learning the modding tools and my new commands, I had to go to a GUI interface. In order to provide a GUI interface it would require realms of information to be displayed. The only convenient source of up-to-date information and changes to such info is the game data itself. That lead me to the executable since all (statistical) game data is stored there in the data section. There are no external statistical data files.

I noticed that there are numerous other abilities / elements that can be modified beyond the standard mod tool limits. This lead me to consider direct modification of this data.

It is also possible to avoid conflicts amongst mods, to avoid the ability overrun problem, and to provide checks / balances on many fields to reduce modding errors. All this is only possible with direct access to the EXE. These are the main reasons I approached the problem this way. It certainly wasn't for development time since this has probably tripled my work .

So these are some of the pros to this option.

The drawbacks, as some of you have mentioned, are:

- The utility will not work with Dom3 without heavy modification. That's not a huge issue as I suspect much of the Dom3 data will be overhauled. It is just a guess but basing on some of my exe mapping it seems many things were added in for the sake of the existing modding tools as afterthoughts and will probably be incorporated in Dom3. At least since I do that kind of afterthought work all the time it wouldn't surprise me if the devs here did the same.

- The utility may not be used by some as they do not like anything that directly modifies the game executable. I understand that position and respect it. Though I would also respectfully add that, in effect, the .dm mods released now also directly modify the run-time EXE data segment in the same fashion I intend to. The only differences are that it can perform this operation on the fly as it is part of the Dom2 code and, more importantly, is written by the developers.

As PDF mentioned, some may only want the exe modified to change things that the current modding tools cannot and therefore my utility should only concern itself with the remainder. The only problem with this, as I see it, is that it somewhat defeats the purpose of having a GUI as users would still need to use text files to change the majority of the game parameters.

Though I may have misunderstood PDF and he may want something along the line as Endoperez mentioned - that working .dm files are created and only the remainder be modified directly. This is an interesting alternative. It does take away the ability to do some checks and avoid conflicts as indicated earlier but that may not be bad if that's what people want.

These are my thoughts on the matter. I hope others will give there thoughts / alternatives as well. I went down the path I did largely based on feedback already so I'm open to more . I have not coded the main utility to modify the exe yet (it just reads it) so now is the time if you want something different to get your opinion in.

I had not wished to bother the developers much as I know they are quite busy. However the only other options I can see to avoid direct exe modification are:

- Expand the current modding utils to allow additional changes. This is quite the undertaking though for them. It could be done by someone else but would require access to the source code which I highly doubt Illwinter is willing to release to anyone.

- There could be another statistical data-only file (identical to the Dom2.exe data segment) that Dom2 reads in like a mod and replaces its current data with. That would be less effort than the first option but still would be work on the developer's part.

These may be options when the devs are considering modding for Dom3 to allow the community to do more custom work but I highly doubt that they will be done for Dom2.

BTW if the powers that be feel this thread should be in the mod sub-forum that's fine by me - feel free to move it.

[Endoperez]

The_Paladin said:
These may be options when the devs are considering modding for Dom3 to allow the community to do more custom work but I highly doubt that they will be done for Dom2.

That's my thoughts. I didn't understand every technical bit he said before this, but as I understand work on Dom3 is going well and would prefer IW team adding new modding tools to Dom3 instead of trying to get some more glitter above the DomII. The modding tools of DomII are, after all, added in a patch.

[PDF]

Paladin,
I did try your map tool -very nice proggie - but indeed am reluctant to change my exe - mainly because I'll have to swap exes back and forth for my MP games, keep track of what changes are where, etc ...

What I did want to mean in the previous post was that working on code-hacks for things that are moddable is a waste of effort : if the problem lies with the absence of modding GUI to create dm files the effort should be put there instead !
Thinking about this, what about making the exe-modifying program in 2 blocks :
1/ A GUI to read/modify/create dm files *and*, let's say ".em" files (exec mod !)that will store the data to change in some text format resembling dm syntax (#themecold theme_id value for example to define a theme preferred heat/cold scale)
2/ A processing program interpreting the .em data and modifying the exe (or rather creating a new exe) accordingly ?

It will then be much more easy to manage the various modded versions one can have, and to exchange them in the community just via files.

Surely I'm overambitious and it'll be too much effort, but that's my Business Analyst background speaking I suppose, I need a programmer now !

[The_Paladin]

PDF et al,

I agree with your idea of .em files. I actually already have a concept in place like that though I use .dgf files . I have a Dom2 Loader (processing program) written that allows the user to select which .exe mod to use (or none) and then run Dominions 2. Once selected, it applies the changes in the selected .dgf file to the .exe and runs it. The original Dom2.exe is always backed up and can be restored at any point. The main utility that generates the .dgf files does NOT change the .exe in any way.

This is for the exact reasons you mentioned - distributing them amongst the community and managing the various .exe mods. The only difference between what you suggested and what I have done is that, at present, the .dgf files are not text readable. They contain raw data to make it easier for the loader to patch the .exe. Since these same .dgf files can be reloaded by the main utility and edited, I do not think that changing them to be text readable is a high priority. It would also be a lot of work as making them text readable means people will try to edit them which means I cannot make some nice assumptions about the order at which data appears, amongst other things . However people have made good suggestions so far so if someone can make a good argument as to why these .dgf files should be text readable then I may be convinced. It would take a lot of convincing though as its a lot more work !

PDF, Endoperez, et al,

You both have made good points for the use of outputting as many changes as possible in .dm format... So much so that I think I will look into that . There is one major problem to overcome though:

Consider the case of the Wolfherd (BF Ulm commander who summons wolves). Say, for some reason, you want to remove his survival skills but give him stealth so he can summon wolves in an enemy province. So how would you go about this? There are two options - use the #clearspec command or not.

1) In order to remove the survival skills in .dm format you would need to use the #clearspec command. By doing so, however, you have also eliminated his ability to summon wolves. No matter what .exe changes are done there is no way to get his ability to summon wolves back when this .dm mod is enabled as the mod will overwrite the .exe changes. So therefore the desired changes are impossible when you incorporate .dm files in this manor.

2) You could try not using the #clearspec command but then the only way to remove the survival skills is with a .exe change forcing you to put all changes but the #stealth command in the .exe.

This type of problem will occur with all monsters that have a special ability that can't be altered in .dm format. As soon as you want to remove any skill from them it would force the majority of the change to be in .exe format.

Even with other monsters who you want to give a new special ability not moddable in .dm format (say give the fortune teller's bad event eliminating ability to someone else) this problem will occur if you also try to remove any ability from that same unit.

I have not thought of a good way around this. For some units, my program could create .dm changes exclusively and everything would be fine but for others, as the examples given above, .exe changes are almost exclusively required.

From a programming point of view I do not like this inconsistency (i.e. Sometimes I can modify glamour in .dm format and sometimes I have to use both .exe and .dm formats depending on the monster). Although I agree with PDF that sometimes this means re-inventing the wheel to modify things that can already be modified, I see no way around it to get the functionality I desire.

I will try however to see how much can be done with .dm changes and think about writing my util to generate both .dm and .dgf files.

However what do you (PDF, Endoperez, and anyone else) think of the idea of the loader / processing program that PDF and I described? I think it should make .exe mods as portable as .dm mods and therefore at least reasonably useful?

Thanks for the comments - they were helpful

[Endoperez]

I don't know if stats and magic could be left to the .dm while all abilities #clearspec affects are left to the .exe/.dgf, or if all changes into a unit should be done only one way.

Without thinking this much, I quess it would be enough if every unit/nation/theme is only modified in *either* .dm or .exe/.dgf . At least in the case of units and their special abilities, it seems that adjusting the same thing in both .dm and through changes in executable is just too much work for its worth.

If your GUI isn't harder to use than directly editing .dgf-files-changed-readable would be, I have no problems regarding .dgf files not being plain text files. Most people seem to avoid modding because they don't want to go through the hassle of learning #commands, so the people who start modding with your GUI probably won't even miss the option.

[PDF]

About "readable format", I suggest that mainly because it's auto-documented, I mean I just have to look at the file to see what the mod does change. Else we'll have to rely on documentation files, and we all know how unreliable they are, whenever they exist .
If the GUI is able to display data as well as create it it somewhat alleviate the problem, but still I don't think it'll be very friendly if a mod changes *many* things.

Another point : did you succeed in editing Castles values ? Those, along with themes costs/preferences, are IMHO the main unmoddable unbalanced features (my MP games show 80% WT, some Castles-Wiz Towers, no Mnt Fort, Fort City etc..)