Rocket-Man

Thank you for the information.

Yes the default filename when selecting save is incrementing from XXX to XXX+1, but I don't use the default format. I save by turn number and either Start (immediately after replay ends), Mid (interim saves during my phase), End (right before I hit replay), and replay (during the replay). As I said, when I try to save a file with the same name, for instance "Scenario Name 005-Mid", it won't overwrite the existing "Scenario Name 005-Mid". It does default to calling the new file "Scenario Name 005-Mid 001" when I select save but I delete the 001 off the end before I select OK.

When I try to save a game in CMRT with an already existing file name, the program will not overwrite the file. I don't get an error from the program and it seems to work as expected, but the date stamp on the file doesn't change nor do the contents when it's reloaded. I haven't played CMRT in months and have not noticed this behavior before. I checked the folder and file attributes and it's not set to read only. I can save a new save with a new file name, and I can delete the existing file and save a new file with the same name. Anybody else notice this behavior and/or know of a fix?

CM Post Apocalypse? One guy is merging with a tree and the other one apparently has gills.

I don't know what I would do if if I had to go back to using the default UI. Thanks for taking this on.

Thus the need to spend some effort working on the LOS system for game engine 5.

The game UI should never "lie" to the user. Either remove the feature or fix it. It's silly to claim the UI showing one thing while it's actually another is a "feature" and not a "problem". I've been playing CM for almost 20 years. I have experience. Telling people to "play more" to overcome obvious deficiencies in the UI keeps the game as a niche market. You might want the UI to be difficult to understand and use, but the vast majority of people who play games don't. This is a common argument when people make suggestions to improve a game's UI: "It would make the game less realistic". Games by their very nature are unrealistic. You want to make CM more realistic? Remove the LOS feature completely and only show the parts of the map that units can see. Or just show what the Commander can see and make him try to figure out the situation from runners, shouting, and radios (if he has one). That's realism. But who would play a game like that? Even less than currently play CM. If a commercial game is not fun, it's not going to be a success. Improving the LOS feature would go a long way to improving the CM experience for players and make the game more fun, which would translate into more sales.

I would like to see some improvements made to the LOS system. 1. When LOS is measured from a waypoint, show the LOS line from the waypoint and not the unit's location. 2. Allow units to area target buildings if they can clearly see the building even if they don't have LOS to the center of the ground level action space the building is on. 3. LOS should always be reciprocal. If location 1 can be seen from location 2, than location 2 can be seen from location 1. This is not always the case in game. Spotting might be harder from one location to another, but reciprocal visibility (baring some special equipment not available on the battlefield in any CM title) is always there in reality. It might be almost impossible to get a hit on a unit that is firing through a small opening for example, but the location the opening is in can always be targeted. 4. If LOS can be drawn from a waypoint to a location, then a unit that moves to that waypoint should always be able to see that location. It's all too common to check LOS, move a unit to that position and then find out that it can't see the location it could with the LOS tool. 5. I know this problem was present in the early days on CMx2, and the Devs "solved" it by making sure trees didn't move after setup, but I still find it common to check LOS during setup only to find a unit can't actually see those locations when the game starts. 6. Allow LOS to be measured from different observer heights: Prone, kneeling, standing, bow vehicle level, turret vehicle level, couple vehicle level. Or just allow a height to be specified: 0, 0.5, 1, 1.5, 2 meters. 6. Fix the LOS line that shows where the terrain blocks the LOS. It in not consistent in showing the actual location where the LOS is blocked. 7. A pie in the sky suggestion I know won't be implemented: Shade all the locations that can't be seen from a location darker and the ones that can be seen lighter. I know this is computationally expensive, but it would improve speed of gameplay enormously.

I actually have all modules and patches for CMFI.

I've only got the base game of CMFI with patches, but I am willing to play anything you want. First thing you should do before playing PBEM is install CM Helper or Whose Turn is it? and Dropbox (or another cloud service) if you don't already have it. Most players use them when they are playing PBEM to assist with turn transfer, although they are not strictly required. PM me when you are ready to start and I will send you my email address for you to send the first turn to or for you to send me an invite to your Dropbox (or another cloud service) folder.

