L.Tankersley

I think this is an issue for people with non-US keyboards. The key-code I'm using for the plus/minus keys to change the elevation in CMBB is wrong for some key layouts. I have a fix in 1.03 that will hopefully fix this problem.

I only just noticed this thread. The reason every fourth elevation level is skipped is discussed in the documentation. Mapping Missions allows 256 separate elevation values. An elevation change of one level represents a change of 1.25 meters (the minimum contour interval for CMBB). However, MM displays elevation in meters, not levels (this is for the benefit of mapmakers working from actual maps that want to match elevations as closely as possible). MM rounds off fractions when displaying elevations. Hence level 1 = 1.25 meters, displayed "1"; level 2 = 2.5 meters, displayed "2"; level 3 = 3.75 meters, displayed "3"; and level 4 = 5.0 meters, displayed "5". When MM exports elevation, it first looks at the area you are exporting and checks the range of elevations found. It then figures out whether the range will fit in 20 levels at 1.25m contours, then checks 2.5 and finally 5m contours. If it still won't fit (if the elevation range is more than 100 meters) it proportionally compresses elevation differences so they will just fit in 20 5m contours. Thanks for the spell-check, I'll fix that in 1.03. Also in 1.03 are warnings if you try to quit or open a new map without saving, and more options for elevation display (you can customize the font used, for example). I'm chasing a bug I introduced in 1.03 but it should be released this weekend or early next week.

It's been about a month since 1.02 was released, and I have finally had time to make some more improvements. I am waiting on some test feedback on one particular feature; once I have that I will post 1.03 for general consumption. Key features in this update: * fix to allow elevation export for users of non-US-style keyboards. (This is what I'm waiting for feedback on; if you can export terrain properly but all your elevations stay at level 7, send me an email and maybe you can get a sneak peek at the new version in exchange for a test or two.) * elevation raise and lower tools * a line-of-sight tool (doesn't give exactly the same results as in CMBB for a variety of reasons, but might be useful nonetheless. And it was easy, and kinda cool.) * ability for user to specify font to use to display elevations * info line in palette window displays "rollover" information about the tile under the cursor * additional keyboard shortcuts and display options * some bug fixes I've done some initial work on a Mac version but my free time is in limited supply. I'll get there eventually.

Yes, actually, there is. How does this affect height? The area is mostly water and marsh, with some scattered trees and soft ground mixed in. The water and marsh tiles, and some other tiles, stay at elevation 3 no matter what I do. I can adjust the other tiles down to them, but I can't move the wet tiles up. What's the deal? Is this a known issue?

...from the lack of response, I take it no one else has seen this, then.

"Sergeant, get that tank unbogged NOW!" ...Where are my cigarettes?

I have encountered an odd problem with a map created with my Mapping Mission tool, and want to see if anyone has seen a similar problem with old-fashioned, garden-variety manually-constructed maps. The map is built in the CMBB mapping editor just fine. In the 2D map editor view everything looks fine. But when I go to the 3D Preview, there is a section of the map that is dramatically "sunken" creating a sharp cliffedge around it. In the editor, the elevation change is from 10 to 11. But in the preview it looks like a change from 3 to 11. It gets weirder. I save the map as a CM scenario file. Then I reload it. Now in the editor, the elevation of the "sunken" portion of the map is shown as 3. Ok, that makes a certain kind of sense. So I manually modify the elevations in that area to be the proper value of 10 or thereabouts. I go to the preview, and once again there is a big pit in the map. I paint the whole area with elevation 15, and still it is a pit. Has anyone else ever seen this situation where elevation changes you make to a portion of a CMBB map don't seem to "take?"

I put version 1.02 up on the CMMC2 website last night (same location as before). Some bug fixes, new features, and a mode to hopefully improve reliability of exports when running on slow computers or with low screen resolutions. Enjoy!

I'll probably throw 1.02 out there Wednesday night or Thursday. I added keyboard shortcuts for some menu commands and for many of the tools in the palette. Also a "compatibility mode" to slow down the export procedure and make it more reliable (especially with slower computers and lower screen resolutions). As far as the "campaign module" goes -- most of that is possible (actually placing units at particular spots would be _very_ difficult to program), but it's not something I'm likely to tackle CMMC2 has human GMs to do that sort of thing. In future I might add a few features like a LOS checker to help support a human-run campaign.

Quick status update: version 1.02 is being tested now; it fixes a couple of minor bugs and tweaks the elevation swath coloring feature added in 1.01. The significant new feature is that if you hold the control key down while clicking "non-linear" terrain features on the map, it will clear any road, rubble or burning status away (sort of a bulldoze-before-you-place-terrain mode). I probably won't put 1.02 out there for a day or two, to see if any other glitches come to light first. On the Mac front, I have started tinkering to refresh my memory of Mac development. It looks like the APIs I need to do the exporting aren't supported by Carbon, so Mapping Mission won't be Carbon. But since CM doesn't run under X anyway, that shouldn't be a big problem. Timeline is "when it's done" -- I'd like to have something working in a few weeks, but that's probably a best-case estimate.

Heh, I've had to use some of those systems; that's why I've got ideas on how to make them better.

The file format is open, so if someone wants to take a crack at this, they are welcome. There are a LOT of different digital map formats out there, though. I would recommend identifying a useful (and freely distributable) archive of digital data before embarking on such an effort. Note that a raster-scanned format (like ADRG or CADRG) probably won't be much use, since they are typically just scanned images, and the colors are too variable to be able to rely on doing a terrain type translation that way. Vector formats like ITD, DFAD and VPF have more promise (and DTED would be ideal for elevations, assuming you can get coverage of the area you're interested in).

