Scenario Generator (WIP)

[Autolykos]

Hello modders!

I have spent a lot of time hacking together various scenarios (mostly for quick MP games), and always found it annoying to make sure all the IDs are correct, all the files are included and all parentheses matched.
To simplify this, I wrote a small C++ program that generates the .eug file and all those little .inc files from a short script (or interactively with a console interface). Now generating the scenario is as simple as writing a few lines like "national ENG England Scotland Northern_Ireland", copying the generated files back to your scenario folder and maybe adding a few finishing touches and customizations.
I've included the source code, as well as three examples (one generates a pretty good approximation of the 1936 scenario, one divides the world into three 1984-style blocks and the last one is a pretty simple battle scenario). They are not meant to be played (as they are still quite incomplete), but as a reference for how the commands should be used. If anyone feels like completing them (or adding more templates and/or refining the country database) I'd be happy to include this in future versions of the program.

To use it, simply run the .exe file (for the console interface) or drag a script on top of it (for fully automatic generation).

The Tech and Policy templates are meant for Darkest Hour Full. For other mods, you'll have to write (or copy/paste) your own.


Changelog:

Alpha 6:
- buildings can now be placed along borders (useful for forts) or on the
shortest path between provinces (useful for infrastructure).
- slightly adjusted paths.cfg to point to directories, not individual files

Alpha 5:
- generates a victory point distribution based on rules in vp_rules.csv
- automatically distribute buildings and resources to countries and areas
(based on current IC/production and infrastructure)

Alpha 4:
- config files to adjust global settings (like province language and paths)
- manually add buildings and resources to provinces

Alpha 3:
- generate armies, fleets and air forces from templates

Alpha 2:
- interactive help for all commands
- support for battle scenarios and inaccessible provinces
- syntax checking for commands, preventing crashes for missing parameters
- allows listing all undistributed provinces, to check if you missed some
- added workarounds for some mismatches between DH's Provinces.csv and province_names.csv
(AREA_MOZIR vs AREA_MOZYR and AREA_RYUKYULAND vs AREA_RYUKYUSLAND)

Features to be included in later versions:
- converting a savegame into a cleaned-up scenario (maybe)

Feel free to request other features that would make your life easier - I'll prioritize those that can be expressed as a few short commands, but would be tedious to add manually to a scenario (I think provinces and armies were the worst; those should work now).

 

[Gungsong Gungts]

i get this
:

is there a prerequisite program or file i need for this?

 

[Autolykos]

is there a prerequisite program or file i need for this?

I've only used the C++ standard library, so I'm a little surprised to see any dependencies at all - but it seems MinGW does in fact use libraries that aren't part of Windows.
Changed the linking to static, file is now a bit bigger, but shouldn't require MinGW's dlls any more.
Worst case, you can always build from source - any compiler that implements C++11 should do.

EDIT: Attached the DLLs here, instead of the top post, since they should not be needed any more.
If you do need them, please consider it as a bug and report it.

 

[Gungsong Gungts]

Thank you, it works perfectly now.

 

[Autolykos]

Uploaded a new version, implementing all promised changes except for auto-generating armies (that's next), plus a few bugfixes.

To any devs reading this:
I'm a bit surprised that the game doesn't hiccup at the bad area names. You may want to fix them nonetheless, since they will probably still screw up the localizations for Mozyr and Ryukyusland.

To anyone who knows about map editing:
I'd appreciate a pointer on how to find out which provinces are adjacent to each other (what file, and how to read it), since this information would be incredibly useful for commands that add border forts or build infrastructure between two provinces.

 

[Jeem]

I've included the source code, as well as two examples (one generates a pretty good approximation of the 1936 scenario, the other divides the world into three 1984-style blocks).

Can you elaborate on this? What do you mean by a good approximation of the 1936 scenario? What about the 1984 one (I know what 1984 is mind you)? Does this edit the iCs, or would the 1984 scenario for example just split the vanilla world into 3 countries?

 

[Autolykos]

It doesn't change IC or resources yet, it can't place bases, VPs or armies, and it doesn't generate trade deals - those will come in later versions (It's still very early Alpha, after all). I'm also not quite sure I distributed the Pacific islands and the Chinese warlords correctly, and I didn't bother setting all the relations to the correct value - that's why I call it an approximation. For now, you could just copy over bases.inc and vp.inc and include them in the .eug.

