SchnelleMeyer

@Butschi
A match made in heaven?
 

All those area features were rather simple to do. The mixture is also quite easy to configure, e.g.:
    "broadleaved_forest": {         "tags": [             ["landuse", "forest"],             ["natural", "wood"]         ],         "required_tags": [             ["leaf_type", "broadleaved"]         ],         "cm_types": [             {"menu": "Foliage", "cat1": "Tree A", "cat2": "density 1", "weight": 1},             {"menu": "Foliage", "cat1": "Tree A", "cat2": "density 2", "weight": 2},             {"menu": "Foliage", "cat1": "Tree A", "cat2": "density 3", "weight": 1},             {"menu": "Foliage", "cat1": "Tree B", "cat2": "density 1", "weight": 1},             {"menu": "Foliage", "cat1": "Tree B", "cat2": "density 2", "weight": 2},             {"menu": "Foliage", "cat1": "Tree B", "cat2": "density 3", "weight": 1},             {"menu": "Foliage", "cat1": "Tree C", "cat2": "density 1", "weight": 1},             {"menu": "Foliage", "cat1": "Tree C", "cat2": "density 2", "weight": 2},             {"menu": "Foliage", "cat1": "Tree C", "cat2": "density 3", "weight": 1},             {"menu": "Foliage", "cat1": "Tree D", "cat2": "density 1", "weight": 1},             {"menu": "Foliage", "cat1": "Tree D", "cat2": "density 2", "weight": 2},             {"menu": "Foliage", "cat1": "Tree D", "cat2": "density 3", "weight": 1},             {"menu": "Foliage", "cat1": "Tree F", "cat2": "density 1", "weight": 1},             {"menu": "Foliage", "cat1": "Tree F", "cat2": "density 2", "weight": 2},             {"menu": "Foliage", "cat1": "Tree F", "cat2": "density 3", "weight": 1},             {"menu": "Foliage", "cat1": "Tree G", "cat2": "density 1", "weight": 1},             {"menu": "Foliage", "cat1": "Tree G", "cat2": "density 2", "weight": 2},             {"menu": "Foliage", "cat1": "Tree G", "cat2": "density 3", "weight": 1}         ],         "process": [             "type_random_individual"         ],         "priority": 1     }, The script will randonly choose one of the "cm_types" for each square where the probability is determined by the weight.
They do, but:
Buildings in particular look somewhat sterile without hedges, gardens, etc. Though, of course, there is only so much I extract from a map. Hedges are possible but are often not in OpenStreetMap. So, scenario designer won't be unemployed all of a sudden. 😉 It is easy to add hedges to OSM data, though, it's just drawing a line which is probably faster than doing it in the CM editor. This is also the way to do historical maps or maps from scratch, I think. I'll do a little tutorial on that... at some point. Oh well.
EDIT: Seems like the code block is not displayed correctly. Well, I how the general structure is visible...
 
 

Maybe it's interesting to have the acutal map for this, too. The sharp eyed among you can probably spy lots of things where conversion from OpenStreetMap is not yet working as it should. 😉

Location in OpenStreetMap

I had to keep radio silence for a while to be able to concentrate - my girlfriend noted recently that by now I have coded enough stuff for a decent bachelor thesis at least. Well, I did rewrite parts of the code at least three times and some of the algorithms were intriguingly finicky, at least if you have wood shavings for a brain as I sometimes seem to have. 😄
There is still metric tons of things to do and to tweak. But sometimes I have to remind myself why this is fun, so I had to indulge in some screenshots and I guess it is only fair to share a few (shamelessly cherry-picked, mind you!). 😉





Enjoy!

My program does nothing fancy it only automates clicking. I did a bit of testing and I've come to the conclusion that this is just how the editor works and it seems it isn't really made for contour lines as input.
Just do the following experiment. Draw vertical elevation lines in the editor like illustrated below. You will always have something like an s-curve (some spline I guess) between two parallel lines. If you have three parallel lines you will just have two s-curves and you will always have a plateau in between. If you space out both lines enough the plateau will be less pronounced but it will still be there.

This will look good if you just have one contour line at the bottom of a hill and one at the top. The way the manual describes it, this may be the intended use. But it does not work for (realistic) contour lines.
I only tested it in CMCW. I don't think the different flavours have different behaviours, or do they?