Mapping Mission v1.01 is now available for download at the same location as before (I deleted the old archive and replaced it with the new version). Changes in this version: * Added "Load Grain From Bitmap File" command. * Fixed bug that always set CM editor resolution to 1280x1024 at startup regardless of the preferences file setting * Improved logic for joining linear features like roads and walls. Should be much more intuitive now. * Increased delays during export to CM editor to improve reliability of export. * Added "Color Elevation Swath" feature to color-code a 10m swath of elevations (for map fine-tuning).

Well, as I noted, there are a few bugs still in the software. One to watch out for: the selected CM editor resolution is not properly restored from the prefs file when Mapping Mission starts up. Although the menu looks like the proper resolution is selected, the resolution will actually be set for 1280x1024. Be sure to manually set the resolution before exporting. A new version fixing this problem is forthcoming. Also, I have improved the handling of linear feature (road, wall, etc.) intersections. I think it's more likely to select the proper intersection tile now. I have occasionally been seeing some problems with exporting maps in which most of the terrain exports properly but some of the tiles don't get set. I think this is a timing/event queue issue and am looking in to it. If anyone else is seeing this sort of thing (particularly with larger maps) I'd be interested to hear about it. I will post here when the new version is ready.

It's good to hear the enthusiastic responses; thanks! As Kip says, the primary reason I built the thing was to make it easier to run campaigns on very large maps while keeping the battle maps consistent. In the past, maps were built in CM-sized chunks a few km on a side, and battles tended to be "shifted" in position a little bit so they would fall in one chunk and not straddle two. When this was a problem, someone had to load one of the chunks, shift it, and recreate (by hand) the overlapping part of the other chunk. But I think the tool will also very useful for making maps for single battles. I've dabbled a bit in map making, and it just made me nuts dropping down a single road tile at a time (and having to worry about whether it was a woods-road or a pines-road, and having to clean up all the little road tiles that ended up sprinkled on either side of the road when I tried to paint a diagonal road and my hand wavered). Hopefully other mapmakers will find this useful as well.

This is discussed in the documentation, but it's not really obvious. The base CM elevation level is 1.25m (or a multiple of this: 2.5m or 5m). Mapping Mission uses 1.25m elevation levels internally. But instead of displaying elevation levels, it displays elevations in meters. These are rounded off to integer values. So level 3 = 3.75m, displayed as 3. Level 4 = 5.0m, displayed as 5. In general, you will have 3 of every 4 elevation values (in meters) allowable in Mapping Mission. I went with displaying elevation in meters because for CMMC purposes, we are working from real maps with elevations in meters, and this makes it easier on the mapmakers. It might be worth adding an option to display elevations in levels rather than meters; I'm not sure.

