New Map Utils For Dom2 - Now Available

[NTJedi]

The Paladin..........

That's awesome news adding a GUI interface... lots more people would use the tools with a user friendly interface.

Thanks so much for bringing these to us !
You're not just a good paladin... but a great paladin.

[The_Paladin]

Ok I've got good news and a little bit of bad news.

I made a previous vague statement about adding in even more options and checking into a few things. That 'checking' was investigating the data structure of Dom2.exe. Based on that I believe that direct modification of that data is feasible and further it will allow modding of some abilities that are not currently moddable. For example I have successfully tested adding Summon Allies to new units. Further to this I have contacted the developers as I did not want to modify Dom2 code without permission. Earlier this afternoon that was given so thanks Kristoffer . So all this is good news.

The bad news is that a relatively small project has grown in dimension because of this. Its not that bad but it does mean that some work I've done up to this point is rather useless.

So in summary the final proposed project features are:

1 - Graphical Interface
2 - Capable of modifying existing maps as per Genesis Map Mod
3 - Capable of directly altering Dom2 data to mod as many abilities / elements of the game as possible (this will incorporate the creation of non-random and random mods as per Genesis Game Mod)

I will work on this project, time permitting, but also as this project has grown if anyone would like to volunteer assistance would be appreciated.

I could likely use someone to help with the writing of the actual utility as there a few independent aspects that can be coded separately. Since most of the existing code is in C++ (and I may need to write a little assembly to check a few things) ideally someone who is familiar with C++ would be helpful.

Anyone who would be available to test out the changes as their made and potentially investigate what certain abilities actually are (as I'm uncertain about a few fields) would be helpful as well.

And also I don't know if this is currently available or not but a complete list of unit abilities would be very helpful.

I believe it will be an interesting project and I've already learned a few things myself. So if you want to help with any of this, please let me know .

[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.

[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.