I decided to have a small intermediate release. It is also officially version 1.0.0. 😊
https://github.com/DerButschi/CMAutoEditor/releases/tag/1.0.0
The main change is that I added a tool to convert official German digital elevation models into a CMAutoEditor compatible format. You can find it in the folder data_conversion. It has several command line arguments:
--dgm-dir (required): path to the directory in which you stored the dgm*.xyz.gz files --bounding-box (required): xmin, ymin, xmax, ymax coordinates of the box you want to extract. The coordinates have to be in the coordinate system the data points are stored in (e.g. for NRW EPSG:25832, i.e. UTM zone 32N). There are lots of tools in the internet with which you can convert from latitude/longitude to UTM, e.g. here. --contour (optional): set the distance between contour levels. 5 means you will have a contour line every 5m in elevation. You will get a two output files, one with a value for each square and another one with elevation value only for contour lines. --output-name (optional): a common name for output files. You will get several output files with a name that starts with this string. --water-level-correction (optional): xlow, ylow, xhigh, yhigh Sets the low and high point for water level correction (see below for an explanation). There will be four output files: output-name.csv, output-name_contour.csv, output-name.png (a heat map of the elevation values. units are CM squares.) and output-name_contour.png, which has contour lines of the data you extracted.
The actual data is availble separately for each German federal state, e.g.
North Rhine-Westphalia
Hessen (Fulda, etc. ...)
Brandenburg & Berlin
... I just realized that only the data from North Rhine-Westphalia is in .gz files, the others seem to zipped. I'll make that work in the next update. Oh well.
 
Water level correction:
This is an odd one. While you are all well aware that water usually flows downhill, rivers in CM are actually lakes, i.e. every square belonging to the same water body has the same water level. In reality, this is of course not the case. But on the map I am currently experimenting with, the difference in elevation along the river is roughly 6m. This leads to the river looking fine at one side:
mg]https://i.imgur.com/DNrYDfO.png[/img]
And being in a deep ravine on the other side:

Water level correction is still a bit experimental but it should in principle get rid of this. You provide the lowest point of the river on the map (UTM coordinates) and the highest point and the tool will calculate a calculate a plain and lower the higher side (and all the other terrain accordingly) to the level of the lower side.
Contour Lines:
@Bulletpoint
I added this option because there were concerns about performance and stair-step effects. And of course it takes much less time to only set contour lines. I tested versions and could not observe any difference in performance. And for stair-step effects...
Every point set:

5m contours:

10m

Doesn't look precisely stair-step effect free to me... Am I doing something wrong?
Ah, one final thing: I changed the license under which the code is published. I can't really see how this affects you but I don't want anyone thinking I'm sneaking an evil ninja license in 😉. You can do whatever you want with the code, you can even sell maps you made with it (as long as BF is ok with it, that is). I only speak broken legalese but I thought the new license might be a bit more fitting for community made stuff: the only restriction is, if you modify the code and make something new with it, you have to make it open source just like the original one.
Right, have fun making maps! 🙂
 
.

And since I've already shown you a bit of the map, here's a litter teaser:

No new features, I just like the autumn looks on this map. Btw. this where I grew up. Well, at the base of the hill in the background in the middle. 😉 