I assume you mean the export to CM; the software generates mouse and key events to simulate a user doing all the clicks and presses necessary to build a map -- just really, really fast (I had to put in a brake because my code would generate events faster than CM could process them and eventually I think I filled the queue -- if other people still see similar issues I may add a user-configurable brake factor to deal with this). Regarding a Mac version, I did a proof-of-concept of the same scheme before I fleshed out the tool and demonstrated to myself that the process would work. No Apple Events/ scripting involved; it's all raw event stuff. (This is why the program needs to know the screen resolution; I have to basically hard-code the pixel coordinates of everything that the program might need to click on, and many of those change with different resolutions.) Not sure what the problem would be here, if the terrain export works. Does everything stay at elevation 7? Do you have a wacky keyboard setup or something? What key do you use to change elevations in the CM editor? Possible, although I doubt I will spend much effort on that myself. The file format is published at the end of the documentation; if someone else wanted to build a random terrain generator using the Mapping Mission format, I would have no problem with that. The first suggestion is already on "the list" -- see the "Planned Future Enhancements" section of the documentation. The second is also planned but it's not on the formal list -- what I have now is good enough for the immediate needs of the CMMC2 project (which already has the map images built). I'll probably add a bit more flexibility to the bitmap import routines, particularly as regards support for other resolutions. (Note that if you have a bitmap of the right resolution, but not the right size, you could create a Mapping Mission map just big enough for the bitmap, import it, and then copy-paste the imported map into a larger work in progress.) Generally, folks, if you have bug reports or suggestions, you should email them to the address given in the documentation. With the volatility of this forum, this thread could easily vanish beneath the waves, and I don't always get here regularly anymore. But thanks for the encouraging feedback!

I feel your pain. But I don't think the port will be too hard; I just need to dust off my Mac programming skills a bit.

[Reposted here because this should be of greater interest to the scenario creation community, and because topics scroll by so durn fast on the main CMBB forum.] I am pleased to announce the release of version 1.0b of Mapping Mission, a third-party CMBB map editor. Features of Mapping Mission include: * exports data to Combat Mission:Barbarossa to Berlin map editor * scrollable windowed interface * support for extremely large maps (thousands of tiles per side) * streamlined user interface including ability to "gesture-click" to orient terrain features and a simple but powerful road tool * copy-paste * support for 256 elevation levels (at 1.25m increments) * open file format to allow other programmers to develop compatible mapping tools * support for importing "terrain mask" bitmaps encoding terrain and elevation (letting map makers "paint" terrain in their paint program of choice and import the results into Mapping Mission) * limited undo function In a nutshell, this is a map editor that builds maps for CMBB, but in a new (open) file format. Naturally, CMBB can't read these files directly. But, Mapping Mission provides an export function that uses the map file as a sort of event script to recreate the map in the CMBB map editor. Mapping Mission cannot open CMBB maps since these are in CMBB's proprietary format. But if map makers build maps using Mapping Mission, they will better be able to reuse and exchange map data (and hopefully map making will be less laborious than before). The impetus for development of Mapping Mission was the Combat Mission Meta Campaign (CMMC), which has recently concluded its first campaign using CMBO as the combat engine and is currently organizing for campaign two (set on the eastern front using CMBB). The campaign will take place over an area more than 30km (1500 CM map tiles) on a side. One of the difficulties encountered in CMMC1 was the amount of time needed to build and modify CM maps. By using Mapping Mission, the entire campaign map can be built before the campaign begins and arbitrary swaths of terrain data can be exported on demand for battle requirements. Currently, Mapping Mission is hosted on the CMMC2 website, www.cmmc2.org . Right now a link to the download (about 90 kbytes zipped) can be found in the site forums, in the "Mapping Mission 1.0 released" topic in the "General CMMC2 Discussion" folder. In the future this download may be hosted at some other location. For now, the link to the appropriate thread is: http://www.cmmc2.org/forums/topic.asp?TOPIC_ID=480 Be warned that, although it seems to be quite stable, the software has not been exhaustively tested. Bugs may still be present. You use the software at your own risk. In particular, users should be sure to read and understand the information about exporting map data to CMBB, as the Mapping Mission software will generate a large number of synthetic events that might cause some consternation on your computer if you are not properly prepared. This version is PC only; I hope to begin work on a Mac version soon. Enjoy!