The 1984 one is just an example of a very minimal scenario that demonstrates a few features I couldn't show in the 1936 one - and the benefit of assigning whole continents in a single line instead of copying and reformatting long lists of IDs.
Eurasia and Oceania should be roughly balanced, but Eastasia might be a bit underpowered (they have only about a third of the IC, but twice the manpower of the others).

Also, while the scenarios should be "playable" without any modifications, this is not what the program is meant to do. It should take away the tedious, repetitive part but leave the fine-tuning to you. I'll probably never include commands that are so fine-grained that including them in the script would be just as much work as making the changes manually in the generated scenario (this includes loading AI or Event files - whether you put the include into the script or the .eug shouldn't matter) - or at least give preferential treatment to commands that give you more bang for your buck.

 

[Autolykos]

And the next update is out. You can now add armies and fill them with units - and the program will make sure you don't get any ID collisions.

 

[yeastmobile]

Why does it say I need libgcc_s_sjlj-1.dll ? I see you said you already fixed that but it is still complaining.

 

[Autolykos]

Recompiled, it should work now (one of the compiler options got removed).
I also uploaded MinGW's dlls, just in case. You should not need them, though.

 

[Autolykos]

Uploaded the weekly update. Biggest change is that you can now add buildings to provinces and change their resource production and manpower.
Also, you do not have to copy over all the csv files any more, if you instead specify their paths in "paths.cfg". Relative paths should be valid, too (use "../" to go back one directory).
I've also added a config file that allows you to read the province and area names in a different language (Although I haven't tested how special characters behave, and expect that Russian will be completely borked). You can also use it do set global defaults for resource multipliers (previously only in countries.csv - which now has a slightly different layout), and specify whether you want buildings and resources written to the respective *.inc files of the province owners, or put into one big bases.inc file.

 

[Autolykos]

And the next update is finished. Automatic placement of buildings and resources is now greatly improved.
You can, e.g. write "auto_build 20 naval_base GER", and it will distribute 20 levels of naval bases along the German coast, preferring provinces with high IC and infrastructure.
Also, each scenario will now suggest a VP distribution (saved to vp.inc) based on rules you can specify in vp_rules.csv

I'm rather content with the amount of features for now, so there won't be more than one or two updates before the project goes Beta and I focus more on bugfixing and polish.

 

[Eginhard 38]

Great job. Though I usually mod "the old way" (manually), it's always nice to see someone refining modding tools. Did you ever think about having a look at Jamie's Map Editor? IMHO it would certainly gain at being made more user-friendly.

 

[Autolykos]

Thanks! My preferred modding tool is also Notepad++, but I've noticed that every time I make a scenario, it starts with an afternoon of copying around the same text files, and typing or copy/pasting in the same stuff over and over. Which is exactly the kind of stupid and repetitive task computers are made for
Jamie's Utility seems to try something different (so yay, I'm not redundant), but it's good to see that editing the map is possible. Sadly, I couldn't find his source code anywhere to figure out the file format. Well, looks like I have to reverse engineer the files myself - but knowing that it can be done provides me with a decent morale boost...

 

[Autolykos]

Finally figured some of the format of the .tbl files out, and added a few additional functions based on that (for placing border forts and infrastructure connections).


What I know so far:

- The .tbl files seem to be binary files containing lots of unsigned(?) integers in little-endian notation.

- adjacent.tbl consists of two blocks: The second block contains triplets of numbers: {Province ID, 0, 0xCDCDCDCD},
while the first block contains array offsets into the second one. So if you want a list of all provinces next to #100, you'd have
to look at offsets[100], offsets[100]+3, offsets[100]+6, ... , offsets[101]-3
I have no idea why the other two numbers are present. The second one seems to be always zero, and the third is
some "magic number" with no apparent purpose (except helping me figure out where the second block starts).

- boundbox.tbl is extremely straightforward. It consists of quadruplets of numbers like {left, top, right, bottom} marking the
points of the province that are furthest out. Except for the first four entries, which are {map width, map height, 0, 0}.

- airdist.tbl seems to consist of unsigned short, and has roughly the right size to store half of the distances - as expected,
since d(a,b)=d(b,a) and d(a,a)=0. But I couldn't figure out the proper sequence yet, and my initial assumption that it
simply stores the lower or upper triangle of the distance matrix in sequence has been proven wrong.
It is also possible that I'm completely on the wrong track here.
Luckily, I can just as well use the coordinates from distances.csv and the haversine formula.

In case you want to use it for your own programs, I've written wrapper classes around these files and put them into "worldmap.hpp" and "worldmap.cpp" in my source code.