M113 ?

[c3k]

Why does the total map data have to be transmitted every turn for PBEM?

Once the base map data is set, each player's computer has the information. Then only changes need be transmitted back and forth. E.g., terrain deformation type "X" placed at location ABC.

Unless this is already being done?

My lack of knowledge about CMSF coding should be quite obvious at this point.

Thanks,

Ken

[Other Means]

Originally posted by c3k:

Why does the total map data have to be transmitted every turn for PBEM?

Once the base map data is set, each player's computer has the information. Then only changes need be transmitted back and forth. E.g., terrain deformation type "X" placed at location ABC.

Unless this is already being done?

My lack of knowledge about CMSF coding should be quite obvious at this point.

Thanks,

Ken

Good point though.

[Battlefront.com]

c3k,

Why does the total map data have to be transmitted every turn for PBEM?

Once the base map data is set, each player's computer has the information. Then only changes need be transmitted back and forth. E.g., terrain deformation type "X" placed at location ABC.

This is the difference between PBEM and other forms of multi-player. For PBEM each player's computer does not have the basic information because it is not in a persistent state like TCP/IP. In other words, there isn't anything loaded into RAM except what comes in the PBEM file, therefore each PBEM exchange must have *all* the data just like a save game file must.

Getting back to Sgt.Joch's point about the map size "red herring"...

As map size increases then, rationally, so should the amount of forces. Even in modern warfare you wouldn't see a single company moving about in a 10x10k environment all on its own. That's the kind of battlespace a Battalion or larger is supposed to fill, consolidating and concentrating it's forces within that on specific areas of interest or known enemy concentrations.

Therefore, one has to keep in mind that a realistic wargame is a careful balance between:

1. Map size

2. Unit density

3. Combat fidelity

The larger a map becomes the higher the unit density and the lower combat fidelity need to be to keep things in balance. Therefore, it is not only a "red herring" to say that the current CM map size is out of balance with the scale, but it's also an argument for changing the scale of combat to have more units with less tactical fidelity. There's nothing wrong with changing the scale, but it isn't the game CMx1 or CMx2 was ever intended on being. Might as well say CM:SF is unrealistic because you can't simulate divisional considerations.

BTW, as a rule dense terrain requires denser unit concentrations. This means that a particular unit mix may require a 4km map if it is open, but only a 500m map if it is something like dense urban. To say you need to have a 10km city map to simulate a realistic fight over a dozen blocks with a company is complete and utter nonsense.

Steve

[SlapHappy]

I found this link concerning frontages in WWII:

http://www.balagan.org.uk/war/crossfire/history/frontages.htm

I don't know how applicable this chart is to modern-day armies. It kinda makes sense that offensive frontages are more "dense" than defensive ones. I'm also sure that these varied based on unit states and point in time during the war.

The data fails to show how deep these frontages were.....scratch that, it mentions some of the typical depths in the textual portion of the web page.

[ May 27, 2008, 03:59 PM: Message edited by: SlapHappy ]

[Other Means]

Originally posted by Battlefront.com:

c3k,

</font><blockquote>quote:</font><hr />Why does the total map data have to be transmitted every turn for PBEM?

Once the base map data is set, each player's computer has the information. Then only changes need be transmitted back and forth. E.g., terrain deformation type "X" placed at location ABC.

This is the difference between PBEM and other forms of multi-player. For PBEM each player's computer does not have the basic information because it is not in a persistent state like TCP/IP. In other words, there isn't anything loaded into RAM except what comes in the PBEM file, therefore each PBEM exchange must have *all* the data just like a save game file must.

{snip}

Steve </font>

[M1A1TC]

Just use guns from CMSF 1.0 to punch holes in his jar. Then can shoot through concrete walls and berms in game, I am sure they can handle his jar as well

[Chainsaw]

for a swedish tank coy its:

on attack: 1km for one Coy

Defence: 1km for one platoon

so the ones for WWII seems fairly accurate.

[Battlefront.com]

Other Means,

It would seem though that a persistent state was possible, wouldn't it? The first 2 emails having the full data and the rest just having changes?