I am pleased to announce the release of version 1.0b of Mapping Mission, a third-party CMBB map editor. Features of Mapping Mission include: * exports data to Combat Mission:Barbarossa to Berlin map editor * scrollable windowed interface * support for extremely large maps (thousands of tiles per side) * streamlined user interface including ability to "gesture-click" to orient terrain features and a simple but powerful road tool * copy-paste * support for 256 elevation levels (at 1.25m increments) * open file format to allow other programmers to develop compatible mapping tools * support for importing "terrain mask" bitmaps encoding terrain and elevation (letting map makers "paint" terrain in their paint program of choice and import the results into Mapping Mission) * limited undo function In a nutshell, this is a map editor that builds maps for CMBB, but in a new (open) file format. Naturally, CMBB can't read these files directly. But, Mapping Mission provides an export function that uses the map file as a sort of event script to recreate the map in the CMBB map editor. Mapping Mission cannot open CMBB maps since these are in CMBB's proprietary format. But if map makers build maps using Mapping Mission, they will better be able to reuse and exchange map data (and hopefully map making will be less laborious than before). The impetus for development of Mapping Mission was the Combat Mission Meta Campaign (CMMC), which has recently concluded its first campaign using CMBO as the combat engine and is currently organizing for campaign two (set on the eastern front using CMBB). The campaign will take place over an area more than 30km (1500 CM map tiles) on a side. One of the difficulties encountered in CMMC1 was the amount of time needed to build and modify CM maps. By using Mapping Mission, the entire campaign map can be built before the campaign begins and arbitrary swaths of terrain data can be exported on demand for battle requirements. Currently, Mapping Mission is hosted on the CMMC2 website, www.cmmc2.org . Right now a link to the download (about 90 kbytes zipped) can be found in the site forums, in the "Mapping Mission 1.0 released" topic in the "General CMMC2 Discussion" folder. In the future this download may be hosted at some other location. For now, the link to the appropriate thread is: http://www.cmmc2.org/forums/topic.asp?TOPIC_ID=480 Be warned that, although it seems to be quite stable, the software has not been exhaustively tested. Bugs may still be present. You use the software at your own risk. In particular, users should be sure to read and understand the information about exporting map data to CMBB, as the Mapping Mission software will generate a large number of synthetic events that might cause some consternation on your computer if you are not properly prepared. This version is PC only; I hope to begin work on a Mac version soon. Enjoy!

I have a Radeon 8500 Mac Edition. It supports fog. BUT, it does NOT support transparent smoke. Basically, all smoke and dust effects (gun blasts, artillery explosions, smoke from fire, dust from collapsed buildings) is completely opaque (looks like "Fast, Compatible Smoke" is turned on even when it isn't. On the whole, though, I like the card. The smoke is annoying, mainly because if you're in a low camera view the smoke of a gun blast can completely obscure what's going on for several seconds. But the textures are very nice and performance is crisp. I still live in hope that someday ATI will fix the problem (I assume it's driver related) but I'm not holding my breath. FYI, I was using an old Radeon Rage Orion prior to this. It supported transparent smoke just fine; unfortunately it was lacking in texture memory (major downsampling) and framerate was low.

I've read that it refers to the weight of a round shot (iron?) of the appropriate diameter. Probably dates back to the Age of Sail I would guess.

Funny.

It's not Apple's bug - my Rage Orion shows transparent smoke just fine on the same computer, same OS, same ATI driver update. But, it is low on texture memory and framerate sucks. The OEM ATI Rage Pro that came with the machine also shows transparent smoke but is even worse than the Orion framerate-wise. I'm pretty sure someone had a 7500 card that displayed smoke. Anybody with a 9000 series out there?

Obviously video cards affect output quality. I was responding to the quote, "...but if your mainboard is, well low budget, wouldn't that effect [sic] your display quality?" and was trying to point out that the video card is really the only component that will make a difference in the video signal that is sent out the VGA/other port on the back of the computer. It's true that different monitors will affect perceived quality, but these screenshots aren't capturing the data as displayed on the system's monitor; they are capturing the data being sent to the monitor and thus can be used for comparisons on any system (subject to my earlier caveat about different compression artifacts). It's also worth pointing out that this thread was initially started to compare Macintosh video cards. The Mac ATI cards, including the Radeon, do support fog (on the PC they don't). On the other hand, the Mac Radeon drivers apparently don't support transparent smoke (from fires, smoke shells, explosions and gun blasts).