I have CMBN commonwealth forces, and just the base game of CMFI and CMRT. If interested respond here or PM me.

That is left over from when I modified my translucent tree mod to make the readme for the translucent brush mod. I will update it, but you only need the three included in the mod. I don't know if this mod will work for CMBN as is, but making one for CMBN is on my to-do list.

Glad you like it. It made my gaming experience a lot better so I thought I would share it so that others could enjoy it too.

That's because I deleted this mod because it is for CMFI as the title says. I accidentally loaded into the wrong location in the repository.

This mod is based on a 2m grid for the near tiles, which places a line at every bend location in the terrain making it easy to see where the terrain folds. Each line of the grass textures (grass and grass yellow) is exactly at the bend locations, but some of the other terrain types aren't due to the different sizes of the terrain tiles. For those who think the 2m grid is too busy, I have uploaded a 4m version called Rocket Man-Default Terrain CMFI 4m Gridded Terrain Mod which doubles the grid spacing, but keeps the lines on the bend locations. Try both of them out and see which one you like. I haven't decided which one I like best yet, so I decided to just upload them both and let everyone try them.

I'll update this mod with a few different transparency options when I can get some free time this week.

I posted a grid to the Repository today as well. The base ground files are the grass files (ground grass and ground grass yellow). The breaks in these files lay exactly on the underlying terrain geometry, which appears to be 2m. So I used a 2m nominal grid on all my files, but the actual spacing for all the terrain files are shown below: Terrain File-grid spacing Ground grass - 2m Ground grass yellow - 2m Ground dirt – 1.89m Ground dirt red - 1.89m Ground forest floor - 1.87m Ground light forest floor - 1.87m Ground dense forest floor - 1.87m Ground hard - 1.87m Ground hard red - 1.87m Ground rocky - 1.87m Ground rocky red - 1.87m Ground heavy rocks - 1.87m Ground sand - 1.87m Ground brush - 2m Ground brush hard - 2m Ground brush red - 2m Ground brush hard red - 2m ground mud – 1.87m ground marsh – 1.87m Ground dirt ploughed ew - 2m Ground dirt ploughed ns - 2m Ground ford - 2m Ground rubble - 2m Ground highway - 2m Ground railroad - 2m Ground paved - 2m Ground paved 2 - 2m Ground cliff – 2.13m Ground cobblestone – 1.93m Ground pavement – 1.81m Ground gravel – 2.25m Ground dirt road – 2.25m Ground pavement 2 – 2.22m Ground green crop – 2.56m Ground grain – 2.56m To get the grid lines approximately equal width in game for all the tiles I had to use quite a few different grids, but with the current engine and tile sizes it is impossible to get the same in game grid distances on all the tiles.

This post is to document the ground tile sizes for CMFI. I did a similar post for the tile sizes in CMBN (see http://filefront.battlefront.com/community/showpost.php?p=1387474&postcount=6) and the only thing that has changed between them is that the base grass files (ground grass and ground grass yellow) were changed form 50m tiles to 8m tiles. Some tiles were also added and are shown with an asterisk (*) after their names. The chart below shows the bitmap name followed by it's size in meters squared. Ground grass - 8m Ground grass yellow - 8m Ground dirt - 22.7m Ground dirt red - 22.7m Ground forest floor - 22.4m Ground light forest floor* - 22.4m Ground dense forest floor* - 22.4m Ground hard - 22.4m Ground hard red* - 22.4m Ground rocky - 22.4m Ground rocky red - 22.4m Ground heavy rocks* - 22.4m Ground sand - 22.4m Ground brush - 16m Ground brush hard - 16m Ground brush red* - 16m Ground brush hard red* - 16m ground mud - 11.2m ground marsh - 11.2m Ground dirt ploughed ew - 10m Ground dirt ploughed ns - 10m Ground ford - 8m Ground rubble - 8m Ground highway - 8m Ground railroad - 8m Ground paved - 8m Ground paved 2 - 8m Ground cliff - 6.4m Ground cobblestone - 5.8m Ground pavement - 5.44m Ground gravel - 4.5m Ground dirt road - 4.5m Ground pavement 2 - 4.44m Ground green crop - 3.5m Ground grain - 2.56m These tile sizes in meters are independent of the tile size in pixels. In other words no matter how big or small the bitmap in pixels, the tile will be smeared or compressed to cover the same distance in meters on the 3D map. In contrast to the base ground files above, all the unnumbered mini ground files (e.g. mini ground grass) are 1 meter per pixel when displayed on the 3D map. In other words, if the mini file is 50 pixels square, it will be 50m square on the 3D map. I haven't been able to figure out exactly what the numbered mini ground files do (e.g. mini ground grass 1, mini ground grass 2, etc.) but I think they are used in the far view to blend two unnumbered mini ground files together. I don't know for sure what their size is at this point either, but I think it they are also 1m/pixel. The base grid for terrain deformations seems to be 2 meters. In other words, each bend in the terrain is exactly 2 meters to the closest possible adjacent perpendicular bend in the terrain. The logic for the bends seems to be the same as in CMx1 (and CMBN), which is four possible bend directions per 2m square square (2 corner to corner, 1 middle top to bottom and one middle side to side - imagine a square with four lines drawn through it all crossing in the middle of the square). I have made a grid for the terrain files based on this information which I will post shortly.

Yea, there isn't a way to get it perfect for everybody in every circumstance, but I'm glad you like it overall.

It's available now at CMMODS if you want to get it there.

Sorry, I just uploaded it. It probably won't be available for download until Monday morning when Battlefront gets a chance to approve it.

Two edits to the above information. 1) Rubble tiles are spread over the footprint of a building and therefore don't have a standard size. 2) Ford tiles have a size of 8m, not 4m.