Yes, in theory this is possible. But it's one of those things that isn't very practical. The primary reason is that every time you go to load a PBEM turn the game would first have to load the "original", then load the turn you selected. Double the load time... anybody up for that?

The other problem is that the game would have to somehow keep that primary file safe and be able to associate it with the incoming turn that the player is trying to load. Otherwise, the game would cease to be playable.

It's simply not worth the effort on our part to do this. I don't think people would find the double load time much fun.

Steve

[Battlefront.com]

SlapHappy,

Nice website find there. Yeah, that seems about right to me. Anybody playing CMx1 will probably agree too.

One can argue for a deeper map for a given force size, but wider tends to require more forces to keep it realistic. Otherwise you get into unrealistic map edge issues. Since CM has always been a simulation of Battalion or less per side, the argument for maps wider than a couple of kilometers is pretty weak from a realism standpoint. From a gamey standpoint, I can completely understand having HUGE maps with plenty of maneuver room.

Steve

[Lurker765]

How would this be double the load time? If the second file is half the size since it doesn't contain the already known map data it would not increase load time significantly. It would have to load information from two files, but if both of them are half the size then you get the same load time.

In addition PBEM file sizes would be half the size for the 100 exchanges after the initial turn. The time saved downloading plus the ability to use normal email accounts rather than dealing with files twice the size seems to be a great payoff.

[Battlefront.com]

Lurker765,

How would this be double the load time?

Good point. However, it would still be significant. Depending on the proportion of map to units/action, it could range from far less than twice the load time to just about the same. I'm also assuming here that there will be some inefficiency in loading new data over old in bulk like that. Not sure about that part though.

In addition PBEM file sizes would be half the size for the 100 exchanges after the initial turn. The time saved downloading plus the ability to use normal email accounts rather than dealing with files twice the size seems to be a great payoff.

For PBEMers, yes, but not for the game as a whole. The coding and testing work necessary to make this viable is not an insignificant investment. Doing something like this, therefore, comes at the expense of something else significant to more players. Because time and resources are limited, and player suggestions are not, we place a higher priority on things which are applicable, and desired by, the most amount of players.

For example, redoing Quick Battles is something that benefits anybody that likes QBs, no matter if that is via solo play, hotseat, TCP/IP, RealTime, WeGo, or PBEM. Therefore, QB redo is ranked as a higher priority. I think our time would be better spent making TCP/IP WeGo than streamlining PBEM. There are work arounds for people with email bandwidth issues, but there are no workarounds for TCP/IP WeGo other than PBEM (which is a poor workaround in their minds).

Workarounds are another thing we keep in mind when selecting what to do and what not to do. A feature that already works, but not optimally, is inherently less important than an equally valuable feature that has yet to be implemented. This is why TCP/IP WeGo has not been implemented yet. But given a choice between adding that and streamlining PBEM file size... I'd go with adding TCP/IP WeGo first.

Again, I'm not saying that we'll never look at this issue, rather I'm being realistic about its chances of happening and honest with you about that assessment.

Steve

[Lurker765]

Thanks for the quick reply.

[c3k]

And we shall call the new, optimized, file protocol the "c3k technique".

I'm glad to offer my services.

Thanks,

Ken

[Pandur]

For PBEM each player's computer does not have the basic information because it is not in a persistent state like TCP/IP. In other words, there isn't anything loaded into RAM except what comes in the PBEM file, therefore each PBEM exchange must have *all* the data just like a save game file must.

would that mean that TCP/ip WEGO has inherently smaler files to transfer, as it stores stuff in RAM persistant!?

As map size increases then, rationally, so should the amount of forces. Even in modern warfare you wouldn't see a single company moving about in a 10x10k environment all on its own. That's the kind of battlespace a Battalion or larger is supposed to fill, consolidating and concentrating it's forces within that on specific areas of interest or known enemy concentrations.

nearly every unit we can "buy" comes with its battalion attached

so instead of deleting the other guys, you take em into battle. that perfectly doable in CMSF allready. you need to have good machine to crunch the data but it works out nice in WEGO.