So, just to give you a quick update, everything below refers to importing stuff from OpenStreetMap
Wot Is Done Already:
Forests, randomized tree types and densities, tree types configurable, weights for types and densities configurable Bushes as above Grass as above Farmland as above water etc. (basically everything that is just a polygon in OSM can be done in this way) Wot I'm Working On:
roads, Roads, ROADS!!! I became a little obsessed with them. By now I'd like a word with the sadist at Battlefront who decided that doing the road tiles the way they are was a good idea. Most designers don't bother, because it is a royal PITA that you can't just combine most of the tiles, because the widths don't fit (so, you can't go from W<->E to NW<->SE directly, there has to be a tile in between. Not even the official Line Drawing Tool in the editor does it right. Oh well. After rather excessive use of graphs and shortest path finding in there and so on, I found a solution that works. I am just fixing edge cases. And then I will have to destroy it because while correct most people will not like the sometimes resulting wiggly roads instead of just diagonal ones. I guess I'm going insane! 🤪 Once that's done though, railways and streams will be easy to implement and fences and walls should also be relatively straightforward. Wot May Come:
Areas (like forests, grass, etc, see above) with configurable cores/borders, such that you can have forests that are more dense on the inside or have different ground, fields with crops but just plowed ground on the edges (randomly) walled or fenced areas - good for having fences around fields, hedges around residential areas, ... Houses, but only types, I can't do 3D-view Flavour Objects (which you will have to fine tune yourself, no automatic stuff in 3D-view): Bus stops where there are bus stops on the map, power poles, etc.) Well, that escalated quickly from nice little project for a weekend or two...

I'd better make good on my promise to polish and publish the other tool first. 😉
For the reverse direction you'd need decent OCR... the rest should more or less be scrolling around (I can take that from the other tool) and getting the logic correct. Oh well, no promises but if I find the time I'll take a look.

Thank you all! 😊 You should dial down the level of praise a bit, though, because otherwise it will go to my head. 😇
And please, please don't get your expectations up too much, I don't want you to be disappointed. This is not a random map generator. It will use randomneIss to decide which tree or crop or grass and so on it puts into a square. The information that there should be a tree comes from OpenStreetMap.
I keep wondering if they don't have something like this, at least for the professional edition? I have a hard time imagining that the British Army (or whoever is their customer) employs CM scenario designers...

Wow, this is awesomeness, I can't say how many clicks I've suffered making 'random' forest and grassland. I really hope that BF see this and pay you a big wedge to incorporate this into the game editor in the future. In the meantime thanks! 

Yes, correct. In OpenStreetMap a forest is a polygon with some tags that mark it as a forest. CMAutoEditor has currently two options for such cases. It either randomly chooses a tree type and density individually for each square within this polygon or an identical one for all squares. The latter is useful for other farmland, for instance. The tool works in a way that you can configure what should go into an area of a specific type. So, if the map contains different grassland types you can have differently looking areas. For forests there are, e.g. tags that say 'broadleaved', so you could select only specific tree types instead of the general mix.
Ok, let's not derail this thread, here is a little sneak peek (mildly cherry-picked of course but everything generated automatically), I'll make a dedicated thread once the code is good enough to present.

I'd contribute a CMAutoEditor map. There is still some work to be done but currently I'm in the process of integrating OpenStreetMap content. Currently importing forests/bushes (with randomized tree types), farmland (with randomized crop types) and water works quite well. Importing roads/foot paths works... in many cases (converting lines on a map into those road tiles is algorithmically less than trivial and, sorry BFC, the line drawing tool sucks). I am thinking about integrating buildings (would have to be very randomized!) but no promises as that is a tough nut to crack and there's no guarantee that it would look adequate in any way...
Anyway, how about we do this: You suggest any area of, say, max. 3km x 3km, preferrably in Germany because there I know how to get good free terrain models in many cases. Name a Combat Mission Title. I'll do the script foo and provide the map. Someone else would have to make a scenario out of it - learning AI plans and all that would currently be a little too much for my schedule. 😉

I wrote a little python script to set the elevation in the editor according to a digital elevation model. Those come in various resolutions, for instance, in Germany data for the whole of Northrhine Westfalia is available for free with a 1mx1m granularity. I then use PyAutoGui in order to automate setting the correcting height and clicking/scrolling in the editor. The script currently sets the height information for every square in the editor, not just contours.
An example height map:

The resulting terrain in the editor (3328mx1920m):

Vista somewhere in there.

The script is not terribly fast, making this map took about 7h, but it beats doing all the clicking yourself. The limitation, btw., is the editor, the script could go faster. The advantage is that you can do much better micro-terrain, I think, the disadvantage is that you can't just use an old topographical map and draw the contour lines. It would be possible to do contour lines but you'd need to have those in a machine readable format.
Anyway, if people here are interested, I could polish the code a bit and make it available to everyone, e.g. via github. If there is additional interest, I could imagine doing other stuff that way, like, for instance, drawing roads from Open Street Map.

Afghanistan lives on in our hearts. Only realistic scenario for a CMA2 is a CW module, which will only happen if CW and all it's potential modules sell like hot cakes into the far future.

Absolutely awesome work! Thank you for documenting your experiments for all of us to learn. Hope for some images too. 

Had a look in mds files and the same principle applies. See how all the strings are preceded by a byte indicating string length and then a 00 spacer. Then the string follows. Even the bip entries do the same:
bip01 spine is 11 characters long 11 in hexadecimal is 0B.
american_ammo-smg is 17 characters long, which is 11 in hex.

My guess is you could rename these to new model names or whatever and it would be fine as long as you also edit the size of the string in the relevant byte.
I use this technique for a few things, mostly swapping textures. For example in an mdr, I edit spare wheel names on a vehicle like the opel blitz. I rename the spare wheel texture it so it uses a different texture to the main wheels, that way I can have snowy wheels on the ground, but the spare type isn't covered in snow.
In my experience with mdr's there is no checksum. But changing a text string to a different length without telling the game its length has changed will result in a hard crash.

CMSF2 British Green Vehicles mod
For the Sim/Game "Combat Mission: Shock Force 2".
Variants for all British vehicles in Green color.
The color was chosen based on averaging some photo sources and considering
the dust in a dry environment. In hindsight this color matches the stock green
"enforcer" remote weapon station texture exactly.
The common black camo over-spray has not been added in this set.
Included vehicles(10):
 uk-challenger2
 uk-crv-scimitar
 uk-crv-spartan
 uk-crv-sultan
 uk-fv432+bulldog
 uk-jackal
 uk-tum-ht
 uk-tum-st
 uk-warrior
 uk-wmik
+ some better fitting vehicle gear textures
All credits to the Battlefront company for supplying the original textures,
from which these modded ones were derived.
Only for use in the Combat Mission games, other then that, this mod is free and non-profit.
This mod cannot be held responsible for harm done to pixeltruppen.
Copy the extracted files into your mod folder, or into your install folder in the data\z\ subfolder.
The naming of the files contains the mod-tag "mountains". This way they only override
the stock vehicle textures when the terrain is set to "mountains", like in the Quick Battle menu.
----------------
A preview image is in the zip file. So you can check if it is worthy
Download from this place: http://www.gb-homepage.nl (Select "Combat Mission" in left navigation window)

 
 
https://www.imagebam.com/view/ME15X1K

Thanks for the correction and my apologies for the wrong. There are some germanic  words which for me are impossible  to write correctly, one of them is this and another one the name of the mortar carried on the  WW2 german tanks turret.
 
Thanks you for considering the suggestions Steve. You and your team did a great work with F&R, congratulations.

Jumpete: Small correction: Nibelungenwerk or Nibelungenwerke - not Nibelungenwerfer.

You could just read this first ...
Pre-orders for Combat Mission Cold War are now open. - Page 14 - Combat Mission Cold War - Battlefront.com Community

From the Pre-orders are open thread:

Such books are usually the most interesting. Details, details, details.

And right here is one of the issues with this forum.  While there are things that CM does that differentiate them from other games, CM is not alone is making "realistic tactical  and brilliant games".  Off the top of my head, there are the Graviteam games, which have a decent following and beat BFC to Steam by close to a decade.  Steel Beasts have a good following of people who use it as a combined arms simulator/game.
I play a lot of tactical combat games, including the above mentioned, as well as CM.  I own every CM game and module, as well as owning several of them multiple times.  Up until five of six  years ago, I played CM almost exclusively as my ground combat go-to game.   But over those more recent years, I have started playing other games as they have grown and, in many ways, surpassed CM overall. 
There are other very good games out there.  But there are people on this forum who are so heavily vested in CM, they are blind to anything else going on.  They have built their online social life around it.  Their hobby isn't wargaming, its CM.  And they will defend BFC regardless of how things are going.  It has created an insular community with a motto of "BFC or Death".  Forum conversations have become very focused on defending CM or BFC against all comers.  The only issue with that is all comers is becoming no comers.  It seems the majority of the discussion has become either John Kettler-like discussions or The Empower Has No Clothes around issues with CM.
I still come back periodically to see what's going on and hope that CMRT or CMBS module news floats out.  But I find myself being less and less enthused about it.  Reading other wargaming forums, I know I'm not alone.  The regulars here think there is only a small minority of detractors for BFC's performance.  That's because the people on other wargaming and gaming forums, who used to be regulars here,  stopped caring a while ago.

Just found this link with thousands of amazing photos from the war. Most were shot by US trained Mujahideen from 1987 to 1989.
https://archive.org/details/afghanmediaresourcecenter?&amp;sort=-downloads&amp;page=6