After extensive testing, I have determined the size of all the tiles in CMBN (i.e. how much ground each bitmap file covers). The chart below shows the bitmap name followed by it's size in meters squared. As you can see, there is a lot a variability. Ground grass - 50m Ground grass yellow - 50m Ground dirt - 22.7m Ground dirt red - 22.7m Ground forest floor - 22.4m Ground hard - 22.4m Ground rocky - 22.4m Ground rocky red - 22.4m Ground sand - 22.4m Ground brush - 16m Ground brush hard - 16m ground mud - 11.2m ground marsh - 11.2m Ground dirt ploughed ew - 10m Ground dirt ploughed ns - 10m Ground rubble - 8m Ground highway - 8m Ground railroad - 8m Ground paved - 8m Ground paved 2 - 8m Ground cliff - 6.4m Ground cobblestone - 5.8m Ground pavement - 5.44m Ground gravel - 4.5m Ground dirt road - 4.5m Ground pavement 2 - 4.44m Ground ford - 4m Ground green crop - 3.5m Ground grain - 2.56m These tile sizes in meters are independent of the tile size in pixels. In other words no matter how big or small the bitmap in pixels, the tile will be smeared or compressed to cover the same distance in meters on the 3D map. In contrast to the base ground files above, all the unnumbered mini ground files (e.g. mini ground grass) are 1 meter per pixel when displayed on the 3D map. In other words, if the mini file is 50 pixels square, it will be 50m square on the 3D map. I haven't been able to figure out exactly what the numbered mini ground files do (e.g. mini ground grass 1, mini ground grass 2, etc.) but I think they are used in the far view to blend two unnumbered mini ground files together. I don't know for sure what their size is at this point either, but I think it they are also 1m/pixel. The base grid for terrain deformations seems to be 2 meters. In other words, each bend in the terrain is exactly 2 meters to the closest possible adjacent perpendicular bend in the terrain. The logic for the bends seems to be the same as in CMx1, which is four possible bend directions per 2m square square (2 corner to corner, 1 middle top to bottom and one middle side to side - imagine a square with four lines drawn through it all crossing in the middle of the square). I have made a grid based on this information which I will be posting sometime in the future.

Looking for an opponent for either CMBN or CMFI. I haven't played a CMx2 game HtH yet, but have played many CMX1 games over the years, although not in a while. If you're interested, either reply to this thread or send me a PM.

The near and far trees already have different transparencies, with the far trees less transparent than the near ones. I made the trees pretty transparent because I thought Ramblers CBMN mod was not transparent enough. With my mod, you can see through multiple trees, but with his, after a few you can't see through them anymore. Have you tried Ramblers CMBN Translucent Tree mod for compariosn?