the players may take the game a bit out of scope, but to play with a reinforced battalion is really fun. and i dont feel the need to...

lower combat fidelity

when playing with such forces. i dont know how you mean that actually. it works nice as is.

but there are no workarounds for TCP/IP WeGo other than PBEM (which is a poor workaround in their minds).

yes, hoooray for TCP/ip WEGO!!!

[Battlefront.com]

Pandur,

would that mean that TCP/ip WEGO has inherently smaler files to transfer, as it stores stuff in RAM persistant!?

It's streaming data, which is inherently faster and more efficient than email. Plus, the data from the previous turn is already loaded, so there is no extra overhead to get the game ready for the next turn. So if the map data is 1mb it is loaded once at the start and the variable sized changes for each turn come in on that. If a turn is small, then perhaps 200k of data is moved from one machine to the other. Even with the "smarter" PBEM system that 1mb map has to be loaded each and every time, but not transfered.

the players may take the game a bit out of scope, but to play with a reinforced battalion is really fun. and i dont feel the need to...

Some people have made division+ sized battles in CMx1. I think they're nuts, but each to his own

The Battalion structure is there for the C2 elements and to make sure people understand what a realistic mix of units is. Wait to you see the size of the Marines Module MEU! When someone really, really wants to put the hurt on an objective, a MEU does the job quite well!

Steve

[Lethaface]

Theatre Of War handles the 'edge' thing pretty good by restricting movement on edges but the visibility of the map doesnt end.

The biggest current maps are just barely playable in RT on my machine so havin much bigger maps wouldnt work for me atleast

I bet most of you didn't play 4x4 as of yet, thats a big map with plenty of maneuver space. For RT having more forces then currently possible would be unmanagable in my opinion.

[Pandur]

@steve

thanks for the info!

@Lethaface

there are allways limits

i limit mysleft to play only wego, that however does not limit my ability to play the game to its fullest

you shouldnt limit yourself to RT, as it limits "your" ability to play the game to its fullest.

[undead reindeer cavalry]

why i don't want to argue about all this with you? because i have already done more than enough. i have no inherent need to point out flaws in CMSF. i actually like your games even if CMSF was a personal disappointment. i have bought several copies of CMx1 games and made other people buy them as well. i consider myself as a fan of BFC. you are free to make the kind of games you want. it's just highly annoying, for a disappointed person, to read quite questionable rationalizations for some design decisions.

like, huh, there is no need for bigger maps because engagement ranges and unit footprint are pretty much the same in modern armored combat in Syrian terrain and in WW2? that's seriously strange talk. it's the kind of talk that is at first just funny, then when you (as a person who'd really have liked a bit different CMSF) realize the consequences for the game it simply pisses you off.

in WW2 the official effective tank engagement range for German tanks was 600-800 meters (800-1000 meters for Tigers and Panthers). in GW1, almost 20 years ago, the effective engagement range was 3000 meters. for AT weapons the increase in effective ranges is even more dramatical. WW2 German field manuals space tanks 50 meters apart. in GW1 tanks were spaced 300 meters apart.

in one of the most studied out modern battles, the 73 Easting, the weather conditions were absolutely awful, visibility ranging from 100 to 1000 meters. no dreams of air support. battle is described as brutal close combat. a single company (troop) footprint has the width of 5000 meters, the footprint for the battalion is 15 000 meters wide. engagement opens at 2000 meters (thermals) with first shot hit probability at 95%.

you can't fit in even a single company, even just for the deployment with zero room for maneuver, not to mention actually having the space required in depth to include the actual battle, in 4x4km map. and a 4x4km map is called HUGE. the aim is said to have a battalion of forces. well, try fit that battalion with 15km wide footprint in a map of 4x4km dimensions.

map size is said to be a data issue, not an eye candy issue. it's a data issue only because of eye candy (rather irrelevant detail for simulating combat at this level). it's also a playability issue because the game is quite unplayable at larger maps -- some gameplay features would be cool here.

map size is just one trade-off amongst many others. for example: tree branches have hit testing so that shells can hit them. yet there is no friendly hit testing so that you would need to have realistic sectors for support arms and maneuver elements. nah, it's irrelevant feature for the game, just fire thru them friendlies. it's vital for the simulation that tree branches have hit testing, tho. right, nuthin wrong with priorities, it's just my "groggy" counterfactual irrational prejudiced nonsense. i just want to hate game, never mind my enthusiastic posts prior release and even supportive posts right after the release.

yes, CMSF can be a fun game. yes, you obviously can create some hihgly realistic battles in it. please just do not deny obvious trade-offs that were made between simulation-wise irrelevant visuals and tactically meaningful features. please do not give highly annoying "rationalizations" for these decisions. just call things as they are.

now, i'll log out and go sulk in the corner. i'm going to launch a game called "M1 Tank Platoon" in Amiga emulator. this game was released in 1989. in it you command a M1 platoon + some support assets (like Apache, AA vehicle or even a M60 platoon). you have a 2D overhead map where you can see the whole battle map, your forces, inspect their status and give them orders. it also shows spotted enemy forces and some basic information about them. then you have the 3D views, either outside the vehicles or at a driver, gunner or commander position. it's quite fun tactical platoon level 3D modern armored combat simulation. its map size is 10x10 km.

[jtcm]

Good post URC.

M1TP: what a great game ! Debussing infantry with Dragons ! Hammerhead TOW-armed tracks ! Hull down positions !

I remember once shooting down a hovering Mi-24 Hind with my Abrams main gun. In a fit of enthusiasm, I also shot down my supporting Apaches.

[cool breeze]

I think the WYSIWYG approach to the unit terrain interactions was hella worth it despite the large amount of data required. If I had to re figure out a highly abstracted system like CMx1 for new spotting technology and new terrain and I still couldn't figure out when my infantry are protected by a crest Id have been really disappointed.

[Battlefront.com]

URC,

Of course there is an argument for longer range engagements. Same can be said for WWII. I know of a situation where an 88 Flak gun picked off Soviet tanks at 5000m. Going for outliers, and 73 Easting was an outlier, has never been a part of our philosophy. The fact is that the actual tactical combat, within the space of an hour, is still well under 2000km on average. But even if it wasn't... I don't think plinking T-72s at 4000km is very interesting. You don't need to maneuver even. Just sit still and whack them.

This has nothing to do with us justifying a technical limitation. It's not and you're insulting our intelligence by saying so. The fact is we feel you're take on what actual combat situations is outside of the scope of a CM battle and therefore not relevant on the whole. CM:SF is a combined arms simulation, not a tank simulator. Therefore, the entire game is weighted towards combined arms.

Now, let's say that you are correct and 4000km limitation is too short. How does that affect the realism of MOUT battle that is for a few blocks of terrain? It doesn't have a bearing on such a battle, does it? Right, it doesn't. So at best you're arguing that far ranging tank battles aren't possible in CM:SF and not that the inherent modeling is a mass market sell out, right?

map size is said to be a data issue, not an eye candy issue. it's a data issue only because of eye candy (rather irrelevant detail for simulating combat at this level).

You're completely and utterly wrong. The big hit is the underlying complexity of the terrain modeling. Tree hits and what not aren't a big deal. The big deal was not having grossly simplistic 20x20m terrain tiling like in CMx1. The greater fidelity of terrain modeling allows for a quantum leap in realism and simulation fidelity. To say it's all eye candy is completely ignorant and once again proves that you're judging the game by the graphics instead of the simulation underneath.

map size is just one trade-off amongst many others. for example: tree branches have hit testing so that shells can hit them. yet there is no friendly hit testing so that you would need to have realistic sectors for support arms and maneuver elements. nah, it's irrelevant feature for the game, just fire thru them friendlies.

Yup, just like CMx1. That's because the AI necessary to prevent such things, as well as the UI to alert players, is just not something we want to mess with. So, if you want to think CM:SF is a "sell out" because it doesn't have something that CMx1 didn't have, then by your own argument CMx1 was a "sell out" too.

it's vital for the simulation that tree branches have hit testing, tho. right, nuthin wrong with priorities, it's just my "groggy" counterfactual irrational prejudiced nonsense.

First thing you've said in weeks that I agree with Indeed, you are completely ignorant about things. A physics check for the LOS/LOF has a bearing on the simulation, but it is also extremely easy to do from a programming standpoint. Friendly fire is a black hole from a development standpoint, therefore we didn't touch that one with a ten foot pole. Probably never will either. So whether we have tree branches enhancing the realism of ballistics or not, the friendly fire issue you mentioned (which is real and we've never denied it) will still be there.

i just want to hate game, never mind my enthusiastic posts prior release and even supportive posts right after the release.

You can't have it both ways. You are making irrational and uninformed arguments and have shown absolutely no interest in taking informed counter arguments into consideration. This has been shown time and time again, so I can't help but feel that you're being irrational. You feel the game is too pretty, therefore the game underneath must have been compromised. Yet you can't seem to make a decent argument to support that. In fact, most of your arguments can apply to CMx1 just as equally, if not more so, than they do to CM:SF. When that's pointed out you dodge it and try another one, which also fails.

yes, CMSF can be a fun game. yes, you obviously can create some hihgly realistic battles in it. please just do not deny obvious trade-offs that were made between simulation-wise irrelevant visuals and tactically meaningful features. please do not give highly annoying "rationalizations" for these decisions. just call things as they are.

I think you should follow your own advice before you give it to others. Overall CM:SF is so much more realistic than CMx1 every could be it should not even be a point for debate at all. Is it perfect? No, and neither was CMx1. I know of nothing in CM:SF that negatively impacts the overall simulation quality, but I do know of a large number of simulation elements that negatively impact mass market appeal. So I say again, if we intended CM:SF to be a "sell out" game as you claim, then we did a completely horrible job at it.

You say you are a fan and a supporter of us. Then for God's sake... stop thinking you know more about CM:SF than we do. You've made bunk arguments to support a flawed (and highly insulting) premise and I've taken the time to show you why. Yet you keep coming back each time without addressing the flaws in your previous posts. In short, you are apparently not at all interested in having a balanced opinion, rather you only wish to preserve the opinion you already have at all costs. That's not very supportive of what we do here.

Steve

[ May 29, 2008, 12:00 PM: Message edited by: Battlefront.com ]

[Thomm]

Originally posted by Battlefront.com:

The fact is that the actual tactical combat, within the space of an hour, is still well under 2000km on average. But even if it wasn't... I don't think plinking T-72s at 4000km is very interesting.

Instant classic post (and factually correct )!

Grab the theatre ballistic missile module, now!

Best regards,

Thomm

[flamingknives]

The thing about '73 Easting is that it was fought in a flat desert.

Being as everyone knows about, who it their right minds is going to engage a technically superior force in the open like that?

[SgtMuhammed]

Read about the sim the Army did about 73 easting and the results of just having the Iraqis in their vehicles and oriented the right way. Way different fight. It was also not that flat. The Iraqi position was essentially a reverse slope defense as the 2ACR had to top a ridge before they could see the defensive line. The Iraqis, however, were so concerned about US air that many of their vehicles were unmanned and the word to prepare for immediate action was appearently never passed down to the line troops.

[Battlefront.com]

As a rule we are pretty leery of "heavily documented" single encounters. They tend to heavily documented because they are abnormal and therefore extremely interesting. By definition that means that they are most likely outliers in some way. That doesn't mean they are irrelevant, but it likely some parts of it are. The trick is to figure out which parts Otherwise people might conclude that one Tiger generally wiped out a company of enemy vehicles simply by reading the 1000 accounts of Whittman's Villers-Bocage experience

73 Easting was a sort of "perfect storm" that has not been equaled in modern times, or arguably ever. The fact that CM:SF can't simulate that engagement in all its glory doesn't bother me at all. I'd be far more concerned if CM:SF wasn't able to adequately simulate one of the hundreds of small unit encounters during OIF. Not as exciting or as well documented, perhaps, but meat and potatoes combat rarely is.

Steve